k8s漏洞修复2（apiserver 6443）

1.漏洞信息

2.漏洞说明

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

3.漏洞修复

3.1 查看漏洞修复前的安全认证

# 测试 1：拿中危的纯静态 RSA 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:6443 -cipher "AES256-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

# 测试 2：拿高危的 3DES 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:6443 -cipher "DES-CBC3-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

• 修复前测试

3.2 备份（

• 一定要备份到其他目录，否则kubelet还会读取，导致配置不生效！！！

# 创建备份目录
mkdir -p /root/manifests_backup/
# 备份
cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/manifests_backup/kube-apiserver.yaml.bak

3.3 添加安全证书

• 添加的时候一定要注意缩进

# 打开 apiserver 的静态 Pod 配置文件
vi /etc/kubernetes/manifests/kube-apiserver.yaml

# 向下滚动，找到 spec.containers.command 列表。在现有的参数（比如 --advertise-address 之类的）下方，新增一行我们昨天用过的那串强加密套件白名单：
- --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.4 保存并退出文件 :wq

• 此时不需要输入任何命令，静待apiserver重启完成，也可以通过命令观察

3.5 通过kubelet观察apiserver的变化

# 观察apiserver pod的启动状态
watch -n 2 kubectl get pods -n kube-system -l component=kube-apiserver

# Kubelet 是负责监控 /etc/kubernetes/manifests/ 目录的幕后推手。你可以直接看它的日志，看它是怎么发现文件改变并采取行动的
journalctl -u kubelet -f

3.6 漏洞修复验证

# 测试 1：拿中危的纯静态 RSA 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:6443 -cipher "AES256-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

# 测试 2：拿高危的 3DES 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:6443 -cipher "DES-CBC3-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

• 修复后测试

4.检查csi-nfs-controller

• 因为我使用了csi-nfs动态存储，修复apiserver时，apiserver会重启，csi-nfs会重连apiserver，这个时候csi-nfs会有波动，记得检查动态存储，别影响数据和pods挂载

4.1 检查 Pod 实时状态与重启计数

• 先看它有没有因为连不上大脑而处于崩溃或频繁重启状态

# 观察重点：看看 READY 是不是 5/5？STATUS 是不是 Running？RESTARTS（重启次数）有没有在疯狂往上涨？
kubectl get pods -n kube-system -l app=csi-nfs-controller -o wide

4.2 调取 Pod 的日志（最核心命令）

• 如果发现它重启了，这个命令能看到它上一次死掉之前吐出的真实报错日志（也就是咱们之前抓到 context deadline exceeded 超时的关键地方）：

kubectl logs -n kube-system $(kubectl get pods -n kube-system -l app=csi-nfs-controller -o jsonpath='{.items[0].metadata.name}') -c csi-provisioner --previous

 4.3 查看最近的 K8s 调度事件 (Events)

• 看看 Kubernetes 官方给这个 Pod 下达了什么警告（比如探针失败、拉取失败等）：

kubectl get events -n kube-system --field-selector involvedObject.name=$(kubectl get pods -n kube-system -l app=csi-nfs-controller -o jsonpath='{.items[0].metadata.name}') --sort-by='.metadata.creationTimestamp'

4.4 检查底层系统日志 (Kubelet)

• 系统底层，看看 Kubelet 有没有CSI 存储挂载失败

journalctl -u kubelet --no-pager -n 1000 | grep -iE "nfs|csi"

5.此次遇到的坑

• 在kubernetes默认配置文件目录进行备份，备份后，在原文件上修改不生效（重启kubelet、删除pod都不生效），切记，文件备份一定要备份到其他目录