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