安全性是 Kubernetes 面臨的主要挑戰之一，因為它的配置復雜性和漏洞較多。雖然Google Kubernetes Engine（GKE）這樣的托管容器服務提供了許多保護功能，但也不會免除所有相關責任。請繼續閱讀，詳細了解 GKE 安全性和保護集群的最佳實踐。

GKE 安全的基本概述

GKE 在許多層中保護您的工作負載，包括容器映像、運行時、集群網絡以及對集群 API 服務器的訪問。

因此，Google 建議采用分層的方法來保護您的集群和工作負載。為組織啟用適當級別的靈活性和安全性以部署和維護工作負載可能需要一定程度的權衡，因為某些設置可能過于嚴格。

GKE 安全最關鍵的方面包括以下內容：

身份驗證和授權;

控制平面安全性，包括組件和配置;

節點安全;

網絡安全。

這些元素也反映在CIS基準中，這有助于圍繞Kubernetes的安全配置構建工作。

為什么CIS基準對GKE安全至關重要？

處理 K8s 安全配置并不像是在公園里散步。

紅帽 2022 年 Kubernetes 和容器安全現狀發現，幾乎四分之一的嚴重問題是可以修復的漏洞。近 70% 的事件是由于配置錯誤而發生的。

自互聯網安全中心（CIS）發布以來，基準已成為全球公認的實施和管理網絡安全機制的最佳實踐。

CIS Kubernetes 基準測試涉及支持強大安全態勢的 K8s 配置建議。它是為開源的 Kubernetes 發行版編寫的，并且基本普遍適用。

獨聯體GKE基準測試實踐

使用像 GKE 這樣的托管服務，并非所有 CIS 基準上的項目都在您的控制之下。

這就是為什么有些建議不能直接自行審核或修改的原因。這些涉及：

控制平面;

Kubernetes 發行版;

節點的操作系統。

但是，您仍然需要注意升級運行工作負載的節點，當然還有工作負載本身。需要審核和修正對這些組件的任何建議。

您可以手動執行此操作，也可以使用處理 CIS 基準測試的工具。例如，使用 CAST AI 的容器安全模塊，您可以在連接集群后的幾分鐘內大致了解基準差異。

該平臺還會優先處理它識別的問題，以便您知道哪些項目需要優先修復。掃描集群時，您還可以根據行業最佳實踐進行檢查，以便更好地評估整體安全狀況并計劃進一步的 GKE 強化。

確保 GKE 安全的十大策略

1. 應用最小特權原則

此基本安全原則是指僅授予用戶帳戶執行預期功能所必需的權限。

它包含在 CIS GKE 基準 6.2.1 中：不希望使用計算引擎默認服務帳戶運行 GKE 集群。

默認情況下，您的節點可以訪問計算引擎服務帳戶。它的廣泛訪問權限使其對多個應用程序有用，但它也具有比運行 GKE 集群所需的更多權限。這就是為什么您必須創建和使用最低特權服務帳戶而不是默認帳戶的原因。

2. 使用 RBAC 加強身份驗證和授權

GKE 支持多個選項，用于通過基于角色的訪問控制 （RBAC） 管理對集群的訪問。

RBAC 支持在群集和命名空間級別更精細地訪問 Kubernetes 資源，但它也允許你創建詳細的權限策略。

CIS GKE 基準 6.8.4 強調需要優先使用 RBAC，而不是傳統的基于屬性的訪問控制 （ABAC）。

另一個 CIS GKE 基準 （6.8.3） 建議使用組來管理用戶，因為它簡化了對身份和權限的控制。它還消除了在組中添加或刪除用戶時更新 RBAC 配置的需要。

3. 增強控制平面的安全性

在責任共擔模式下，Google 會為您管理 GKE 控制平面組件。但是，您仍負責保護節點、容器和 Pod。

默認情況下，Kubernetes API 服務器使用公共 IP 地址?？梢允褂檬跈嗑W絡和專用群集來保護它，這使您能夠分配專用 IP 地址。

您還可以通過執行常規憑據輪換來增強控制平面的安全性。啟動該過程時，TLS 證書和群集證書頒發機構將自動輪換。

4. 定期升級您的 GKE 基礎設施

Kubernetes 經常發布新的安全功能和補丁，因此讓您的 K8s 保持最新狀態是改善安全狀況的最簡單方法之一。

GKE 會自動為您修補和升級控制平面。節點自動升級也會自動升級集群中的節點。CIS GKE 基準 6.5.3 建議保持該設置。

