Access Context Manager Perimeters and Access Levels

VPC Service Controls (opens in a new tab) service perimeters are context-based security boundaries defined in Access Context Manager that protect Google Cloud projects and restricted APIs from data exfiltration. A service perimeter encloses a set of member projects and the services to protect, and it denies requests that originate outside the perimeter unless an access level or ingress rule explicitly allows them. Perimeters also control egress across the boundary, for example by allowing only certain projects to read BigQuery data inside. Perimeters do not replace Identity and Access Management (IAM), so least-privilege IAM must still be applied inside the perimeter.

1.1Unified Perimeters and Multiple Perimeters

A unified perimeter design uses one large service perimeter that encloses all qualifying projects in an organization. The unified perimeter provides the strongest protection against data exfiltration with the lowest management overhead because resources inside can communicate freely when IAM and network controls permit. Administrators then focus mainly on north-south access from the internet to resources inside the perimeter, rather than on traffic between internal zones.

Multiple smaller perimeters split the organization into separate security zones, which requires managing east-west traffic between perimeters in addition to north-south traffic. That overhead grows considerably with size and perimeter count, so segmented designs should stay simple and avoid multiple bridges, perimeter network projects, DMZ perimeters, and complex access levels. Multiple perimeters are appropriate when security zones must remain distinct:

• High-trust data and lower-tier de-identified data, such as raw patient data in one perimeter and anonymized data in another perimeter that can be shared externally.
• Regulated data that needs an isolated compliance boundary, such as data subject to PCI DSS.
• Data-sharing workflows where a separate perimeter holds shareable copies while the source perimeter remains protected.
• Independent third-party tenants hosted in one organization, where movement of data from one tenant to another is treated as exfiltration and each tenant receives its own perimeter.

Layer any perimeter with additional controls, such as preventing direct internet egress from VPC networks inside the perimeter.

1.2Regular Perimeters, Bridge Perimeters, and Cross-Perimeter Flows

A regular service perimeter defines a security zone around its member projects and restricted services, and any access from outside that zone must be explicitly permitted. A bridge perimeter is a special perimeter type that connects projects that remain in different regular perimeters so they can share data in a controlled way without merging their security zones. Bridges should be minimized because each bridge creates east-west policy that must be reviewed and maintained, and tenant or high-trust boundaries that must not leak should remain without a bridge.

Cross-perimeter communication is enforced with ingress rules that allow traffic into a perimeter and egress rules that allow traffic to leave a perimeter. In a Shared VPC pattern with an aiml-host-project and service projects ph-fm-svc-project-1, ph-fm-svc-project-2, and ph-fm-svc-project-3, traffic flows from subnets in the host project perimeter to the Agent Platform API (opens in a new tab) and Compute Engine API in each service project perimeter. Return traffic flows from each service project perimeter back to the Compute Engine API in the host project perimeter because compute creation creates bidirectional flows. Each direction depends on a matching rule: the destination perimeter needs an ingress rule that accepts the source identity and network, and the source perimeter needs an egress rule that permits the call to the destination project and service. A related boundary appears with Cloud Storage Requester Pays, where a request inside a perimeter that protects Cloud Storage cannot name a paying project outside the perimeter unless that paying project is in the same perimeter or in a perimeter bridge with the bucket project.

1.3Building Enforcement with Access Levels and Dry-Run Testing

Building enforcement with access levels means creating network and context conditions in Access Context Manager that ingress and egress rules can reference. An access level expresses conditions such as private IP subnetworks in a specific VPC. In the host-to-service example, one access level is created per shared subnet, so gce-subnet-1 represents the CIDR shared with ph-fm-svc-project-1, gce-subnet-2 represents the CIDR shared with ph-fm-svc-project-2, and gce-subnet-3 represents the CIDR shared with ph-fm-svc-project-3. Those access levels are then used in the ingress rules of the service project perimeters and the egress rules of the host project perimeter to permit only the required Agent Platform API and Compute Engine API flows between the zones.

