上個月，Kubernetes被曝首個重大安全漏洞，動搖了Kubernetes的生態系統。這個漏洞允許攻擊者通過Kubernetes API服務器攻擊集羣，使其運行代碼執行安裝惡意軟件等行爲。
今年早些時候，特斯拉遭遇了一場複雜的加密貨幣挖礦惡意軟件感染，起因是Kubernetes控制檯配置錯誤。Kubernetes控制檯沒有密碼保護，攻擊這利用這一點訪問了其中的一個pod，這裏面有特斯拉在AWS環境中的訪問憑證。
隨着容器和容器編排器的採用率不斷增加，組織需要採取必要的措施來保護關鍵的計算基礎設施。可以參考以下9個客戶反饋的Kubernetes最佳安全實踐來保護你的基礎設施。
1. 升級到最新版本
除了修復bug，Kubernetes每個季度的更新都會新增一些安全特性。爲了用好這些特性，我們建議你運行最新的穩定版本。最好的方法是使用運行最新的版本（帶有最新的補丁），特別是在發現上個月的漏洞爆發之後。你的版本越舊，升級和支持會變得越來越困難，所以你應該計劃每個季度至少升級一次。使用託管的Kubernetes服務可以使升級變得非常容易。
2. 啓用基於角色的訪問控制(RBAC)
控制訪問Kubernetes API的訪問者，以及他們對RBAC有哪些權限。RBAC通常在Kubernetes 1.6或更高版本中默認啓用(之後會針對某些託管服務)，但是如果你從1.6版本就開始升級，並且沒有更改配置，則需要再次檢查設置。由於Kubernetes授權控制器的組合方式，你必須同時啓用RBAC和禁用遺留授權(ABAC)。
RBAC被強制執行後，你仍然需要有效地使用它。爲了支持特定命名空間的訪問權限，通常應該避免集羣級別的訪問權限。避免給任何人集羣管理的權限，即使是調試權限——僅在需要時根據具體情況授予訪問權限要安全得多。
你可以使用“kubectl get clusterrolebinding”或“kubectl get rolebinding -all-namespaces”來研究集羣角色。快速檢查誰被授予特殊的“集羣管理員”角色；在這個例子中，它只是“masters”：
如果你的應用程序需要訪問Kubernetes API，請單獨創建服務賬戶，並在每個使用站點爲它們提供所需的最小權限集。這比爲命名空間的默認賬戶授予不受限制的權限要好。大多數應用程序根本不需要訪問API；’ automountServiceAccountToken '可以設置爲“false”。
3. 使用命名空間來建立安全邊界
創建獨立的命名空間是隔離組件很重要。我們發現，當不同類型的工作負載部署在不同的命名空間中時，應用安全控制(如網絡策略)要容易得多。
你的團隊是否在有效地使用命名空間？可以通過檢查非默認命名空間來看看情況：
4. 分離的敏感負載
爲了減少被盜用的影響，最好在一組專用計算機上運行敏感的工作負載。這種方法降低了共享容器運行時或主機訪問安全性較差的應用程序時的風險。例如，一個被破壞的節點的kubelet憑證只有被放到調度節點的pod上，才能訪問secret的內容——如果重要的secret被調度到集羣中的許多節點上，那麼對手將有更多的機會竊取它們。
可以使用節點池(雲中或本地)和Kubernetes的命名空間、taint、容忍和其他控件來實現這種分離。
5. 安全的雲端元數據訪問
敏感的元數據，例如kubelet管理憑證，有時會被竊取或誤用來升級集羣中的特權。例如，最近Shopify披露的漏洞報告獎勵裏詳細說明了用戶如何通過混淆微服務使用特權進而從雲提供商的元數據服務裏泄露信息。GKE的元數據隱藏特性改變了集羣部署機制，我們建議使用它來避免這種暴露，直到永久解決方案出現替代它。在其他環境中可能需要類似的對策。
6. 創建和定義集羣網絡策略
網絡策略允許用戶控制對容器化應用程序的網絡訪問。要使用它們，需要確保有一個支持該資源的網絡提供商；對於一些Kubernetes託管商，如谷歌Kubernetes引擎(GKE)，你需要進行選擇。(如果集羣已經存在，那麼在GKE中啓用網絡策略需要進行簡單的滾動升級。)設置好之後，從一些基本的默認網絡策略開始，比如默認情況下阻塞來自其他名稱空間的流量。
如果在谷歌容器引擎中運行，可以檢查集羣是否在啓用策略支持的情況下運行：
7. 運行集羣範圍的Pod安全策略
Pod安全策略可以設置集羣中工作負載的默認運行方式。考慮定義一個策略並啓用Pod安全策略允許控制器——根據雲提供商或部署模型的不同，指令也不同。可以要求放棄NET_RAW功能的部署，以防止某些類型的網絡欺騙攻擊。
8. 強化節點安全
可以按照以下三個步驟改進節點上的安全狀態:
-
確保主機安全並正確配置。一種方法是根據CIS基準檢查配置；許多產品都有自動檢查器，可以自動評估是否符合這些標準。
-
控制對敏感端口的網絡訪問。確保你的網絡阻止了對使用kubelet端口的訪問，包括10250和10255。除非來自受信任的網絡，否則要考慮限制對Kubernetes API服務器的訪問。惡意用戶濫用對這些端口的訪問，在集羣中運行加密幣挖礦機，這些集羣沒有設置成在kubelet API服務器上需要有身份驗證和授權。
-
最小化對Kubernetes節點的管理訪問。通常應該限制對集羣中節點的訪問——調試和其他任務通常可以在不直接訪問節點的情況下處理。
9. 打開審計日誌
確保啓用了審計日誌，並且正在監視異常或不需要的API調用，特別是任何授權失敗——這些日誌條目將有一個狀態消息“Forbidden”。授權失敗可能意味着攻擊者試圖濫用竊取的憑證。Kubernetes託管商(包括GKE)在其雲控制檯中提供對這些數據的訪問，並允許設置授權失敗的警報。
展望未來
按照這些建議創建一個更安全的Kubernetes集羣。請記住，即使按照這些提示安全地配置了Kubernetes集羣，仍然需要將安全性構建到容器配置及其運行時操作的其他方面。在改進技術堆棧的安全性時，要找到爲容器部署提供治理中心點併爲容器和雲本地應用程序提供持續監視和保護的工具。
原文鏈接：
https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/