IAP Web：Cloud Run 配置与授权

验证：未记录
适用版本
未记录
验证范围
尚未登记验证记录。

本页使用 Cloud Run 原生 IAP；Console：Cloud Run → Security。

推荐做法#

  • 先选 OAuth client：无 Organization 或 external users 场景先完成相应初始化。
  • 用户/Group 授 IAP role；IAP service agent 授 Cloud Run Invoker；runtime SA 保持业务最小权限。
  • 分别验证已授权、未授权、撤权后的浏览器会话；检查其他 ingress 路径。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
REGION='REPLACE_REGION'
SERVICE='REPLACE_SERVICE'

gcloud run services describe "$SERVICE" --project="$PROJECT_ID" --region="$REGION"
gcloud run services get-iam-policy "$SERVICE" --project="$PROJECT_ID" --region="$REGION"

容易踩的坑#

  • 不要同时在 ALB 和 Cloud Run 开 IAP；不要把浏览器 cookie 当 CI 认证。

关闭 IAP 前，先恢复 Invoker IAM check 并清理匿名授权。 否则移除 IAP 后可能意外公开服务；用匿名和已授权身份分别复测。

OAuth 与启用步骤 · 失败定位

配置说明与完整示例（按需展开）

本页只演示直接在 Cloud Run service 上启用 IAP。能力范围、ALB 层集成和身份选择先看 IAP 总览。以下命令在配置了 gcloud 的本机执行；文档做本地静态验证，未在云端完成此流程验收。

1. 确定实验前提#

使用 Cloud Run 实验的 lab-hello。启用 IAP 会改变认证流程，不用于 Pub/Sub push、Webhook 或生产 Worker。

本例浏览器直连 run.app，使用 ingress all；先确认 ALB 层 IAP 未启用、Invoker IAM check 已开启。

source lab.env
gcloud config set project "$PROJECT_ID"
gcloud run services describe lab-hello \
  --project="$PROJECT_ID" --region="$REGION"
gcloud run services get-iam-policy lab-hello \
  --project="$PROJECT_ID" --region="$REGION"

先检查输出中的 ingress、IAP 和 IAM；撤销演示服务的匿名 binding，并检查 allAuthenticatedUsers 与 inherited permissions，再开放本例入口。

下面移除命令仅在相应 binding 确实存在、且是该演示服务需要撤销的授权时执行；不存在时跳过：

gcloud run services remove-iam-policy-binding lab-hello \
  --project="$PROJECT_ID" --region="$REGION" \
  --member=allUsers --role=roles/run.invoker

确认仍要求 IAM authentication 后，设置本例访问路径：

gcloud run services update lab-hello \
  --project="$PROJECT_ID" --region="$REGION" --ingress=all

2. 准备管理权限和 OAuth client#

管理者需要与操作相符的权限；访问者不需要这些管理 roles。

操作 官方指南列出的相应 role / 权限
更新 Cloud Run service Cloud Run Admin
使用运行 Service Account / 镜像 Service Account User（actAs）及适用的 Artifact Registry Reader
管理 IAP 访问策略 IAP Policy Admin
配置 no-Organization / external-user 场景 按场景需要 IAP Settings Admin、OAuth Config Editor

支持的 Organization 内场景可用 Google-managed OAuth client。无 Organization 或需 external users 时，先初始化 custom OAuth client，再执行下节 CLI：在 Cloud Run → Security → Require authentication → IAP 按向导设置，或按官方流程创建。

OAuth consent screen 展示应用名称、提供方与请求信息；Google Auth Platform 的 Branding 管展示，Audience 管用户范围，Testing 时按要求配置 Test users。最终 IAP 权限仍需 IAM 授予。Custom OAuth client

3. 启用 IAP 并配置两层授权#

先区分谁在访问谁：

浏览器用户
  → IAP：用户需要 IAP-secured Web App User
  → Cloud Run：IAP service agent 需要 Cloud Run Invoker
  → 运行应用：使用 service 自己的 runtime Service Account

这三个身份不能互换。roles/iap.httpsResourceAccessor 允许用户通过 IAP；roles/run.invoker 允许 IAP service agent 调用 Cloud Run。

gcloud services enable iap.googleapis.com --project="$PROJECT_ID"
export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
  --format='value(projectNumber)')
export HUMAN_EMAIL=$(gcloud config get-value account)

gcloud run services update lab-hello \
  --project="$PROJECT_ID" --region="$REGION" --iap