如果出于任何原因，您需要禁用自動升級，Google 建議每月執行一次升級，并按照 GKE 安全公告了解關鍵補丁。

5. 保護節點元數據

CIS GKE 基準 6.4.1 和 6.4.2 提到了影響節點安全性的兩個關鍵因素，這仍然是您的責任。

v0.1 和 v1beta1 計算引擎元數據服務器終結點在 2020 年被棄用并關閉，因為它們沒有強制實施元數據查詢標頭。

一些針對 Kubernetes 的攻擊依賴于訪問虛擬機的元數據服務器來提取憑據?？梢允褂霉ぷ髫撦d標識或元數據隱藏來防止這些攻擊。

6. 禁用 Kubernetes 儀表板

幾年前，攻擊者獲得特斯拉云資源并使用它們來挖掘加密貨幣的消息使世界感到震驚。在這種情況下，攻擊媒介是一個 Kubernetes 儀表板，它向公眾公開，沒有身份驗證或提升的權限。

如果您想避免跟隨特斯拉的困境，建議遵守 CIS GKE 基準 6.10.1。該標準清楚地概述了在 GKE 上運行時應禁用 Kubernetes Web UI。

默認情況下，GKE 1.10 及更高版本禁用 K8s 儀表板。您還可以使用以下代碼：

gcloud container clusters update CLUSTER_NAME \

    --update-addons=KubernetesDashboard=DISABLED

7. 遵循 NSA-CISA 框架

CIS Kubernetes Benchmark 為構建安全的運營環境提供了堅實的基礎。但是，如果您想走得更遠，請在安全程序中為 NSA-CISA Kubernetes 強化指南騰出空間。

NSA-CISA 報告概述了 Kubernetes 生態系統中的漏洞，并推薦了配置集群安全性的最佳實踐。

它提供了有關漏洞掃描、識別錯誤配置、日志審核和身份驗證的建議，幫助您確保適當解決常見的安全挑戰。

8. 提高您的網絡安全

在 GKE 中運行的大多數工作負載都需要與集群內外運行的其他服務進行通信。但是，您可以控制允許流經集群的流量。

首先，您可以使用網絡策略來限制容器到容器的通信。默認情況下，可以通過網絡訪問所有群集 Pod IP 地址。您可以通過定義流經 Pod 的流量并為與配置的標簽不匹配的流量停止它來鎖定命名空間中的連接。

其次，您可以使用網絡負載均衡器來平衡 Kubernetes Pod。為此，您需要創建與容器標簽匹配的負載均衡器服務。您將擁有一個面向外部的 IP 映射到 Kubernetes Pod 上的端口，并且您將能夠使用 kube-proxy 在節點級別過濾授權流量。

9. 保護容器對谷歌云資源的訪問

您的容器和容器可能需要訪問 Google Cloud 中的其他資源。有三種方法可以執行此操作：使用工作負載標識、節點服務帳戶和服務帳戶 JSON 密鑰。

訪問 Google Cloud 資源的最簡單、最安全的選項是使用工作負載標識。此方法允許您在 GKE 上運行的 Pod 獲取對 Google Cloud 服務帳戶的權限。

您應該使用特定于應用的 Google Cloud 服務帳號來提供憑據，以便應用擁有在發生泄露時可以撤銷的最低必要權限。

10. 獲取 GKE 配置的密鑰管理器

獨聯體 GKE 基準 6.3.1.建議使用云 KMS 中管理的密鑰加密 Kubernetes 密鑰。

Google Kubernetes Engine 為您提供了多種秘密管理選項。您可以在 GKE 中原生使用 Kubernetes 機密，但您也可以使用您管理的密鑰和應用層機密加密在應用程序層保護這些機密。

還有像Hashicorp Vault這樣的機密管理器，它們提供了一種一致的、生產就緒的方式來管理GKE中的機密。確保檢查您的選項并選擇最佳解決方案。

在幾分鐘內評估 GKE 的安全性

Kubernetes 生態系統不斷增長，但其安全配置挑戰也在不斷增長。如果您想掌握 GKE 容器安全性，您需要能夠識別潛在威脅并有效地跟蹤它們。

借助 Kubernetes 安全報告，您可以根據 CIS 基準、NSA-CISA 框架和其他容器安全最佳實踐掃描 GKE 集群，以識別漏洞、發現錯誤配置并確定其優先級。只需幾分鐘即可全面了解集群的安全狀況。