K8S主机漏洞扫描时检测到kube-服务目标SSL证书已过期漏洞的一种永久性修复方法
1、背景
PaaS平台102xx、102xx端口检测到目标SSL证书已过期漏洞，分别对应kube-controller-manager证书、kube-scheduler证书。
2、系统版本
1.0、2.0版本均涉及。
k8s 1.19、1.23版本均涉及。
3、故障现象
PaaS平台部署1年以后，在主机漏洞扫描时，会收到：102xx、102xx端口检测到目标SSL证书已过期漏洞，需要运维工程师执行漏洞修复操作。
4、故障分析
PaaS平台部署后，k8s kube-contoller-manager、kube-scheduler证书自动生成，保存内存之中，有效期为1年，无法手工更新。
前期，各项目组解决此问题的方法是申请时间窗口，每年一次做服务维护性重启，重启后证书重新生成，有效期仍为1年。上述方法不仅耗费人力，在重启过程中，PaaS平台抖动可能给业务系统造成一些不必要的负面影响。
5、解决办法
5.1、kube-*服务证书参数
kube-controller-manager、kube-scheduler服务，均支持如下参数：
--client-ca-file CA证书文件
--tls-cert-file 向本服务提供的证书文件
--tls-private-key-file 向本服务提供的密钥文件
在上述3个服务配置文件中，提供上述3个参数，即可让服务从指定文件读取相应的证书与密钥，可以把tls-cert-file所指向的证书有效期调整为100年，从而防止证书过期问题发生。
5.2、kube-*服务证书生成与分发
需要说明的是： kube-controller-manager、kube-scheduler证书/密钥，只要是任何有效的证书/密钥即可，不需要任何特殊配置。现提供一种在ansible节点上，证书/密钥的生成方式：
create-cert() {
SERVICE=$1
DIR=$2
cd $DIR
openssl genrsa -out $SERVICE.key 2048
openssl req -new -key $SERVICE.key -subj '/CN=kube-$SERVICE/C=CN/ST=BeiJing/L=BeiJing/OU=CMCC/O=PJPAAS' -out $SERVICE.csr -config master_ssl.cnf
openssl x509 -req -in $SERVICE.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $SERVICE.crt -days 36500 -extensions v3_req -extfile master_ssl.cnf
}
create-cert kube-controller-manager /opt/xxg-auto-kz/kubernetes_ssl
create-cert kube-scheduler /opt/xxg-auto-kz/kubernetes_ssl
ansible node -i /deploy/hosts -m copy -a "src=kube-controller-manager.key dest=/etc/kubernetes/ssl"
ansible node -i /deploy/hosts -m copy -a "src=kube-controller-manager.crt dest=/etc/kubernetes/ssl"
ansible node -i /deploy/hosts -m copy -a "src=kube-scheduler.key dest=/etc/kubernetes/ssl"
ansible node -i /deploy/hosts -m copy -a "src=kube-scheduler.crt dest=/etc/kubernetes/ssl"
5.3、修改配置并重启kube-*服务
5.3.1、重启kube-controller-manager服务
在master节点上执行：
grep client-ca-file /etc/kubernetes/controller-manager || {
sed -i '/root-ca-file/a\--tls-private-key-file=/etc/kubernetes/ssl/kube-controller-manager.key \\' /etc/kubernetes/controller-manager
sed -i '/root-ca-file/a\--tls-cert-file=/etc/kubernetes/ssl/kube-controller-manager.crt \\' /etc/kubernetes/controller-manager
sed -i '/root-ca-file/a\--client-ca-file=/etc/kubernetes/ssl/ca.crt \\' /etc/kubernetes/controller-manager
systemctl restart kube-controller-manager
systemctl status kube-controller-manager | grep Active:
sleep 1
curl -kvs https://localhost:102xx 2>&1 | grep -A 6 "Server certificate:" | grep "expire date:"
}
5.3.2、重启kube-scheduler服务
在master节点上执行：
grep client-ca-file /etc/kubernetes/scheduler || {
sed -i '/KUBE_SCHEDULER_ARGS/a\--tls-private-key-file=/etc/kubernetes/ssl/kube-scheduler.key \\' /etc/kubernetes/scheduler
sed -i '/KUBE_SCHEDULER_ARGS/a\--tls-cert-file=/etc/kubernetes/ssl/kube-scheduler.crt \\' /etc/kubernetes/scheduler
sed -i '/KUBE_SCHEDULER_ARGS/a\--client-ca-file=/etc/kubernetes/ssl/ca.crt \\' /etc/kubernetes/scheduler
systemctl restart kube-scheduler
systemctl status kube-scheduler | grep Active:
sleep 1
curl -kvs https://localhost:102xx 2>&1 | grep -A 6 "Server certificate:" | grep "expire date:"
}
6、总结与建议
6.1、总结
PaaS平台1.0、2.0部署完成后，kube-*服务证书为1年，因此，在租户系统上线时（一般不超过几个月），当时的主机漏洞扫描并不能扫出kube-*服务证书过期。租户系统上线1年以后，此问题才逐渐暴露。本文给出非临时解决方案（并非最优方案），对kube-*服务证书过期问题进行修复。
6.2、建议
研发对上述方案进行验证（或提供更优方案），集成证书生成操作至一体化平台部署脚本中，在平台部署时，直接解决证书过期隐患。