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

作者：老 Z，中電信數智科技有限公司山東分公司運維架構師，雲原生愛好者，目前專注於雲原生運維，雲原生領域技術棧涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。

前言

內容導圖

測試伺服器配置

主機名	IP	CPU	記憶體	系統盤	資料盤	用途
zdeops-master	192.168.9.9	2	4	40	200	Ansible 運維控制節點
ks-k8s-master-0	192.168.9.91	4	16	40	200+200	KubeSphere/k8s-master/k8s-worker
ks-k8s-master-1	192.168.9.92	4	16	40	200+200	KubeSphere/k8s-master/k8s-worker
ks-k8s-master-2	192.168.9.93	4	16	40	200+200	KubeSphere/k8s-master/k8s-worker
storage-node-0	192.168.9.95	2	8	40	200+200	ElasticSearch/GlusterFS
storage-node-0	192.168.9.96	2	8	40	200+200	ElasticSearch/GlusterFS
storage-node-0	192.168.9.97	2	8	40	200+200	ElasticSearch/GlusterFS
harbor	192.168.9.89	2	8	40	200	Harbor
合計	8	22	84	320	2800

測試環境涉及軟體版本資訊

作業系統：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) 的具體資訊如下：

kubesphere-ssl-tls-0

kubesphere-ssl-tls-1

漏洞分析

分析漏洞報告資訊，我們發現漏洞涉及以下埠和服務：

埠號	服務
2379/2380	Etcd
6443	kube-apiserver
10250	kubelet
10257	kube-controller
10259	kube-scheduler

在漏洞節點 (任意 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))

漏洞原因：

相關服務配置檔案裡使用了 IDEA、DES 和 3DES 等演算法。

利用測試工具驗證漏洞：

可以使用 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 配置引數的可參考配置。

原始掃描結果中的 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

原始掃描結果去掉 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 相關元件順序不同也沒發現異常。

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

編輯 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

重啟 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 服務中斷，生產環境謹慎操作。

驗證漏洞是否修復：

# 執行掃描命令
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

編輯 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

重啟 kube-apiserver：

不需要手動重啟，由於是靜態 Pod， Kubernetes 會自動重啟。

驗證漏洞：

# 執行掃描命令
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

編輯 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

重啟 kube-controller：

不需要手動重啟，由於是靜態 Pod， Kubernetes 會自動重啟。

驗證漏洞：

# 執行完整掃描命令
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

編輯 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

重啟 kube-scheduler：

不需要手動重啟，由於是靜態 Pod， Kubernetes 會自動重啟。

驗證漏洞：

# 執行完整掃描命令
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

編輯 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 官方文件。

重啟 kubelet：

systemctl restart kubelet

重啟有風險，操作需謹慎！

驗證漏洞：

# 執行完整掃描命令
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 釋出！

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

前言

測試伺服器配置

測試環境涉及軟體版本資訊

簡介

漏洞資訊及修復方案

漏洞詳細資訊

漏洞分析

漏洞修復方案

漏洞修復

修復 Etcd

修復 kube-apiserver

修復 kube-controller

修復 kube-scheduler

修復 kubelet

常見問題

Etcd 啟動失敗

報錯資訊：

解決方案：

Etcd 服務不斷重啟

報錯資訊 (省略掉了一部分)：

解決方案：

相關文章