Implementing Google's BeyondCorp zero trust access model to eliminate implicit trust from the network perimeter, enforce identity-aware access controls using IAP, Access Context Manager, and Chrome Enterprise Premium for VPN-less secure application access.
Implementing Google's BeyondCorp zero trust access model to eliminate implicit trust from the network perimeter, enforce identity-aware access controls using IAP, Access Context Manager, and Chrome Enterprise Premium for VPN-less secure application access.
When replacing traditional VPN infrastructure with identity-based application access
When migrating to Google Cloud and requiring zero trust access for internal applications
When implementing device trust verification as a prerequisite for resource access
When needing context-aware access policies based on user identity, device posture, and location
When securing access for remote and hybrid workforce without network-level trust
Do not use when applications require raw network-level access (e.g., UDP-based protocols not supported by IAP), for consumer-facing public applications, or when the organization lacks an identity provider with MFA capabilities.
Common Misconfigurations & Verification
Origin reachable bypassing IAP: BeyondCorp protects only traffic via the HTTPS load balancer / BeyondCorp connector. A backend with a public IP, or a VPC firewall allowing the app port from anywhere, lets clients skip IAP. Restrict ingress to the IAP source range 35.235.240.0/20 and strip public IPs from GCE/GKE nodes.
IAM binding without an access-level condition: granting roles/iap.httpsResourceAccessor to a group but omitting --condition=...accessLevels/corporate-managed verifies identity yet never checks device posture, so an unenrolled device passes. Confirm every binding carries the access-level expression.
allUsers/allAuthenticatedUsers left on a backend: instantly makes the app public; audit each service's IAM policy.
Endpoint Verification collected but not enforced: gathering posture without an access level that requires ENCRYPTED/requireScreenlock leaves the signals decorative.
Verify: from off-network curl http://<backend-ip>:<port>/ directly, it must be unreachable (only 35.235.240.0/20 permitted). Sign in from a device that fails the corporate-managed level and confirm jsonPayload.decision="DENY" / status.code=16 in the iap_tunnel logs. Audit IAM for any allUsers binding.
Prerequisites
Google Cloud organization with Cloud Identity or Google Workspace
Identity-Aware Proxy (IAP) API enabled on the GCP project
Chrome Enterprise Premium license for endpoint verification
Applications deployed behind a Google Cloud Load Balancer or on App Engine/Cloud Run
Endpoint Verification extension deployed on all corporate devices
Access Context Manager API enabled
Workflow
Step 1: Configure Access Context Manager with Access Levels
Define access levels that represent trust tiers based on device and user attributes.
Cloud Audit Logs: Immutable log records of all IAP access decisions for compliance and forensic analysis
Common Scenarios
Scenario: Migrating 50+ Internal Applications from VPN to BeyondCorp
Context: A technology company with 3,000 employees uses Cisco AnyConnect VPN for accessing internal applications. The VPN introduces latency, creates a single point of failure, and grants excessive network access after authentication.
Approach:
Inventory all 50+ applications and categorize by hosting (GCP, on-prem, SaaS) and protocol (HTTPS, TCP, SSH)
Deploy Endpoint Verification to all corporate devices and establish baseline device posture data over 2 weeks
Create access levels in Access Context Manager: corporate-managed, contractor-device, high-trust
Enable IAP on GCP-hosted HTTPS applications first (App Engine, Cloud Run, GKE services)
Deploy BeyondCorp Enterprise connectors for on-premises applications
Migrate users in 3 phases: IT/Engineering (week 1-2), General staff (week 3-4), Executives/Finance (week 5-6)
Configure re-authentication policies: 8 hours for general apps, 1 hour for financial systems
Set up BigQuery audit pipeline for continuous monitoring and anomaly detection
Decommission VPN after 30-day parallel operation period
Pitfalls: Some legacy applications may not support HTTPS proxying and require TCP tunnel mode. Device enrollment takes time; plan a 2-week onboarding period before enforcing device posture requirements. Break-glass accounts with bypassed access levels must be created and tested for identity provider outages.
