很多团队把数据库密码、第三方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写进镜像。镜像生命周期很长，一旦泄露很难彻底清理。

第二，项目级广泛授权。Secret访问权应尽量绑定到具体Secret和具体服务账号。

第三，使用latest但不验证。latest方便，但关键业务最好用明确版本灰度。

第四，设置了轮换计划却没有轮换执行器。轮换通知只是提醒，不会自动改数据库密码。

第五，没有启用数据访问审计日志。出了问题只能知道谁改了Secret，不知道谁读了Secret。

第六，应用日志打印配置。读取Secret后不要把值写入启动日志、异常日志或调试接口。

结语

Cloud Run使用Secret Manager并不复杂，关键是把流程闭环：创建Secret、最小权限、注入服务、版本切换、轮换通知和审计日志。做到这些后，密钥不再跟着镜像和配置文件到处跑，安全边界会清楚很多。

如需国际云服务器合规开户流程咨询、Google Cloud Cloud Run部署、Secret Manager密钥治理、安全加固和运维支持，可通过平台私信说明业务地区、服务规模、密钥类型和合规要求。客户本人完成实名、验证码、支付和合同确认；本文不含返佣链接，不承诺百分百安全。

官方资料

1. Configure secrets for Cloud Run services：https://docs.cloud.google.com/run/docs/configuring/services/secrets
2. Create rotation schedules in Secret Manager：https://docs.cloud.google.com/secret-manager/docs/secret-rotation
3. About rotation schedules：https://docs.cloud.google.com/secret-manager/docs/rotation-recommendations
4. Secret Manager Audit Logging：https://docs.cloud.google.com/secret-manager/docs/audit-logging
5. Secret Manager documentation：https://docs.cloud.google.com/secret-manager/docs