草庐IT

修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南

KubeSphere 云原生 2023-06-03 原文

作者：老 Z，中电信数智科技有限公司山东分公司运维架构师，云原生爱好者，目前专注于云原生运维，云原生领域技术栈涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。

前言

测试服务器配置

主机名IPCPU内存系统盘数据盘用途
zdeops-master192.168.9.92440200Ansible 运维控制节点
ks-k8s-master-0192.168.9.9141640200+200KubeSphere/k8s-master/k8s-worker
ks-k8s-master-1192.168.9.9241640200+200KubeSphere/k8s-master/k8s-worker
ks-k8s-master-2192.168.9.9341640200+200KubeSphere/k8s-master/k8s-worker
storage-node-0192.168.9.952840200+200ElasticSearch/GlusterFS
storage-node-0192.168.9.962840200+200ElasticSearch/GlusterFS
storage-node-0192.168.9.972840200+200ElasticSearch/GlusterFS
harbor192.168.9.892840200Harbor
合计822843202800

测试环境涉及软件版本信息

  • 操作系统：CentOS-7.9-x86_64
  • Ansible：2.8.20
  • KubeSphere：3.3.0
  • Kubernetes：v1.24.1
  • GlusterFS：9.5.1
  • ElasticSearch：7.17.5
  • Harbor：2.5.1

简介

生产环境 KubeSphere 3.3.0 部署的 Kubernetes 集群在安全评估的时候发现安全漏洞，其中一项漏洞提示 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)。

本文详细描述了漏洞产生原因、漏洞修复方案、漏洞修复的操作流程以及注意事项。

漏洞信息及修复方案

漏洞详细信息

漏洞报告中涉及漏洞 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183) 的具体信息如下：

漏洞分析

  1. 分析漏洞报告信息，我们发现漏洞涉及以下端口和服务：
端口号服务
2379/2380Etcd
6443kube-apiserver
10250kubelet
10257kube-controller
10259kube-scheduler
  1. 在漏洞节点 (任意 Master 节点) 查看、确认端口号对应的服务：
# ETCD
[root@ks-k8s-master-0 ~]# ss -ntlup | grep Etcd | grep -v "127.0.0.1"
tcp    LISTEN     0      128    192.168.9.91:2379                  *:*                   users:(("Etcd",pid=1341,fd=7))
tcp    LISTEN     0      128    192.168.9.91:2380                  *:*                   users:(("Etcd",pid=1341,fd=5))

# kube-apiserver
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 6443
tcp    LISTEN     0      128    [::]:6443               [::]:*                   users:(("kube-apiserver",pid=1743,fd=7))

# kubelet
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10250
tcp    LISTEN     0      128    [::]:10250              [::]:*                   users:(("kubelet",pid=1430,fd=24))

# kube-controller
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10257
tcp    LISTEN     0      128    [::]:10257              [::]:*                   users:(("kube-controller",pid=19623,fd=7))

# kube-scheduler
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10259
tcp    LISTEN     0      128    [::]:10259              [::]:*                   users:(("kube-scheduler",pid=1727,fd=7))
  1. 漏洞原因：

相关服务配置文件里使用了 IDEA、DES 和 3DES 等算法。

  1. 利用测试工具验证漏洞：

可以使用 Nmap 或是 openssl 进行验证，本文重点介绍 Nmap 的验证方式。

注意：openssl 的方式输出太多且不好直观判断，有兴趣的可以参考命令 openssl s_client -connect 192.168.9.91:10257 -cipher "DES:3DES"。

在任意节点安装测试工具 Nmap ，并执行测试命令。

错误的姿势，仅用于说明选择 Nmap 版本很重要，实际操作中不要执行。

# 用 CentOS 默认源安装 nmap
yum install nmap

