You’ve built a fantastic internal web application that your employees use for critical operational tasks. It’s hosted on a Compute Engine VM or a GKE cluster. Traditionally, to keep this application secure and only accessible to your internal staff, you would:
- Place the application on a private network or behind a VPN.
- Force all employees to connect to the VPN before they can access the app.
This approach works, but it comes with headaches: VPNs can be slow, difficult to manage at scale, and create a “moat” around your network that, once breached, exposes everything within. Modern security thinking has shifted to a “zero-trust” model: never trust, always verify. Every request, regardless of origin, should be authenticated and authorized.
How do you provide secure access to your internal applications without the overhead of a VPN, while embracing zero-trust principles? You need a smart bouncer at the door, one that checks every ID and every authorization. You need Identity-Aware Proxy (IAP).
What is Identity-Aware Proxy (IAP)?
Identity-Aware Proxy (IAP) is a Google Cloud service that allows you to control access to your web applications and backend resources running on GCP. It verifies a user’s identity and checks if they are authorized to access a resource before letting their request reach your application.
- Zero-Trust by Design: IAP doesn’t assume trust based on network location. It authenticates and authorizes every user for every request.
- Context-Aware: It integrates with Google’s identity system (Google accounts, Google Workspace, Cloud Identity) and checks if the user’s identity has the correct IAM permissions.
- No VPN Required: It allows you to expose your applications to the internet without making them publicly accessible. Users simply access a public URL, and IAP handles the security layer.
- Analogy: Imagine a private, members-only club. Instead of making everyone enter through a secret tunnel (VPN), IAP sets up a very visible, public entrance. But at that entrance, there’s a highly intelligent bouncer. Every person who approaches the door is asked for their ID (Google Identity) and checked against a list of authorized members (IAM policies). Only if they are on the list are they allowed in. The club itself remains private and secure, even with a public-facing door.
How IAP Works: The Request Flow
- User Request: An employee wants to access your internal app, for example,
https://my-internal-app.example.com. - IAP Intercepts: The request first hits a Google Cloud Load Balancer (usually an External HTTP(S) Load Balancer), which then forwards it to the IAP service.
- Authentication: IAP checks if the user is signed in with a Google Identity. If not, it redirects them to the Google login page.
- Authorization (IAM Check): Once authenticated, IAP checks the IAM policy on the specific backend service or resource the user is trying to reach. It looks for the
IAP-secured Web App Userrole (roles/iap.httpsResourceAccessor) granted to that user’s identity. - Forward to Backend:
- If authorized: IAP adds a special HTTP header to the request (which includes information about the authenticated user’s identity) and securely forwards the request to your application backend.
- If NOT authorized: IAP blocks the request and returns an “Access Denied” page.
- Application Receives Request: Your application receives the request, already knowing that it’s from an authenticated and authorized user. It can even trust the identity information provided in the IAP headers.
Key Point: Your application doesn’t need to do any authentication itself. IAP handles it all. This dramatically simplifies your application security.
What Can IAP Protect?
IAP isn’t just for public web apps. It’s highly versatile:
- App Engine: Services running on App Engine Standard or Flexible.
- Compute Engine (GCE): VMs (via instance groups or NEGs behind a load balancer).
- Google Kubernetes Engine (GKE): Services running in GKE (via Ingress or GKE load balancers).
- Cloud Run: Services deployed to Cloud Run.
- Internal HTTP(S) Load Balancer: Yes, you can even put IAP on an internal load balancer to secure internal microservices.
- SSH/RDP to VMs: You can even use IAP to provide secure SSH or RDP access to your individual Compute Engine VMs without requiring public IPs or VPNs for those VMs.
Common Pitfalls & Best Practices
- Pitfall: Thinking IAP is a firewall. It’s not a network-level firewall; it’s an application-level access control.
- Best Practice: Still use network firewalls to block all unauthenticated traffic from reaching your backend applications directly. IAP works best when your application backends are private, and IAP is the only entry point.
- Pitfall: Granting the
IAP-secured Web App Userrole toallUsers(public access) without understanding the implications. - Best Practice: Grant the
IAP-secured Web App Userrole only to specific user accounts or Google Groups that need access. This is the core of IAP’s security model. - Pitfall: Not understanding the role of the Cloud Load Balancer. IAP works with a load balancer, not as a replacement for it.
- Best Practice: When setting up IAP for web applications, you’ll almost always be configuring it on the Backend Service of an External HTTP(S) Load Balancer.
- Pitfall: Over-relying on IAP headers for all application-level authorization.
- Best Practice: While IAP provides strong identity and some context, your application should still perform its own fine-grained authorization based on the user’s role within the application (e.g., “Is this user an admin?”). IAP gets them to the door; your app decides what they can do inside.
Quick Reference Command Center
Setting up IAP usually involves a few steps in the GCP Console or gcloud commands, primarily enabling IAP on a backend service and then setting IAM policies.
| Action | Command |
|---|---|
| Enable IAP on a Backend Service | gcloud compute backend-services update [BACKEND_SERVICE_NAME] --global --iap=enabled |
| Grant IAP Access to a User | gcloud compute backend-services add-iam-policy-binding [BACKEND_SERVICE_NAME] --global --member=user:[USER_EMAIL] --role=roles/iap.httpsResourceAccessor |
| Grant IAP Access to a Group | gcloud compute backend-services add-iam-policy-binding [BACKEND_SERVICE_NAME] --global --member=group:[GROUP_EMAIL] --role=roles/iap.httpsResourceAccessor |
| Enable IAP for SSH/RDP (TCP Tunnels) | gcloud compute ssh [INSTANCE_NAME] --zone=[ZONE] --tunnel-through-iap (Requires iap.tunnelInstances.accessViaIAP permission) |