關於 GKE 中的服務帳戶

本頁說明 Google Kubernetes Engine (GKE) 中的服務帳戶，以及這些帳戶如何為應用程式提供身分。您將瞭解不同類型的服務帳戶，以及在 GKE 中驗證資源存取權時，何時應使用各類型服務帳戶，而不必依賴個人憑證。

本頁面適用於安全專家和作業人員，他們負責建立及管理服務帳戶，以便與 GKE 應用程式互動。如要進一步瞭解 Google Cloud 內容中提及的常見角色和範例工作，請參閱常見的 GKE Enterprise 使用者角色和工作。

Kubernetes 服務帳戶和 IAM 服務帳戶

下表說明 Kubernetes 服務帳戶與 IAM 服務帳戶之間的主要差異：

GKE 中的服務帳戶類型
Kubernetes ServiceAccount
  • Kubernetes API 伺服器中的 ServiceAccount 物件
  • 範圍限定為叢集中的 Kubernetes 命名空間
  • 為叢集內的 Pod 提供身分
IAM 服務帳戶
  • 使用 IAM API 管理
  • 專案範圍 Google Cloud
  • 為專案中的應用程式提供身分

Kubernetes ServiceAccount

Kubernetes 服務帳戶是在叢集層級管理，並以 ServiceAccount 物件的形式存在於 Kubernetes API 伺服器中。Kubernetes 說明文件和 GKE 說明文件通常會使用「ServiceAccount」ServiceAccount一詞，將這些 Kubernetes 資源與其他環境 (例如 IAM) 中的服務帳戶區分開來。

您可以在命名空間中建立 Kubernetes ServiceAccount，然後使用 Pod 資訊清單中的 serviceAccountName 欄位，將該 ServiceAccount 指派給 Pod。節點上的 kubelet 程序會取得指派 ServiceAccount 的短期不記名權杖，並將權杖掛接為 Pod 中的投影磁碟區。

短期存取權權杖是由 API 伺服器簽署的 JSON Web Token (JWT)，也就是 OpenID Connect (OIDC) 提供者。如要驗證不記名權杖，請在 GKE API 中呼叫 projects.locations.clusters.getJwks 方法，取得叢集的公開驗證金鑰。

Kubernetes ServiceAccount 憑證遭駭

如果 Kubernetes 服務帳戶憑證遭盜用，請使用下列任一選項撤銷憑證：

  • 重新建立 Pod：不記名權杖會繫結至每個專屬 Pod UID，因此重新建立 Pod 會使先前的憑證失效。
  • 重新建立 Kubernetes 服務帳戶：不記名權杖會繫結至 Kubernetes API 中 ServiceAccount 物件的 UID。刪除 ServiceAccount，然後建立具有相同名稱的新 ServiceAccount。由於新 ServiceAccount 的 UID 不同，先前的權杖會失效。
  • 執行憑證輪替：這項作業會撤銷叢集中的所有 Kubernetes 服務帳戶憑證。輪替作業也會變更叢集的 CA 憑證和 IP 位址。詳情請參閱憑證輪替。

IAM 服務帳戶

IAM 服務帳戶是在專案層級使用 IAM API 管理。您可以使用這些服務帳戶執行動作，例如以程式輔助方式呼叫 API，以及管理在產品中執行的應用程式權限。 Google CloudGoogle Cloud

詳情請參閱 IAM 服務帳戶總覽。

GKE 服務代理

IAM 服務代理程式是 IAM 服務帳戶，可管理。 Google Cloud

GKE 會使用 Kubernetes Engine 服務代理程式，代表您管理叢集資源的生命週期，例如節點、磁碟和負載平衡器。啟用 GKE API 時，這個服務代理人會擁有網域 container-engine-robot.iam.gserviceaccount.com，並在您的專案中獲得 Kubernetes Engine 服務代理人角色 (roles/container.serviceAgent)。

這個服務代理程式的 ID 如下：

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

PROJECT_NUMBER 是您的數字專案編號。

如果移除專案中服務代理程式的權限，可以按照「錯誤 400/403：缺少帳戶的編輯權限」一文中的操作說明復原權限。

預設 GKE 節點服務帳戶

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

如果貴機構強制執行 iam.automaticIamGrantsForDefaultServiceAccounts 機構政策限制，專案中的預設 Compute Engine 服務帳戶可能不會自動取得 GKE 的必要權限。

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

如要將 roles/container.defaultNodeServiceAccount 角色授予 Compute Engine 預設服務帳戶，請完成下列步驟：

主控台

  1. 前往「歡迎」頁面：

    前往「歡迎」

  2. 在「專案編號」欄位中，按一下「複製到剪貼簿」。
  3. 前往「IAM」(身分與存取權管理)IAM 頁面：

    前往「身分與存取權管理」頁面

  4. 按一下「授予存取權」。
  5. 在「New principals」(新增主體) 欄位中，指定下列值： 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     將 PROJECT_NUMBER 替換為您複製的專案編號。
  6. 在「Select a role」(選取角色) 選單中，選取「Kubernetes Engine Default Node Service Account」(Kubernetes Engine 預設節點服務帳戶) 角色。
  7. 按一下 [儲存]。

gcloud

  1. 找出 Google Cloud 專案編號：
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    將 PROJECT_ID 替換為您的專案 ID。

    輸出結果會與下列內容相似：

    12345678901
  2. 將 roles/container.defaultNodeServiceAccount 角色指派給 Compute Engine 預設服務帳戶：
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    將 PROJECT_NUMBER 替換為上一步的專案編號。

除非您要遷移至使用者管理的服務帳戶，否則請勿停用預設的 Compute Engine 服務帳戶。

特定服務帳戶的適用時機

您使用的服務帳戶類型取決於要為應用程式提供的身分類型，如下所示：

  • 為 Pod 提供要在叢集中使用的身分：使用 Kubernetes ServiceAccount。每個 Kubernetes 命名空間都有 default ServiceAccount，但建議您為每個命名空間中的每項工作負載，建立新的最低權限 ServiceAccount。
  • 為 Pod 提供可在叢集外部使用的身分：使用 Workload Identity Federation for GKE。透過 GKE 適用的工作負載身分聯盟，您可以在 IAM 政策中將 Kubernetes 資源 (例如 ServiceAccount) 指定為主體。舉例來說，從 Pod 呼叫 Secret Manager 或 Spanner 等 API 時，請使用 GKE 適用的工作負載身分聯盟。 Google Cloud
  • 為節點提供預設身分：建立 GKE 叢集或節點時，請使用自訂的最低權限 IAM 服務帳戶。如果您未使用自訂 IAM 服務帳戶，GKE 會使用 Compute Engine 預設服務帳戶。

後續步驟