很多团队把数据库密码、第三方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_IDyour-project-idexportREGIONasia-east1exportSERVICE_NAMEapi-serviceexportSECRET_NAMEdb-passwordexportRUN_SAcloudrun-api-sagcloud configsetproject$PROJECT_IDgcloud servicesenablesecretmanager.googleapis.com run.googleapis.com创建Cloud Run运行时服务账号gcloud iam service-accounts create$RUN_SA\--display-nameCloud Run API runtime service accountexportRUN_SA_EMAIL$RUN_SA$PROJECT_ID.iam.gserviceaccount.com生产环境不要直接使用项目默认计算服务账号。每个服务使用独立运行时服务账号权限边界更清晰。三、创建Secret和初始版本gcloud secrets create$SECRET_NAME\--replication-policyautomatic\--labelsserviceapi,envprod,ownerplatform添加初始版本printfreplace-with-real-password|\gcloud secrets versionsadd$SECRET_NAME--data-file-查看Secretgcloud secrets describe$SECRET_NAME\--formatyaml(name,replication,labels,createTime)注意命令示例里的值不要直接复制到生产命令历史里。真实密钥应通过安全输入方式、CI受保护变量或密钥生成流程写入避免被shell history和日志记录。四、授予Cloud Run最小访问权限只给运行时服务账号访问指定Secret的权限gcloud secrets add-iam-policy-binding$SECRET_NAME\--memberserviceAccount:$RUN_SA_EMAIL\--roleroles/secretmanager.secretAccessor验证IAMgcloud secrets get-iam-policy$SECRET_NAME\--formattable(bindings.role,bindings.members)不要把roles/secretmanager.secretAccessor直接授予所有开发者、默认服务账号或项目级别广泛成员。能按Secret授权就不要按项目授权。五、把Secret注入Cloud RunCloud Run支持两种常见方式作为环境变量注入或作为文件挂载。官方文档提醒Cloud Run推荐把敏感信息存储在Secret Manager中并将Secret提供给容器使用。方式一作为环境变量。gcloud run deploy$SERVICE_NAME\--imagegcr.io/$PROJECT_ID/api-service:latest\--region$REGION\--service-account$RUN_SA_EMAIL\--set-secretsDB_PASSWORD$SECRET_NAME:latest方式二作为文件挂载。gcloud run services update$SERVICE_NAME\--region$REGION\--set-secrets/secrets/db/password$SECRET_NAME:latest选择建议环境变量适合应用启动时读取一次的配置文件挂载适合按文件路径读取、并可能需要观察版本变化的场景无论哪种方式都要确认应用日志不会打印密钥值。六、版本切换和回滚Secret Manager支持多个版本。添加新版本printfnew-password-value|\gcloud secrets versionsadd$SECRET_NAME--data-file-查看版本gcloud secrets versions list$SECRET_NAME\--formattable(name,state,createTime)如果Cloud Run使用:latest新部署或新实例读取时会指向最新版本。但生产环境更建议在关键变更时使用明确版本号做灰度验证gcloud run services update$SERVICE_NAME\--region$REGION\--set-secretsDB_PASSWORD$SECRET_NAME:2如果新密钥异常可以回滚到上一版本gcloud run services update$SERVICE_NAME\--region$REGION\--set-secretsDB_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-period2592000s\--next-rotation-time2026-08-28T00:00:00Z\--topicssecret-rotation-events后续可以让Cloud Functions、Cloud Run Job或工单系统订阅这个主题触发“生成新密钥 → 更新下游系统 → 添加Secret版本 → 灰度发布 → 验证 → 禁用旧版本”的流程。不要把轮换通知误解成“密钥自动安全了”。真正的轮换必须包含下游凭据更新和应用验证。八、审计日志查询Secret Manager支持Cloud Audit Logs。官方文档说明Google Cloud服务会生成记录管理活动和访问活动的审计日志。对Secret Manager来说谁创建、修改、访问Secret都应能在审计体系里追踪。查询管理活动resource.typeaudited_resource protoPayload.serviceNamesecretmanager.googleapis.com protoPayload.methodName:google.cloud.secretmanager查询Secret访问resource.typeaudited_resource protoPayload.serviceNamesecretmanager.googleapis.com protoPayload.methodNamegoogle.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion如果查不到数据访问日志检查项目是否启用了Data Access Audit Logs。很多环境默认只记录管理活动数据读取类日志需要单独启用。九、验收清单验收项命令/方法通过标准Secret存在gcloud secrets describe能看到标签和复制策略版本存在versions list至少一个enabled版本IAM最小权限get-iam-policy仅运行时SA可读Cloud Run注入services describesecrets配置正确应用验证健康检查/业务接口能使用新密钥审计日志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 serviceshttps://docs.cloud.google.com/run/docs/configuring/services/secretsCreate rotation schedules in Secret Managerhttps://docs.cloud.google.com/secret-manager/docs/secret-rotationAbout rotation scheduleshttps://docs.cloud.google.com/secret-manager/docs/rotation-recommendationsSecret Manager Audit Logginghttps://docs.cloud.google.com/secret-manager/docs/audit-loggingSecret Manager documentationhttps://docs.cloud.google.com/secret-manager/docs
很多团队把数据库密码、第三方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_IDyour-project-idexportREGIONasia-east1exportSERVICE_NAMEapi-serviceexportSECRET_NAMEdb-passwordexportRUN_SAcloudrun-api-sagcloud configsetproject$PROJECT_IDgcloud servicesenablesecretmanager.googleapis.com run.googleapis.com创建Cloud Run运行时服务账号gcloud iam service-accounts create$RUN_SA\--display-nameCloud Run API runtime service accountexportRUN_SA_EMAIL$RUN_SA$PROJECT_ID.iam.gserviceaccount.com生产环境不要直接使用项目默认计算服务账号。每个服务使用独立运行时服务账号权限边界更清晰。三、创建Secret和初始版本gcloud secrets create$SECRET_NAME\--replication-policyautomatic\--labelsserviceapi,envprod,ownerplatform添加初始版本printfreplace-with-real-password|\gcloud secrets versionsadd$SECRET_NAME--data-file-查看Secretgcloud secrets describe$SECRET_NAME\--formatyaml(name,replication,labels,createTime)注意命令示例里的值不要直接复制到生产命令历史里。真实密钥应通过安全输入方式、CI受保护变量或密钥生成流程写入避免被shell history和日志记录。四、授予Cloud Run最小访问权限只给运行时服务账号访问指定Secret的权限gcloud secrets add-iam-policy-binding$SECRET_NAME\--memberserviceAccount:$RUN_SA_EMAIL\--roleroles/secretmanager.secretAccessor验证IAMgcloud secrets get-iam-policy$SECRET_NAME\--formattable(bindings.role,bindings.members)不要把roles/secretmanager.secretAccessor直接授予所有开发者、默认服务账号或项目级别广泛成员。能按Secret授权就不要按项目授权。五、把Secret注入Cloud RunCloud Run支持两种常见方式作为环境变量注入或作为文件挂载。官方文档提醒Cloud Run推荐把敏感信息存储在Secret Manager中并将Secret提供给容器使用。方式一作为环境变量。gcloud run deploy$SERVICE_NAME\--imagegcr.io/$PROJECT_ID/api-service:latest\--region$REGION\--service-account$RUN_SA_EMAIL\--set-secretsDB_PASSWORD$SECRET_NAME:latest方式二作为文件挂载。gcloud run services update$SERVICE_NAME\--region$REGION\--set-secrets/secrets/db/password$SECRET_NAME:latest选择建议环境变量适合应用启动时读取一次的配置文件挂载适合按文件路径读取、并可能需要观察版本变化的场景无论哪种方式都要确认应用日志不会打印密钥值。六、版本切换和回滚Secret Manager支持多个版本。添加新版本printfnew-password-value|\gcloud secrets versionsadd$SECRET_NAME--data-file-查看版本gcloud secrets versions list$SECRET_NAME\--formattable(name,state,createTime)如果Cloud Run使用:latest新部署或新实例读取时会指向最新版本。但生产环境更建议在关键变更时使用明确版本号做灰度验证gcloud run services update$SERVICE_NAME\--region$REGION\--set-secretsDB_PASSWORD$SECRET_NAME:2如果新密钥异常可以回滚到上一版本gcloud run services update$SERVICE_NAME\--region$REGION\--set-secretsDB_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-period2592000s\--next-rotation-time2026-08-28T00:00:00Z\--topicssecret-rotation-events后续可以让Cloud Functions、Cloud Run Job或工单系统订阅这个主题触发“生成新密钥 → 更新下游系统 → 添加Secret版本 → 灰度发布 → 验证 → 禁用旧版本”的流程。不要把轮换通知误解成“密钥自动安全了”。真正的轮换必须包含下游凭据更新和应用验证。八、审计日志查询Secret Manager支持Cloud Audit Logs。官方文档说明Google Cloud服务会生成记录管理活动和访问活动的审计日志。对Secret Manager来说谁创建、修改、访问Secret都应能在审计体系里追踪。查询管理活动resource.typeaudited_resource protoPayload.serviceNamesecretmanager.googleapis.com protoPayload.methodName:google.cloud.secretmanager查询Secret访问resource.typeaudited_resource protoPayload.serviceNamesecretmanager.googleapis.com protoPayload.methodNamegoogle.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion如果查不到数据访问日志检查项目是否启用了Data Access Audit Logs。很多环境默认只记录管理活动数据读取类日志需要单独启用。九、验收清单验收项命令/方法通过标准Secret存在gcloud secrets describe能看到标签和复制策略版本存在versions list至少一个enabled版本IAM最小权限get-iam-policy仅运行时SA可读Cloud Run注入services describesecrets配置正确应用验证健康检查/业务接口能使用新密钥审计日志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 serviceshttps://docs.cloud.google.com/run/docs/configuring/services/secretsCreate rotation schedules in Secret Managerhttps://docs.cloud.google.com/secret-manager/docs/secret-rotationAbout rotation scheduleshttps://docs.cloud.google.com/secret-manager/docs/rotation-recommendationsSecret Manager Audit Logginghttps://docs.cloud.google.com/secret-manager/docs/audit-loggingSecret Manager documentationhttps://docs.cloud.google.com/secret-manager/docs
