k8s集群apiserver漏洞修复

1.漏洞情况

2.漏洞说明

• .SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)
  通俗解释：这通常被称为 Sweet32​ 漏洞。意思是目标服务器（端口 6443）在建立加密连接时，还在支持一种叫做 3DES的老旧加密算法。
  潜在风险：3DES的加密强度较弱，攻击者如果能截获大量的加密网络流量，就有可能利用数学规律“碰撞”出密码，从而解密出传输的敏感信息（如登录 Cookie、身份令牌等）。
• 目标主机支持 RSA 密钥交换
  通俗解释：在 TLS 握手阶段，服务器允许使用 RSA 算法来协商加密密钥。
  潜在风险：这种传统的密钥交换方式最大的缺陷是不支持“前向保密”。也就是说，如果攻击者某一天窃取到了服务器的私钥，他就能用这个私钥解密过去所有时间段内记录下来的加密流量。此外，RSA 密钥交换历史上也曾存在容易被暴力破解的漏洞（如 ROBOT 攻击）。

3.漏洞修复

• 在 3 个 Master 的高可用（HA）架构中，修复 6443 端口（kube-apiserver）的逻辑依然是修改静态 Pod 的 YAML 文件。但为了保证业务零停机、零感知，操作原则必须遵循四个字：滚动更新（Rolling Update）。
• 因为 3 个 Master 前面通常会有负载均衡器（比如 HAProxy、Keepalived 或云厂商的 SLB），当你重启其中一台的 apiserver 时，流量会自动平滑地打到另外两台上。所以，绝对不能同时修改多台节点，必须改完一台，确认彻底恢复后，再动下一台。

3.1 确认高可用集群状态

# 在任意一台机器上执行以下命令，确保 3 台 apiserver 当前都在健康工作
kubectl get endpoints kubernetes -n default

3.2 逐个节点修复漏洞

• master1节点

#1 备份
cp /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml.bak

#2 修改配置
vi /etc/kubernetes/manifests/kube-apiserver.yaml
## 在 spec.containers.command 列表中，添加强加密套件白名单
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

# 3 保存并等待自动重启
保存退出（:wq）。由于是高可用集群，此时即使 master1 的 apiserver 短暂下线，你敲 kubectl 命令也不会卡死，因为流量去到了 master2 和 master3。

# 4 【关键】验证 master1 满血复活
等待约 30 秒，执行以下命令，确保 master1 的 apiserver 已经成功带上新参数启动，并且重新加入了 endpoints 列表：
## 查看 master1 的 apiserver 容器是否变为 Running 且 READY 是 1/1
kubectl get pods -n kube-system -l component=kube-apiserver -o wide | grep master1

## 再次确认 endpoints 里面包含 3 个 IP
kubectl get endpoints kubernetes -n default

• master2节点

# 操作步骤同 master1

# 铁律：只有在第一阶段的第 5 步验证完全通过，证明 master1 已经正常提供服务后，才能开始处理 master2

• master3节点

# 操作步骤同 master 1

# 铁律：同样，必须在 master2 彻底恢复后，再操作 master3

 

一定记住，逐个击破！！！