近期，Kubernetes儀表盤和外部IP代理接連被發現存在安全問題。針對這兩個漏洞，Kubernetes發佈了相應的補丁版本供會受漏洞影響的用戶解決問題。本文將更深入解讀這兩個安全漏洞的原理、會對您的Kubernetes部署造成的影響以及相應的應對之策。
通過kubernetes儀表盤訪問自定義TLS證書
Kubernetes儀表盤漏洞（CVE-2018-18264）會影響v1.10.0或更早的儀表盤版本。因爲這一漏洞，用戶可以“跳過”登錄過程，假設配置的服務帳戶，最後獲得儀表盤所使用的自定義TLS證書。如果您已將Kubernetes儀表盤配置爲需要登錄並將其配置爲使用自定義TLS證書，那麼這一漏洞會影響到您，您需要及時注意。
該漏洞的運作原理
此漏洞可以分爲兩部分來解釋。
第一個是，因爲登陸時用戶可以選擇“跳過”這一選項，那麼任何用戶都可以繞過登錄過程，該過程在v1.10.0或更早版本中始終默認啓用。這樣一來，用戶就完全跳過登錄過程並能使用儀表盤配置的服務帳戶。
第二個是，使用儀表盤配置的服務帳戶，必須最低限度地有權限訪問自定義TLS證書（以secret的形式存儲）。未經身份驗證的登錄，加上儀表板使用配置的服務帳戶來檢索這些secret的能力，組合在一起的結果就是這一安全問題。
使用儀表盤v1.10.1補丁時，默認情況下將不再啓用“跳過”選項，並且會禁用儀表盤在UI中檢索和顯示它的功能。
該漏洞對Rancher 1.6.x和2.x意味着什麼？
在Rancher 2.x中，默認情況下不會啓用Kubernetes儀表盤，因爲Rancher 2.0用戶界面可用作替代方案。若您不會使用到儀表盤代碼庫，則不受此漏洞的影響。如果您更改了默認設置、在Rancher管理的任何Kubernetes集羣之上部署了Kubernetes儀表盤，請務必使用Kubernetes官方提供的指南及補丁修復這一漏洞。
如果你使用的是Rancher 1.6.x，則完全無需擔心。在Rancher 1.6.x中，Kubernetes儀表盤作爲每個Kubernetes集羣環境的一部分包含在內；但是，1.6.x部署不受影響，因爲Rancher Server充當了Kubernetes儀表盤的身份驗證授權和代理。它不利用默認的Kubernetes儀表盤登錄機制。此外，Rancher部署的Kubernetes儀表盤不使用任何自定義TLS證書。
Kubernetes API服務器外部IP地址代理漏洞
下面讓我們來探討Kubernetes公告所描述的第二個漏洞。
Kubernetes API服務器使用節點、node或服務代理API，將請求代理到pod或節點。通過直接修改podIP或nodeIP，可以將代理請求定向到任何IP。API服務器總是被部署在某網絡中的，利用這個漏洞就訪問該網絡中的任何可用IP了。儘管自從v1.10發佈以來，Kubernetes已經在很大程度上增加了檢查以緩解這個問題，但最近才發現有一條路徑的問題並沒有被完全解決——將代理指向本地地址到運行API服務器的主機。
該漏洞的運作原理
通過使用Kubernetes API，用戶可以使用節點代理、pod代理或服務代理API請求與pod或節點的連接。Kubernetes接受此請求，找到podIP或nodeIP的關聯IP，並最終將該請求轉發到該IP。這些通常由Kubernetes自動分配。但是，集羣管理員（或具有類似“超級用戶”權限的不同角色）可以更新資源的podIP或nodeIP字段以指向任意IP。
這在很大程度上不是問題，因爲“普通”用戶無法更改資源的podIP或nodeIP。podIP和nodeIP字段位於pod和節點資源的狀態子資源中。爲了更新狀態子資源，必須專門授予RBAC規則。默認情況下，除了集羣管理員和內部Kubernetes組件（例如kubelet、controller-manager、scheduler）之外，沒有Kubernetes角色可以訪問狀態子資源。想要利用此漏洞，首先得擁有對集羣的高級別訪問權限。
這一次Kubernetes官方發佈的修復，是確定***向量可以存在於與集羣分開管理控制面板的設置中。在這種情況下，集羣管理員是不能訪問運行API服務器的主機的。這種情況存在於您從雲提供商處獲得的託管Kubernetes服務中。在這種情況下，集羣管理員可以通過將podIP / nodeIP修改爲本地地址（如127.0.0.1）來訪問API服務器的本地地址。今天發佈的修復將阻止代理到本地地址。
這對Rancher用戶意味着什麼？
Rancher託管集羣的默認權限，僅允許集羣所有者和成員更改podIP或nodeIP字段。將該權限提供給其他用戶時，必須假定允許用戶能夠完全訪問集羣中的任何節點。所有其他默認角色（例如項目所有者/成員）都無權訪問這些字段。今天發佈的修復程序所適用的部署的Kubernete集羣，是其控制面板網絡與應用程序使用的網絡不同的。在Rancher 1.6.x或2.x中創建的Kubernete集羣，均默認集羣管理員具有對控制面板節點的完全訪問權限。如果您正在使用Rancher 2.x，並且正在使用託管雲提供商（例如EKS、GKE、AKS），請與他們覈實安全性是否存在問題，因爲控制面板是歸雲提供商所有。
我們始終希望能確保Rancher用戶能夠在最短時間內使用到最新的安全修復程序和相應補丁，Kubernetes版本v1.10.12、v1.11.6和v1.12.4解決了這兩個安全漏洞，這三個版本的Kubernetes將可在Rancher 版本v2.1.5和v2.0.10中使用。如果你是Rancher v1.6.x版本的用戶，則無需做任何更新，因爲標準的v1.6.x安裝不受這次安全漏洞影響。
您還可以通過下述兩個鏈接瞭解到Kubernetes官方針對這兩個漏洞的相應討論：
https://discuss.kubernetes.io/t/security-release-of-dashboard-v1-10-1-cve-2018-18264/4069