關於 GKE 中的服務帳戶

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

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

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 中的投影磁碟區。根據預設，這個預估量會以「kube-api-access-」前置字串開頭命名。以這個前置字元開頭的所有磁碟區都會由 GKE 管理，因此您無法修改這些磁碟區的大小。如要更準確地監控磁碟用量，請從監控設定中排除以 kube-api-access- 前置字元開頭的磁碟區。

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

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

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

CLUSTER_PROJECT_NUMBER 是包含 GKE 叢集的專案專案編號。

Kubernetes Engine 預設節點服務代理

Kubernetes 1.33 以上版本的叢集會使用 Kubernetes Engine 預設節點服務代理程式，支援 Kubernetes 節點的記錄和監控功能。啟用 GKE API 時，這個服務代理人會獲得專案的 Kubernetes Engine 預設節點服務代理人角色 (roles/container.defaultNodeServiceAgent)，且網域為 gcp-sa-gkenode.iam.gserviceaccount.com。

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

service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER 是包含 GKE 叢集的專案專案編號。

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

節點服務帳戶

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

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

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

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

節點服務帳戶的電子郵件地址

節點服務帳戶的電子郵件地址取決於服務帳戶類型，如下所示：

  • 預設 Compute Engine 服務帳戶：

    CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.com

    將 CLUSTER_PROJECT_NUMBER 替換為包含叢集的專案編號，例如 1234567890。

  • 自訂服務帳戶：

    SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com

    更改下列內容：

    • SERVICE_ACCOUNT_NAME：服務帳戶名稱。
    • SERVICE_ACCOUNT_PROJECT_ID：包含服務帳戶的 Google Cloud 專案 ID。

節點服務帳戶和專案服務代理程式

建立叢集或節點集區時，叢集專案中的服務代理程式會使用附加至節點的服務帳戶，執行映像檔提取等工作。根據預設，叢集專案中的服務代理程式具有下列存取權，可存取該專案中的節點服務帳戶：

  • 專案中的 Compute Engine 服務代理程式可以為相同專案中的節點服務帳戶建立存取權杖。
  • 專案中的 GKE 服務代理程式可以模擬同一專案中的節點服務帳戶。

部分機構會使用專屬專案管理所有服務帳戶。如果節點服務帳戶不在叢集專案中，叢集專案中的服務代理程式就無法建立權杖或模擬該服務帳戶。您必須在服務帳戶中，將下列角色授予叢集專案中的服務代理：

  • 在服務帳戶上，對叢集專案中的 Compute Engine 服務代理人授予服務帳戶憑證建立者 (roles/iam.serviceAccountTokenCreator) 角色。
  • 將服務帳戶的服務帳戶使用者 (roles/iam.serviceAccountUser) 授予叢集專案中的 GKE 服務代理程式。

詳情請參閱「設定跨專案的服務帳戶用量」。

特定服務帳戶的適用時機

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

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

後續步驟