Creation of a subnet-based basic access level follows an ordered workflow in the Google Cloud console:

1. Select scope: In the project selector, open the All tab and select the organization that owns the access policy.
2. Start basic mode: Create a basic access level and choose Basic mode for conditions.
3. Name and result: Enter the access level title, such as gce-subnet-1, and set When condition is met, return to TRUE.
4. Choose private addresses: Under IP Subnetworks, choose Private IP so the condition matches internal VPC addresses.
5. Bind to VPC: Select VPC Networks, then identify the project and VPC name that contains the shared subnet.
6. Add CIDR: Select the IP subnetwork CIDR range that the host project shared with the corresponding service project.

New perimeters should first be created in dry-run mode, in which the perimeter logs violations as though enforcement were active but does not block access to restricted services. Dry-run logs allow teams to discover missing ingress rules, egress rules, or access levels before enforcement would break the bidirectional host-to-service flows. Perimeters can be created and updated with the Google Cloud CLI by naming the perimeter, restricted services, member resources as projects/PROJECT, and YAML files for ingress and egress policies, and new projects should pass a review and qualification process before they are added to the enforced set. Context-aware controls for service accounts (opens in a new tab) follow the same principle of validating identity and context before enforcement blocks legitimate automation.

An Access Context Manager access level is a named set of requirements that a request must meet before access to a protected resource is honored. Access levels live inside an access policy, which is an organization-wide container for access levels and service perimeters, and they evaluate signals about user identity, device state, and network context on every request. An access level alone does not block traffic; the boundary takes effect only after the access level is attached to an enforcement point such as an Identity-Aware Proxy (IAP) IAM condition, an access binding, or a VPC Service Controls (opens in a new tab) ingress rule.

2.1Attributes That Define a Boundary

Attributes that define a boundary are the identity, network, and device signals that an access level combines to control who can reach a resource, from where, and from what device. Identity attributes check principals such as user or service accounts, network attributes check IP subnetworks and geographic location, and device attributes check operating system, browser configuration, credential strength, and device posture. Chrome Enterprise Premium (opens in a new tab) supplies the rich device signals that make posture checks possible, and Endpoint Verification, a Chrome extension for Windows, Mac, and ChromeOS, gathers the device attributes that Access Context Manager references during evaluation. If a client device is not managed, it must be treated as unmanaged and untrusted, so the access level can only enforce identity and IP address and cannot enforce device posture because no device signals exist.

The design tradeoff is signal richness versus coverage. Identity and IP address work for any device, including unmanaged devices, but cannot prove device health. Device type, OS, browser posture, certificate-based mutual TLS, and third-party vendor posture require managed devices with Endpoint Verification or Chrome Enterprise Premium. User-centric Chrome Enterprise Premium controls reject user traffic that fails the access level, while resource-centric VPC Service Controls controls define perimeters where resources can communicate and apply to both users and service accounts.

2.2Basic Access Levels

A basic access level is built in Basic mode with structured conditions for network and location, without writing code. A basic access level is the right choice when the security posture depends only on where the request comes from, such as allowing only a corporate public IP range or blocking all other networks. Basic levels are simple to audit and maintain, but they cannot express device health, authentication strength, or vendor zero-trust assessments.

To gate access with a basic IP-based level, the configuration follows an ordered sequence:

1. Create conditions in Basic mode: Start a new access level and select Basic mode as the condition builder.
2. Set title and result: Name the level, for example corp-public-block, and set When condition is met to return TRUE.
3. Select IP Subnetworks: Choose Public IP as the subnetwork type.
4. Enter allowed range: Specify the external IP address range that satisfies the level, so requests from outside that range fail the check.
5. Attach to enforcement: Bind the level through IAM Conditions, access bindings, or VPC Service Controls ingress rules, because the level has no effect until attached.

2.3Custom Access Levels

