Cloud Run IAM 与安全实践指南预定义角色、服务身份、容器安全与 IAP 接入控制【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文基于skills29技能库中 cloud-run-basics 技能的 IAM Security 参考文档 编写系统讲解 Cloud Run 的 IAM 授权模型如何为项目成员选择合适的预定义角色roles/run.admin、roles/run.invoker等、如何为每个 Cloud Run 资源配置最小权限的服务身份、如何通过 Ingress/VPC egress/二进制授权/密钥管理四道安全控制点加固部署以及如何使用 IAP 一键开启安全接入。读完本文你可以独立完成 Cloud Run 服务的完整权限与访问安全配置并理解仓库中 SKILL.md、iac-usage.md 等配套文档中命令与 Terraform 资源背后对应的 IAM 语义。预定义 IAM 角色谁能部署、谁能调用Cloud Run 使用 Identity and Access ManagementIAM来保护资源并控制“谁可以部署、谁可以调用”。在开始操作前先从角色选择入手。文档给出的四个核心预定义角色如下预定义角色用途roles/run.admin对所有 Cloud Run 资源的完全控制。roles/run.invoker调用 Cloud Run 服务并执行作业jobs。roles/run.developer读写权限但不能设置 IAM 策略。roles/run.viewer对 Cloud Run 资源的只读访问。结合仓库中 SKILL.md 的 “Required roles” 一节可以把角色模型看得更完整部署一个 Cloud Run 资源需要在项目上持有以下一组角色而不仅仅是roles/run.adminCloud Run Adminroles/run.admin——项目级Cloud Run Source Developerroles/run.sourceDeveloper——项目级Service Account Userroles/iam.serviceAccountUser——授予在服务身份上允许“扮演”该服务账号Logs Viewerroles/logging.viewer——项目级用于查看部署日志此外若使用 Cloud Build 构建源码Cloud Build 会自动使用 Compute Engine 默认服务账号作为默认构建账号除非覆盖。为了让 Cloud Build 构建你的源码需要为 Cloud Build 服务账号授予roles/run.builder角色SKILL.md 给出了对应命令gcloud projects add-iam-policy-binding PROJECT_ID \ --memberserviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS \ --roleroles/run.builder \ --quiet其中PROJECT_ID替换为你的 Google Cloud 项目 IDSERVICE_ACCOUNT_EMAIL_ADDRESS替换为 Cloud Build 服务账号的邮箱。这条命令正是上面“预定义角色”表中最典型的一次落地把roles/run.builder绑定到一个服务账号成员上。服务身份Cloud Run 资源以谁的身份运行Cloud Run 资源以特定的服务账号即“服务身份”service identity运行它决定了资源在运行时能访问哪些其他 GCP 资源。文档列出了两类服务账号用户管理的服务账号推荐由你手动创建并自行确定该服务账号访问特定 Google Cloud 资源所需的最小权限集合。用户管理的服务账号格式为SERVICE_ACCOUNT_NAMEPROJECT_ID.iam.gserviceaccount.comCompute Engine 默认服务账号Cloud Run 自动提供 Compute Engine 默认服务账号作为默认服务身份。其格式为PROJECT_NUMBER-computedeveloper.gserviceaccount.com默认服务账号的最佳实践最小权限 组织策略约束默认情况下Compute Engine 默认服务账号会被自动创建。如果你在创建 Cloud Run 资源时没有指定服务账号Cloud Run 就会使用这个默认服务账号。这里有一个需要重点对待的风险点根据组织策略配置默认服务账号可能自动被授予项目的 Editor 角色。文档强烈建议通过强制执行iam.automaticIamGrantsForDefaultServiceAccounts组织策略约束来禁用这种自动角色授予如果你的组织创建时间晚于 2024 年 5 月 3 日该约束默认已强制执行。仓库中另一技能 org-policies.md 同样将iam.automaticIamGrantsForDefaultServiceAccounts列为组织级基线约束之一可以交叉印证这是 GCP 项目初始化阶段就应统一治理的策略而不是等到出问题再补。由此延伸出的核心建议是为每一个Cloud Run 资源创建一个拥有最小权限的用户管理的服务账号当某个服务需要访问其他 GCP 资源例如 Cloud SQL时把该服务的身份授予那个资源上相应的 IAM 角色——授权粒度落在资源侧而不是给服务账号一个大而全的项目级角色。四类安全控制点Ingress、VPC Egress、二进制授权与密钥管理在“谁能访问你的服务”与“你的服务能访问谁”两个方向上文档给出了四个安全控制点Ingress 设置入口控制控制服务是否可从互联网到达all、仅可从 VPC 内部访问internal还是经由负载均衡器访问internal-and-cloud-load-balancing。VPC Egress出口控制使用 VPC connector 或 Direct VPC egress让 Cloud Run 访问你 VPC 内的资源。二进制授权Binary Authorization确保只有受信任的容器镜像能够被部署。密钥管理Secrets Management使用 Secret Manager 将敏感信息如 API 密钥、数据库密码以环境变量或卷的形式安全地传入容器。这些控制在仓库其他参考文档中有具体的操作落点可以形成完整的证据链Ingress 的 CLI 表达cli-usage.md 在 “Common Flags” 一节明确说明--allow-unauthenticated使服务公开可访问--no-allow-unauthenticated则限制为仅认证用户可访问——这正是 Ingress/调用检查在部署命令上的开关。Ingress 的 Terraform 表达iac-usage.md 中的服务示例使用了ingress INGRESS_TRAFFIC_ALL字段对应all语义。VPC Egress 的深入实践networking.md 专门讲解了 Direct VPC egress 的成本与性能策略可缩容到零、第二执行环境、--vpc-egressall-traffic/--vpc-egressprivate-ranges-only等是“Ingress 控制 VPC 内部可达”之后的出口侧配套方案。容器安全最佳实践部署到 Cloud Run 的镜像如何加固文档将容器安全实践归纳为六条覆盖从构建到运行的全链路。在将容器化应用打包并部署到 Cloud Run 时应遵循以下建议构建最小化容器镜像从精简镜像如 Alpine 或 scratch出发并利用多阶段构建multi-stage builds让运行时的容器保持轻量。以非 root 用户运行避免容器以 root 用户运行。在 Dockerfile 中配置容器以非 root 用户启动一旦容器被攻破可限制权限提升与文件访问范围。保持基础镜像更新使用积极维护且安全的基础镜像例如 Google 基础镜像或 Docker Hub 官方镜像。启用漏洞扫描在 Artifact Registry 中开启自动化漏洞扫描持续扫描容器镜像/软件包中的已知 CVE并通过定期重建容器镜像与重新部署服务来应用最新的安全更新。实现确定性构建为基础镜像和包依赖固定具体的版本、tag 或 digest以获得可预期、可复现的构建结果同时防止未经核实的代码进入容器。管控 Preview 特性使用自定义组织策略禁止使用 Preview 特性。值得注意的是第 4 条与仓库中 SKILL.md 关于容器镜像来源的建议相互呼应文档推荐使用 Artifact Registry 而非直接使用 Docker HubDocker Hub 镜像的拉取缓存最长可达一小时而 Artifact Registry 也正是启用漏洞扫描这一安全控制点的前提。公开访问服务两种创建方式及取舍要创建一个公开的 Cloud Run 服务有两条路径禁用 Cloud Run Invoker IAM 检查推荐。将 Cloud Run Invoker IAM 角色授予allUsers成员类型。推荐第一种的原因在于它通过服务自身的入口配置声明“无需认证”而不是在 IAM 策略里塞入一个allUsers成员——后者会把公开意图分散到授权策略中更难审计。仓库的 iac-usage.md 中展示了第二种方式在 Terraform 里的实际写法可作为对照参考resource google_cloud_run_v2_service default { name cloudrun-service location us-central1 deletion_protection false ingress INGRESS_TRAFFIC_ALL template { containers { image us-docker.pkg.dev/cloudrun/container/hello } } } resource google_cloud_run_v2_service_iam_member noauth { location google_cloud_run_v2_service.default.location name google_cloud_run_v2_service.default.name role roles/run.invoker member allUsers }google_cloud_run_v2_service_iam_member资源把roles/run.invoker绑定到allUsers使该服务对外公开。若改用推荐的第一种方式则在服务配置层面关闭 Invoker 检查对应 CLI 语义即 cli-usage.md 中的--allow-unauthenticated标志而不在策略里添加allUsers。启用 IAP一键开启全链路身份验证对 Cloud Run 服务直接启用 Identity-Aware ProxyIAP可以一键保护来自所有入口路径的流量包括默认的run.appURL 和负载均衡器入口。将 IAP 与 Cloud Run 集成后可以按以下三种场景管理用户或组的访问组织内部为与 Cloud Run 服务处于同一组织的用户配置访问权限组织外部为来自不同组织的用户配置访问权限无组织项目为不属于任何 Google 组织的项目中的用户配置访问权限。文档指出启用 IAP 可以简单到在部署命令里加上相应标志gcloud run deploy SERVICE_NAME \ --regionREGION \ --imageIMAGE_URL \ --no-allow-unauthenticated \ --iap \ --quiet命令中各参数含义SERVICE_NAME要部署的服务名不存在则随部署创建REGION服务所在区域IMAGE_URL容器镜像地址--no-allow-unauthenticated关闭未认证调用与 cli-usage.md 中的说明一致即“仅限制认证用户访问”--iap为该服务开启 IAP 流量保护。这条命令体现了本文前面各节的组合拳--no-allow-unauthenticated收紧入口侧调用检查--iap叠加统一身份层再配合前文“每个资源一个最小权限用户管理的服务账号”就构成了从 IAM 角色、服务身份到访问控制三层的完整安全基线。排障关联IAM 报错时先查授权SKILL.md 的 “What to do if a deployment fails” 一节将IAM/Permission Error列为部署失败的第一类高频原因并明确指引读者去读本文references/iam-security.md。当部署因权限失败时可沿本文内容逐层排查部署者是否持有roles/run.admin、roles/run.sourceDeveloper、roles/iam.serviceAccountUser、roles/logging.viewerSKILL.md 要求的完整集合若使用--source构建Cloud Build 服务账号是否已获roles/run.builder运行时访问其他 GCP 资源失败时服务身份是否已在目标资源如 Cloud SQL上被授予相应角色。小结Cloud Run 的安全模型由三个层面构成调用者侧预定义角色roles/run.*与 IAP、资源侧用户管理的服务账号 最小权限 组织策略iam.automaticIamGrantsForDefaultServiceAccounts、运行时侧Ingress 设置、VPC egress、二进制授权、Secret Manager 与容器镜像加固六条实践。仓库中 cloud-run-basics 技能的配套文档为本文提供了可交叉验证的操作细节cli-usage.md 的认证相关标志、iac-usage.md 的ingress字段与allUsersIAM 绑定示例、networking.md 的 Direct VPC egress 策略以及 org-policies.md 中的组织级约束。需要说明的是以上角色名称、命令标志与 Terraform 资源字段均出自当前仓库文档实际使用时请以你所在项目与组织的 gcloud/Terraform 版本行为为准。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cloud Run IAM 与安全实践指南预定义角色、服务身份、容器安全与 IAP 接入控制【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文基于skills29技能库中 cloud-run-basics 技能的 IAM Security 参考文档 编写系统讲解 Cloud Run 的 IAM 授权模型如何为项目成员选择合适的预定义角色roles/run.admin、roles/run.invoker等、如何为每个 Cloud Run 资源配置最小权限的服务身份、如何通过 Ingress/VPC egress/二进制授权/密钥管理四道安全控制点加固部署以及如何使用 IAP 一键开启安全接入。读完本文你可以独立完成 Cloud Run 服务的完整权限与访问安全配置并理解仓库中 SKILL.md、iac-usage.md 等配套文档中命令与 Terraform 资源背后对应的 IAM 语义。预定义 IAM 角色谁能部署、谁能调用Cloud Run 使用 Identity and Access ManagementIAM来保护资源并控制“谁可以部署、谁可以调用”。在开始操作前先从角色选择入手。文档给出的四个核心预定义角色如下预定义角色用途roles/run.admin对所有 Cloud Run 资源的完全控制。roles/run.invoker调用 Cloud Run 服务并执行作业jobs。roles/run.developer读写权限但不能设置 IAM 策略。roles/run.viewer对 Cloud Run 资源的只读访问。结合仓库中 SKILL.md 的 “Required roles” 一节可以把角色模型看得更完整部署一个 Cloud Run 资源需要在项目上持有以下一组角色而不仅仅是roles/run.adminCloud Run Adminroles/run.admin——项目级Cloud Run Source Developerroles/run.sourceDeveloper——项目级Service Account Userroles/iam.serviceAccountUser——授予在服务身份上允许“扮演”该服务账号Logs Viewerroles/logging.viewer——项目级用于查看部署日志此外若使用 Cloud Build 构建源码Cloud Build 会自动使用 Compute Engine 默认服务账号作为默认构建账号除非覆盖。为了让 Cloud Build 构建你的源码需要为 Cloud Build 服务账号授予roles/run.builder角色SKILL.md 给出了对应命令gcloud projects add-iam-policy-binding PROJECT_ID \ --memberserviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS \ --roleroles/run.builder \ --quiet其中PROJECT_ID替换为你的 Google Cloud 项目 IDSERVICE_ACCOUNT_EMAIL_ADDRESS替换为 Cloud Build 服务账号的邮箱。这条命令正是上面“预定义角色”表中最典型的一次落地把roles/run.builder绑定到一个服务账号成员上。服务身份Cloud Run 资源以谁的身份运行Cloud Run 资源以特定的服务账号即“服务身份”service identity运行它决定了资源在运行时能访问哪些其他 GCP 资源。文档列出了两类服务账号用户管理的服务账号推荐由你手动创建并自行确定该服务账号访问特定 Google Cloud 资源所需的最小权限集合。用户管理的服务账号格式为SERVICE_ACCOUNT_NAMEPROJECT_ID.iam.gserviceaccount.comCompute Engine 默认服务账号Cloud Run 自动提供 Compute Engine 默认服务账号作为默认服务身份。其格式为PROJECT_NUMBER-computedeveloper.gserviceaccount.com默认服务账号的最佳实践最小权限 组织策略约束默认情况下Compute Engine 默认服务账号会被自动创建。如果你在创建 Cloud Run 资源时没有指定服务账号Cloud Run 就会使用这个默认服务账号。这里有一个需要重点对待的风险点根据组织策略配置默认服务账号可能自动被授予项目的 Editor 角色。文档强烈建议通过强制执行iam.automaticIamGrantsForDefaultServiceAccounts组织策略约束来禁用这种自动角色授予如果你的组织创建时间晚于 2024 年 5 月 3 日该约束默认已强制执行。仓库中另一技能 org-policies.md 同样将iam.automaticIamGrantsForDefaultServiceAccounts列为组织级基线约束之一可以交叉印证这是 GCP 项目初始化阶段就应统一治理的策略而不是等到出问题再补。由此延伸出的核心建议是为每一个Cloud Run 资源创建一个拥有最小权限的用户管理的服务账号当某个服务需要访问其他 GCP 资源例如 Cloud SQL时把该服务的身份授予那个资源上相应的 IAM 角色——授权粒度落在资源侧而不是给服务账号一个大而全的项目级角色。四类安全控制点Ingress、VPC Egress、二进制授权与密钥管理在“谁能访问你的服务”与“你的服务能访问谁”两个方向上文档给出了四个安全控制点Ingress 设置入口控制控制服务是否可从互联网到达all、仅可从 VPC 内部访问internal还是经由负载均衡器访问internal-and-cloud-load-balancing。VPC Egress出口控制使用 VPC connector 或 Direct VPC egress让 Cloud Run 访问你 VPC 内的资源。二进制授权Binary Authorization确保只有受信任的容器镜像能够被部署。密钥管理Secrets Management使用 Secret Manager 将敏感信息如 API 密钥、数据库密码以环境变量或卷的形式安全地传入容器。这些控制在仓库其他参考文档中有具体的操作落点可以形成完整的证据链Ingress 的 CLI 表达cli-usage.md 在 “Common Flags” 一节明确说明--allow-unauthenticated使服务公开可访问--no-allow-unauthenticated则限制为仅认证用户可访问——这正是 Ingress/调用检查在部署命令上的开关。Ingress 的 Terraform 表达iac-usage.md 中的服务示例使用了ingress INGRESS_TRAFFIC_ALL字段对应all语义。VPC Egress 的深入实践networking.md 专门讲解了 Direct VPC egress 的成本与性能策略可缩容到零、第二执行环境、--vpc-egressall-traffic/--vpc-egressprivate-ranges-only等是“Ingress 控制 VPC 内部可达”之后的出口侧配套方案。容器安全最佳实践部署到 Cloud Run 的镜像如何加固文档将容器安全实践归纳为六条覆盖从构建到运行的全链路。在将容器化应用打包并部署到 Cloud Run 时应遵循以下建议构建最小化容器镜像从精简镜像如 Alpine 或 scratch出发并利用多阶段构建multi-stage builds让运行时的容器保持轻量。以非 root 用户运行避免容器以 root 用户运行。在 Dockerfile 中配置容器以非 root 用户启动一旦容器被攻破可限制权限提升与文件访问范围。保持基础镜像更新使用积极维护且安全的基础镜像例如 Google 基础镜像或 Docker Hub 官方镜像。启用漏洞扫描在 Artifact Registry 中开启自动化漏洞扫描持续扫描容器镜像/软件包中的已知 CVE并通过定期重建容器镜像与重新部署服务来应用最新的安全更新。实现确定性构建为基础镜像和包依赖固定具体的版本、tag 或 digest以获得可预期、可复现的构建结果同时防止未经核实的代码进入容器。管控 Preview 特性使用自定义组织策略禁止使用 Preview 特性。值得注意的是第 4 条与仓库中 SKILL.md 关于容器镜像来源的建议相互呼应文档推荐使用 Artifact Registry 而非直接使用 Docker HubDocker Hub 镜像的拉取缓存最长可达一小时而 Artifact Registry 也正是启用漏洞扫描这一安全控制点的前提。公开访问服务两种创建方式及取舍要创建一个公开的 Cloud Run 服务有两条路径禁用 Cloud Run Invoker IAM 检查推荐。将 Cloud Run Invoker IAM 角色授予allUsers成员类型。推荐第一种的原因在于它通过服务自身的入口配置声明“无需认证”而不是在 IAM 策略里塞入一个allUsers成员——后者会把公开意图分散到授权策略中更难审计。仓库的 iac-usage.md 中展示了第二种方式在 Terraform 里的实际写法可作为对照参考resource google_cloud_run_v2_service default { name cloudrun-service location us-central1 deletion_protection false ingress INGRESS_TRAFFIC_ALL template { containers { image us-docker.pkg.dev/cloudrun/container/hello } } } resource google_cloud_run_v2_service_iam_member noauth { location google_cloud_run_v2_service.default.location name google_cloud_run_v2_service.default.name role roles/run.invoker member allUsers }google_cloud_run_v2_service_iam_member资源把roles/run.invoker绑定到allUsers使该服务对外公开。若改用推荐的第一种方式则在服务配置层面关闭 Invoker 检查对应 CLI 语义即 cli-usage.md 中的--allow-unauthenticated标志而不在策略里添加allUsers。启用 IAP一键开启全链路身份验证对 Cloud Run 服务直接启用 Identity-Aware ProxyIAP可以一键保护来自所有入口路径的流量包括默认的run.appURL 和负载均衡器入口。将 IAP 与 Cloud Run 集成后可以按以下三种场景管理用户或组的访问组织内部为与 Cloud Run 服务处于同一组织的用户配置访问权限组织外部为来自不同组织的用户配置访问权限无组织项目为不属于任何 Google 组织的项目中的用户配置访问权限。文档指出启用 IAP 可以简单到在部署命令里加上相应标志gcloud run deploy SERVICE_NAME \ --regionREGION \ --imageIMAGE_URL \ --no-allow-unauthenticated \ --iap \ --quiet命令中各参数含义SERVICE_NAME要部署的服务名不存在则随部署创建REGION服务所在区域IMAGE_URL容器镜像地址--no-allow-unauthenticated关闭未认证调用与 cli-usage.md 中的说明一致即“仅限制认证用户访问”--iap为该服务开启 IAP 流量保护。这条命令体现了本文前面各节的组合拳--no-allow-unauthenticated收紧入口侧调用检查--iap叠加统一身份层再配合前文“每个资源一个最小权限用户管理的服务账号”就构成了从 IAM 角色、服务身份到访问控制三层的完整安全基线。排障关联IAM 报错时先查授权SKILL.md 的 “What to do if a deployment fails” 一节将IAM/Permission Error列为部署失败的第一类高频原因并明确指引读者去读本文references/iam-security.md。当部署因权限失败时可沿本文内容逐层排查部署者是否持有roles/run.admin、roles/run.sourceDeveloper、roles/iam.serviceAccountUser、roles/logging.viewerSKILL.md 要求的完整集合若使用--source构建Cloud Build 服务账号是否已获roles/run.builder运行时访问其他 GCP 资源失败时服务身份是否已在目标资源如 Cloud SQL上被授予相应角色。小结Cloud Run 的安全模型由三个层面构成调用者侧预定义角色roles/run.*与 IAP、资源侧用户管理的服务账号 最小权限 组织策略iam.automaticIamGrantsForDefaultServiceAccounts、运行时侧Ingress 设置、VPC egress、二进制授权、Secret Manager 与容器镜像加固六条实践。仓库中 cloud-run-basics 技能的配套文档为本文提供了可交叉验证的操作细节cli-usage.md 的认证相关标志、iac-usage.md 的ingress字段与allUsersIAM 绑定示例、networking.md 的 Direct VPC egress 策略以及 org-policies.md 中的组织级约束。需要说明的是以上角色名称、命令标志与 Terraform 资源字段均出自当前仓库文档实际使用时请以你所在项目与组织的 gcloud/Terraform 版本行为为准。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
