Identity-Aware Proxy 概览

本页面介绍了 Identity-Aware Proxy (IAP) 的基本概念。

借助 IAP,您可以为通过 HTTPS 访问的应用建立一个中央授权层,从而可以采用一种应用级访问权限控制模型,而无需依赖网络级防火墙。

IAP 政策可在整个组织范围内伸缩。您可以集中定义访问权限政策,并将其应用于所有应用和资源。建议您指定专门负责创建和实施政策的团队,这样可以保护项目免受任何应用中错误的政策定义或实现的影响。

何时使用 IAP

当您要对应用和资源强制执行访问权限控制政策时,请使用 IAP。IAP 使用签名标头或 App Engine 标准环境 Users API 来保护应用的安全。借助于 IAP,您可以设置基于群组的应用访问权限,也就是说,您可以允许员工但不允许承包商使用某一资源,或者只允许特定部门使用该资源。

IAP 的工作原理

如果某一应用或资源受 IAP 保护,则该应用或资源只能由具备正确 Identity and Access Management (IAM) 角色成员(也称为用户)通过代理进行访问。如果您授权某用户访问受 IAP 保护的应用或资源,该用户只需要遵守所用产品实现的精确访问权限控制,而不需要 VPN。如果用户尝试访问受 IAP 保护的资源,Cloud IAP 会执行身份验证和授权检查。

App Engine
使用 Cloud IAP 时 App Engine 的请求路径示意图
Compute Engine
使用 Cloud IAP 时 Compute Engine 和 Kubernetes Engine 的请求路径示意图
GKE
使用 Cloud IAP 时 Compute Engine 和 Kubernetes Engine 的请求路径示意图
本地
使用 Cloud IAP 时本地应用的请求路径示意图

身份验证

向 Google Cloud 资源发出的请求通过 App Engine 或 Cloud Load Balancing (HTTPS) 传入。这些产品的服务基础架构代码会检查应用或后端服务是否启用了 IAP。如果启用了 IAP,则受保护资源的相关信息会被发送到 IAP 身份验证服务器。因此,请求标头或 Cookie 中会包含 Google Cloud 项目编号、请求网址及任何 IAP 凭据等信息。

接下来,IAP 会检查用户的浏览器凭据。如果凭据不存在,则用户会被重定向到 OAuth 2.0 Google 帐号登录流程,以便将令牌存储在浏览器 Cookie 中,供日后登录使用。如果您需要为现有用户创建 Google 帐号,则可以使用 Google Cloud Directory Sync 与 Active Directory 或 LDAP 服务器同步。

如果请求凭据有效,则身份验证服务器会使用这些凭据来获取用户的身份(电子邮件地址和用户 ID)。然后,身份验证服务器会使用该身份检查用户的 IAM 角色,并检查用户是否有权访问资源。

如果您使用的是 Compute Engine 或 Google Kubernetes Engine,则可以访问虚拟机 (VM) 的应用服务端口的用户可以绕过 IAP 身份验证。若代码在受 IAP 保护的应用所在虚拟机上运行,Compute Engine 和 GKE 防火墙无法阻止其访问。防火墙规则可以阻止来自其他虚拟机的访问,前提是配置正确。请了解您的职责以确保安全。

授权

身份验证完成后,IAP 会应用相关的 IAM 政策来检查用户是否有权访问所请求的资源。如果用户对资源所属的 Cloud Console 项目拥有 IAP-secured Web App User 角色,即有权访问相应应用。如需管理 IAP-secured Web App User 角色列表,请使用 Cloud Console 上的 IAP 面板

为资源启用 IAP 后,IAP 会自动创建 OAuth 2.0 客户端 ID 和密钥。如果您删除自动生成的 OAuth 2.0 凭据,IAP 将无法正常运行。您可以在 Cloud Console API 和服务中查看和管理 OAuth 2.0 凭据。

您的职责

IAP 可以为向 App Engine 或 Cloud Load Balancing HTTP(S) 发出的所有请求提供身份验证和授权保护。IAP 无法针对项目内的活动提供保护,例如项目内部的另一个虚拟机。

为确保安全,您必须采取以下预防措施:

  • 配置防火墙和负载平衡器以防范没有通过服务基础架构传入的流量。
  • 使用签名标头或 App Engine 标准环境 Users API

后续步骤