A custom access level is written as a Common Expression Language (CEL) expression and can combine identity, network, device, browser, and third-party vendor signals in one policy. A custom access level is required when the posture demands device trust, such as requiring encrypted storage, OS version, browser attributes, credential strength, or a non-expired CrowdStrike Falcon zero-trust assessment like timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m"). A CEL expression of true creates an allow-all level, which is used to build exemptions that remove device and location checks for a specific OAuth client without weakening the main policy. Custom levels provide the strongest posture, but they depend on Chrome Enterprise Premium licensing, Endpoint Verification deployment, and correct CEL logic, which increases design and testing cost. Vendor posture from tools such as Microsoft Intune and certificate-based access for user groups (opens in a new tab) are expressed through the same custom CEL model.

Custom access levels that rely on third-party signals require additional planning for data freshness, expiration handling, and licensing, as shown in guidance for custom access levels using Microsoft Intune data (opens in a new tab).

2.4Combining Conditions and Enforcing the Level

Combining conditions inside one access level creates a single boundary that requires all checks to pass together, while assigning multiple separate levels broadens access. When several access levels are assigned to Google Workspace apps or IAP-secured resources, a device needs to satisfy only one of the levels to be granted access. If the intent is to require corporate network plus compliant device plus strong credential at the same time, those checks must live together in one access level that returns true only when all of them pass.

Enforcement connects the access level to the traffic path from client to resource. For IAP TCP-forwarding for SSH network access (opens in a new tab), IAP acts as an intermediary between the client device and the VM and performs authentication of the Google credential, authorization against IAM, optional context-aware verification of the access level, and auditing of success and failure when data access logs are enabled. Two attachment models control scope: access bindings are identity-based policies that apply the same level to every resource a group attempts to reach, including IAP, APIs, and console, while IAM Conditions on the IAP role are resource-based policies that apply different levels to different sets of VMs. For VPC Service Controls, the ingress rule checks both IAM permission and whether the request from outside the perimeter satisfies the referenced access level, while requests from inside the perimeter skip ingress evaluation.

Access Context Manager is the Google Cloud service that defines context-aware access boundaries from user identity, device state, and network context. An access policy is the organization-wide container that holds access levels and VPC Service Controls (opens in a new tab) service perimeters, and enforcement happens when those levels and perimeters are attached to resources through bindings, Identity and Access Management (IAM) conditions, and ingress rules. Operations depend on rich signals from managed devices, continuous audit logging, and dry-run testing to avoid unexpected denials.

3.1Access Policies, Access Levels, and Service Perimeters

An Access Context Manager access policy is the top-level, organization-wide container for access control configuration. The access policy holds access levels, which describe the requirements that must be met for a request to be honored, and service perimeters, which define the protected projects, resources, and restricted application programming interfaces (APIs) that cannot be reached from the public internet except through ingress rules. For example, an access level can restrict requests by IP address, user identity, and device type and operating system, where device-type controls require a Chrome Enterprise Premium (opens in a new tab) (formerly BeyondCorp Enterprise) license. Because the policy sits at the organization scope, the same access levels can be reused across Identity-Aware Proxy (IAP), APIs, the Google Cloud console, and VPC Service Controls perimeters.

3.2Device Signals and Endpoint Verification

Device signals are the managed-device attributes that allow an access level to evaluate device posture. When devices are managed with Chrome Enterprise Premium, administrators can create access levels that check credential strength, browser configuration, and device posture, and then enforce those levels on IAP TCP-forwarding through access bindings or IAM conditions. Endpoint Verification is the Chrome extension for Windows, Mac, and ChromeOS that collects those device attributes, and Access Context Manager references the collected attributes to enforce fine-grained access levels. If the client configuration is not controlled, the device must be treated as unmanaged and untrusted, so access can be managed only by user identity and device IP address and cannot be restricted by device posture.

3.3Applying Access Levels With Access Bindings and IAM Conditions

