7 步保障 Kubernetes 集群安全
隨著 Kubernetes 的發展和改進，新的安全威脅和風險也逐漸向 K8s 轉移，因此 K8s 安全性變得越來越重要，而保護 K8s 集群已成為 DevOps 團隊不容忽視的重要任務。K8s 有多種實現類型（本地、雲管理、混合等）、眾多開源支援工具和各種配置設置，且保護運行容器工作負載的任何安全敏感架構的需求也在增長。
根據 CNCF 的 K8s 安全審計調查，攻擊者可以通過利用各種 K8s 漏洞和幾種標準配置進行非法行為。今天，我們將探討一些實施保障 K8s 安全的最佳實踐。
K8s 和 K8s 集群
K8s 是一個用於管理容器（容器化應用程式）的系統，容器則可以理解為是一個輕量級的虛擬機。要創建應用程式，就需要先創建一些容器並使用 K8s 來管理這些容器。這確實是一個龐大且快速擴展的生態系統，並且 K8s 的設施、支援和工具相對比較容易獲得。K8s 可以立即生成和擴展容器，並跨所有容器管理存儲。
K8s 集群是包含所有 K8s 組件的K8s 系統。集群可以在物理機（如 PC 或筆記型電腦電腦）或虛擬機上運行。如果你有一台機器運行完整的 K8s 系統，則該機器託管您的 K8s 集群；假設你有兩台機器運行 K8s，這兩台機器都會組織你的 K8s 集群。集群可以在物理機和虛擬機的任意組合上運行。
7步保護 K8s 集群安全
接下來我們一起看看企業應該實施哪些安全最佳實踐來確保其 K8s 集群的安全性。
1. 將 K8s 升級到最新版本
最基本且經常被忽視的安全最佳實踐是將 K8s 生態系統保持最新狀態。企業將受益於新的安全功能和錯誤跟蹤更新以及變體版本。此外，在啟動到生產集群之前，請在測試環境中使用最新的完整版本。
2. 驗證 Kubernetes API 伺服器
Kubernetes API 伺服器，也被稱為 Kube-API 伺服器，是 K8s 集群的核心。K8s API 是 K8s 集群的主要訪問點。管理員或服務帳戶可以通過命令行實用程式 kubectl、REST API 調用或其他客戶端 SDK 訪問 API。伺服器提供訪問並保證集群是可操作的。所有在集群內部調用的 API 嘗試都應該使用加密的傳輸層安全性。建議採用完全符合訪問控制規則的 API 伺服器的 API 身份驗證方法。
3. 啟用 RBAC 授權機制
RBAC 即基於角色的訪問控制機制，允許多個應用程式基於最小許可權執行具體操作，並且僅授予執行必要的許可權。管理員應遵循以下 K8s RBAC 最佳實踐：
- 使用
–authorization-mode=RBAC參數在 API 伺服器中啟用 RBAC，強制 RBAC 作為集群安全的標準配置。 - 為每個應用程式使用專用的用戶服務帳戶，而不是 K8s 創建的默認服務帳戶。專用服務帳戶允許管理員對每個應用程式強制執行 RBAC，並更好地控制提供給每個應用程式資源的細粒度許可權。
- 減少可選 API 伺服器標誌的數量，以減少 API 伺服器的攻擊面。每個標誌都有助於集群管理的特定方面，這可能會也可能不會暴露 API 伺服器。減少以下可選標誌的使用：例如匿名身份驗證， 不安全的綁定地址，和不安全埠。
- 定期調整和更新 RBAC 政策。首先刪除不再需要的任何許可權，這個動作可能很耗時，但能有效保障安全。
- 強制執行最低許可權以使 RBAC 系統生效。當集群管理員遵循 Pareto 原則時，只將所需的許可權分配給用戶或應用程式。不應授予額外許可權，應避免使用通配符
[「*」]或一攬子訪問。
4. 提高節點安全性
首先加強運行 pod 節點安全性：
- 配置的標準和基準。根據安全建議配置主機。使用與特定 K8s 版本相關的 Internet 安全中心基準驗證集群。
- 最小化管理訪問。通過限制管理訪問來減少 K8s 節點上的攻擊面。
- 節點上進行隔離和約束。在特定節點上執行特定的 pod，這樣可以確保 pod 在具有特定隔離和安全設置的節點上運行。
向節點對象添加標籤以允許 pod 專門針對節點，從而控制 pod 可以訪問哪些節點。應用節點標籤後，將節點選擇器添加到 pod 部署中，以便 pod 對所選節點進行顯著更改。
5. 控制 kubelet 訪問許可權
kubelet 發揮著在每個集群節點上持續運行的操作員的作用。它通過 API 與用戶通訊，這些 API 管理試圖在節點上運行並執行特定任務的 pod。未經授權向 kubelet 披露為攻擊者提供了 API 訪問許可權，並可能危及節點或集群的安全。
要減少攻擊面並防止通過 kubelet 對 API 進行未經授權的訪問，請執行以下步驟：
- 在啟動 kubelet 之前，將
-anonymous-auth標誌設置為false以禁用匿名訪問：-anonymous-auth=false。 - 使用
-kubelet-client-certificate和-kubelet-client-key標誌開始 Kube-Episerver 命令。這可確保 API 伺服器對 kubelet 進行身份驗證並防止匿名請求。 - kubelet 提供了一個只讀 API，管理員無需登錄即可使用。這樣可能會暴露潛在的敏感集群資訊，管理員應使用以下命令關閉只讀埠：
—read-only-port=0。
6. 配置命名空間和網路策略
命名空間將敏感工作負載與非敏感工作負載區分開來。處理多個命名空間可能會有些困難，但這使得實現安全控制變得更簡單，例如管理性能的網路策略以調節進出 pod 的流量。
7. 啟用審計日誌
啟用 K8s 審計日誌並監督它們是否存在非法行為和可疑的 API 調用。K8s 可以保存集群活動的詳細記錄，所以我們可以立即在審核日誌中檢測到可能的安全問題。例如，攻擊者試圖暴力破解密碼可能會創建身份驗證和授權日誌。如果這些行為反覆出現，則可能存在安全問題。
要啟用審計日誌，需使用 K8s 審計策略，允許管理員根據情況配置審計級別：
None– 與此規則匹配的事件將不會被記錄。Metadata– 記錄請求的元數據，例如請求用戶、時間戳、資源和動詞。Request– 記錄事件的元數據以及請求正文，但不記錄響應正文。這不適用於對非資源的請求。RequestResponse– 跟蹤事件元數據、請求和響應正文。這不適用於對非資源的請求。
這些資訊的大部分由 K8s 審計日誌記錄，並且與集群 API 的簡單結合允許您將這些日誌發送到外部日誌記錄和存儲解決方案。同時還可以生成儀錶板、可疑行為警報和事件調查報告。
總結
依賴 K8s 作為後端的 DevOps 團隊必須意識到集群和可以在其中運行的 Docker 容器可能面臨的所有風險和攻擊。由於可用的攻擊向量種類繁多、技術的不斷進步以及該工具的一致、廣泛採用，惡意攻擊者發現滲透集群能夠有效發起攻擊並獲得利益。保護 K8s 集群是一項艱巨的任務，密切關注並儘可能檢測系統漏洞或惡意攻擊行為至關重要。