gcloud run services add-iam-policy-binding lab-hello \
  --project="$PROJECT_ID" --region="$REGION" \
  --member="serviceAccount:service-$PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com" \
  --role=roles/run.invoker

--iap 启用 service 级 IAP。上述 gcp-sa-iap 是 Google 管理的 IAP service agent，不是本例运行应用的 lab-run。通过 Console 开启时，Invoker 授权可自动配置；CLI 路径需核对它已存在。

给本次浏览器测试账号授权；先确认 HUMAN_EMAIL 确实是准备在浏览器登录的 Google 用户：

gcloud iap web add-iam-policy-binding \
  --project="$PROJECT_ID" \
  --resource-type=cloud-run \
  --service=lab-hello --region="$REGION" \
  --member="user:$HUMAN_EMAIL" \
  --role=roles/iap.httpsResourceAccessor

团队使用 Google Group 时把 member 换为 group:实际组邮箱。用户有 OAuth 登录资格与有 IAP role 是两项条件，必须分别满足。Cloud Run IAP 官方流程

4. 验收与撤权#

查看配置和访问 URL：

gcloud run services describe lab-hello \
  --project="$PROJECT_ID" --region="$REGION"
gcloud iap web get-iam-policy \
  --project="$PROJECT_ID" --resource-type=cloud-run \
  --service=lab-hello --region="$REGION"
gcloud run services describe lab-hello \
  --project="$PROJECT_ID" --region="$REGION" --format='value(status.url)'

确认输出显示 IAP enabled。使用浏览器测试：

测试身份 预期
未登录的新会话 进入相应登录流程，而不是直接看到 hello
已获 IAP 授权的账号 登录后看到 hello
可以完成 OAuth 登录、但没有 IAP 授权的账号 无法进入应用

若 external 账号被 OAuth Audience / Test users 限制拦住，只证明 OAuth 层拒绝，不能当成 IAP role 的反向测试。机器调用另走 programmatic authentication：SA OIDC token 的 audience 使用 IAP OAuth client ID，并配置相应 programmatic client allowlist 与 IAP 访问权；SA JWT 则使用受保护 URL 作为 audience，并具备签名能力。两者不能混用，也不能复制浏览器 cookie 充当 CI 凭据。机器调用方案

撤销本次直接授予的用户 binding：

gcloud iap web remove-iam-policy-binding \
  --project="$PROJECT_ID" --resource-type=cloud-run \
  --service=lab-hello --region="$REGION" \
  --member="user:$HUMAN_EMAIL" \
  --role=roles/iap.httpsResourceAccessor

等待权限传播后，用新会话复测。若仍能访问，检查 Project、Folder、Organization 的 inherited permissions，以及 Google Group membership 等其他授权来源；删除一个本地 binding 不等于移除了所有访问许可。

5. 身份传递与失败定位#

应用若基于 IAP 身份做业务授权，应验证 x-goog-iap-jwt-assertion 中的 IAP JWT assertion，检查签名、issuer、有效期与对应资源预期的 aud claim。不要信任任意传入的 email header；不同 IAP 接入位置的 expected audience 不能混用。Signed headers

停在哪一层 检查什么
无法完成 Google 登录 / OAuth 错误 OAuth client、Audience、Test users、实际账号、Organization 条件
登录成功但 IAP 拒绝 目标 IAP resource、用户或 Group 的 role binding、条件与继承
IAP 放行但 Cloud Run 调用失败 IAP service agent 的 Invoker、服务状态、ingress 路径
应用自己返回 403 / 5xx 应用授权、JWT 校验、runtime Service Account、下游依赖

6. 结束实验#

本节恢复 IAM authentication。关闭 IAP 前确认 Invoker IAM check 开启且无匿名授权；若直接删除演示服务则跳过还原，按 Cloud Run 清理。

gcloud run services update lab-hello \
  --project="$PROJECT_ID" --region="$REGION" --no-iap
gcloud run services remove-iam-policy-binding lab-hello \
  --project="$PROJECT_ID" --region="$REGION" \
  --member="serviceAccount:service-$PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com" \
  --role=roles/run.invoker

重新验证匿名请求被拒绝、原有授权调用者仍能按 Cloud Run IAM 方式访问。只撤销本次新增且不再使用的 binding；共享 OAuth client 或 Google 管理的 service agent 不随意删除。删除专用服务则按 Cloud Run 清理执行。

IAP TCP：SSH、权限与连接诊断 Forward

搜索文档

输入关键词，搜索所有文档。

↑ ↓ 选择 · Enter 打开 · Esc 关闭