# 执行针对 2379 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 结果输出如下
Starting Nmap 6.40 ( http://nmap.org ) at 2023-02-13 14:14 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).
PORT     STATE SERVICE
2379/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds

注意： 分析输出的结果发现并没有任何警告信息。原因是 Nmap 版本过低，需要 7.x 以上才可以。

正确的姿势，实际执行的操作：

# 从 Nmap 官网，下载安装新版软件包
rpm -Uvh https://nmap.org/dist/nmap-7.93-1.x86_64.rpm

# 执行针对 2379 端口的 ssl-enum-ciphers 检测
# nmap -sV --script ssl-enum-ciphers -p 2379 192.168.9.91 (该命令输出更为详细也更加耗时，为节省篇幅使用下面简单输出的模式)
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).

PORT     STATE SERVICE
2379/tcp open  Etcd-client
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

# 执行针对 2380 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).

PORT     STATE SERVICE
2380/tcp open  Etcd-server
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

# 执行针对 6443 端口的 ssl-enum-ciphers 检测（10250/10257/10259 端口扫描结果相同）
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:29 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).

PORT     STATE SERVICE
6443/tcp open  sun-sr-https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

注意： 扫描结果中重点关注 warnings，64-bit block cipher 3DES vulnerable to SWEET32 attack。

漏洞修复方案

漏洞扫描报告中提到的修复方案并不适用于 Etcd、Kubernetes 相关服务。

针对于 Etcd、Kubernetes 等服务有效的修复手段是修改服务配置文件，禁用 3DES 相关的加密配置。

Cipher Suites 配置参数的选择，可以参考 ETCD 官方文档或是 IBM 私有云文档，网上搜到的很多配置都是参考的 IBM 的文档，想省事的可以拿来即用。

对于配置参数的最终选择，我采用了最笨的方法，即把扫描结果列出的 Cipher 值拼接起来。由于不清楚影响范围，所以保守的采用了在原有配置基础上删除 3DES 相关的配置。

下面的内容整理了 Cipher Suites 配置参数的可参考配置。

  1. 原始扫描结果中的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
  1. 原始扫描结果去掉 3DES 的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384

使用该方案时必须严格按照以下顺序配置，我在测试时发现顺序不一致会导致 Etcd 服务反复重启。

ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

虽然 CIPHER 配置一样，但是在使用下面的顺序时，Etcd 服务反复重启，我排查了好久也没确定根因。也可能是我写的有问题，但是比对多次也没发现异常，只能暂时是认为是顺序造成的。

ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384

注意： 只有 Etcd 服务受到顺序的影响，kube 相关组件顺序不同也没发现异常。

  1. IBM 相关文档中的 Cipher Suites 配置：

网上搜到的参考文档使用率最高的配置。实际测试也确实好用，服务都能正常启动，没有发现 Etcd 不断重启的现象。如果没有特殊需求，可以采用该方案，毕竟选择越少出安全漏洞的几率也越小。

- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

漏洞修复

建议使用以下顺序修复漏洞：

  • Etcd
  • kube-apiserver
  • kube-controller
  • kube-scheduler
  • kubelet

上面的操作流程中，重点是将 Etcd 的修复重启放在最前面执行。因为 kube 等组件的运行依赖于 Etcd，我在验证时最后升级的 Etcd，当 Etcd 启动失败后（反复重启），其他服务由于无法连接 Etcd，造成服务异常停止。所以先确保 Etcd 运行正常再去修复其他组件。

本文所有操作仅演示了一个节点的操作方法，多节点存在漏洞时请按组件依次执行，先修复完成一个组件，确认无误后再去修复另一个组件。

以下操作是我实战验证过的经验，仅供参考，生产环境请一定要充分验证、测试后再执行！

修复 Etcd

  1. 编辑 Etcd 配置文件 /etc/Etcd.env：

KubeSpere 3.3.0 采用二进制的方式部署的 Etcd，相关配置文件包含 /etc/systemd/system/Etcd.service 和 /etc/Etcd.env，参数配置保存在 /etc/Etcd.env。

# 在文件最后增加配置(用 cat 命令自动配置)
cat >> /etc/Etcd.env << "EOF"

