能否将同一Kubernetes服务账户（KSA）绑定多个GCP服务账户？

1. 同一个KSA能否绑定多个GSA？ #

不行。Workload Identity通过KSA的iam.gke.io/gcp-service-account注解实现与GSA的关联，这个注解是一对一绑定的——一个KSA只能关联一个GSA，无法同时绑定多个。

2. 让各服务使用对应GSA认证的方案 #

根据你的部署架构，有两种可行方案：

方案A：为每个GSA创建独立KSA #

为每个业务服务对应的GSA创建专属KSA，分别完成Workload Identity绑定，然后在Helm部署时给不同服务指定对应的KSA：

• 创建pubsub-ksa绑定到Pub/Sub的GSA
• 创建storage-ksa绑定到Cloud Storage的GSA
• 创建secret-manager-ksa绑定到Secret Manager的GSA
• 在Helm的values.yaml中为每个服务组件配置对应的serviceAccountName字段

这种方案符合你“各服务使用不同GSA”的权限隔离需求，也是Workload Identity的标准用法。

方案B：单Pod多进程场景的特殊处理 #

如果你的SpringBoot应用是单Pod内运行多个服务进程（无法拆分Pod），可以通过代码层面动态获取临时凭证实现：

• 保持一个KSA绑定到拥有所有服务权限的GSA（不推荐，破坏权限隔离），或者
• 使用工作负载身份联盟，在代码中针对不同服务调用GCP IAM API，获取对应GSA的临时访问凭证（需要额外开发，适合无法拆分Pod的场景）

3. Terraform配置多个KSA与GSA绑定示例 #

以下是Terraform中为每个GSA创建对应KSA并完成绑定的代码示例：

步骤1：创建GSA（如果尚未创建） #

# Pub/Sub服务对应的GSA
resource "google_service_account" "pubsub_gsa" {
  account_id   = "pubsub-gsa"
  display_name = "Pub/Sub Service Account"
}

# Cloud Storage服务对应的GSA
resource "google_service_account" "storage_gsa" {
  account_id   = "storage-gsa"
  display_name = "Cloud Storage Service Account"
}

# Secret Manager服务对应的GSA
resource "google_service_account" "secret_manager_gsa" {
  account_id   = "secret-manager-gsa"
  display_name = "Secret Manager Service Account"
}

步骤2：创建对应KSA并关联GSA #

# Pub/Sub对应的KSA
resource "kubernetes_service_account" "pubsub_ksa" {
  metadata {
    name      = "pubsub-ksa"
    namespace = "your-app-namespace"
    annotations = {
      # 关联对应的GSA邮箱
      "iam.gke.io/gcp-service-account" = google_service_account.pubsub_gsa.email
    }
  }
}

# Cloud Storage对应的KSA
resource "kubernetes_service_account" "storage_ksa" {
  metadata {
    name      = "storage-ksa"
    namespace = "your-app-namespace"
    annotations = {
      "iam.gke.io/gcp-service-account" = google_service_account.storage_gsa.email
    }
  }
}

# Secret Manager对应的KSA
resource "kubernetes_service_account" "secret_manager_ksa" {
  metadata {
    name      = "secret-manager-ksa"
    namespace = "your-app-namespace"
    annotations = {
      "iam.gke.io/gcp-service-account" = google_service_account.secret_manager_gsa.email
    }
  }
}

步骤3：配置IAM绑定，允许KSA impersonate GSA #

# 授权Pub/Sub KSA使用对应的GSA
resource "google_service_account_iam_binding" "pubsub_workload_binding" {
  service_account_id = google_service_account.pubsub_gsa.name
  role               = "roles/iam.workloadIdentityUser"
  members = [
    "serviceAccount:${var.gcp_project_id}.svc.id.goog[your-app-namespace/pubsub-ksa]",
  ]
}

# 授权Storage KSA使用对应的GSA
resource "google_service_account_iam_binding" "storage_workload_binding" {
  service_account_id = google_service_account.storage_gsa.name
  role               = "roles/iam.workloadIdentityUser"
  members = [
    "serviceAccount:${var.gcp_project_id}.svc.id.goog[your-app-namespace/storage-ksa]",
  ]
}

# 授权Secret Manager KSA使用对应的GSA
resource "google_service_account_iam_binding" "secret_manager_workload_binding" {
  service_account_id = google_service_account.secret_manager_gsa.name
  role               = "roles/iam.workloadIdentityUser"
  members = [
    "serviceAccount:${var.gcp_project_id}.svc.id.goog[your-app-namespace/secret-manager-ksa]",
  ]
}

步骤4：Helm中指定对应KSA #

在Helm的values.yaml中为不同服务组件配置对应的serviceAccountName：

# Pub/Sub服务部署配置
pubsubService:
  serviceAccountName: pubsub-ksa

# Cloud Storage服务部署配置
storageService:
  serviceAccountName: storage-ksa

# Secret Manager服务部署配置
secretManagerService:
  serviceAccountName: secret-manager-ksa

注意事项 #

• 确保你的GKE集群已经启用Workload Identity特性
• 所有IAM绑定中的成员格式必须正确：serviceAccount:<项目ID>.svc.id.goog[<命名空间>/<KSA名称>]
• 每个GSA需要提前配置好对应服务的权限（比如Pub/Sub的GSA需要roles/pubsub.publisher或roles/pubsub.subscriber权限）

内容的提问来源于stack exchange，提问作者ankit_