Implementing Zero Trust With Beyondcorp

Implementing Zero Trust with BeyondCorp

Overview

Google BeyondCorp Enterprise implements the zero trust security model by eliminating the concept of a trusted network perimeter. Instead of relying on VPNs and network location, BeyondCorp authenticates and authorizes every request based on user identity, device posture, and contextual attributes. Identity-Aware Proxy (IAP) serves as the enforcement point, intercepting all requests to protected resources and evaluating them against Access Context Manager policies. This skill covers configuring IAP for web applications, defining access levels based on device trust and network attributes, and auditing access policies for compliance.

When to Use

• When deploying or configuring implementing zero trust with beyondcorp capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Common Misconfigurations & Verification

BeyondCorp fails open when IAP is configured but not actually in the request path, or when access levels are too loose. Check for these:

• Backend reachable around IAP. If the Compute Engine VM / GKE service has a public IP or a load-balancer path that skips IAP, the proxy is bypassed - lock the firewall so only IAP source ranges reach the backend.
• Access levels too permissive. A level keyed only on a broad corporate IP range (ipSubnetworks) grants access to anyone on the VPN, ignoring device trust.
• Device-trust signals not required. Access Context Manager allows the request without checking Endpoint Verification attributes (OS version, disk encryption, screen lock).
• IAP IAM binding left as allUsers / allAuthenticatedUsers.
• Access level bound to the policy but left in dry-run only.

How to confirm: from outside the trusted context (untrusted IP, unmanaged device), hit the protected URL and confirm IAP returns a deny, not the app. Probe the backend's direct IP and verify the firewall refuses anything that is not an IAP source range. Check IAP audit logs show the deny with the failed access-level reason, and confirm a compliant device from a trusted context succeeds.

Prerequisites

• Google Cloud project with BeyondCorp Enterprise license
• IAP API enabled (iap.googleapis.com)
• Access Context Manager API enabled (accesscontextmanager.googleapis.com)
• GCP resources to protect (Compute Engine, App Engine, or GKE services)
• Endpoint Verification deployed on managed devices
• Python 3.9+ with google-cloud-iap library

Steps

Step 1: Enable IAP on Target Resources

Configure Identity-Aware Proxy on Compute Engine, App Engine, or HTTPS load balancer backends.

Step 2: Define Access Levels

Create Access Context Manager access levels based on IP ranges, device attributes (OS version, encryption, screen lock), and geographic location.

Step 3: Bind Access Policies

Apply access levels as IAP conditions to enforce context-aware access decisions on protected resources.

Step 4: Audit and Monitor

Query IAP audit logs, verify policy enforcement, and identify gaps in zero trust coverage.

Expected Output

JSON report containing IAP-protected resources, access level definitions, policy binding audit results, and zero trust coverage metrics.