kube-apiserver tls-cipher-suites configuration to solve SWEET32 attack
最近又遇到新狀況，所以記錄一下解決過程
因為k8s apiserver有出現SSL Medium Strength Cipher Suites Supported(SWEET32)弱點，需要修正
客戶是使用nmap來掃描apiserver使用的port號
剛好我們的ERP系統也是使用k8s cluster，所以就順便一併解決這個問題
這邊先安裝好nmap 7.80版，nmap工具的介紹大家就自行google囉
可以看到我用nmap去掃描其中一台AP3的6443 port，有出現C級的ciphers，警告說這個會發生SWEET32 attack
其實概念很簡單
他是顯示這五個cipher，其中一個有問題，表示kube-apiserver有用到這五種cipher
所以目標就是將不合格的那個拿掉
ciphers:
| 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
所以我們就來修改一下kube-apiserver的command
vim /etc/kubernetes/manifests/kube-apiserver.yaml參數的內容，可以參考kubernetes的官方文件，我們是使用v1.18的版本，總共有底下圖示這些
https://v1-18.docs.kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
增加這一段啟動參數，我們只保留四個strength為A的ciphers
- --tls-cipher-suites=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存檔離開，打完收工
喔不～出現錯誤了Orz
來檢查為什麼，看一下apiserver log
發現啟動過程中，有缺少所需要的cipher
那就查看看有哪些是相關的cipher吧
可以看到有三個跟AES_128_GCM_SHA256相關的cipher
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256其中TLS_RSA_WITH_AES_128_GCM_SHA256已經有了，那我們就再修改一次yaml，將二個TLS_ECDHE開頭的追加上去吧
- --tls-cipher-suites=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,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256存檔後再來看一下apiserver是否有成功啟動
為什麼還是死掉的！！！為什麼為什麼為什麼
出現新的錯誤
其實這跟go語法裡檢查cipher排列順序有關，所以cipher要依照前述的kube-apiserver tls-cipher-suites內容順序來排
https://go.googlesource.com/net/+/master/http2/server.go
因此我們修正tls-cipher-suites的內容為
- --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,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嘿嘿～看起來可以囉
再來驗證一下nmap
可以看到之前有問題的cipher已經被拿掉，並且least strength變為A
再將其他二台kube-apiserver加上相同的設定，就搞定了
後續要注意的可能是少了TLS_RSA_WITH_3DES_EDE_CBC_SHA這個cipher，對於apiserver會有什麼影響尚未知
目前還沒出問題，功能一切正常
