強化叢集安全性的最佳做法

本文提供最佳做法，協助您提升 Google Kubernetes Engine (GKE) 環境的安全性。負責定義、管理及實施政策和程序的資安專員，可以運用這些最佳做法保護組織資料。

如要查看所有 GKE 最佳做法的整合式總覽，請參閱「GKE 最佳做法」。

您應已熟悉下列項目：

新的 GKE 叢集預設會採用本文中的許多最佳做法。Autopilot 模式叢集的預設安全防護機制比 Standard 模式叢集更嚴格。

如要在整個組織中實施及強制執行本文件中的最佳做法，請考慮使用下列服務：

  • Security Command Center： 自動檢查叢集是否實作多項最佳做法，以及其他常見的錯誤設定。
  • 組織政策服務：在組織、資料夾或專案中，對 GKE 資源強制執行特定最佳做法。本文的特定章節提供 Cloud de Confiance 控制台連結，方便您對這些建議套用代管限制。

Cloud de Confiance 環境設計

以下各節說明在 Cloud de Confiance中規劃及設計資源時，應考量的安全性措施。雲端架構師在規劃及 定義 Cloud de Confiance 架構時，應採用這些建議。

最佳做法

規劃資源結構 Cloud de Confiance

建議：實作企業基礎藍圖，這是根據最佳做法為企業環境打造的完整基礎。

機構、資料夾和專案的架構會影響您的資安態勢。 Cloud de Confiance 設計這些基礎資源時，請確保能大規模控管服務的治理和安全性。

規劃多租戶環境

建議做法：實作 Cloud de Confiance 和 GKE 最佳做法，適用於多用戶群企業平台。

許多 GKE 客戶管理分散式團隊，工程工作流程和責任各自獨立。這些多租戶環境必須具備共用基礎架構，供所有開發人員使用，同時根據角色和職責限制元件存取權。企業應用程式藍圖以企業基礎藍圖為基礎，可協助您在多租戶環境中部署內部開發人員平台。

如需詳細資訊，請參閱下列文件：

使用標記將資源分組 Cloud de Confiance

建議做法：使用標記整理 GKE 資源，以便依據條件強制執行政策，並提升團隊的責任感。

標記是中繼資料，可附加至機構、資料夾和專案中的資源，以識別資源階層中的業務層面。Cloud de Confiance 您可以將標記附加至 GKE 叢集和節點集區，然後使用這些標記，依條件套用 IAM 政策和防火牆政策。

如需詳細資訊，請參閱下列文件：

規劃虛擬私有雲網路

建議：實作 Cloud de Confiance 和 GKE 虛擬私有雲網路設計最佳做法。

虛擬私有雲網路設計和使用的功能會影響網路安全性。根據資源階層和安全目標規劃網路。 Cloud de Confiance詳情請參閱下列文件：

設計事件應變計畫

建議：建立並維護符合安全性與可靠性目標的事件應變計畫。

即使您實作所有可能的安全控管措施，仍可能發生安全事件。事件應變計畫有助於找出資安控管機制的潛在缺口、快速有效地應對各類事件，以及減少服務中斷期間的停機時間。詳情請參閱下列文件：

Cloud de Confiance 網路安全

以下各節提供虛擬私有雲網路的安全建議。網路架構師和網路管理員應套用這些建議，在網路層級縮小攻擊面，並限制非預期網路存取行為的影響。

最佳做法

使用最低權限防火牆規則

建議做法：建立防火牆規則時，請採用最小權限原則，僅針對必要用途提供存取權。請盡可能確保防火牆規則不會與 GKE 預設防火牆規則衝突或覆寫後者。

GKE 會建立預設虛擬私有雲防火牆規則，啟用系統功能並強制執行良好的安全性做法。如果您建立的寬鬆防火牆規則優先順序高於預設防火牆規則 (例如允許所有輸入流量進行偵錯的防火牆規則)，叢集可能會遭到意外存取。

使用 Shared VPC 處理跨專案流量

建議做法：使用 Shared VPC，讓多個專案中的資源透過內部 IP 位址相互通訊。

貴機構中不同專案的資源可能需要相互通訊。舉例來說，某個專案中 GKE 叢集的前端服務，可能需要與另一個專案中的後端 Compute Engine 執行個體通訊。

如需詳細資訊，請參閱下列文件：

使用獨立網路隔離環境

