Identity-Aware Proxy (IAP) Basics
Identity-Aware Proxy (IAP) is a Google Cloud service that controls access to your cloud applications and VMs running on GCP. It works by verifying user identity and the context of the request to determine if a user should be allowed to access a resource. IAP acts as a central authorization layer, replacing the need for traditional VPNs in many scenarios.
The “Bouncer” Analogy
Imagine a high-security office building. In a traditional setup (VPN), you give employees a keycard to the front door. Once inside, they might be able to wander the halls. With IAP, there is a specialized bouncer standing directly in front of every single room. Even if you are inside the building, the bouncer checks your ID and your specific permissions for that room before letting you in. If you aren’t on the list for the “Server Room,” you can’t even touch the door handle.
Detail Elaboration: How IAP Works
IAP intercepts requests sent to your application. When a request reaches the Google Front End (GFE), IAP checks the user’s credentials (via Google Identity/Cloud IAM). If the user is authenticated, IAP then checks the IAM policy for that specific resource to see if the user has the required roles (like roles/iap.httpsResourceAccessor).
Practical Example: A developer wants to access an internal Jenkins server running on a Compute Engine VM. Instead of opening port 80/443 to the entire internet or requiring the developer to toggle a VPN, you enable IAP. The developer logs in with their corporate Google account, and IAP grants access based on their identity.
Core Concepts & GCP Best Practices
- Security (Zero Trust): IAP implements “BeyondCorp” principles. It assumes the network is hostile and verifies every request.
- Operational Excellence: Simplifies administration by removing the overhead of managing VPN clients and hardware.
- Scalability: Since it leverages the Google Front End, it scales automatically with your traffic.
- Cost Optimization: IAP itself is a managed service that can reduce the costs associated with maintaining complex network security appliances.
IAP vs. Traditional VPN
| Feature | Identity-Aware Proxy (IAP) | Cloud VPN |
|---|---|---|
| Access Level | Application/Service Level (Layer 7) | Network Level (Layer 3) |
| Client Software | None (Browser-based / Cloud SDK) | VPN Client or Gateway required |
| Best Use Case | Web Apps, SSH/RDP access | Connecting On-prem to VPC |
| Security Model | Zero Trust / Identity-centric | Perimeter-based security |
Decision Matrix: When to use IAP?
IF you need to provide access to a web application hosted on App Engine, GCE, or GKE… THEN use IAP (HTTPS).
IF you need to SSH or RDP into a VM without a Public IP address… THEN use IAP TCP Forwarding.
IF you need to connect an entire office network to your VPC… THEN use Cloud VPN.
Exam Tips: ACE Golden Nuggets
- Firewall Rule: To use IAP for SSH, you must allow ingress traffic from the IP range
35.235.240.0/20on port 22. This is a common exam question! - The Role: The specific IAM role required for users to pass through IAP is
roles/iap.httpsResourceAccessor. - Shared Responsibility: IAP handles authentication/authorization, but your app must still be able to handle session management if needed.
- Distractor: Don’t choose “Cloud Armor” for identity-based access; Cloud Armor is for WAF and DDoS protection, not user identity verification.
IAP Architecture & Flow
Key GCP Services
- App Engine: Standard/Flex support.
- Compute Engine: Via HTTP(S) Load Balancer.
- GKE: Via Ingress controller.
Common Pitfalls
- Forgetting to set up the OAuth Consent Screen.
- Not allowing the IAP IP range in VPC firewalls.
- Assuming IAP encrypts traffic (SSL is still needed).
Quick Patterns
- Internal Admin Tools: Secure them without a VPN.
- SSH Bastion: Use IAP TCP forwarding to remove public IPs from VMs.