Google Cloud IAP Architecture for Enterprise Security

Overview

Identity-Aware Proxy (IAP) authenticates users and authorizes access to applications before traffic reaches backend services. Enterprises place IAP in front of HTTPS workloads behind Cloud Load Balancing instead of extending the corporate network with VPN tunnels. IAP integrates with Google Identity, workforce federation (SAML/OIDC), and IAM, so every request is evaluated against principal, resource, and optional context attributes. For platform teams, IAP implements zero trust at the edge: no implicit trust from IP alone, centralized audit via Cloud Audit Logs, and consistent policy across GKE, Compute Engine, and Cloud Run.

Introduction

Perimeter security assumes users on the corporate network are trustworthy. That model fails when applications run on managed Kubernetes, serverless runtimes, and multi-region load balancers. VPNs add client distribution, split tunneling, and capacity overhead, and often grant broad network access instead of least-privilege access to specific applications.

IAP makes the application URL the security boundary. Users reach an HTTPS endpoint; Google terminates TLS, validates identity, checks IAM and optional access levels, then forwards authorized sessions to backends. Security teams gain one control point for admin consoles and internal tools without exposing SSH or RDP to the internet.

This post covers enterprise IAP architecture, request flow, governance aligned with SOC 2, ISO 27001, and PCI DSS, and practices platform engineers use in production.

Architecture Overview

External or Internal HTTP(S) Load Balancing sits in front of backend services (GKE Ingress, NEG-backed VMs, Cloud Run). IAP is enabled on the backend service or serverless NEG. Authentication uses Google accounts or Cloud Identity/workforce federation (Okta, Azure AD). Authorization uses IAM roles such as roles/iap.httpsResourceAccessor, optionally with Access Context Manager access levels (device posture, geo).

Backends stay private: GKE without node public IPs, VMs on private subnets, Cloud Run with internal-and-LB ingress. Cloud Audit Logs record AuthorizeUser and IAP configuration changes.

Architecture Diagram

Architecture Flow Explanation

1. User requests https://admin.example.com; DNS resolves to the load balancer.
2. TLS terminates at the LB; IAP requires HTTPS for web resources.
3. Without a valid IAP session, IAP redirects to Google sign-in or to a federated IDP (SAML/OIDC).
4. After authentication, IAP maintains a stable user identity (email address, subject).
5. IAP evaluates IAM on the protected resource:

6. Access Context Manager or IAM conditions can require a corp device or a time window.
7. Authorized requests include X-Goog-IAP-JWT-Assertion; applications must validate JWT aud, iss, exp, and sub—never trust X-Forwarded-User
8. AuthorizeUser events feed Admin Activity logs for compliance.

IAP TCP (SSH/RDP) uses gcloud compute ssh with tunneling and roles/iap.tunnelResourceAccessor.

Core Security / Governance Best Practices

1. No IP-only trust: Pair IAP with internal load balancers and private backends; use Access Levels as supplementary signals.
2. Least privilege IAM: Grant httpsResourceAccessor to groups per backend; avoid allAuthenticatedUsers unless intentional.
3. JWT validation in apps: Verify audience /projects/PROJECT_NUMBER/global/backendServices/SERVICE_ID.
4. Workforce federation: Enforce MFA at the IdP; map IdP groups to Google groups for IAM bindings.
5. Domain restriction: Block personal Gmail via OAuth brand settings where PCI/SOC 2 requires workforce-only access.
6. Centralized logging: Sink Admin Activity to a security project; alert on IAP SetIamPolicy and authorization failures.
7. Separate admin vs customer paths: Distinct backend services, certs, and IAM groups limit blast radius.
8. Prevent bypass: Firewall deny direct instance access; restrict Cloud Run ingress to LB-only paths.
9. OAuth hygiene: Separate OAuth clients for prod/nonprod; quarterly Asset Inventory review of IAP resources.
10. Compliance mapping: Document logical access (ISO 27001 A.9), authentication (PCI DSS 8), revocation via IdP (SOC 2 CC6.1); retain logs per policy.

Operational Benefits

• Smaller VPN footprint: offboarding is IdP group removal plus IAM.
• One mechanism for GKE UIs, CI tools, and NEG-backed VMs.
• Grant/deny events export to SIEM via log sinks.
• Revoke access by IAM or IdP without regional firewall changes.

Common Challenges and Mitigations

Enterprise Implementation Recommendations

• Enable IAP APIs from landing-zone Terraform; bind Cloud Identity synced groups (gcp-platform-admins).
• Terraform backend service example:

• Staging mirrors prod with separate OAuth clients and audiences.
• PCI cardholder environments: IAP-only paths; annual access reviews per PCI DSS 7 and 8.

Conclusion

IAP delivers zero-trust access for human users to HTTPS applications and for tunneled admin sessions, without a parallel VPN estate. With IAM least privilege, federation, JWT verification, and centralized audit logging, IAP aligns operations with SOC 2, ISO 27001, and PCI DSS access expectations. Treat IAP as mandatory for internal HTTPS tools and verify no backend bypass exists.

Drop a query if you have any questions regarding Google Cloud Identity-Aware Proxy and we will get back to you quickly.