建議：針對測試、測試和正式環境，使用不同的 Shared VPC 網路。

將開發環境彼此隔離，以減少未經授權存取或破壞性錯誤的影響和風險。詳情請參閱「多個主機專案」。

無法變更的安全性設定

下列各節提供安全防護建議，這些建議只能在建立叢集或節點集區時設定。您無法更新現有叢集或節點集區來變更這些設定。平台管理員應將這些建議套用至新的叢集和節點集區。

使用最低權限的 IAM 節點服務帳戶

建議做法：為 GKE 叢集和節點集區使用自訂 IAM 服務帳戶，而非預設的 Compute Engine 服務帳戶。

GKE 會使用附加至節點的 IAM 服務帳戶，執行記錄和監控等系統工作。這些節點服務帳戶至少須具備專案的 Kubernetes Engine 預設節點服務帳戶 (roles/container.defaultNodeServiceAccount) 角色。根據預設，GKE 會使用Compute Engine 預設服務帳戶 (系統會在專案中自動建立) 做為節點服務帳戶。

如果您在專案或機構中的其他函式使用 Compute Engine 預設服務帳戶，該服務帳戶的權限可能超出 GKE 的需求，導致您面臨安全風險。

附加至節點的服務帳戶只能由執行記錄和監控等工作的系統工作負載使用。如要為自己的工作負載佈建身分，請使用 Workload Identity Federation for GKE。

如要在貴機構強制執行這項建議，請使用constraints/container.managed.disallowDefaultComputeServiceAccount 受管理的組織政策限制。如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

使用 Container-Optimized OS 節點映像檔

建議：除非您有使用 Ubuntu 或 Windows 的特定需求，否則請為節點使用 Container-Optimized OS 節點映像檔。

Container-Optimized OS 專為執行容器而打造、最佳化及強化，Container-Optimized OS 是 Autopilot 模式唯一支援的節點映像檔，也是標準模式的預設節點映像檔。

如需詳細資訊，請參閱下列文件：

節點安全性設定

下列各節提供 GKE 節點設定的安全性建議。平台管理員和安全工程師應套用這些建議，提升 GKE 節點的完整性。

最佳做法

使用受防護的 GKE 節點

建議做法：在所有叢集和節點集區中啟用受防護的 GKE 節點、安全啟動和完整性監控功能。

Shielded GKE 節點提供可驗證的身分和完整性檢查，可提升節點的安全性。Autopilot 叢集一律會啟用 Shielded GKE 節點，以及節點完整性監控和安全啟動等功能。在標準叢集中，請執行下列操作：

  • 請勿在叢集中停用受防護的 GKE 節點。
  • 在所有節點集區中啟用安全啟動功能。
  • 請勿停用節點集區的完整性監控功能。

如要進一步瞭解如何啟用這些功能，請參閱「使用受防護的 GKE 節點」。

如要在貴機構強制執行這項建議，請使用constraints/container.managed.enableShieldedNodes 受管理的組織政策限制。如要在 Cloud de Confiance 控制台查看這項代管限制，請前往「Policy details」(政策詳細資料) 頁面。

前往「政策詳細資料」

停用不安全的 kubelet 唯讀通訊埠

建議：停用 kubelet 唯讀通訊埠，並將使用通訊埠 10255 的任何工作負載改為使用更安全的通訊埠 10250。

節點上執行的 kubelet 程序會使用不安全的連接埠 10255 提供唯讀 API。Kubernetes 不會對這個通訊埠執行任何驗證或授權檢查。kubelet 會在更安全的已驗證通訊埠 10250 上提供相同的端點。

詳情請參閱「停用 GKE 叢集中的 kubelet 唯讀通訊埠」。

如要在組織中強制執行這項建議，請使用 constraints/container.managed.disableInsecureKubeletReadOnlyPort 代管組織政策限制。如要在 Cloud de Confiance 控制台查看這項代管限制，請前往「Policy details」(政策詳細資料) 頁面。

前往政策詳細資料

停用節點自行註冊功能

建議：使用受信任的控制層元件建立 Node 物件，而非 kubelet。

根據預設，在控制層傳回已核准的 CertificateSigningRequest 後，新 GKE 節點中的 kubelet 程序會向控制層註冊節點。這種自我註冊工作流程會產生安全風險，遭入侵的 kubelet 可能會註冊含有惡意汙點或標籤的新節點，例如 CVE-2025-5187。

