降低多租戶機群中的身分識別相同風險

本頁提供設定及使用機群 Workload Identity 聯盟的最佳做法。這項機群功能可讓您集中設定應用程式的驗證程序，以便跨專案存取 Google Cloud API。如要瞭解採用其他車隊功能的最佳做法，請參閱「規劃車隊功能」。

本頁內容適用於平台管理員和操作員，以及想要盡量減少機群中身分相同相關風險的資安工程師。

閱讀本頁面之前，請先熟悉「關於機群 Workload Identity 聯盟」一文中的概念。

術語

本頁面使用下列術語：

  • Workload Identity Federation for GKE：這項功能可為單一 Google Cloud 專案中的 GKE 工作負載提供身分。
  • Fleet Workload Identity Federation：這項功能可將 Workload Identity Federation for GKE 擴展至整個 Fleet 的工作負載，包括 Google Cloud外部和多個專案中的工作負載。
  • 工作負載身分集區：實體，可為工作負載提供身分，格式與 Identity and Access Management (IAM) 相容。每個叢集都是工作負載身分集區中的身分提供者。

機群中的身分相同性

工作負載身分集區是實體，可為工作負載提供身分，格式須符合 IAM 驗證及授權要求時可用的格式。使用 GKE 適用的工作負載身分聯盟時，每個專案預設都會有固定的 Google 管理工作負載身分集區，且該集區是專案專屬。

透過機群 Workload Identity 聯盟，機群主機專案的 Google 管理工作負載身分識別集區，會成為您註冊至機群的所有叢集的預設工作負載身分識別集區，無論叢集是否位於其他專案或其他雲端。您可以選擇為特定叢集設定自行管理的 workload identity 集區，取代預設集區。

在艦隊 Workload Identity Federation 和 GKE 適用的 Workload Identity Federation 中，您可以使用 IAM 允許政策，將特定 Google Cloud資源的角色授予叢集中的實體，例如 Kubernetes ServiceAccount 或 Pod。在允許政策中，您可以使用 主體 ID 參照這些實體，這是 IAM 可讀取的命名語法。主體 ID 包含叢集使用的 Workload Identity 集區名稱，以及選取叢集中特定實體的其他資訊。舉例來說，下列主體 ID 會選取命名空間中的 Kubernetes ServiceAccount：

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

在本例中，下列欄位包含主體的相關資訊：

  • PROJECT_NUMBER：機群主機專案的專案編號。
  • WORKLOAD_IDENTITY_POOL_NAME：工作負載身分集區的名稱。
  • NAMESPACE：命名空間的名稱。
  • SERVICEACCOUNT：Kubernetes ServiceAccount 的名稱。

叢集會產生短期 OAuth 2.0 存取權杖，用來驗證對 Google Cloud API 的要求。這些存取權杖包含建立要求的實體主體 ID。IAM 會使用主體 ID，確保允許政策授權實體執行所要求的作業。

身分識別一致性對多租戶 Fleet 的影響

主體 ID 會導致身分相同，也就是說，環境中與特定主體 ID 相符的任何實體，在 IAM 中都會視為相同。使用 GKE 的單一專案工作負載身分聯合時，身分相同性會套用至專案中所有共用主體 ID 的實體。不過，使用機群 Workload Identity 聯盟時，無論叢集專案為何，只要整個機群中的實體共用主體 ID，就會套用相同的身分。

舉例來說，使用前一節中的主體 ID，來自使用相同 ServiceAccount、相同命名空間和相同工作負載身分識別集區的 Pod 要求，無論叢集或專案為何，都會取得相同的主體 ID。

如果 Fleet 只在 Fleet 主機專案中執行叢集，身分識別相同性的影響與 GKE 適用的 Workload Identity Federation 相同。不過，如果機群有在其他專案中執行的叢集，身分識別一致性會擴及機群中的所有已註冊叢集。

Fleet 身分識別一致性的複雜度範例

以下範例情境說明實作機群 Workload Identity Federation 時，可能發生的身分相同性複雜情況。每個情境都會提供可能的解決方法，協助您應對這些複雜情況。

單一專案機群，所有叢集都已註冊，且使用相同的工作負載身分集區

