如何管理客户 Google Cloud 项目的权限与费用？

结论

实际项目通常建议选择方案 3：项目和 Cloud Billing account 归客户所有，服务方通过 IAM 获得部署和运维所需的权限。

这种安排的权责关系更清楚：

• 客户直接向 Google 支付云费用，账目和税务关系明确。
• 项目、日志、数据、配额和长期资源始终归客户所有。
• 合作结束后，客户撤销服务方的 IAM 权限即可，无需迁移项目或更换结算主体。
• 服务方只收取开发、部署或运维费用，无需代垫云费用。
• 客户可以自行查看成本、设置预算和管理访问权限。

方案 2 在技术上可行，但通常只适合过渡期，或者双方已经明确约定资源归属的情况。关联客户的 billing account 不会将项目所有权转移给客户。项目仍在原来的 organization 或个人账号资源层级中。

推荐的资源和权限结构

建议采用以下结构：

客户的 Google Cloud Organization
└── Folder（可选）
    └── Project
        ├── 客户管理员：Owner 或项目管理权限
        ├── 服务方团队：部署和运维权限
        └── 客户的 Cloud Billing account

日常开发不要依赖共享 Google 账号。客户和服务方成员应使用各自的身份，再通过 IAM 分配权限。自动部署应使用专用 service account，并尽量采用 Workload Identity Federation 或短期凭据。

推荐实施步骤

1. 由客户创建项目

客户可以在 Google Cloud Console 中创建项目，也可以使用命令行：

gcloud projects create CUSTOMER_PROJECT_ID \
  --name="Customer Production" \
  --organization=CUSTOMER_ORG_ID

如果客户通过 folder 管理环境，可以改用：

gcloud projects create CUSTOMER_PROJECT_ID \
  --name="Customer Production" \
  --folder=CUSTOMER_FOLDER_ID

生产、测试和开发环境通常应拆分到不同项目，例如：

customer-app-prod
customer-app-staging
customer-app-dev

2. 关联客户自己的 billing account

先查看当前身份有权访问的 billing account：

gcloud billing accounts list

再将项目与 billing account 关联：

gcloud billing projects link CUSTOMER_PROJECT_ID \
  --billing-account=CUSTOMER_BILLING_ACCOUNT_ID

执行者需要同时具备以下权限：

• billing account 上的项目关联权限，例如 roles/billing.user
• 项目上的结算关联修改权限，例如 roles/billing.projectManager

客户的 Organization Policy、IAM Deny policy 或企业内部审批流程也可能限制这些权限的授予。

3. 授予服务方管理权限

客户应按照服务方的实际工作范围授予最小必要权限，不要默认分配 roles/owner。

例如，授予项目查看权限：

gcloud projects add-iam-policy-binding CUSTOMER_PROJECT_ID \
  --member="user:developer@example.com" \
  --role="roles/viewer"

如果由一个团队负责，可以使用 Google Group：

gcloud projects add-iam-policy-binding CUSTOMER_PROJECT_ID \
  --member="group:gcp-operators@example.com" \
  --role="roles/viewer"

之后根据实际使用的产品增加相应角色，例如 Cloud Run、GKE、Cloud SQL 或 Compute Engine 的管理角色。部分预定义管理员角色包含的权限较多，正式环境中最好先查看权限清单：

gcloud iam roles describe roles/run.admin

CI/CD 不应长期使用个人账号。可以创建用于部署的 service account：

gcloud iam service-accounts create deployer \
  --project=CUSTOMER_PROJECT_ID \
  --display-name="Deployment service account"

创建后，只授予流水线实际需要的角色。

如果必须采用方案 2

采用方案 2 需要满足以下条件：

1. 项目由你创建或管理。
2. 客户已有可用的 Cloud Billing account。
3. 客户愿意在该 billing account 上授权你的身份。
4. 你有权修改项目的结算关联。

客户需要在其 billing account 上向你的 Google 身份授予 Billing Account User：

gcloud billing accounts add-iam-policy-binding \
  CUSTOMER_BILLING_ACCOUNT_ID \
  --member="user:operator@example.com" \
  --role="roles/billing.user"

你还需要在目标项目上拥有 roles/billing.projectManager，然后执行：

gcloud billing projects link YOUR_PROJECT_ID \
  --billing-account=CUSTOMER_BILLING_ACCOUNT_ID

关联完成后，可以检查结果：

gcloud billing projects describe YOUR_PROJECT_ID

如果客户不愿直接授予你的身份访问 billing account，也可以让客户的 Billing Account Administrator 执行关联。对于一次性的关联操作，这种方式通常更符合最小权限原则。

需要注意的是，客户将 billing account 关联到你的项目后，需要承担该项目产生的费用，但不会因此自动获得项目管理权、资源访问权或数据所有权。这些权限仍需通过项目 IAM 单独授予。

各方案的适用性

成本管理建议

客户应在自己的 billing account 下设置预算和告警。预算既可以通过 Console 创建，也可以使用 Billing Budgets API 或 Terraform 管理。

Terraform 示例：

resource "google_billing_budget" "project_budget" {
  billing_account = var.billing_account_id
  display_name    = "Production monthly budget"

  budget_filter {
    projects = [
      "projects/${var.project_number}"
    ]
  }

  amount {
    specified_amount {
      currency_code = "USD"
      units         = "1000"
    }
  }

  threshold_rules {
    threshold_percent = 0.5
  }

  threshold_rules {
    threshold_percent = 0.9
  }

  threshold_rules {
    threshold_percent = 1.0
  }
}

Cloud Billing Budget 默认只负责监控和通知，并不是硬性消费上限。达到预算后，虚拟机、数据库和其他资源不会自动停止。若要自动处理超出预算的情况，需要结合 Pub/Sub、Cloud Functions 或其他自动化机制。相关规则必须谨慎设计，以免直接停止重要的生产服务。

详细费用还可以导出到 BigQuery，按项目、服务、SKU 或标签进行分析。成本管理中可以采用以下做法：

• 每个客户使用独立项目。
• 为资源统一设置 labels 或 tags。
• 分离生产、测试和开发环境。
• 配置异常费用通知。
• 定期检查闲置磁盘、静态 IP、快照、日志存储和网络出口费用。
• 限制高成本 API 的配额，但不要将配额视为完整的成本上限。

需要避免的做法

不要只图方便，长期把客户项目放在个人账号的控制之下。即使客户可以查看费用，后续仍可能出现这些问题：

• 合作终止后需要交接项目和迁移数据。
• 双方对谁有权删除、导出或恢复数据产生争议。
• billing account 与项目控制权分属不同主体。
• 个人账号因离职、停用等原因无法继续使用或恢复。
• 审计日志和安全责任的边界不明确。
• 代付费用引发税务、发票和合同问题。

除非你提供的是合同中明确约定的托管云服务，否则更实用的安排仍然是：客户拥有 organization、项目和 billing account，服务方通过独立身份、用户组或 service account 获得最小必要权限。

备注：内容仅供参考。