| name | configuring-identity-aware-proxy-with-google-iap |
| description | 配置 Google Cloud Identity-Aware Proxy(IAP),使用访问级别、上下文感知策略 和服务账号的程序化访问,为 Compute Engine、App Engine、Cloud Run 和 GKE 服务 强制执行每请求身份验证。
|
| domain | cybersecurity |
| subdomain | zero-trust-architecture |
| tags | ["google-iap","identity-aware-proxy","gcp","zero-trust","access-context-manager","cloud-run","app-engine"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
使用 Google IAP 配置身份感知代理
适用场景
- 需要为 Google Cloud 应用程序(App Engine、Cloud Run、GKE、Compute Engine)提供基于身份的访问保护时
- 实施需要设备态势和位置验证的上下文感知访问时
- 无需 VPN 或公开 IP 即可安全访问内部工具时
- 需要对 Web 应用程序和 TCP 服务进行每请求认证和授权时
- 使用服务账号为 IAP 保护的资源配置程序化访问时
不适用于无法置于 HTTPS 负载均衡器后方的非 HTTP 应用程序、需要未经认证访问的面向公众的应用程序,或应用程序自行处理认证且 IAP 会与现有认证流程冲突的场景。
前置条件
- 已启用计费的 Google Cloud 项目
- 已启用 IAP API(
gcloud services enable iap.googleapis.com)
- 部署在 HTTPS 负载均衡器、App Engine 或 Cloud Run 后方的应用程序
- 用于用户管理的 Cloud Identity 或 Google Workspace
- 已启用 Access Context Manager API 用于访问级别
- 已为项目配置 OAuth 同意屏幕
工作流程
步骤 1:在后端服务上启用 IAP
为不同 GCP 计算平台配置 IAP。
gcloud services enable iap.googleapis.com
gcloud services enable accesscontextmanager.googleapis.com
gcloud iap oauth-brands create \
--application_title="Internal Applications" \
--support_email=security@company.com
gcloud iap oauth-clients create \
projects/PROJECT_ID/brands/BRAND_ID \
--display_name="IAP Web Client"
gcloud compute backend-services update my-backend-service \
--iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
--global
gcloud iap web enable \
--resource-type=app-engine \
--oauth2-client-id=CLIENT_ID \
--oauth2-client-secret=CLIENT_SECRET
gcloud run services add-iam-policy-binding my-service \
--member="serviceAccount:service-PROJECT_NUM@gcp-sa-iap.iam.gserviceaccount.com" \
--role="roles/run.invoker" \
--region=us-central1
gcloud compute backend-services update my-cloud-run-backend \
--iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
--global
gcloud compute instances add-iam-policy-binding my-vm \
--member="group:developers@company.com" \
--role="roles/iap.tunnelResourceAccessor" \
--zone=us-central1-a
gcloud compute ssh my-vm --zone=us-central1-a --tunnel-through-iap
gcloud compute start-iap-tunnel my-windows-vm 3389 \
--local-host-port=localhost:3390 \
--zone=us-central1-a
步骤 2:配置访问控制的 IAM 绑定
向特定用户和组授权,并可选设置访问级别条件。
gcloud iap web add-iam-policy-binding \
--resource-type=backend-services \
--service=my-backend-service \
--member="group:engineering@company.com" \
--role="roles/iap.httpsResourceAccessor"
gcloud iap web add-iam-policy-binding \
--resource-type=backend-services \
--service=finance-app \
--member="group:finance@company.com" \
--role="roles/iap.httpsResourceAccessor" \
--condition='expression=request.auth.access_levels.exists(x, x == "accessPolicies/POLICY_ID/accessLevels/corporate-device"),title=RequireCorporateDevice,description=需要托管企业设备'
gcloud iap web add-iam-policy-binding \
--resource-type=backend-services \
--service=admin-console \
--member="group:admins@company.com" \
--role="roles/iap.httpsResourceAccessor" \
--condition='expression=request.time.getHours("America/New_York") >= 8 && request.time.getHours("America/New_York") <= 18 && request.time.getDayOfWeek("America/New_York") >= 1 && request.time.getDayOfWeek("America/New_York") <= 5,title=BusinessHoursOnly'
步骤 3:使用 Access Context Manager 创建访问级别
使用设备属性和网络条件定义基于上下文的访问要求。
cat > managed-device.yaml << 'EOF'
- devicePolicy:
allowedEncryptionStatuses:
- ENCRYPTED
osConstraints:
- osType: DESKTOP_WINDOWS
minimumVersion: "10.0.19045"
- osType: DESKTOP_MAC
minimumVersion: "14.0"
- osType: DESKTOP_CHROME_OS
requireScreenlock: true
requireAdminApproval: true
allowedDeviceManagementLevels:
- ADVANCED
EOF
gcloud access-context-manager levels create managed-device \
--policy=POLICY_ID \
--title="托管设备" \
--basic-level-spec=managed-device.yaml
步骤 4:配置会话设置和重新认证
为每个应用程序设置会话持续时间和重新认证策略。
gcloud iap settings set \
--project=PROJECT_ID \
--resource-type=compute \
--service=finance-app \
reauthSettings.method=LOGIN \
reauthSettings.maxAge=14400s \
reauthSettings.policyType=MINIMUM
步骤 5:为服务账号配置程序化访问
通过 IAP 保护的端点启用服务间通信。
"""使用服务账号凭据访问 IAP 保护的资源。"""
import google.auth
import google.auth.transport.requests
from google.auth import impersonated_credentials
import requests as req
IAP_CLIENT_ID = "YOUR_IAP_OAUTH_CLIENT_ID.apps.googleusercontent.com"
IAP_URL = "https://my-app.company.com/api/data"
def access_iap_resource():
credentials, project = google.auth.default()
authed_session = google.auth.transport.requests.AuthorizedSession(
credentials,
target_audience=IAP_CLIENT_ID
)
response = authed_session.get(IAP_URL)
print(f"状态: {response.status_code}")
print(f"响应: {response.text[:500]}")
return response
if __name__ == "__main__":
access_iap_resource()
步骤 6:设置审计日志和监控
为所有 IAP 访问决策配置日志记录。
gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json
gcloud logging metrics create iap-denied-access \
--description="IAP 访问拒绝次数" \
--log-filter='resource.type="gce_backend_service" AND protoPayload.status.code=16'
gcloud logging read '
resource.type="gce_backend_service"
protoPayload.serviceName="iap.googleapis.com"
timestamp >= "2026-02-22T00:00:00Z"
' --project=PROJECT_ID --format='table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.status.code,resource.labels.backend_service_name)' --limit=50
核心概念
| 术语 | 定义 |
|---|
| Identity-Aware Proxy | GCP 服务,拦截 Web 请求和 TCP 连接,认证用户并在代理到后端服务前评估访问策略 |
| 后端服务(Backend Service) | IAP 保护的 GCP 负载均衡器组件;可服务于 Compute Engine 实例、GKE Pod、Cloud Run 服务或 App Engine |
| IAP 隧道(IAP Tunnel) | 通过 IAP 的安全 TCP 隧道,允许在没有公开 IP 或 VPN 的情况下 SSH、RDP 访问虚拟机 |
| OAuth 同意屏幕 | GCP 配置,指定 IAP 认证期间向用户显示的应用名称和支持邮箱 |
| 访问级别(Access Level) | Access Context Manager 中 IAP 授权时评估的命名条件(设备态势、IP、地理位置) |
| 重新认证(Re-authentication) | IAP 功能,在可配置的会话持续时间后要求用户重新证明身份 |
工具与系统
- Google Cloud IAP:用于 GCP 应用程序和 TCP 服务的身份感知反向代理
- Access Context Manager:根据设备、网络和地理属性定义访问级别
- gcloud CLI:配置 IAP、访问级别和 IAM 绑定的命令行工具
- IAP TCP Forwarding:基于隧道的虚拟机访问,用于无公开 IP 的 SSH/RDP
- Cloud Audit Logs:所有 IAP 访问决策的不可变记录,用于合规性
- Endpoint Verification:Chrome 扩展程序,收集设备属性用于访问级别评估
常见场景
场景:使用 IAP 保护 15 个内部 GCP 服务
场景背景:一家电商公司在 GKE 和 Cloud Run 上运行 15 个内部服务(管理仪表板、内部 API、监控工具)。目前这些服务仅由 VPN 和防火墙规则保护,造成过多网络级访问。
方法:
- 将所有服务部署在带托管 SSL 证书的 HTTPS 负载均衡器后方
- 为每个后端服务启用 IAP,使用每服务独立的 OAuth 客户端
- 创建将 Google Groups 映射到特定服务的 IAM 绑定(管理组 -> 管理仪表板,工程团队 -> 监控)
- 定义访问级别:managed-device(加密 + 屏幕锁),corp-network(办公室 IP 范围)
- 对管理仪表板和财务工具应用 managed-device 访问级别
- 配置 IAP TCP 隧道用于 GKE 节点的 SSH 访问(替换 SSH 跳板机)
- 为管理工具设置 4 小时重新认证,为监控工具设置 8 小时
- 配置 Cloud Audit Logs 并为重复拒绝创建告警
常见陷阱:IAP 每请求增加 10-50ms 延迟;测试应用性能。通过 IAP 的 WebSocket 连接需要特定后端服务配置。GKE 内部的服务间调用应通过内部服务网格绕过 IAP,而非使用外部 IAP 端点。紧急访问应使用没有访问级别条件的单独 IAM 绑定。
输出格式
Google Cloud IAP 配置报告
==================================================
项目: ecommerce-internal
报告日期: 2026-02-23
IAP 保护的服务:
后端服务: 12
App Engine: 1
Cloud Run: 2
IAP TCP 隧道: 4(SSH 访问)
总计: 19
访问控制:
IAM 绑定: 34
带访问级别: 18(52.9%)
访问级别: 3(managed-device, corp-network, high-trust)
会话策略:
管理工具: 4 小时重新认证(SECURE_KEY)
敏感应用: 4 小时重新认证(LOGIN)
通用工具: 8 小时重新认证(LOGIN)
访问日志(过去 24 小时):
总请求数: 23,456
已认证: 23,289(99.3%)
IAM 拒绝: 112
访问级别拒绝: 55
唯一用户数: 134