Identity-Aware Proxy (IAP) Basics
Identity-Aware Proxy (IAP) is a Google Cloud service that intercepts web requests sent to your application, authenticates the user making the request via Google Identity Service, and only lets the request through if the user has the correct Identity and Access Management (IAM) role. It acts as a central authorization layer for applications accessed by HTTPS and resources accessed via TCP (like SSH or RDP).
The Analogy: The Digital Bouncer
Imagine a high-end club. Traditionally, to keep the club safe, you’d build a massive wall (VPN) and only give keys to members. If a member loses their key, anyone can get in.
With IAP, there is no wall. Instead, there is a Smart Bouncer at the door. When you try to enter, the bouncer doesn’t just check if you have a key; they check your ID (Identity), verify you are on the guest list (IAM Roles), and check if you are wearing the right dress code (Context-Aware access like device security status). If you don’t meet every requirement, you don’t get in—no matter how you try to bypass the door.
Detail Elaboration: How IAP Works
IAP works by shifting access control from the network perimeter to individual users and devices. This is the core of the Zero Trust security model (BeyondCorp).
1. HTTPS Resources
When protecting App Engine, Cloud Run, or HTTP(S) Load Balancers, IAP sits behind the Load Balancer. When a request hits the LB, IAP checks for an active session cookie. If none exists, it redirects to Google Login. Once authenticated, IAP checks the IAM policy for the roles/iap.httpsResourceAccessor role.
2. TCP Forwarding
For Compute Engine instances, IAP allows you to connect via SSH or RDP without the VM having a public IP address. You wrap your traffic in HTTPS, send it to IAP, and IAP forwards it to the VM’s internal IP. This eliminates the need for “Bastion Hosts” or “Jump Boxes”.
Core Concepts & Best Practices
- Security: Centralizes access control. If a user leaves the company and their Google account is disabled, their access to all IAP-protected apps is revoked instantly.
- Reliability: Leverages Google’s global infrastructure. There is no VPN hardware to fail or scale.
- Cost Optimization: IAP is effectively free for most Google Cloud resources (App Engine, GCE). You save money by removing the need for expensive VPN licenses and dedicated Bastion Host VMs.
- Operational Excellence: Simplifies remote work. Employees don’t need to toggle a VPN client; they just navigate to a URL.
Comparison: Access Methods
| Feature | Identity-Aware Proxy (IAP) | Cloud VPN | Public IP + Firewall |
|---|---|---|---|
| Access Model | Identity-Based (Zero Trust) | Network-Based (Perimeter) | Open (IP-Based) |
| Client Software | None (Browser/gcloud) | VPN Client required | None |
| Granularity | Per-user/Per-application | Whole Subnet/Network | IP Ranges only |
| Setup Complexity | Low (Enable & IAM) | High (Tunnels/BGP) | Low (Dangerous) |
Scenario-Based Learning (Decision Matrix)
- IF you need to provide access to an internal web app for remote employees… THEN use IAP with an HTTPS Load Balancer.
- IF you need to SSH into a VM that has no public IP… THEN use IAP TCP Forwarding (
gcloud compute ssh --tunnel-through-iap). - IF you want to ensure only company-managed laptops can access a resource… THEN use IAP with Context-Aware Access levels.
- IF you need to connect two VPCs in different projects… THEN use VPC Peering (IAP is for user-to-resource, not network-to-network).
Exam Tips: ACE Golden Nuggets
- The Magic IP Range: For IAP TCP Forwarding to work, you MUST create a firewall rule allowing ingress from
35.235.240.0/20on port 22 (SSH) or 3389 (RDP). - IAM Role to Remember: To access an app, users need
roles/iap.httpsResourceAccessor. To use TCP tunneling, they needroles/iap.tunnelResourceAccessor. - The “No Public IP” Distractor: If an exam question asks how to SSH into a VM without a public IP, IAP is almost always the correct answer. Do not choose “Cloud VPN” unless a persistent site-to-site connection is mentioned.
- Shared Secret vs IAP: IAP is superior to hard-coded shared secrets or passwords because it handles identity and rotation automatically.
IAP Architecture & Flow
Request Flow: Identity Verification → IAM Check → Context Check → Resource Access
- App Engine: Standard/Flex support.
- Compute Engine: SSH/RDP via TCP tunnel.
- GKE: Backends via BackendConfig.
- On-Prem: Via Cloud Interconnect/VPN.
- Forgetting to allow
35.235.240.0/20in firewall. - Assuming IAP encrypts data (it’s for auth, use TLS for data).
- Not granting
Service Account Userrole for tunneling.
- Zero Trust: IAP + Access Context Manager.
- Bastion-less: IAP Tunneling + Internal IPs only.
- Legacy Auth: Use IAP to wrap old apps with modern SSO.