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、建议

研发对上述方案进行验证（或提供更优方案），集成证书生成操作至一体化平台部署脚本中，在平台部署时，直接解决证书过期隐患。