为何google_storage_bucket_iam_policy未覆盖项目级存储权限？

核心原因 #

1. GCP IAM权限是累加生效的 #

GCP的权限规则遵循累加原则——只要用户在任意层级（组织、文件夹、项目、资源）被授予了允许的权限，就会拥有该权限，低层级的策略无法覆盖高层级的允许权限。你给email_2设置的是项目级storage.objects.create权限，这个权限会自动继承到项目下所有GCS存储桶，包括B1。

2. google_storage_bucket_iam_policy的作用范围有限 #

这个Terraform资源仅负责完全替换存储桶自身的IAM策略，它只能管理存储桶层级的IAM绑定，无法修改或覆盖项目、组织等更高层级的IAM设置。也就是说，它只会清空并替换B1自己的IAM规则，但项目级的权限规则依然独立存在，且会作用到B1上。

实现预期效果的方法 #

如果要让email_2无法在B1中创建对象，有两种可行方案：

• 方案一：移除项目级权限（不推荐，可能影响项目内其他存储桶或资源）
  直接删除项目中给email_2授予的storage.objects.create权限，这样继承到B1的权限就会消失。

• 方案二：添加存储桶级拒绝规则（推荐，精准控制）
  在B1的IAM策略中添加拒绝绑定，拒绝规则的优先级高于允许权限，即使项目级有允许权限，拒绝规则也会生效。用Terraform实现的示例代码如下：

# 给email_2添加存储桶级的创建权限拒绝规则
resource "google_storage_bucket_iam_binding" "deny_email2_b1_create" {
  bucket = "B1"
  role   = "roles/storage.objects.create"
  members = [
    "user:email_2@yourdomain.com",
  ]
  condition {
    title       = "DenyEmail2CreateInB1"
    description = "明确禁止email_2在B1存储桶创建对象"
    expression  = "true"
  }
}

或者使用GCP的Deny Policy资源更灵活地配置拒绝规则：

resource "google_storage_bucket_deny_policy" "deny_email2_b1" {
  bucket = "B1"
  name   = "deny-email2-create"
  rule {
    deny_rule {
      denied_principals = ["user:email_2@yourdomain.com"]
      denied_permissions = ["storage.objects.create"]
    }
    description = "禁止email_2在B1创建对象"
  }
}

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