如果您使用 Shielded GKE 節點 (所有 GKE 叢集預設會啟用這項功能)，可以防止 kubelet 註冊節點。相反地，控制層傳回已核准的 CertificateSigningRequest 後，受信任的控制層元件會在 Kubernetes API 中建立新的 Node 物件。GKE 會拒絕 kubelet 建立 Node 物件的所有嘗試。

詳情請參閱控制層節點建立。

存取控管

以下各節提供建議，協助您限制叢集中的未授權存取權。安全工程師和身分與帳戶管理員應採用這些建議，縮小攻擊面並限制未經授權存取造成的影響。

最佳做法

限制叢集探索 API 的存取權

建議：限制從網際網路存取控制層和節點，避免叢集探索 API 端點遭到非預期存取。

根據預設，Kubernetes 建立的叢集會有一組寬鬆的預設 API 探索角色。這些預設角色會將叢集 API 的資訊廣泛提供給各種預設群組，例如 system:authenticated。這些預設角色無法為 GKE 叢集提供有意義的安全防護等級。舉例來說，system:authenticated 群組可以讀取 CustomResources 等 API 的相關資訊，並指派給任何經過驗證的使用者 (包括擁有 Google 帳戶的使用者)。

如要限制叢集探索 API 的存取權，請按照下列步驟操作：

  • 限制控制層存取權：僅使用 DNS 端點存取控制層。如果您使用 IP 端點，請設定授權網路，將存取權限制在一組已知位址範圍內。
  • 設定私人節點：停用節點的外部 IP 位址，讓網路外部的用戶端無法存取節點。

詳情請參閱「關於網路隔離」。

如未啟用這些網路隔離功能，請將所有 API 探索資訊 (尤其是 CustomResources 的結構定義、APIService 定義，以及擴充 API 伺服器託管的探索資訊) 視為公開揭露。

將團隊和環境放在不同的命名空間或叢集

為各個團隊和環境分別建立不同的命名空間或叢集，授予團隊最低的 Kubernetes 存取權限。為每個命名空間或叢集指派成本中心和標籤，以利問責和退款。

您可以搭配使用 IAM 和 RBAC 權限與命名空間，限制使用者在 Cloud de Confiance 控制台上與叢集資源的互動。詳情請參閱「 依命名空間啟用存取權及查看叢集資源」。

在存取權政策中採用最小權限原則

建議做法：僅授予開發人員在命名空間中部署及管理應用程式所需的存取權，尤其是在正式環境中。設計存取控管政策時，請先列出使用者需要在叢集中執行的工作，然後只授予他們執行這些工作所需的權限。

在 GKE 中，您可以使用 IAM 和 Kubernetes 角色式存取控管 (RBAC) 授予資源權限。這些存取控管機制會搭配運作。如要降低存取權管理複雜度，請採取下列做法：

  • 如要授予專案或 Cloud de Confiance 資源的存取權，請使用 IAM 角色。

  • 如要授予叢集中 Kubernetes 資源 (例如命名空間) 的存取權，請使用 RBAC。

如要進一步瞭解如何規劃及設計 IAM 和 RBAC 政策，請參閱下列文件：

使用 Workload Identity Federation for GKE 存取 Cloud de Confiance API

建議做法：如要從 Cloud de Confiance GKE 工作負載存取資源，請使用 Workload Identity Federation for GKE。

建議使用 Workload Identity Federation for GKE 向 Cloud de Confiance API 進行驗證。您可以將各種資源的 IAM 角色授予叢集中的主體，例如特定 Kubernetes ServiceAccount 或 Pod。此外，與靜態權杖檔案等替代方案相比，Workload Identity Federation for GKE 可保護節點上的機密中繼資料，並提供更安全的驗證工作流程。

Autopilot 叢集一律會啟用 Workload Identity Federation for GKE。在 Standard 叢集中，為所有叢集和節點集區啟用 Workload Identity Federation for GKE。此外，請遵循下列建議：

  • 如果您在應用程式程式碼中使用 Cloud de Confiance 用戶端程式庫，請勿將 Cloud de Confiance 憑證發布至工作負載。使用用戶端程式庫的程式碼會自動擷取 GKE 適用的 Workload Identity Federation for GKE 憑證。
  • 對於需要不同身分的每個工作負載，請使用不同的命名空間和 ServiceAccount。將 IAM 權限授予特定 ServiceAccount。

