強化叢集安全性

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

您應該已熟悉下列項目：

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

如要在整個機構中實作並強制執行本文的最佳做法，請考慮使用下列服務：

  • 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 會建立預設虛擬私有雲防火牆規則，啟用系統功能並強制執行良好的安全做法。如果您建立的寬鬆防火牆規則優先順序高於預設防火牆規則 (例如允許所有輸入流量的防火牆規則，用於偵錯)，叢集可能會遭到未經授權的存取。

使用共用虛擬私有雲進行跨專案流量傳輸

建議做法：使用共用虛擬私有雲，讓多個專案中的資源透過內部 IP 位址相互通訊。

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

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

使用個別網路隔離環境

建議做法：為預先發布、測試和正式環境使用個別的共用虛擬私有雲網路。

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

無法變更的安全性設定

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

使用最低權限的 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 控制台中查看這項受管理限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

使用 Container-Optimized OS 節點映像檔

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

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

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

節點安全性設定

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

最佳做法

使用受防護的 GKE 節點

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

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

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

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

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

前往政策詳細資料

停用不安全的 kubelet 唯讀連接埠

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

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

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

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

前往政策詳細資料

存取權控管

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

最佳做法

限制叢集探索 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) 授予資源權限。這些存取權控管機制會搭配運作。為降低存取權管理複雜度，請採取下列措施：

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

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

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

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

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

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

Autopilot 叢集一律會啟用 Workload Identity Federation for GKE。在標準叢集中，為所有叢集和節點集區啟用 GKE 適用的工作負載身分聯盟。此外，請按照下列建議操作：

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

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

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

前往政策詳細資料

使用群組管理存取權

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

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

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

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

前往政策詳細資料

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

建議：在所有 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。

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

請勿單獨使用這項功能來保護叢集安全。實作下列額外安全措施：

GKE 網路安全

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

最佳做法

限制控制層存取權

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

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

如要隔離控制平面，請執行下列其中一項操作：

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

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

    前往政策詳細資料

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

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

  • 搭配外部 IP 型端點使用授權網路：將外部 IP 型端點的存取權限制為僅限信任的來源 IP 位址範圍。

    如果您不具備既有的 VPN 基礎架構，或是遠端使用者或分公司透過公開網際網路存取叢集，建議選擇此選項。

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

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

將節點與網際網路隔離

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

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

前往政策詳細資料

限制 Pod 之間的網路流量

建議：使用 NetworkPolicies、服務網格或兩者，控管 Pod 對 Pod 的網路流量。

根據預設，叢集中的每個 Pod 都能與其他 Pod 通訊。限制服務間的網路存取權後，攻擊者會更難以在叢集內橫向移動。您的服務也能獲得部分保護，防範意外或刻意阻斷服務的情形。視需求而定，您可以採用下列一或兩種方法，限制 Pod 間的流量：

機密資料保護

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

最佳做法

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

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

在叢集外部儲存密鑰

建議：使用 Secret Manager 等外部密鑰管理工具，在叢集外部儲存 API 金鑰等敏感資料。

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

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

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

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

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

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

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

工作負載安全性

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

最佳做法

使用 GKE Sandbox 隔離工作負載

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

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

在下列情境中使用 GKE Sandbox：

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

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

限制工作負載自行修改的能力

建議做法：使用准入控制器，防止工作負載自行修改，或防止修改有風險的工作負載屬性，例如 ServiceAccount。

特定 Kubernetes 工作負載 (尤其是系統工作負載) 有權自行修改。舉例來說，部分工作負載會自動垂直擴縮。雖然自我修改很方便，但如果攻擊者已入侵節點，就能在叢集中進一步擴大影響範圍。舉例來說，攻擊者可能會讓命名空間中的工作負載變更自身，以在相同命名空間中以權限較高的 ServiceAccount 執行。

除非必要，否則請勿授予 Pod 自行修改的權限。如果某些 Pod 必須自行修改，請使用 Policy Controller 限制工作負載可變更的內容。舉例來說，您可以使用 NoUpdateServiceAccount 限制範本，防止 Pod 變更其 ServiceAccount。建立政策時，請從限制中排除任何叢集管理元件，如下列範例所示：

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

以政策為準的強制執行

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

最佳做法

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

建議：如要在機構、資料夾或專案中強制執行安全措施，請使用 Organization Policy Service。

您可以使用機構政策集中定義限制，並在資源階層的各個層級強制執行。各種 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 控制台中查看這項受管理限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

設定記錄檔收集作業

建議：如要降低作業負擔，並維持記錄檔的統整檢視畫面，請在叢集採用一致的記錄策略。請勿在標準叢集中停用記錄收集功能。

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

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

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

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

前往政策詳細資料

監控資源是否有安全性問題

使用 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 聯盟，讓應用程式在其他環境中向叢集進行驗證。Google Cloud

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

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

前往政策詳細資料

維持停用 ABAC

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

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

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

前往政策詳細資料

請保持啟用 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 受管理的組織政策限制。 如要在 Google Cloud 控制台中查看這項受管理限制，請前往「政策詳細資料」頁面。

前往政策詳細資料

後續步驟