Kubernetes儀表盤和外部IP代理漏洞及應對之策

近期，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
 

https://discuss.kubernetes.io/t/security-impact-of-kubernetes-api-server-external-ip-address-proxying/4072