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

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

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

您應該已熟悉下列項目:

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

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

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

Google Cloud 環境設計

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

最佳做法

規劃 Google Cloud 資源結構

建議做法:實作企業基礎藍圖,這是根據我們的最佳做法,為企業環境建立的完整基礎。

Google Cloud 組織、資料夾和專案的架構會影響資安態勢。設計這些基礎資源時,請確保能大規模控管及保護各項服務。

規劃多租戶環境

建議做法:實作 Google Cloud 和 GKE 多租戶企業平台最佳做法。

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

如需詳細資訊,請參閱下列文件:

使用標記將 Google Cloud 資源分組

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

標記是中繼資料,可附加至組織、資料夾和專案中的資源,用於識別Google Cloud 資源階層中的業務維度。您可以將標記附加至 GKE 叢集和節點集區,然後使用這些標記,依條件套用 IAM 政策和防火牆政策。

如需詳細資訊,請參閱下列文件:

規劃虛擬私有雲網路

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

虛擬私有雲網路設計和使用的功能會影響網路安全。根據 Google Cloud資源階層和安全性目標規劃網路。如需詳細資訊,請參閱下列文件:

設計事件應變計畫

建議做法:建立並維護符合安全性和可靠性目標的事件應變計畫。

即使您實施了所有可能的安全控管措施,仍可能發生安全性事件。事件應變計畫可協助您找出安全控管措施中的潛在漏洞、快速有效地應對各種事件,並減少服務中斷期間的停機時間。詳情請參閱下列文件:

Google Cloud 網路安全

下列各節提供虛擬私有雲網路的安全性建議。網路架構師和網路管理員應套用這些建議,減少網路層級的攻擊面,並限制非預期網路存取的影響。

最佳做法

使用最小權限防火牆規則

建議做法:建立防火牆規則時,請採用最小權限原則,僅提供必要用途的存取權。請盡可能確保防火牆規則不會與 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 代管組織政策限制。如要在 Google Cloud 控制台查看這項代管限制,請前往「Policy details」(政策詳細資料) 頁面。

前往「政策詳細資料」

使用 Container-Optimized OS 節點映像檔

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

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

如需詳細資訊,請參閱下列文件:

節點安全性設定

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

最佳做法

使用 Shielded GKE 節點

建議:在所有叢集和節點集區中,啟用 Shielded GKE 節點、安全啟動和完整性監控功能。

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

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

如要進一步瞭解如何啟用這些功能,請參閱「使用 Shielded GKE 節點」。

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

前往「政策詳細資料」

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

建議:停用 kubelet 唯讀通訊埠,並將使用 10255 通訊埠的所有工作負載改為使用更安全的 10250 通訊埠。

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

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

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

前往「政策詳細資料」

停用節點自我註冊

建議做法:對於使用受防護 GKE 節點的叢集,請使用受信任的控制層元件建立 Node 物件,而非 kubelet。

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

如果您在執行 GKE 1.37.1-gke.3020000 以上版本的新叢集中使用 Shielded GKE 節點,受信任的控制層元件會註冊 Node 物件,而非 kubelet 程序,進而降低這項風險。在舊版中建立的叢集,即使升級後,仍會繼續使用 kubelet 自行註冊。如要保護這些叢集,請手動啟用控制層節點建立功能。詳情請參閱「建立控制層節點」。

存取控管

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

最佳做法

限制叢集探索 API 的存取權

建議做法:限制從網際網路存取控制層和節點,避免意外存取叢集探索 API 端點。

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

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

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

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

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

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

為各個團隊和環境分別建立不同的命名空間或叢集,授予團隊最低的 Kubernetes 存取權限。為每個命名空間或叢集指派成本中心和標籤,以便追蹤責任歸屬和費用。

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

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

建議:僅授予開發人員在命名空間中部署及管理應用程式所需的存取權,尤其是在正式環境中。設計存取控管政策時,請規劃使用者需要在叢集中執行的工作,並僅授予執行這些工作所需的權限。

在 GKE 中,您可以使用 IAM 和 Kubernetes 角色式存取控管 (RBAC) 授予資源權限。這些存取控管機制會搭配運作。如要降低管理存取權的複雜度,請按照下列步驟操作:

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

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

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

使用 Workload Identity Federation for GKE 存取 Google Cloud API

建議做法:如要從 GKE 工作負載存取 Google Cloud 資源,請使用 Workload Identity Federation for GKE。

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

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

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

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

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

前往「政策詳細資料」

使用群組管理存取權

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

以群組管理使用者時,身分管理系統和身分管理員可以透過修改各種群組中的使用者成員資格,集中控管身分。這種管理方式可避免每次特定使用者需要更新權限時,都必須更新 RBAC 或 IAM 政策。

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

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

前往「政策詳細資料」

限制匿名存取叢集端點

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

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

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

