GitHub Action部署含Google Cloud Secret的Firebase函数时出现403权限拒绝问题求助

看起来你遇到的核心问题是：本地部署包含secrets: ['MY_SECRET']的Cloud Function完全正常，但通过GitHub Action用服务账号部署时，出现secretmanager.versions.get权限被拒绝的报错，即使已经给服务账号配置了Secret Manager Secret Accessor角色。结合你提到的项目名称和项目ID的差异，我整理了几个关键排查和解决步骤：

1. 强制在部署命令中使用项目ID而非名称 #

你注意到Secret Manager中显示的资源ID是projects/123456789/secrets/MY_SECRET（数字项目ID），但报错里用的是projects/my-project/secrets/MY_SECRET/versions/latest（项目名称），这很可能是问题的关键。虽然Firebase CLI通常能通过项目名称解析到对应的ID，但在CI/CD环境中，偶尔会出现解析偏差或者缓存问题，导致资源定位错误。

修改GitHub Action中的部署命令，明确指定项目ID：

npx firebase-tools deploy --project 123456789

这样能确保CLI直接定位到正确的项目，避免名称和ID不匹配带来的权限校验问题。

2. 验证服务账号的权限绑定是否正确 #

即使你已经添加了Secret Manager Secret Accessor角色，也要做以下确认：

• 登录Google Cloud Console的IAM页面，找到你的GitHub Action使用的服务账号，确认该角色是绑定在数字项目ID对应的项目下，而不是其他项目（比如同名的测试项目）。
• 检查角色的权限范围：Secret Manager Secret Accessor角色确实包含secretmanager.versions.get和secretmanager.secrets.get这两个必要权限，但如果是手动添加的自定义角色，可能会遗漏。可以在IAM角色详情页查看权限列表确认。
• 测试服务账号的本地访问权限：下载服务账号的密钥文件到本地，运行以下命令测试是否能访问Secret：

  export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/service-account-key.json"
  gcloud secrets versions access latest --secret=MY_SECRET --project=123456789
  

如果这个命令失败，说明服务账号的权限确实有问题；如果成功，那问题大概率出在GitHub Action的环境配置上。

3. 检查GitHub Action的环境配置细节 #

• 确保Firebase CLI认证正确：确认你在GitHub Action中是通过服务账号密钥正确认证的，比如是否设置了GOOGLE_APPLICATION_CREDENTIALS环境变量，或者使用了firebase login:ci生成的token（如果用token的话，要确保该token对应的账号有足够权限）。
• 统一Firebase CLI版本：本地部署用的CLI版本和GitHub Action中的版本可能不一致，不同版本对Secret的处理逻辑可能有差异。在部署命令中指定固定版本，比如：

  npx firebase-tools@13.10.2 deploy --project 123456789
  

  版本号和你本地使用的保持一致即可。

4. 确认Secret的状态 #

虽然本地部署正常，但还是要快速确认：

• MY_SECRET确实存在于目标项目中，并且至少有一个版本（即latest版本存在）。
• Secret的名称完全匹配（大小写敏感），比如函数代码里的MY_SECRET和Cloud中的名称没有拼写错误。

按照以上步骤排查，尤其是第一步指定项目ID，应该能解决你遇到的403权限问题。

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