How to Configure Google Cloud Access Context Manager (ACM) for Zero Trust Perimeters

In traditional network security, boundaries are defined by IP addresses and firewalls. If you are inside the corporate building (and thus on the corporate IP subnet), you are trusted and granted access to internal data. In a cloud-first, work-from-anywhere world, this perimeter model is entirely obsolete.

Zero Trust architecture demands that access decisions be based on the context of the request, regardless of the network location. Are they using a company-issued, managed laptop? Is the hard drive encrypted? Is the OS fully patched? Is the user logging in from a known geographic region?

In Google Cloud Platform (GCP), the engine that enforces these context-aware Zero Trust policies across all APIs and resources is Access Context Manager (ACM). ACM allows security architects to define strict, attribute-based access levels and apply them to VPC Service Controls or Identity-Aware Proxy (IAP), ensuring that even if a user has perfect IAM credentials, they cannot touch the data unless their device and context are mathematically secure.

This guide explains how to architect and deploy Access Context Manager policies in Google Cloud.

Understanding the ACM Architecture

ACM relies on two foundational components:

1. Access Levels: These are the logical rulesets (e.g., “Must be from a US IP address” AND “Must be using a Corporate Mac”). You define Access Levels globally at the GCP Organization level.
2. Enforcement Points: ACM does not block traffic by itself. It provides the logic. You must attach the Access Level to an enforcement point, primarily VPC Service Controls (VPC SC) (for securing backend APIs like Cloud Storage) or Identity-Aware Proxy (IAP) (for securing web applications and SSH access).

To evaluate device posture (e.g., “Is the hard drive encrypted?”), ACM integrates tightly with Endpoint Verification, a lightweight Chrome extension/agent deployed to your corporate laptops that feeds telemetry directly into Google Cloud.

Step 1: Deploying Endpoint Verification

If you want to build context rules based on device health, you must deploy Endpoint Verification.

1. Deploy the Endpoint Verification Chrome Extension to your corporate browser fleet via Google Workspace Admin Console or your MDM (like Jamf or Intune).
2. For deeper OS telemetry (like Screen Lock status and Disk Encryption status), you must also deploy the native OS helper app (available for Windows, macOS, and Linux) alongside the Chrome extension.

Once deployed, devices will begin reporting their cryptographic health status to your GCP Organization.

Step 2: Creating an Access Level in ACM

We will create a highly restrictive Access Level designed for accessing sensitive financial data in BigQuery.

The policy: The user must be on a company-owned device, the disk must be encrypted, and they must be connecting from an IP address originating in North America.

1. Navigate to the Google Cloud Console.
2. Switch to the Organization scope.
3. Go to Security > Access Context Manager.
4. Click Create Access Level.
5. Title: High-Security-Financial-Tier.

Under the Conditions tab, define the attributes:

• IP Subnetworks: Leave blank (unless you want to restrict to specific corporate egress IPs, which defeats the purpose of Zero Trust anywhere-access).
• Regions: Select United States and Canada.
• Device Policy:
  • Check Require Screen Lock.
  • Check Require Admin Approval (Requires the device to be explicitly approved in the Google Workspace inventory).
  • Check Require Corp Owned Device.
  • Under OS Constraints, add an entry for macOS and explicitly check Require Disk Encryption (FileVault). Add another entry for Windows and require BitLocker.

Click Save.

Step 3: Advanced Custom Access Levels (CEL)

The GUI builder is excellent for standard policies, but ACM supports incredibly complex logic using the Common Expression Language (CEL).

If you switch the Access Level mode to Custom, you can write programmatic rules. For example, to ensure a user only accesses the data if they authenticated using a FIDO2 security key within the last 4 hours:

request.auth.claims.amr.exists(m, m == "fido") && 
request.time - request.auth.time < duration("4h")

This level of cryptographic session enforcement is impossible with legacy firewalls.

Step 4: Enforcing the Access Level via VPC Service Controls

Now that the rule (High-Security-Financial-Tier) exists, it must be enforced.

Assume you have a VPC Service Controls perimeter locking down your BigQuery APIs to prevent data exfiltration. If you lock it down completely, your remote data scientists cannot run their queries. You must poke a contextual hole through the perimeter.

1. Go to Security > VPC Service Controls.
2. Edit your existing perimeter.
3. Navigate to the Ingress Policy tab.
4. Click Add Rule.
5. Under From (the source of the request), leave the Identities blank (to apply to all users), but under Access Levels, select the High-Security-Financial-Tier you just created.
6. Under To (the destination), select the BigQuery API.

Conclusion

When this policy is enforced, the cloud evaluates the cryptomathematics of every single API request in real-time. If a Data Scientist attempts to query BigQuery from their personal, unencrypted iPad in a coffee shop, ACM will detect the missing Endpoint Verification telemetry and instantly block the API call—even if their IAM credentials are perfectly valid. By deploying Access Context Manager, organizations transition from flawed network perimeters to impenetrable, identity-and-device-aware Zero Trust architecture.