GCP访问Secret Manager提示secretmanager.versions.access权限被拒绝

最高频诱因：Cloud Shell默认凭证覆盖 #

Cloud Shell 预置了当前登录用户的gcloud身份凭证，Python SDK的默认凭证查找逻辑存在fallback机制：如果手动指定的密钥文件路径解析失败、权限不足，SDK会自动回退加载Cloud Shell内置凭证，不会抛出凭证加载错误，直接用无权限的内置身份发起请求返回403。
按以下步骤修复：

• 不要用相对路径指定密钥文件，先在Cloud Shell终端执行realpath keyfile.json拿到密钥文件的绝对路径，替换代码里的环境变量值，示例：

  os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = '/home/user_12345/keyfile.json'
  

• 清除本地残留的ADC缓存，终端执行：

  rm -f ~/.config/gcloud/application_default_credentials.json
  

• 初始化客户端前添加环境变量，强制SDK跳过GCE元数据服务探测，避免加载Cloud Shell内置默认凭证：

  os.environ['NO_GCE_CHECK'] = 'true'
  

次高频诱因：IAM配置不生效 #

哪怕给服务账号绑定了Owner、Secret Accessor等角色，以下配置错误也会导致权限不生效：

• 角色绑定层级错误：不要只在组织、文件夹层级绑定角色，直接进入Secret Manager控制台找到目标密钥，在密钥单独的权限配置页给服务账号授予Secret Manager Secret Accessor角色，跳过权限继承逻辑。
• 权限传播延迟：IAM角色绑定后最长需要2分钟完成全局同步，绑定完成后等待120秒再重试，不要配置完立刻测试。

低频诱因：访问控制策略拦截 #

• 若项目配置了VPC Service Controls服务边界，Cloud Shell默认不在边界信任范围内，请求会被拦截，返回的报错会刻意提示「资源可能不存在」避免泄露边界信息，需要将Cloud Shell出口加入边界允许列表，或在边界内的计算实例上运行代码。
• 若组织配置了「禁止服务账号静态密钥认证」的全局策略，你生成的keyfile.json会被直接拒绝认证，需要联系组织管理员放开权限，或改用服务账号模拟的方式认证，不要使用静态密钥。

有效性校验 #

修复后先执行凭证校验逻辑，确认当前加载的凭证正确，再调用密钥接口：

from google.auth import default
from google.cloud import secretmanager

# 读取当前生效的凭证
creds, loaded_project = default()
# 打印凭证对应的服务账号邮箱，必须是你创建的、已授权的目标服务账号
# 如果打印出你的个人用户邮箱、Compute Engine默认服务账号邮箱，说明凭证加载逻辑仍有问题
print(f"当前生效凭证账号: {creds.service_account_email}")

# 显式传入凭证初始化客户端
secret_client = secretmanager.SecretManagerServiceClient(credentials=creds)
secret_name = f'projects/{project_id}/secrets/{secret_id}/versions/{version_id}'
response = secret_client.access_secret_version(request={"name": secret_name})

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