Configuring Google Cloud Identity-Aware Proxy (IAP) to enforce per-request identity verification for Compute Engine, App Engine, Cloud Run, and GKE services using access levels, context-aware policies, and programmatic access with service accounts.
Configuring Google Cloud Identity-Aware Proxy (IAP) to enforce per-request identity verification for Compute Engine, App Engine, Cloud Run, and GKE services using access levels, context-aware policies, and programmatic access with service accounts.
When protecting Google Cloud applications (App Engine, Cloud Run, GKE, Compute Engine) with identity-based access
When implementing context-aware access requiring device posture and location verification
When providing secure access to internal tools without VPN or public IP exposure
When needing per-request authentication and authorization for web applications and TCP services
When configuring programmatic access to IAP-protected resources using service accounts
Do not use for non-HTTP applications that cannot be placed behind an HTTPS load balancer, for public-facing applications that need unauthenticated access, or when applications handle their own authentication and IAP would conflict with existing auth flows.
Prerequisites
Google Cloud project with billing enabled
IAP API enabled (gcloud services enable iap.googleapis.com)
Application deployed behind HTTPS Load Balancer, App Engine, or Cloud Run
Cloud Identity or Google Workspace for user management
Access Context Manager API enabled for access levels
OAuth consent screen configured for the project
Workflow
Step 1: Enable IAP on Backend Services
Configure IAP for different GCP compute platforms.
# Enable required APIs
gcloud services enable iap.googleapis.com
gcloud services enable accesscontextmanager.googleapis.com
# Create OAuth consent screen
gcloud iap oauth-brands create \
--application_title="Internal Applications" \
--support_email=security@company.com
# Create OAuth client
gcloud iap oauth-clients create \
projects/PROJECT_ID/brands/BRAND_ID \
--display_name="IAP Web Client"# === Enable IAP on Compute Engine Backend Service ===
gcloud compute backend-services update my-backend-service \
--iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
--global
# === Enable IAP on App Engine ===
gcloud iap web enable \
--resource-type=app-engine \
--oauth2-client-id=CLIENT_ID \
--oauth2-client-secret=CLIENT_SECRET
# === Enable IAP on Cloud Run ===# First grant IAP service account the Cloud Run Invoker role
gcloud run services add-iam-policy-binding my-service \
--member= \
--role= \
--region=us-central1
gcloud compute backend-services update my-cloud-run-backend \
--iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
--global
gcloud compute instances add-iam-policy-binding my-vm \
--member= \
--role= \
--zone=us-central1-a
gcloud compute ssh my-vm --zone=us-central1-a --tunnel-through-iap
gcloud compute start-iap-tunnel my-windows-vm 3389 \
--local-host-port=localhost:3390 \
--zone=us-central1-a
Scenario: Securing 15 Internal GCP Services with IAP
Context: An e-commerce company runs 15 internal services on GKE and Cloud Run (admin dashboards, internal APIs, monitoring tools). Currently, these services are protected only by VPN and firewall rules, creating excessive network-level access.
Approach:
Deploy all services behind an HTTPS Load Balancer with managed SSL certificates
Enable IAP on each backend service with per-service OAuth clients
Create IAM bindings mapping Google Groups to specific services (admin group -> admin dashboard, engineering -> monitoring)
Apply managed-device access level to admin dashboard and financial tools
Configure IAP TCP tunneling for SSH access to GKE nodes (replacing SSH bastion host)
Set re-authentication to 4 hours for admin tools, 8 hours for monitoring
Configure Cloud Audit Logs and create alerting for repeated denials
Pitfalls: IAP adds 10-50ms latency per request; test application performance. WebSocket connections through IAP require specific backend service configuration. Service-to-service calls within GKE should bypass IAP using internal service mesh, not external IAP endpoints. Break-glass access should use a separate IAM binding without access level conditions.