# TLS CIPHER SUITES settings
ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
EOF
  1. 重启 Etcd 服务：
# 重启服务
systemctl restart Etcd

# 验证服务已启动
ss -ntlup | grep Etcd

# 正确的结果如下
tcp    LISTEN     129    128    192.168.9.91:2379                  *:*                   users:(("Etcd",pid=40160,fd=7))
tcp    LISTEN     0      128    127.0.0.1:2379                  *:*                   users:(("Etcd",pid=40160,fd=6))
tcp    LISTEN     0      128    192.168.9.91:2380                  *:*                   users:(("Etcd",pid=40160,fd=5))

# 持续观测 确保服务没有反复重启
watch -n 1 -d 'ss -ntlup | grep Etcd'

注意： 如果是多节点模式，一定要所有节点都修改完配置文件，然后，所有节点同时重启 Etcd 服务。重启过程中会造成 Etcd 服务中断，生产环境谨慎操作。

  1. 验证漏洞是否修复：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 17:48 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).

PORT     STATE SERVICE
2379/tcp open  Etcd-client
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

# 为了节省篇幅，2380 端口扫描完整输出结果略,实际结果与 2379 端口一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91 | grep SWEET32

修复 kube-apiserver

  1. 编辑 kube-apiserver 配置文件 /etc/kubernetes/manifests/kube-apiserver.yaml：
# 新增配置(在原文件 47 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
46     - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
47     - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
48     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_        256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-apiserver：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 09:22 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).

PORT     STATE SERVICE
6443/tcp open  sun-sr-https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kube-controller

  1. 编辑 kube-controller 配置文件 /etc/kubernetes/manifests/kube-controller-manager.yaml：
# 新增配置(在原文件 33 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
33     - --use-service-account-credentials=true
34     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_        256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-controller：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91 | grep SWEET32

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kube-scheduler

  1. 编辑 kube-scheduler 配置文件 /etc/kubernetes/manifests/kube-scheduler.yaml：
# 新增配置(在原文件 19 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
19     - --leader-elect=true
20     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_  256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-scheduler：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91 | grep SWEET32

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kubelet

  1. 编辑 kubelet 配置文件 /var/lib/kubelet/config.yaml：
# 在配置文件最后添加
tlsCipherSuites: [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_  256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]

提示： 更多的 cipher suites 配置，请参考 Kubernetes 官方文档。

  1. 重启 kubelet：
systemctl restart kubelet

重启有风险，操作需谨慎！

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91 | grep SWEET32

注意： 对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

常见问题

Etcd 启动失败

报错信息：

Feb 13 16:17:41 ks-k8s-master-0 Etcd: Etcd Version: 3.4.13
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Git SHA: ae9734ed2
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go Version: go1.12.17
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go OS/Arch: linux/amd64
Feb 13 16:17:41 ks-k8s-master-0 Etcd: setting maximum number of CPUs to 4, total number of available CPUs is 4
Feb 13 16:17:41 ks-k8s-master-0 Etcd: the server is already initialized as member before, starting as Etcd member...
Feb 13 16:17:41 ks-k8s-master-0 Etcd: unexpected TLS cipher suite "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:17:42 ks-k8s-master-0 systemd: Failed to start Etcd.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service failed.

解决方案：

删除配置文件中的 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 字段，至于原因没有深入研究。

Etcd 服务不断重启

报错信息 (省略掉了一部分)：

修改配置文件后，重新启动 Etcd，启动的时候命令执行没有报错。但是，启动后查看 status 有异常，且 /var/log/messages 中有如下信息

Feb 13 16:25:55 ks-k8s-master-0 systemd: Etcd.service holdoff time over, scheduling restart.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Stopped Etcd.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Starting Etcd...
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=https://192.168.9.91:2379
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_AUTO_COMPACTION_RETENTION=8
.....（省略）

Feb 13 16:25:58 ks-k8s-master-0 systemd: Started Etcd.
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 192.168.9.91:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 127.0.0.1:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: accept tcp 127.0.0.1:2379: use of closed network connection
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:25:58 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service failed.