詳情請參閱「從 GKE 工作負載向 API 進行驗證 Cloud de Confiance 」。

如要在貴機構強制執行這項建議，請使用constraints/container.managed.enableWorkloadIdentityFederation 受管理的組織政策限制。如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往「政策詳細資料」

透過群組管理存取權

建議做法：在存取權政策中，將權限授予使用者群組，而非個別使用者。

在群組中管理使用者時，身分管理系統和身分管理員可以修改各群組中的使用者成員資格，集中控管身分。這類管理方式可避免在特定使用者需要更新權限時，更新 RBAC 或 IAM 政策。

您可以在 IAM 或 RBAC 政策中指定 Google 群組。 如需詳細資訊，請參閱下列文件：

如要在貴機構中強制執行這項建議，請使用constraints/container.managed.enableGoogleGroupsRBAC 受管理的組織政策限制。 如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

限制叢集端點的匿名存取權

建議：在所有 Autopilot 和 Standard 叢集中，禁止對健康狀態檢查端點以外的所有叢集端點提出匿名要求。

根據預設，Kubernetes 會將 system:anonymous 使用者和 system:unauthenticated 群組指派給叢集端點的匿名要求。如果 RBAC 政策授予該使用者或群組額外權限，匿名使用者可能會危害服務或叢集本身的安全性。

在 GKE 1.32.2-gke.1234000 以上版本中，您可以將匿名要求可連線的端點集，限制為僅限 /healthz、/livez 和 /readyz Kubernetes API 伺服器健康狀態檢查端點。您必須匿名存取這些健康狀態檢查端點，才能驗證叢集是否正常運作。

如要限制叢集端點的匿名存取權，請使用 gcloud CLI 或 GKE API 建立或更新標準和 Autopilot 叢集時，為 --anonymous-authentication-config 旗標指定 LIMITED。在驗證期間，GKE 會拒絕對叢集端點發出的匿名要求，但健康狀態檢查端點除外。即使 RBAC 政策授予匿名使用者和群組存取權，匿名要求也不會傳送至端點。遭拒的要求會傳回 HTTP 狀態 401。

在 GKE 1.35.0-gke.1171000 以上版本中，系統預設只會在新建叢集上拒絕匿名存取非健康檢查端點。

如要使用組織政策，在組織、資料夾或專案中強制執行這項建議，請使用 resource.anonymousAuthenticationConfig.mode 條件建立自訂限制。如需更多資訊和限制範例，請參閱「使用自訂組織政策限制 GKE 資源的動作」。

請勿僅依賴這項功能保護叢集。導入下列額外安全措施：

GKE 網路安全性

下列各節提供建議，協助您提升叢集中的網路安全性。網路管理員和安全工程師應採用這些建議，保護工作負載和基礎架構免於遭到非預期的外部或內部存取。

最佳做法

限制控制層存取權

建議：啟用以 DNS 為基礎的端點，以便存取控制層，並停用所有以 IP 為基礎的控制層端點。

根據預設，網際網路上的用戶端等外部實體可以連線至控制層。您可以設定網路隔離，限制哪些人可以存取控制層。

如要隔離控制層，請執行下列任一操作：

  • 只使用 DNS 型端點 (建議)：為控制層啟用 DNS 型端點，並停用內部和外部 IP 型端點。所有控制層存取權都必須使用 DNS 端點。您可以使用 VPC Service Controls，控管哪些人可以存取 DNS 型端點。

    如要在貴機構強制執行這項建議，請使用constraints/container.managed.enableControlPlaneDNSOnlyAccess 受管理的組織政策限制。如要在 Cloud de Confiance 控制台查看這項代管限制，請前往「Policy details」(政策詳細資料) 頁面。

    前往「政策詳細資料」

  • 停用以外部 IP 為基礎的端點：移除控制層的外部 IP 位址。虛擬私有雲網路外部的用戶端無法使用外部 IP 位址存取控制層。

    如果您使用 Cloud Interconnect 和 Cloud VPN 等技術，將公司網路連線至虛擬私有雲網路，這個選項就非常適合。

  • 搭配使用授權網路和外部 IP 端點：限制只有受信任的來源 IP 位址範圍，才能存取外部 IP 端點。

    如果您沒有現有的 VPN 基礎架構，或是遠端使用者或分公司透過公用網際網路存取叢集，這個選項就非常適合。