Applying access levels means attaching a level to an IAM policy, either as an identity-based access binding or as a resource-based IAM condition. An access binding assigns an access level to a group and applies uniformly to every resource that members attempt to access, including IAP, other APIs, and the console. An IAM condition attaches an access level to an individual IAM role binding, such as the IAP-Secured Web App User or IAP TCP-forwarding grant on specific virtual machines (VMs), so different sets of VMs can have different policies. Basic access levels limit access by network or geo-location, such as a public-IP subnetwork condition, while Chrome Enterprise Premium subscribers can also require credential strength, browser posture, or device posture through custom Common Expression Language (CEL) expressions.

3.4Perimeter Enforcement for IAP TCP-Forwarding

Perimeter enforcement for IAP TCP-forwarding controls Secure Shell (SSH) access to VMs without exposing port 22 with an external IP address. Identity-Aware Proxy (IAP) TCP-forwarding acts as an intermediary between the client device and the VM, similar to a bastion host or reverse proxy. For each SSH connection attempt, IAP TCP-forwarding performs authentication by verifying a valid Google credential, authorization by checking IAM permission to connect through IAP, optional context-aware access by verifying that user, device, and location satisfy the required access levels, and auditing by logging successful and failed attempts when data access logs are enabled. When the destination VM is inside a VPC Service Controls perimeter, IAP also enforces the perimeter boundary because API access originating from that VM is considered to originate from inside the perimeter.

Traffic from outside the perimeter must satisfy both IAM and the perimeter ingress rules, while traffic from inside the perimeter must satisfy IAM but bypasses ingress-rule checks. IAP considers a connection to originate from inside a service perimeter when any of the following is true:

• The source IP is the external IP address of a VM that is part of the service perimeter.
• The connection is made through Private Google Access from a VM that is part of the service perimeter.
• The connection is made through a Private Service Connect access endpoint that is part of the service perimeter.

To allow external SSH into a perimeter, administrators create ingress rules that permit IAP ingress for specific identities and sources and can configure those rules to enforce context-aware access. Granting direct external SSH without IAP risks use of unrevoked credentials, abuse of stolen credentials, denial of service from internet flooding, and data exfiltration by copying data between the perimeter VM and an outside workstation. Best practices for SSH network access (opens in a new tab) and certificate-based access for user groups (opens in a new tab) reinforce the same pattern of removing direct internet paths and requiring context checks at the proxy.

3.5Monitoring, Logging, and Troubleshooting Access Denials

Monitoring, logging, and troubleshooting for perimeters and context-aware access depend on audit logging and dry-run validation before enforcement. VPC Service Controls perimeters should first be tested in dry-run mode to observe what would be denied, and Context-Aware Access policies support a dry-run mode that lets service accounts reach resources while logging enforcement events without actually denying access. Cloud Audit Logs carry Context-Aware Access logs, and IAP logs each successful and failed TCP-forwarding connection attempt when data access logs are enabled, so administrators can trace which access level, ingress rule, or IAM grant allowed or blocked a request.

Access denials most often reflect a mismatch between the request context and the configured levels and bindings. A user identity can be restricted indirectly when it belongs to a Google group that has a bound Context-Aware Access policy, which then blocks the call flow even when the direct IAM grant looks correct. Enforcement-mode bindings deny traffic that dry-run mode would only log, and an access level that omits a source IP, device signal, or principal will deny legitimate requests from that source until the level is updated to include it.

Key Facts

• VPC Service Controls service perimeters deny requests originating outside the perimeter unless an access level or ingress rule explicitly allows them, and they do not replace least-privilege IAM inside the perimeter.
• A common unified perimeter provides stronger exfiltration protection with lower overhead than multiple segmented perimeters, which require managing both east-west traffic between perimeters and north-south traffic from the internet.
• A bridge perimeter connects projects in different regular perimeters for controlled sharing without merging their security zones, with cross-perimeter flows requiring a matching egress rule in the source perimeter and ingress rule in the destination perimeter.
• Multiple access levels assigned to the same app combine as logical OR, so conditions that must all pass together have to be combined into a single access level.
• IAP TCP-forwarding connections to VMs inside a VPC Service Controls perimeter must satisfy both IAM and perimeter ingress rules when originating from outside, while connections originating from inside satisfy IAM but bypass ingress-rule checks.