如要限制對叢集端點的匿名存取,請在使用 gcloud CLI 或 GKE API 建立或更新 Standard 和 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 代管組織政策限制。如要在 Google Cloud 控制台查看這項代管限制,請前往「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 代管組織政策限制。如要在 Google Cloud 控制台查看這項代管限制,請前往「Policy details」(政策詳細資料) 頁面。

前往「政策詳細資料」

限制 Pod 之間的網路流量

建議做法:使用 NetworkPolicy、服務網格或兩者,控管 Pod 對 Pod 的網路流量。

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

  • 如需負載平衡、服務授權、節流、配額和指標等功能,請使用 Cloud Service Mesh。如果您有大量不同的服務,且這些服務之間有複雜的互動,服務網格就非常實用。
  • 如需基本的流量控管機制,請使用 Kubernetes NetworkPolicies。如要確認 NetworkPolicies 是否正常運作,請設定網路政策記錄。

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

    前往「政策詳細資料」

敏感資料保護

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

最佳做法

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

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

將 Secret 儲存在叢集外

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

在 Kubernetes 中,您可以將機密資料儲存在叢集的 Secret 中。您可以使用 Secret 將機密資料提供給應用程式,而不必將該資料納入應用程式程式碼。不過,將這類資料儲存在叢集內會有下列風險:

  • 只要能在命名空間中建立 Pod,就能讀取該命名空間中任何 Secret 的資料。
  • 只要具備 RBAC 或 IAM 權限,可讀取所有 Kubernetes API 物件,就能讀取 Secret。

基於上述風險,只有在無法以其他方式將資料提供給工作負載時,才應在叢集中建立 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」。
  • 第三方 Secret 管理工具:HashiCorp Vault 等第三方工具可為 Kubernetes 工作負載提供 Secret 管理功能。這些工具需要比 Secret Manager 更多的初始設定,但比在叢集中建立 Secret 更安全。如要設定第三方工具來管理 Secret,請參閱供應商的說明文件。此外,請參考下列建議:

    • 如果第三方工具在叢集中執行,請使用與執行工作負載的叢集不同的叢集。
    • 使用 Cloud Storage 或 Spanner 儲存工具的資料。
    • 使用內部直通式網路負載平衡器,將第三方 Secret 管理工具公開給在虛擬私有雲網路中執行的 Pod。
  • 使用 Kubernetes Secret (不建議):如果上述選項都不適用於您的用途,可以將資料儲存為 Kubernetes Secret。Google Cloud 預設在儲存層加密資料。 這項預設儲存層加密機制包含儲存叢集狀態的資料庫,該資料庫是以 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 最佳做法。

政策型違規處置

下列各節提供使用政策在多項資源中強制執行安全限制的建議。身分和帳戶管理員以及資安工程師應套用這些建議,確保叢集和工作負載符合組織的安全規定。

最佳做法

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

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

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

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

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

建議做法:使用 Policy Controller 或 PodSecurity 許可控制器等許可控制器,審查傳入的 API 要求,並對這些要求強制執行政策。

許可控制器會攔截經過驗證和授權的 Kubernetes API 要求,先執行驗證或變更工作,再允許資源保留在 API 中。

您可以使用下列方法,在 GKE 叢集中進行許可控制:

叢集管理

下列各節提供長期管理叢集的建議,例如升級、監控及設定記錄。資安工程師、平台管理員和 SRE 應採用這些建議,維護 GKE 平台的資安態勢。

最佳做法

定期升級 GKE 基礎架構

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

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

為確保 GKE 叢集執行最新版本,請按照下列步驟操作:

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

啟用安全性公告通知

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

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

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

前往「政策詳細資料」

設定記錄收集

建議:為減少作業負擔並維持記錄的整合檢視,請在叢集間實施一致的記錄策略。請勿停用 Standard 叢集的記錄收集功能。

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

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

如需詳細資訊,請參閱下列文件:

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

前往「政策詳細資料」

監控資源,找出安全問題

使用 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 Federation,讓Google Cloud 或其他環境中的應用程式向叢集進行驗證。

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

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

前往「政策詳細資料」

不啟用 ABAC

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

ABAC 是舊版授權方法,在所有 GKE 叢集中預設為停用,且無法在 Autopilot 叢集中啟用。

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

前往「政策詳細資料」

讓 DenyServiceExternalIPs 許可控制器保持啟用狀態

建議:請勿停用 DenyServiceExternalIPs 許可控制器。

這個許可控制器會禁止 Service 使用 ExternalIP,並緩解 GCP-2020-015。在 GKE 1.21 以上版本建立的叢集中,預設會啟用這個許可控制器。如果叢集最初是在舊版 GKE 上建立,請啟用許可控制器:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
如要在組織中強制執行這項建議,請使用 constraints/container.managed.denyServiceExternalIPs 代管組織政策限制。 如要在 Google Cloud 控制台查看這項代管限制,請前往「Policy details」(政策詳細資料) 頁面。

前往「政策詳細資料」

後續步驟