使用服务账号在CI/CD部署Go App至App Engine遇权限不足问题

你遇到的是部署Go标准环境App Engine应用时，服务账号无法获取GCR临时镜像元数据的403权限错误，以下是具体调试和解决方案：

一、验证服务账号权限的实际有效性 #

• 本地用服务账号密钥测试：将GitHub Action中使用的服务账号密钥下载到本地，执行gcloud auth activate-service-account --key-file=你的密钥文件.json，然后运行gcloud app deploy（用你项目的配置），看是否复现相同错误。如果本地也报错，说明权限配置本身有问题；如果本地正常，问题出在GitHub Action的环境配置（比如密钥未正确加载、环境变量错误）。
• 确认角色绑定方式：检查服务账号的Storage Admin角色是直接绑定到账号本身，还是通过组继承。组权限可能存在生效延迟，建议直接给服务账号绑定角色。
• 用IAM权限测试工具验证：在Google Cloud控制台的IAM页面找到该服务账号，点击"测试权限"，输入us.gcr.io/myprojectid/app-engine-tmp/路径，测试是否拥有storage.objects.get权限（获取镜像元数据必须的权限）。

二、补充GCR/Artifact Registry相关权限 #

虽然Storage Admin角色理论上覆盖GCR操作，但由于GCR与Artifact Registry的整合，部分场景需要额外角色：

• 添加Container Registry Viewer角色：针对GCR镜像的读取权限，确保服务账号能拉取镜像元数据。
• 如果项目已迁移到Artifact Registry，添加Artifact Registry Reader角色：部分App Engine部署会自动使用Artifact Registry存储临时镜像，需要对应权限。

三、排查镜像本身的问题 #

• 检查临时镜像是否存在：登录Google Cloud控制台的Container Registry（或Artifact Registry），查看us.gcr.io/myprojectid/app-engine-tmp/app/default/ttl-18h路径下是否存在报错中的镜像标签。如果镜像不存在，可能是部署过程中镜像上传失败导致的前置问题。
• 手动拉取镜像测试：用授权后的服务账号执行docker pull us.gcr.io/myprojectid/app-engine-tmp/app/default/ttl-18h:65ff63ae-0547-4731-b625-ca7612b30c97，如果拉取失败，说明权限确实不足；如果能拉取，问题可能出在App Engine部署服务的内部权限传递。

四、检查组织级别的访问限制 #

• 组织政策限制：确认项目所在的Google Cloud组织是否有禁止外部服务账号访问镜像仓库的政策（比如"限制对Container Registry的访问"类政策）。
• VPC Service Controls：如果项目启用了VPC服务控制，需要确保GitHub Action的请求IP在允许的访问范围内，或者改用Cloud Build作为部署中间层（Cloud Build在VPC控制范围内，可避免IP限制）。

五、关于Artifact Registry变更的影响 #

近期GCR逐步迁移到Artifact Registry，部分新创建的App Engine项目会默认使用Artifact Registry存储部署镜像。如果你的项目属于这种情况，仅配置Storage Admin可能不够，需要额外给服务账号添加Artifact Registry的相关角色（如Artifact Registry Admin或Reader），确保对镜像仓库的读写权限。

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