很多团队把数据库密码、第三方API Key、Webhook Token直接写在环境变量、配置文件甚至镜像里。短期看省事，长期看风险很高：镜像被拉取、CI日志泄露、配置文件误传、离职账号未清理，都可能让密钥变成长期暴露点。
Google Cloud官方建议，Cloud Run服务需要API Key、密码、证书等敏感信息时，应把这些信息存储在Secret Manager中，再以环境变量或文件挂载方式提供给容器。本文用gcloud演示一套可落地流程：创建Secret、给Cloud Run运行时服务账号授予最小权限、把Secret注入服务、发布新版本、设置轮换通知，并用Cloud Audit Logs查询访问记录。
一、架构：密钥不要跟着镜像走
推荐链路是：
开发者/CI → Secret Manager创建密钥版本 → Cloud Run服务账号按需读取 → 容器以环境变量或文件使用 → Cloud Audit Logs记录访问。
这里有三个原则：
- 镜像只包含代码，不包含真实密钥；
- Cloud Run服务账号只拿需要的Secret访问权；
- 轮换密钥后必须验证新版本是否生效。
Secret Manager并不会让你不用做权限治理。它只是把密钥从“到处散落”收回到可控位置，后续仍要靠IAM、版本管理、轮换机制和审计日志。
二、准备变量
exportPROJECT_ID="your-project-id"exportREGION="asia-east1"exportSERVICE_NAME="api-service"exportSECRET_NAME="db-password"exportRUN_SA="cloudrun-api-sa"gcloud configsetproject"$PROJECT_ID"gcloud servicesenablesecretmanager.googleapis.com run.googleapis.com创建Cloud Run运行时服务账号：
gcloud iam service-accounts create"$RUN_SA"\--display-name="Cloud Run API runtime service account"exportRUN_SA_EMAIL="$RUN_SA@$PROJECT_ID.iam.gserviceaccount.com"生产环境不要直接使用项目默认计算服务账号。每个服务使用独立运行时服务账号，权限边界更清晰。
三、创建Secret和初始版本
gcloud secrets create"$SECRET_NAME"\--replication-policy="automatic"\--labels=service=api,env=prod,owner=platform添加初始版本：
printf"replace-with-real-password"|\gcloud secrets versionsadd"$SECRET_NAME"--data-file=-查看Secret：
gcloud secrets describe"$SECRET_NAME"\--format="yaml(name,replication,labels,createTime)"注意：命令示例里的值不要直接复制到生产命令历史里。真实密钥应通过安全输入方式、CI受保护变量或密钥生成流程写入，避免被shell history和日志记录。
四、授予Cloud Run最小访问权限
只给运行时服务账号访问指定Secret的权限：
gcloud secrets add-iam-policy-binding"$SECRET_NAME"\--member="serviceAccount:$RUN_SA_EMAIL"\--role="roles/secretmanager.secretAccessor"验证IAM：
gcloud secrets get-iam-policy"$SECRET_NAME"\--format="table(bindings.role,bindings.members)"不要把roles/secretmanager.secretAccessor直接授予所有开发者、默认服务账号或项目级别广泛成员。能按Secret授权，就不要按项目授权。
五、把Secret注入Cloud Run
Cloud Run支持两种常见方式：作为环境变量注入，或作为文件挂载。官方文档提醒，Cloud Run推荐把敏感信息存储在Secret Manager中，并将Secret提供给容器使用。
方式一：作为环境变量。
gcloud run deploy"$SERVICE_NAME"\--image="gcr.io/$PROJECT_ID/api-service:latest"\--region="$REGION"\--service-account="$RUN_SA_EMAIL"\--set-secrets="DB_PASSWORD=$SECRET_NAME:latest"方式二：作为文件挂载。
gcloud run services update"$SERVICE_NAME"\--region="$REGION"\--set-secrets="/secrets/db/password=$SECRET_NAME:latest"选择建议：
- 环境变量适合应用启动时读取一次的配置；
- 文件挂载适合按文件路径读取、并可能需要观察版本变化的场景；
- 无论哪种方式，都要确认应用日志不会打印密钥值。
六、版本切换和回滚
Secret Manager支持多个版本。添加新版本：
printf"new-password-value"|\gcloud secrets versionsadd"$SECRET_NAME"--data-file=-查看版本：
gcloud secrets versions list"$SECRET_NAME"\--format="table(name,state,createTime)"如果Cloud Run使用:latest，新部署或新实例读取时会指向最新版本。但生产环境更建议在关键变更时使用明确版本号做灰度验证：
gcloud run services update"$SERVICE_NAME"\--region="$REGION"\--set-secrets="DB_PASSWORD=$SECRET_NAME:2"如果新密钥异常，可以回滚到上一版本：
gcloud run services update"$SERVICE_NAME"\--region="$REGION"\--set-secrets="DB_PASSWORD=$SECRET_NAME:1"七、设置轮换通知
Secret Manager的轮换计划不是自动替你生成新密码，而是在设定周期到达时向Pub/Sub主题发送通知。官方文档说明，Secret Manager会基于你指定的轮换频率和时间向关联的Pub/Sub主题发通知。
创建Pub/Sub主题：
gcloud pubsub topics create secret-rotation-events为Secret设置轮换计划：
gcloud secrets update"$SECRET_NAME"\--rotation-period="2592000s"\--next-rotation-time="2026-08-28T00:00:00Z"\--topics="secret-rotation-events"后续可以让Cloud Functions、Cloud Run Job或工单系统订阅这个主题，触发“生成新密钥 → 更新下游系统 → 添加Secret版本 → 灰度发布 → 验证 → 禁用旧版本”的流程。
不要把轮换通知误解成“密钥自动安全了”。真正的轮换必须包含下游凭据更新和应用验证。
八、审计日志查询
Secret Manager支持Cloud Audit Logs。官方文档说明，Google Cloud服务会生成记录管理活动和访问活动的审计日志。对Secret Manager来说，谁创建、修改、访问Secret，都应能在审计体系里追踪。
查询管理活动：
resource.type="audited_resource" protoPayload.serviceName="secretmanager.googleapis.com" protoPayload.methodName:"google.cloud.secretmanager"查询Secret访问：
resource.type="audited_resource" protoPayload.serviceName="secretmanager.googleapis.com" protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion"如果查不到数据访问日志，检查项目是否启用了Data Access Audit Logs。很多环境默认只记录管理活动，数据读取类日志需要单独启用。
九、验收清单
| 验收项 | 命令/方法 | 通过标准 |
|---|---|---|
| Secret存在 | gcloud secrets describe | 能看到标签和复制策略 |
| 版本存在 | versions list | 至少一个enabled版本 |
| IAM最小权限 | get-iam-policy | 仅运行时SA可读 |
| Cloud Run注入 | services describe | secrets配置正确 |
| 应用验证 | 健康检查/业务接口 | 能使用新密钥 |
| 审计日志 | Logs Explorer | 能看到访问记录 |
| 轮换通知 | Pub/Sub订阅 | 能收到轮换事件 |
十、常见坑
第一，把Secret写进镜像。镜像生命周期很长，一旦泄露很难彻底清理。
第二，项目级广泛授权。Secret访问权应尽量绑定到具体Secret和具体服务账号。
第三，使用latest但不验证。latest方便，但关键业务最好用明确版本灰度。
第四，设置了轮换计划却没有轮换执行器。轮换通知只是提醒，不会自动改数据库密码。
第五，没有启用数据访问审计日志。出了问题只能知道谁改了Secret，不知道谁读了Secret。
第六，应用日志打印配置。读取Secret后不要把值写入启动日志、异常日志或调试接口。
结语
Cloud Run使用Secret Manager并不复杂，关键是把流程闭环：创建Secret、最小权限、注入服务、版本切换、轮换通知和审计日志。做到这些后，密钥不再跟着镜像和配置文件到处跑，安全边界会清楚很多。
如需国际云服务器合规开户流程咨询、Google Cloud Cloud Run部署、Secret Manager密钥治理、安全加固和运维支持，可通过平台私信说明业务地区、服务规模、密钥类型和合规要求。客户本人完成实名、验证码、支付和合同确认；本文不含返佣链接，不承诺百分百安全。
官方资料
- Configure secrets for Cloud Run services：https://docs.cloud.google.com/run/docs/configuring/services/secrets
- Create rotation schedules in Secret Manager：https://docs.cloud.google.com/secret-manager/docs/secret-rotation
- About rotation schedules：https://docs.cloud.google.com/secret-manager/docs/rotation-recommendations
- Secret Manager Audit Logging：https://docs.cloud.google.com/secret-manager/docs/audit-logging
- Secret Manager documentation：https://docs.cloud.google.com/secret-manager/docs