解决方案：

在实际测试中遇到了两种场景都产生了类似上面的报错信息：

第一种，在多节点 Etcd 环境中，需要先修改所有节点的 Etcd 配置文件，然后，同时重启所有节点的 Etcd 服务。

第二种，Etc Cipher 参数顺序问题，不断尝试确认了最终顺序后（具体配置参考正文），反复重启的问题没有再现。

本文由博客一文多发平台 OpenWrite 发布！

指南2016TLS_ECDHE_RSA_WITH_AESWITHTLSk8s容器平台kubesphere云计算

有关修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南的更多相关文章

  1. Tomcat AJP 文件包含漏洞（CVE-2020-1938） - 2

    目录1．漏洞简介2、AJP13协议介绍Tomcat主要有两大功能：3．Tomcat远程文件包含漏洞分析4．漏洞复现 5、漏洞分析6．RCE实现的原理1．漏洞简介2020年2月20日，公开CNVD的漏洞公告中发现ApacheTomcat文件包含漏洞（CVE-2020-1938）。ApacheTomcat是Apache开源组织开发的用于处理HTTP服务的项目。ApacheTomcat服务器中被发现存在文件包含漏洞，攻击者可利用该漏洞读取或包含Tomcat上所有webapp目录下的任意文件。该漏洞是一个单独的文件包含漏洞，依赖于Tomcat的AJP（定向包协议）。AJP自身存在一定缺陷，导致存在可控

  2. Ruby 和指南针路径与 yeoman 项目 - 2

    我安装了ruby​​、yeoman，当我运行我的项目时，出现了这个错误:Warning:Running"compass:dist"(compass)taskWarning:YouneedtohaveRubyandCompassinstalledthistasktowork.Moreinfo:https://github.com/gruUse--forcetocontinue.Use--forcetocontinue.我有进入可变session目标的路径，但它不起作用。谁能帮帮我？ 最佳答案 我必须运行这个:geminstallcom

  3. Simulink方法总结和避坑指南（一）——Simulink入门与基本调试方法 - 2

    文章目录一、项目场景二、基本模块原理与调试方法分析——信源部分：三、信号处理部分和显示部分：四、基本的通信链路搭建：四、特殊模块：interpretedMATLABfunction：五、总结和坑点提醒一、项目场景  最近一个任务是使用simulink搭建一个MIMO串扰消除的链路，并用实际收到的数据进行测试，在搭建的过程中也遇到了不少的问题（当然这比vivado里面的debug好不知道多少倍）。准备趁着这个机会，先以一个很基本的通信链路对simulink基础和相关的debug方法进行总结。  在本篇中，主要记录simulink的基本原理和基本的SISO通信传输链路（QPSK方式），计划在下篇记

  4. ruby - Ruby gems 的问题(损坏？)试图让指南针在 npm 中工作 - 2

    我不是Ruby专家，但想弄清楚发生了什么，因为我试图让指南针在节点应用程序中工作，但我的Ruby似乎坏了。打字:ruby--version让我:ruby2.1.1p76(2014-02-24revision45161)[x86_64-darwin13.0]我安装了Homebrew，之前遇到过Ruby版本的问题，但它似乎已安装并且可以正常工作。但是，当我使用gem输入请求时，出现此错误:$gem-hErrorloadingRubyGemsplugin"/Users/user_dir/.rvm/gems/ruby-2.1.1@global/gems/executable-hooks-1.3

  5. ruby - 使用指南针安装 bootstrap sass - 2

    我正在尝试安装bootstrap-sass并收到以下错误。我试过旧版本的sass，但bundler一直在安装3.3.0。WARN:UnresolvedspecsduringGem::Specification.reset:sass(~>3.2)WARN:Clearingoutunresolvedspecs.Pleasereportabugifthiscausesproblems./Library/Ruby/Gems/2.0.0/gems/compass-0.12.2/lib/compass/sass_extensions/monkey_patches/browser_support.r

  6. JMockit 使用指南 - 2

    目录配置模拟模拟类型与实例期望录制-回放-验证指定调用计数验证指定自定义结果验证调用参数联级模拟部分模拟模拟未实现的类其他伪装伪装方法及类伪装未实现类本文主要内容如何在SpringBoot中配置使用JMockit如何mock/faking依赖的对象如何对行为mock如何VerificationJMockit之所以强大，是因其使用了javaagent对类的字节码做了修改，在JVM的所有mock工具中，它是功能最强大的。同时注解又是最少的。配置在SpringBoot项目中使用JMockit隔离代码做单元测试，需要做以下配置引入JMockit依赖。dependencies>dependency>gr

  7. ruby-on-rails - 是否有针对经验丰富的 Ruby 开发人员的 Rails 指南？ - 2

    几年前，我从一些Rails初学者指南开始学习Ruby/Rails。那时我已经学习了Rails的基础知识，例如模型和路由的一些约定优于配置，以及如何使用helpers等。但是，我并没有坚持多久，因为此后不久我发现了Sinatra，并决定我个人更喜欢它。不过，我最终真的爱上了Ruby，从那以后我写了很多Ruby，几乎没有一个是针对任何Rails项目的。然而，事实证明大部分可用的Ruby工作都是针对Rails应用程序的。所以我现在想再尝试一下Rails。现在，该引用资料很棒并且有很多有用的信息，但我只查看了我需要的特定内容的引用资料，而没有记住。但我不太可能在引用资料中看到像script/c

  8. ruby-on-rails - 关于将实例变量传递给 redirect_to 方法的困惑。正如 Rails 指南中所见 - 2

    我正在研究ruby​​onrails指南，即http://guides.rubyonrails.org/layouts_and_rendering.html上的“布局和渲染”主题我对将实例变量传递给redirect_to方法感到困惑。这怎么可能？我认为redirect_to与重定向到另一个网页或url相关。在指南中给出的示例中，它说了以下内容:2.2.2RenderinganAction’sViewIfyouwanttorendertheviewthatcorrespondstoadifferentactionwithinthesametemplate,youcanuserenderw

  9. 《ChatGPT实用指南》(精编版)重磅发布，全网免费分享，快上车，别掉队 - 2

    文/高扬（微信公众号：量子论）据上次3月18号发布的V1.8版，已经过去十天，这期间AI领域发生了很多重大变化。因此，我们对《ChatGPT实用指南》进行了重大改版，增加了大量实用的操作和详细的讲解，保证小白可以轻松上手，快速驾驭ChatGPT。V2.0版本亮点：1、结构更合理。分为基础篇、进阶篇、高级篇，从易到难，由浅入深，符合学习规律。2、内容更充实。扩充了27页的内容，尽量看图说话，将操作步骤一步步地展示出来。3、排版更美观。按图书出版的规范制作，便于知识点查阅。后记：2022年11月底，我们在HackerNews上看到了关于ChatGPT的新闻报道后，开始意识到，人工智能的春天来了，这

  10. U3D游戏开发工程师正确入行姿势指南 - 2

    2021年，游戏圈上演了一场精彩绝伦的抢人大战。在上海游戏圈，年薪百万的人越来越多了。据多名HR估算，在上海，过去一年TA、引擎、美术等稀缺岗位拟的薪资涨幅大概在20%-30%左右。某位圈内知名资深游戏猎头对此发出感叹：“50K的数值策划、角色原画；70K的技术美术；80K的技术总监...他们的年薪总包都接近百万，就连应届生入行的薪资也水涨船高，这要是放在以往都是不敢想象的”。以往含年薪、期权等的年总包收入上百万元，起码得是总监级别。如今工作五六年的人从广深跳到上海游戏公司，年薪能从50-70万跃上100万元，拿百万年薪的游戏从业者越来越多了上海游戏圈近年发展迅速，既有颇具发展潜力的中生代F4

随机推荐