在大多數情況下，請只使用 DNS 型端點存取控制層。如要啟用以 IP 為基礎的端點，請使用授權網路，將控制層存取權限制在下列實體：

  • 您指定的 IP 位址範圍。
  • 與叢集位於相同虛擬私有雲網路中的 GKE 節點。
  • Google 保留用於叢集管理的 IP 位址。

將節點與網際網路隔離

根據預設，所有 GKE 節點都有外部 IP 位址，網際網路上的用戶端可以連線。如要移除這個外部 IP 位址，請啟用私人節點。

如要在貴機構強制執行這項建議，請使用constraints/container.managed.enablePrivateNodes 受管理的組織政策限制。如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往「政策詳細資料」

限制 Pod 之間的網路流量

建議：使用 NetworkPolicy 和/或服務網格控管 Pod 對 Pod 的網路流量。

根據預設，叢集中的每個 Pod 都能與其他 Pod 通訊。限制服務之間的網路存取權，可大幅提高攻擊者在叢集中橫向移動的難度。您的服務也能獲得一定程度的保護，防範意外或蓄意的阻斷服務事件。視需求而定，請使用下列一或兩種方法，限制 Pod 間的流量：

敏感資料保護

下列各節提供加密資料和保護憑證等機密資訊的建議。安全工程師和平台管理員應套用這些建議，降低重要資料遭人擅自存取的風險。

最佳做法

加密使用中的工作負載資料

使用機密 GKE 節點，透過硬體式記憶體加密機制，保護工作負載使用中的資料。您可以根據需求選擇機密運算技術。詳情請參閱「使用機密 GKE 節點加密使用中的工作負載資料」。

將 Secret 儲存在叢集外

建議：使用 Secret Manager 等外部 Secret Manager，將 API 金鑰等機密資料儲存在叢集外部。

在 Kubernetes 中，您可以將叢集中的機密資料儲存在 Secret 中。您可以透過祕密向應用程式提供機密資料，不必將該資料納入應用程式程式碼。不過，將這類資料儲存在叢集中，可能會有下列風險：

  • 凡是能在命名空間中建立 Pod 的使用者，都能讀取該命名空間中任何 Secret 的資料。
  • 只要具備 RBAC 或 IAM 存取權，可讀取所有 Kubernetes API 物件，就能讀取 Secret。

由於存在這些風險，只有在無法以任何其他方式將資料提供給工作負載時，才應在叢集中建立密鑰。建議您按照下列偏好順序，儲存及存取私密資料：

  • Secret Manager 用戶端程式庫：搭配使用 Secret Manager API 和 Workload Identity Federation for GKE，透過應用程式程式碼以程式輔助方式存取密鑰。詳情請參閱「使用用戶端程式庫存取儲存在 GKE 叢集外的 Secret」。
  • Secret Manager 資料做為掛接磁碟區：使用 GKE 適用的 Secret Manager 外掛程式，將機密資料做為掛接磁碟區提供給 Pod。如果您無法修改應用程式程式碼，以使用 Secret Manager 用戶端程式庫，這個方法就很實用。詳情請參閱「搭配使用 Secret Manager 外掛程式與 Google Kubernetes Engine」。

  • 第三方密鑰管理工具：HashiCorp Vault 等第三方工具可為 Kubernetes 工作負載提供密鑰管理功能。這些工具需要比 Secret Manager 更多的初始設定，但比在叢集中建立 Secret 更安全。如要設定第三方密鑰管理工具，請參閱供應商的說明文件。此外，請參考下列建議：

    • 如果第三方工具在叢集中執行，請使用與執行工作負載的叢集不同的叢集。
    • 使用 Cloud Storage 或 Spanner 儲存工具的資料。
    • 使用內部直通式網路負載平衡器，將第三方密碼管理工具公開給在 VPC 網路中執行的 Pod。

  • 使用 Kubernetes Secret (不建議)：如果上述選項都不適合您的用途，您可以將資料儲存為 Kubernetes Secret。Cloud de Confiance 預設會在儲存層加密資料。 這項預設的儲存層加密機制包括儲存叢集狀態的資料庫，該資料庫是以 etcd 或 Spanner 為基礎。此外，您還能使用自己管理的金鑰，在應用程式層加密這些 Secret。詳情請參閱「在應用程式層加密 Secret」。

工作負載安全防護

