使用Direct WIF时get-gke-credentials缺container.clusters.get权限

问题根因 #

使用Direct Workload Identity Federation模式时，GitHub的身份（仓库/分支/用户）会被直接映射为GCP中的身份主体，但这个主体默认没有访问GKE集群的权限，导致调用get-gke-credentials时缺少container.clusters.get权限。

解决方案 #

1. 确认映射的GCP身份主体 #

查看你创建的Workload Identity Provider的属性映射规则，确定GitHub Actions对应的GCP身份格式。例如：

• 仓库级映射的主体格式：

  principalSet://iam.googleapis.com/projects/[PROJECT_ID]/locations/global/workloadIdentityPools/[POOL_ID]/repo:[OWNER]/[REPO_NAME]
  

• 限定特定分支的映射主体格式：

  principalSet://iam.googleapis.com/projects/[PROJECT_ID]/locations/global/workloadIdentityPools/[POOL_ID]/repo:[OWNER]/[REPO_NAME]:ref:refs/heads/dev
  

2. 给身份主体授予GKE集群访问权限 #

使用gcloud命令给上述身份主体绑定包含container.clusters.get权限的角色，推荐使用预定义的roles/container.clusterViewer角色（包含查看集群的必要权限）：

gcloud projects add-iam-policy-binding my-project \
  --member="principalSet://iam.googleapis.com/projects/299900345299/locations/global/workloadIdentityPools/github/repo:your-username/your-repo" \
  --role="roles/container.clusterViewer"

替换命令中的your-username/your-repo为你的GitHub仓库路径，my-project为GCP项目ID。

若需要更细粒度的权限，可创建仅包含container.clusters.get的自定义角色，再绑定给该主体。

3. 验证权限配置 #

通过模拟GitHub Actions的身份验证权限是否生效：

1. 从GitHub Actions日志中下载生成的凭证文件（如gha-creds-c9c4d62169250d9a.json）到本地。
2. 使用该凭证登录gcloud：

   gcloud auth login --cred-file=gha-creds-c9c4d62169250d9a.json
   

3. 尝试获取GKE集群信息：

   gcloud container clusters describe preprod --location us-central1 --project my-project
   

   若命令能成功返回集群详情，说明权限配置正确。

4. 检查属性映射规则 #

确保Workload Identity Provider的属性映射规则匹配你的GitHub Actions触发条件。例如，若仅允许dev分支的推送触发动作，映射规则需包含分支属性，避免身份匹配错误导致权限失效。

补充说明 #

Direct Workload Identity Federation模式确实无需创建中间服务账号，但GCP仍需将GitHub身份与具体资源权限绑定——这是容易忽略的点，因为多数资料聚焦于服务账号 impersonation 场景，而Direct模式是直接将外部身份（GitHub）与GCP权限关联。

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