如何通过Terraform为GCP Cloud Functions默认App Engine服务账号配置Firebase权限以使用Admin SDK创建自定义认证令牌

我来帮你梳理清楚这个问题的解决步骤，刚好我之前在Terraform管理GCP基础设施时也处理过类似的场景：

1. 如何获取默认的App Engine服务账号？ #

你说得没错，这个账号是项目创建时自动生成的，格式固定为：{你的GCP项目ID}@appspot.gserviceaccount.com。

在Terraform里，你不需要额外去“获取”它，直接通过项目ID拼接即可。如果你的项目ID是通过Terraform变量或者数据源管理的，可以这么写：

# 假设项目ID存储在变量中
variable "project_id" {
  type = string
}

locals {
  app_engine_default_service_account = "${var.project_id}@appspot.gserviceaccount.com"
}

如果是通过google_project数据源获取项目信息，也可以直接用数据源的project_id字段来拼接。

2. 用Terraform给该账号添加角色，且不影响其他服务账号 #

关键是要使用**google_project_iam_member**资源，而不是google_project_iam_binding。前者是给指定角色添加单个成员，不会覆盖该角色下的其他现有成员；后者会替换整个角色的成员列表，容易误删其他权限配置。

针对你需要的Firebase Admin SDK管理员服务代理角色（对应权限角色roles/firebase.admin），Terraform配置示例如下：

resource "google_project_iam_member" "app_engine_firebase_admin" {
  project = var.project_id
  role    = "roles/firebase.admin"
  member  = "serviceAccount:${local.app_engine_default_service_account}"
}

这个配置只会把默认App Engine服务账号添加到roles/firebase.admin角色中，完全不会影响该角色下的其他服务账号，也不会改动其他角色的权限。

3. 这个方案是否最优？ #

你的处理思路是完全正确的：

• 纯GCP Cloud Functions默认确实使用App Engine服务账号作为执行身份，给它添加必要的Firebase权限是最直接的方式。
• 使用无参数的initializeApp()是最佳实践，因为Cloud Functions会自动从环境中加载默认服务账号的凭据，不需要手动配置密钥文件。

如果你追求更细粒度的权限控制，也可以创建一个自定义服务账号，只给它分配Firebase自定义令牌创建所需的最小权限（比如firebase.auth.createCustomToken对应的权限），然后将Cloud Functions配置为使用这个自定义账号执行。不过这种方式需要额外管理服务账号和Cloud Functions的执行身份配置，对于大多数场景来说，给默认App Engine账号添加roles/firebase.admin已经足够简便且安全。

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