上個月，全球最受歡迎的容器編排引擎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集羣，您依然需要將安全性構建到容器配置的其他方面及其運行時操作中。當您提高技術堆棧的安全性時，需要尋找能夠爲容器部署提供中心治理點的工具，併爲容器和雲原生應用程序提供持續監控和保護。