請參考下列車隊設定：

  • 機群的所有成員叢集都位於機群主專案中。
  • 專案中的所有叢集都是機群成員。
  • 所有叢集都使用相同的工作負載身分識別集區。

在這個情境中，機群的所有成員叢集都位於機群主專案中，且該專案中的所有叢集都是機群成員。

圖表：專案中的所有叢集都位於同一個機群

如「機群的身分相同性影響」一節所述，在此情境中使用機群 Workload Identity Federation，與使用 Workload Identity Federation for GKE 相同，不會有額外風險。

單一專案機群，其中註冊了部分叢集，且具有相同的工作負載身分集區

請參考下列車隊設定：

  • 機群包含兩個叢集，兩者都在機群主專案中執行。
  • 機群主專案包含不屬於機群成員的第三個叢集。
  • 這個叢集不是 Fleet 成員，但已啟用 GKE 適用的工作負載身分聯盟。
  • 專案中的所有叢集都使用相同的工作負載身分集區

圖表：專案中的部分叢集位於同一機群。

完成這項設定後，您在專案中某個叢集內授予實體的任何角色，都會套用至專案中與主體 ID 相符的其他實體。這可能會導致您不慎將權限授予車隊以外的實體。舉例來說，將角色授予主體 ID，在命名空間中選取特定服務帳戶，會產生下列影響：

  • 在指定命名空間中執行的工作負載，以及在車隊成員叢集中使用指定服務帳戶的工作負載，都會共用存取權。
  • 在第三個非成員叢集中執行的工作負載，如果使用相同的命名空間和服務帳戶名稱，也會取得相同存取權。

下列建議或許有助於解決這個複雜問題：

  • 設定機群成員叢集，以使用自行管理的工作負載身分集區 (搶先版)。這可確保機群成員叢集中的實體與非成員叢集有不同的主體 ID。詳情請參閱「Authenticate to Google Cloud APIs from mixed-trust fleet workloads」。

  • 建立專屬機群主機專案，並使用機構政策防止專屬機群主機專案執行叢集。這會將全機群工作負載身分識別集區信任網域，與 GKE 專案層級信任網域分開。只有已註冊的叢集會共用機群範圍的工作負載身分識別集區。

    這些建議適用於 Google Cloud 和附加叢集上的叢集。

多專案機群，已註冊部分叢集，且工作負載身分識別集區相同

請參考下列車隊設定：

  • 機群包含在兩個專案中執行的成員叢集： Google Cloudproject-1 和 project-2。
  • project-1 是機群主專案。project-1 中的所有叢集都是機群成員。
  • project-2 包含一個機群成員叢集和一個未註冊的叢集。
  • project-1 中的所有叢集都會使用專案的 Google 管理 workload identity 集區，這也是預設的機群 workload identity 集區。
  • project-2 中的機群成員叢集會使用全機群工作負載身分集區。

圖表：機群包含兩個專案的叢集。

在這種情況下，您授予機群主專案中實體的任何權限，也會套用至 project-2 中的成員叢集實體，因為這些實體共用同一個工作負載身分集區。

如要解決這項複雜問題，請建立專屬的 Google Cloud 專案，做為機群主機專案。project-1 和 project-2 中的機群成員叢集預設會共用專屬專案的工作負載身分集區。然後，您可以在主體 ID 中使用 project-1 的工作負載身分集區，將專案範圍的存取權授予 project-1 中的叢集。

防止建立類似的身分

如要在車隊中確保身分一致性，您必須謹慎實作存取權控管機制，防止有意或無意建立類似身分。舉例來說，假設您要授予命名空間中，使用特定 ServiceAccount 的所有 Pod 存取權。如果有人在其他機群成員叢集中建立該命名空間和 ServiceAccount，該叢集中的 Pod 會取得相同存取權。

為減少發生這個問題的機率，請使用授權機制，只允許一組信任的使用者建立、更新或刪除命名空間和 Kubernetes 服務帳戶。

  • 在 IAM 中，下列權限可提供這項存取權：

    • container.namespaces.*
    • container.serviceAccounts.*

  • 如果是 Kubernetes 角色型存取控制 (RBAC)，下列 ClusterRole 範例會設定特殊存取權，以便與這些 Kubernetes 資源互動：

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["create","delete","update","patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: serviceaccount-admin
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create","delete","update","patch","impersonate"]

後續步驟