使用Terraform部署GCP与Google Workspace资源时的认证权限及应用授权异常问题

我来帮你梳理下这个问题的核心原因和解决办法——你遇到的403权限不足，本质是因为Google Workspace的管理API和普通GCP资源的认证逻辑不一样，普通的应用默认凭据（ADC）方式没法满足Workspace的域级操作需求。

问题根源 #

你用gcloud auth application-default login获取的是个人用户的OAuth令牌，虽然你手动加了scopes，但Workspace的目录角色管理这类操作，需要的是域范围委派的权限——简单说就是需要一个能代表整个Workspace域执行管理操作的身份，而普通用户令牌没有这个权限。另外，“低安全应用设置”早就被Google废弃了，完全起不到作用，不用再折腾这个了。

正确的解决步骤 #

我们需要切换到服务账号+域范围委派的方案，具体操作如下：

1. 创建并配置GCP服务账号

   • 登录GCP控制台，找到IAM与Admin > 服务账号，创建一个新的服务账号；
   • 给这个服务账号分配必要的GCP权限（如果还要管理GCP资源的话，比如项目编辑权限）；
   • 关键一步：在服务账号详情页，找到“域范围委派”，勾选“启用Google Workspace域范围委派”，记下页面上的客户端ID，后面要用到。

2. 在Google Workspace后台配置域范围委派

   • 登录你的Workspace admin控制台，进入安全 > API控制 > 域范围委派；
   • 点击“添加新的客户端ID”，把刚才记下的服务账号客户端ID填进去；
   • 在“OAuth范围”里输入你需要的scopes，比如：
     https://www.googleapis.com/auth/admin.directory.rolemanagement,https://www.googleapis.com/auth/admin.directory.user
   • 保存设置，这个操作可能需要几分钟生效。

3. 下载服务账号密钥文件

   • 回到GCP控制台的服务账号页面，找到刚才创建的服务账号，点击“密钥” > “添加密钥” > “创建新密钥”，选择JSON格式，下载后保存到本地安全的位置。

4. 修改Terraform的Provider配置

   • 对于googleworkspace provider，我们需要指定服务账号密钥，并且指定要模拟的Workspace管理员账号（也就是你之前手动操作的那个管理员邮箱）：

   provider "googleworkspace" {
     customer_id              = var.workspace_customer_id
     credentials              = file("/path/to/your-service-account-key.json")
     impersonated_user_email  = "your-super-admin@your-domain.com"
   }
   

   • 如果你想统一用这个服务账号管理GCP资源，google provider也可以配置成用这个密钥：

   provider "google" {
     project     = var.project
     region      = "us-central1"
     zone        = "us-central1-c"
     credentials = file("/path/to/your-service-account-key.json")
   }
   

5. 启用Admin SDK Directory API

   • 在GCP控制台的API库中，搜索“Admin SDK”，找到后点击启用这个API——Workspace的目录操作依赖这个API，必须启用。

验证测试 #

配置完成后，你可以先通过gcloud命令验证权限是否正常：

gcloud auth activate-service-account --key-file=/path/to/your-service-account-key.json
gcloud config set auth/impersonate_service_account your-super-admin@your-domain.com
# 测试调用Workspace目录API，比如列出角色
gcloud admin directory roles list

如果这个命令能正常返回结果，那Terraform的配置就应该能正常运行了。

额外注意点 #

• 用来模拟的impersonated_user_email必须是Workspace的超级管理员账号，普通管理员可能权限不够；
• 域范围委派的scopes要准确，不要漏写你需要的权限；
• 服务账号密钥文件要妥善保管，不要提交到代码仓库里。

备注：内容来源于stack exchange，提问作者thomas