下列各節提供建議，協助您提升叢集安全性，防範工作負載問題。安全工程師和平台管理員應套用這些建議，提升 GKE 基礎架構的工作負載防護能力。

最佳做法

使用 GKE Sandbox 隔離工作負載

建議：使用 GKE Sandbox，防止惡意程式碼影響叢集節點上的主機核心。

您可以在沙箱環境中執行容器，防範大多數容器跳脫攻擊 (也稱為本機提權攻擊)。如 GKE 安全性公告所述，這類攻擊可讓攻擊者存取容器的主機 VM。攻擊者可以利用這項主機存取權，存取同一 VM 上的其他容器。GKE Sandbox 有助於減少這類攻擊造成的影響。

在下列情況下，請使用 GKE Sandbox：

  • 您有執行不信任程式碼的工作負載。
  • 您希望在攻擊者入侵工作負載中的容器時，將影響降到最低。

詳情請參閱「使用 GKE Sandbox 強化工作負載隔離」。

使用 RBAC 限制工作負載存取權

建議：設計及實作良好的 RBAC 政策，降低工作負載未經授權存取的風險。

Kubernetes Pod 會使用 ServiceAccount 提供的身分執行各種動作，例如存取其他命名空間中的資源，或讀取 Secret 中的資料。請根據對應工作負載的需求，使用 RBAC 限制 ServiceAccount 的權限。為降低工作負載未經授權存取的風險，請實施 RBAC 最佳做法。

以政策為準的強制執行

下列各節提供建議，說明如何使用政策在多個資源中強制執行安全性限制。身分和帳戶管理員以及安全工程師應套用這些建議，確保叢集和工作負載符合機構安全規定。

最佳做法

在 Cloud de Confiance 資源階層中強制執行政策

建議做法：如要在組織、資料夾或專案中強制執行安全措施，請使用組織政策服務。

您可以使用組織政策集中定義限制，並在資源階層的各個層級強制執行這些限制。多種 Cloud de Confiance 產品會發布代管限制，讓您套用該產品的最佳做法建議。舉例來說，GKE 會針對本文中的許多最佳做法，發布代管限制。

如要進一步瞭解如何啟用組織政策，請參閱「建立及管理組織政策」。

在工作負載許可期間強制執行政策

建議：使用許可控制器 (例如 Policy Controller 或 PodSecurity 許可控制器) 檢查傳入的 API 要求，並對這些要求強制執行政策。

准入控制器 會攔截 Kubernetes API 的已驗證授權要求，以便在允許資源保留在 API 中之前，執行驗證或變動工作。

您可以在 GKE 叢集中使用下列方法進行准入控制：

叢集管理

以下各節提供叢集管理建議，例如升級、監控及設定記錄。安全工程師、平台管理員和 SRE 應根據這些建議，維護 GKE 平台的資安態勢。

最佳做法

定期升級 GKE 基礎架構

建議：將 GKE 版本維持在最新狀態，即可使用新的安全防護功能並套用安全性修補程式。使用發布管道、加速修補程式自動升級，以及自動升級節點。

Kubernetes 和 GKE 經常發布新修補程式版本，其中包含安全性改善項目和漏洞修正。對於所有叢集，GKE 會自動將控制層升級至更穩定的子版本和修補程式版本。

如要確保 GKE 叢集執行最新版本，請按照下列步驟操作：

  • 在發布管道註冊叢集。Autopilot 叢集一律會註冊發布管道。
  • 如果叢集位於發布管道中，請啟用加速修補程式自動升級，以便在發布管道中提供安全性修補程式版本時，立即取得這些版本。
  • 如果 Standard 叢集未加入發布管道，請啟用節點自動升級。自 2019 年 6 月起，使用Cloud de Confiance 控制台建立的叢集預設會啟用節點自動升級功能；自 2019 年 11 月 11 日起，使用 GKE API 建立的叢集預設會啟用節點自動升級功能。
  • 如果您使用維護政策，請設定維護期間，讓 GKE 至少每月自動升級節點一次。
  • 如果節點集區未使用節點自動升級功能，請按照自己的排程，至少每月升級一次節點集區。
  • 請追蹤 GKE 安全性公告和 GKE 版本資訊，瞭解安全性修補程式的相關資訊。

啟用安全性公告通知

建議：設定通知，以便在有影響叢集的新安全性公告時收到通知。

