Identity-Aware Proxy (IAP)
Identity-Aware Proxy (IAP) provides a centralized authorization layer for managing access to cloud resources and applications, ensuring secure access through authentication and authorization checks.
| Category | Identity & Access Management |
|---|---|
| This page updated | a month ago |
| Pricing Details | Pricing based on usage and resource access. |
| Target Audience | Cloud architects, security professionals, and developers managing cloud resources. |
Identity-Aware Proxy (IAP) is designed for managing access to cloud resources and applications by providing a centralized authorization layer. Here’s how it works:
IAP intercepts requests to your Google Cloud resources, such as those accessed through App Engine, Cloud Load Balancing (HTTPS), or internal HTTP load balancing. It performs authentication and authorization checks using Google Identity Service and IAM roles. When a user attempts to access an IAP-secured resource, IAP redirects them to an OAuth 2.0 Google Account sign-in flow if necessary, and then verifies the user's identity and IAM role to determine if they are authorized to access the requested resource.
The technical architecture of IAP involves integrating with Google Cloud services to extract user identity from proxy-injected HTTP headers, such as the x-goog-iap-jwt-assertion header. This integration relies on the Cloud Resource Manager API to retrieve project details and validate the JWT payload, including claims like issue time, expiration time, issuer, and audience. For applications running on Compute Engine or Kubernetes Engine, the spring.cloud.gcp.security.iap.audience property must be explicitly configured to determine the correct audience string.
Operationally, IAP requires careful configuration of firewall and load balancer settings to ensure that all traffic is routed through the serving infrastructure. It also supports features like TCP forwarding for SSH and RDP access to VMs without public IP addresses, enhancing the security posture by implementing a zero-trust access model.
Key technical details include the automatic creation of OAuth 2.0 client IDs and secrets when IAP is enabled, and the necessity of managing these credentials through the Google Cloud console. Additionally, IAP policies can be centrally defined and applied across the organization, ensuring consistent access control without relying on network-level firewalls.
However, there are operational limitations to consider, such as the need to configure additional security measures for traffic that doesn't come through the serving infrastructure and the potential for increased complexity in multi-account setups. Moreover, IAP does not protect against activities within a project, such as access by other VMs within the same project.