9項Kubernetes安全最佳實踐

上個月，全球最受歡迎的容器編排引擎Kubernetes，被爆出首個嚴重的安全漏洞，使得整個Kubernetes生態發生震蕩。該漏洞（CVE-2018-1002105）使攻擊者能夠通過Kubernetes API伺服器破壞集群，允許他們運行代碼來執行一些惡意活動，比如安裝惡意軟體等。

今年年初，由於Kubernetes控制台中的配置錯誤，特斯拉被一個惡意挖掘加密貨幣的軟體所感染。攻擊者利用了特定Kubernetes控制台沒有密碼保護的這一漏洞，訪問其中一個包含特斯拉大型AWS環境訪問憑據的pod。

隨著越來越多的企業開始使用容器以及容器編排引擎，他們需要採取必要的措施來保護計算機基礎架構中的這一關鍵部分。為了幫助您完成這項工作，本文將為您介紹9項Kubernetes安全最佳實踐。

01 升級到最新版本

每一季度的更新都會添加新的安全相關功能，而不僅僅是修復bug，為了充分利用這些安全特性，我們建議您始終保持運行最新的穩定版本。

02 啟用基於角色的訪問控制（RBAC）

控制誰可以訪問Kubernetes API以及他們對基於角色的訪問控制（RBAC）的許可權。默認情況下，RBAC通常在Kubernetes 1.6及更高版本中啟用，但如果您從那時起進行了升級並且沒有更改配置，則需要仔細檢查您的設置。由於Kubernetes授權控制器的組合方式，您必須同時啟用RBAC並禁用傳統的基於屬性的訪問控制（ABAC）。

啟用RBAC之後，您還需要有效地使用它。為了特定命名空間的許可，您通常需要避免集群範圍的許可權。即便是為了調試，也應避免給予任何集群管理員許可權，而是僅在需要的情況下根據具體情況授予訪問許可權，以提高安全性。

您可以使用kubectl get clusterrolebinding或kubectl get rolebinding -all-namespaces來探索集群角色和角色。同時，快速檢查誰被授予了特殊的「cluster-admin」角色，在這個例子中，它是「master」組：

如果您的應用程序需要訪問Kubernetes API，請單獨創建服務帳戶，並為每個使用站點提供所需的最小許可權集。這優於為命名空間的默認帳戶授予過寬的許可權。

大多數應用程序根本不需要訪問API， 對於這一情況，可以將automountServiceAccountToken設置為「false」。

03 使用命名空間建立安全邊界

創建單獨的命名空間是組件之間重要的第一層隔離。當不同類型的工作負載部署在不同的命名空間中時，我們發現應用安全控制（如網路策略）要容易得多。

您的團隊有在高效地使用命名空間嗎？檢查一下那些非默認命名空間，即可確認了：

04 將敏感工作負載彼此分開

為了將潛在的破壞影響力限制在最小值，最好在一組專用計算機上運行敏感工作負載。此方法降低了通過共享容器運行時或主機的安全性較低的應用程序訪問敏感應用程序的風險。例如，受損節點的kubelet憑證通常只有在安裝到該節點上安排的pod中時才能訪問機密內容，如果重要機密被安排到整個集群中的許多節點上，則攻擊者將有更多機會竊取它們。

您可以使用節點池（在雲或本地）和Kubernetes命名空間、污點（taints）、容差（tolerations）和其他控制項來實現此分離。

05 安全的雲元數據訪問

敏感元數據（例如kubelet管理員憑據）有時會被盜或被濫用來升級集群中的許可權。最近Shopify的賞金細節泄露bug就是一例。這說明了用戶能夠通過將微服務混淆為雲提供商的元數據服務泄露信息來升級許可權。GKE的元數據隱藏功能可以更改群集部署機制以避免此暴露，我們建議您在找到另一個永久的替代解決方案之前，一直使用這一功能。在其他環境中可能也需要類似的對策。

06 創建和定義集群網路策略

網路策略允許您控制進出容器化應用程序的網路訪問。要使用它們，您需要確保擁有支持此資源的網路提供程序，對於一些託管的Kubernetes提供商，例如Google Kubernetes Engine（GKE），您需要選擇加入。（如果您的集群已存在，則在GKE中啟用網路策略需要進行簡短的滾動升級。）一旦到位，請從一些基本的默認網路策略開始，例如默認阻止來自其他命名空間的流量。

如果您在GKE中運行，則可以檢查集群是否在啟用了策略支持的情況下運行：

07 運行集群範圍的Pod安全策略

Pod安全策略設置了允許在集群中運行工作負載的默認值。考慮定義策略並啟用Pod安全策略許可控制器，說明因雲提供商或部署模型而異。首先，您可以要求部署放棄NET_RAW功能以抵禦某些類型的網路欺騙攻擊。

08 加強節點安全

您可以按照以下三個步驟來改進節點上的安全狀態：

• **確保主機安全且配置正確。**其中一種方法是根據CIS基準來檢查您的配置，許多產品都有自動檢查功能，可以自動評估配置是否與這些標準一致。
• **控制對敏感埠的網路訪問。**確保您的網路阻止訪問kubelet使用的埠，包括10250和10255。此外，還需限制對可信網路以外的Kubernetes API伺服器的訪問。因為惡意用戶很有可能會濫用對這些埠的訪問許可權，以便在未配置並需要在kubelet API伺服器上進行身份驗證和授權的集群中運行加密貨幣挖掘程序。
• **最小化對Kubernetes節點的管理訪問。**通常應該限制對集群中節點的訪問，因為調試和執行其他任務可以在不直接訪問節點的情況下進行。

09 啟用審核日誌（Audit Logging）

請確保您已經啟用審核日誌，並監視他們是否存在異常或不需要的API調用，尤其是任何失敗授權——這些日誌條目將顯示狀態「Forbidden」。授權失敗可能意味著攻擊者試圖濫用被盜憑據。託管Kubernetes提供程序（包括GKE）可在其雲控制台中訪問此數據，並允許您設置授權失敗警報。

遵循上文的9項建議，您可以獲得更安全的Kubernetes集群。請記住，即便您已經完全按照以上步驟安全地配置了您的Kubernetes集群，您依然需要將安全性構建到容器配置的其他方面及其運行時操作中。當您提高技術堆棧的安全性時，需要尋找能夠為容器部署提供中心治理點的工具，並為容器和雲原生應用程序提供持續監控和保護。

? 著作權歸作者所有

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！