只要出現與叢集相關的安全性公告，GKE 就會將這些事件的通知，以訊息形式發布至您設定的 Pub/Sub 主題。您可以透過 Pub/Sub 訂閱項目接收這類通知、整合第三方服務，以及在 Cloud Logging 中接收通知。

如要在組織中強制執行這項建議，請使用 constraints/container.managed.enableSecurityBulletinNotifications 代管組織政策限制。如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往「政策詳細資料」

設定記錄收集

建議做法：為減少作業負擔，並維持記錄的整合檢視畫面，請在叢集之間實作一致的記錄策略。請勿在 Standard 叢集中停用記錄收集功能。

GKE 叢集會將特定記錄傳送至 Google Cloud Observability。您也可以選擇設定收集其他類型的記錄。除了系統和工作負載記錄檔，所有 GKE 叢集都會將下列稽核記錄檔傳送至 Logging：

  • Kubernetes 稽核記錄：依時間順序記錄對 Kubernetes API 伺服器發出的呼叫。Kubernetes 稽核記錄項目可用於調查可疑的 API 要求、收集統計資料，或針對不必要的 API 呼叫建立監控快訊。
  • GKE 稽核記錄：記錄 GKE API 的管理和存取活動。

如需詳細資訊，請參閱下列文件：

如要在貴機構中強制執行這項建議，請使用constraints/container.managed.enableCloudLogging 受管理的組織政策限制。 如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

監控資源是否有安全問題

使用 GKE 資安態勢資訊主頁和 Security Command Center 監控叢集和工作負載，找出潛在問題。您可以使用這些服務，檢查是否有影響 GKE 基礎架構的活躍安全漏洞、威脅和安全性公告。

預設安全性設定

下列各節說明新叢集預設設定的選項，可減輕特定安全疑慮，例如漏洞或風險。安全工程師和平台管理員應驗證現有叢集是否使用這些設定。

最佳做法

停用舊版用戶端驗證方式

建議：停用舊版 API 伺服器驗證方式，例如靜態憑證和密碼。

Kubernetes API 伺服器有多種驗證方法。在 GKE 中，支援的方法包括服務帳戶不記名權杖、OAuth 權杖和 X.509 用戶端憑證。gcloud CLI 會使用 OAuth 權杖，為 GKE 驗證使用者。

靜態密碼等舊版驗證方式會增加叢集遭入侵的攻擊面，因此已停用。在 Autopilot 叢集中，您無法啟用或使用這些驗證方式。

請使用下列其中一種方法向 Kubernetes API 伺服器進行驗證：

  • 使用者：使用 gcloud CLI 讓 GKE 驗證使用者、為叢集產生 OAuth 存取權杖，並將權杖保持在最新狀態。
  • 應用程式：使用 Workload Identity 聯盟，讓應用程式在 Cloud de Confiance 叢集或其他環境中向叢集進行驗證。

如要進一步瞭解如何進行驗證，以及如何停用舊版驗證方式，請參閱「向 Kubernetes API 伺服器進行驗證」。

如要在貴機構強制執行這項建議，請使用constraints/container.managed.disableLegacyClientCertificateIssuance 受管理的組織政策限制。如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往「政策詳細資料」

停用 ABAC

建議做法：使用 IAM 和 RBAC 控制 GKE 中的存取權。請勿啟用屬性式存取控管 (ABAC)。

ABAC 是舊版授權方法，所有 GKE 叢集預設都會停用這項功能，且 Autopilot 叢集無法啟用。

如要在組織中強制執行這項建議，請使用 constraints/container.managed.disableABAC 代管組織政策限制。如要在 Cloud de Confiance 控制台查看這項代管限制，請前往「Policy details」(政策詳細資料) 頁面。

前往政策詳細資料

請保持啟用 DenyServiceExternalIPs 許可控制器

建議：請勿停用 DenyServiceExternalIPs 准入控制器。

這個許可控制器會禁止服務使用 ExternalIP，並防範 GCP-2020-015。在 GKE 1.21 以上版本建立的叢集，預設會啟用這個准入控制器。如果是以較舊的 GKE 版本建立的叢集，請啟用許可控制器：

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
如要在貴機構中強制執行這項建議，請使用constraints/container.managed.denyServiceExternalIPs 受管理的組織政策限制。 如要在 Cloud de Confiance 控制台中查看這項代管限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

後續步驟