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集群，您依然需要將安全性構建到容器配置的其他方面及其運行時操作中。當您提高技術堆棧的安全性時，需要尋找能夠為容器部署提供中心治理點的工具，并為容器和云原生應用程序提供持續監控和保護。