Terraform中google_project_iam与google_service_account_iam的差异及适用场景

一、google_project_iam 与 google_service_account_iam 的核心差异及适用场景 #

核心差异 #

• 作用范围：
  • google_project_iam：针对整个GCP项目的IAM权限管理，控制身份对项目内所有资源的访问权限（比如创建虚拟机、操作Cloud Storage桶等）。
  • google_service_account_iam：针对**单个GCP服务账号（SA）**的权限管理，包括两个方向：一是控制哪些身份能使用/管理该SA；二是给该SA本身赋予访问其他资源的权限。

适用场景 #

• google_project_iam：
  • 给团队成员分配项目级通用权限（比如项目编辑者、查看者角色）。
  • 给某个SA授予项目内所有资源的批量权限（比如允许SA读写项目下所有GCS桶）。
• google_service_account_iam：
  • Workload Identity场景：绑定Kubernetes服务账号到GCP SA，允许K8s工作负载以GCP SA的身份访问GCP资源。
  • 精细化控制SA的使用权限（比如只允许特定用户/SA扮演目标SA）。
  • 给SA授予特定资源的权限（比如允许某SA仅访问指定的Cloud SQL实例）。

二、iam_policy、iam_binding、iam_member 的区别及场景案例 #

这三个是IAM资源下的子类型，核心区别在于对现有权限的影响方式：

• iam_policy：完全替换资源的整个IAM策略，会清除所有原有绑定，风险极高。
• iam_binding：针对单个角色，替换该角色下的所有成员，原有成员会被全部覆盖。
• iam_member：针对单个角色增量添加单个成员，不会影响该角色下的其他现有成员，日常使用最安全。

1. google_project_iam 下的案例 #

iam_policy（谨慎使用）

适用于完全重置项目IAM策略的场景，比如项目初始化或彻底清理权限：

resource "google_project_iam_policy" "project_admin_policy" {
  project     = "my-gcp-project-id"
  policy_data = data "google_iam_policy" "project_admin_policy".policy_data
}

data "google_iam_policy" "project_admin_policy" {
  binding {
    role = "roles/owner"
    members = [
      "user:admin@example.com",
      "serviceAccount:admin-sa@my-gcp-project-id.iam.gserviceaccount.com",
    ]
  }
}

注意：执行后项目原有的所有IAM绑定会被清空，仅保留上述配置的成员。

iam_binding

适用于统一替换某一角色下所有成员的场景，比如更新项目查看者列表：

resource "google_project_iam_binding" "project_viewers" {
  project = "my-gcp-project-id"
  role    = "roles/viewer"

  members = [
    "user:alice@example.com",
    "user:bob@example.com",
  ]
}

执行后，项目中原有roles/viewer角色的成员会被替换为alice和bob。

iam_member（日常常用）

适用于给项目增量添加权限，不影响现有配置：

resource "google_project_iam_member" "add_editor" {
  project = "my-gcp-project-id"
  role    = "roles/editor"
  member  = "user:charlie@example.com"
}

该操作仅给charlie添加项目编辑者权限，原有编辑者不受影响。

2. google_service_account_iam 下的案例 #

iam_policy（谨慎使用）

适用于完全重置某SA的IAM策略，比如仅允许指定身份使用该SA：

resource "google_service_account_iam_policy" "sa_restrict_access" {
  service_account_id = "my-sa@my-gcp-project-id.iam.gserviceaccount.com"
  policy_data        = data "google_iam_policy" "sa_restrict_access".policy_data
}

data "google_iam_policy" "sa_restrict_access" {
  binding {
    role = "roles/iam.serviceAccountUser"
    members = [
      "user:admin@example.com",
      "serviceAccount:k8s-sa@my-gcp-project-id.iam.gserviceaccount.com",
    ]
  }
}

执行后该SA的所有原有IAM绑定会被清空，仅保留上述配置的成员。

iam_binding

适用于统一替换能使用某SA的身份列表，比如批量更新Workload Identity绑定：

resource "google_service_account_iam_binding" "sa_workload_identities" {
  service_account_id = "my-gcp-sa@my-gcp-project-id.iam.gserviceaccount.com"
  role               = "roles/iam.workloadIdentityUser"

  members = [
    "serviceAccount:my-gcp-project-id.svc.id.goog[my-k8s-ns/my-k8s-sa-1]",
    "serviceAccount:my-gcp-project-id.svc.id.goog[my-k8s-ns/my-k8s-sa-2]",
  ]
}

执行后，该SA的roles/iam.workloadIdentityUser角色下的原有成员会被替换为上述两个K8s SA。

iam_member（Workload Identity标准配置）

这是Workload Identity最常用的配置方式，增量添加单个K8s SA到GCP SA的绑定：

resource "google_service_account_iam_member" "workload_identity_binding" {
  service_account_id = "my-gcp-sa@my-gcp-project-id.iam.gserviceaccount.com"
  role               = "roles/iam.workloadIdentityUser"
  member             = "serviceAccount:my-gcp-project-id.svc.id.goog[my-k8s-ns/my-k8s-sa]"
}

该操作仅允许指定的K8s SA扮演目标GCP SA，不会影响该SA的其他权限设置。

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