Identity-Aware Proxy (IAP)
Identity-Aware Proxy is Google's implementation of the BeyondCorp model: zero-trust access to internal applications without a VPN. IAP sits between the public internet and your internal service, intercepts every request, verifies the user's identity and IAM permissions, and forwards only authenticated and authorized traffic to the backend. The mental shift from a traditional VPN architecture is real — instead of "trust the network, then check the user," IAP says "verify the user every request, never trust the network alone."
IAP has two distinct surfaces. The first is HTTPS access to web applications running on Cloud Run, App Engine, GKE, or Compute Engine. The second is TCP forwarding for SSH and RDP into Compute Engine VMs without a bastion host. Both share the same authentication model and the same operational philosophy.
Zero-Trust Access to Internal Apps
In a traditional architecture, users connect to a VPN to enter the corporate network, then access internal tools that trust the network perimeter. The VPN is the security boundary; once inside, traffic is largely trusted. This model breaks when employees work from anywhere, when contractors need partial access, when laptops are the new perimeter, and when one compromised credential lets the attacker pivot across everything inside the network.
IAP inverts the model. The internal app is exposed through Google's edge, behind IAP. There is no VPN to set up; users authenticate to GCP (using their Cloud Identity or federated identity), and IAP checks IAM permissions on every request. Compromise of any single workstation does not grant network-level access to other internal services — each service has its own IAM policy.
HTTPS Apps Behind IAP
For web applications served over HTTPS, IAP is enabled on the load balancer or directly on Cloud Run / App Engine. Requests arrive at Google's edge, IAP terminates them, verifies the user via OAuth and IAM, and forwards to the backend with headers that identify the authenticated user. The backend sees a normal HTTPS request plus convenience headers like X-Goog-Authenticated-User-Email and X-Goog-Authenticated-User-Id, and — for cryptographic verification — a signed JWT in the X-Goog-IAP-JWT-Assertion header.
For Compute Engine workloads, IAP works through an external Application Load Balancer in front of the VMs. For internal apps that should not be publicly addressable, IAP is the right shape: the LB has a public IP, but only IAM-authorized identities ever reach the backend.
IAP TCP Forwarding
For SSH into Compute Engine VMs and RDP into Windows VMs, IAP TCP forwarding eliminates the need for a bastion host or public IP on the target. The flow: gcloud compute ssh with IAP enabled opens a tunnel from your machine through Google's edge into the VM, with IAM checking your access on every connection. The VM has no public IP, no inbound exposure, no bastion to maintain. SSH and RDP keys are validated as usual at the OS level after IAP lets the connection through; IAP is a gate, not a replacement for OS-level auth.
IAM Roles for IAP
Two primary roles. roles/iap.httpsResourceAccessor on a backend service or App Engine app grants HTTPS access through IAP. roles/iap.tunnelResourceAccessor on a project, VPC, or specific VM grants TCP tunneling access. Bind these to groups, never to individuals (the rule remains the same as everywhere else in IAM). IAM Conditions on these bindings are particularly useful — time-bounded grants for temporary access, region restrictions for compliance.
IAP vs Traditional VPN / Bastion
IAPzero trustA paradigm shift, not just a different vendor.
IAP — per-request identity and authorization at Google's edge. No network perimeter to trust. No client software to install. Granular IAM on each app and each VM. The right default for internal admin tools, dev environments, internal dashboards, and operator SSH access.
VPN / Bastion — network-level boundary. Users enter the trusted network, then access internal services. Easier when many legacy services share infrastructure assumptions (multicast, broadcast, custom protocols), harder when the threat model includes compromise inside the network. Still has its place for legacy systems IAP cannot front.
- VPN deployed for access to internal admin tools when IAP would replace the VPN entirely and remove the operational tax of running it.
- Bastion host maintained for SSH when IAP TCP forwarding makes the bastion unnecessary — and removes the bastion's own attack surface.
- IP allow-listing used to gate access to an internal tool. IPs change when users travel, when offices move, when VPNs rotate; IAP authenticates the user and the device, not the IP.
- Trusting the unsigned
X-Goog-Authenticated-User-*headers as a security boundary. They carry no signature — an attacker who bypasses the LB (e.g., from inside the VPC) can forge them. The backend should verify the signed JWT inX-Goog-IAP-JWT-Assertioninstead. - IAP IAM bindings without IAM Conditions for sensitive resources. Time-bounded or region-bounded conditions reduce blast radius for temporary grants.
- OAuth client misconfigured on initial setup. Legitimate users get cryptic 403s; the team debugs network paths instead of looking at the IAP screen.
- IAP for all internal admin tools, dev environments, dashboards, and operator-only services. Default to IAP, justify any deviation.
- IAP TCP forwarding for SSH and RDP. Bastion hosts only when IAP genuinely cannot reach the target.
- Verify the signed JWT in the
X-Goog-IAP-JWT-Assertionheader in the backend as defense in depth — validating its signature, issuer, and audience. TreatX-Goog-Authenticated-User-*as convenience headers only, never as proof of identity on their own. - IAM Conditions on sensitive resources — time-bounded, region-bounded, attribute-bounded as the case warrants.
- Workforce Identity Federation paired with IAP so authentication uses the corporate IdP, not a separate Google login.
- Cloud Audit Logs reviewed for IAP access events. Every authenticated request is logged; unusual patterns surface early compromise.
Knowledge Check
What is the core idea behind Identity-Aware Proxy?
- Run a fully managed VPN service at Google's edge that users can install on their own laptops without needing any local admin permissions or a separate client download
- Verify the user's identity and IAM permissions on every request at Google's edge — no VPN, no network perimeter to trust, granular access on each app and each VM
- Replace IAM entirely with a standalone OAuth proxy that grants role-free access to all internal apps
- Provide an automatic firewall rule that allows the IP ranges of every authenticated user's device
What does IAP TCP forwarding eliminate the need for?
- SSH keys on Compute Engine VMs — IAP forwards a single Google-managed key on every connection it tunnels
- A bastion host or public IP on the target VM — IAP tunnels SSH and RDP through Google's edge with IAM authorization on every connection
- VPC firewall rules altogether — IAP tunneling bypasses all firewall enforcement on the target subnet
- OS-level authentication — IAP authenticates the user fully at the edge and then lets them straight in to the VM without any further credential checks
How should a backend behind IAP cryptographically verify the caller's identity?
- Validate the signed JWT in the
X-Goog-IAP-JWT-Assertionheader; theX-Goog-Authenticated-User-*headers are unsigned and can be forged by anyone who bypasses the load balancer - Verify the signature on the
X-Goog-Authenticated-User-Emailheader, which IAP cryptographically signs on every single request - It does not need to verify anything at all; any request that manages to reach the backend has already been fully authorized by IAP further upstream and so cannot possibly be spoofed
- Recompute the identity headers locally from the OAuth session cookie that IAP forwards along with the request, then trust the result as authoritative
When does a traditional VPN still beat IAP?
- For internal HTTPS web apps, since IAP has no way to front that kind of traffic
- For SSH shell access to Compute Engine VMs, because IAP is only able to handle plain HTTPS traffic
- For legacy services that depend on protocols IAP does not front (multicast, broadcast, proprietary TCP applications) — those still need the network-level boundary a VPN provides
- For external partner and contractor access, because IAP categorically rejects any identity that is not already a native Google Workspace user account inside your own organization
Why is IP allow-listing a weaker access control than IAP for internal admin tools?
- IP allow-listing is fundamentally incompatible with Google Cloud Load Balancing and so cannot front Cloud Run or App Engine workloads
- IPs change when users travel, offices move, or VPN concentrators rotate; IAP authenticates the user identity per request, which is more durable and far more precise
- IP allow-listing requires an expensive paid feature tier that most engineering teams simply cannot afford to enable
- IP allow-listing automatically opens every VPC firewall rule to the allowed IPs, quietly defeating all of the other access controls you have carefully set up elsewhere
You got correct