Diagnosing perimeter violations is the process of finding and understanding API calls blocked by a VPC Service Controls perimeter. Managing multi-project architectures involves designing service perimeters that span multiple projects to allow secure data flow between them and hybrid environments.
You diagnose violations by checking Cloud Audit Logs for blocked API calls. Violation logs are written to a specific log name when a request is blocked. You run a BigQuery query to get details like the timestamp, blocked service, API method, protected project, caller identity, and the reason for the block. To find real enforcement blocks, you filter out entries where the dryRun field is true, as those are only from perimeters still in test mode. Reviewing these logs helps you decide if a blocked caller should have access, which tells you whether to update the perimeter's ingress rules or access levels.
Dry-run mode is a testing state that logs potential violations without actually blocking API calls. You should use it before enforcing a perimeter to safely test your design on existing workloads. You analyze dry-run logs with a similar BigQuery query, filtering specifically for entries where dryRun is true. This helps you find unexpected access patterns, like calls from unauthorized IPs or service accounts, before you start blocking traffic. After confirming workloads run without violations in dry-run, you can move projects to a live, enforced perimeter one at a time.
Different violation reasons point to specific misconfigurations. A SERVICE_NOT_ALLOWED_FROM_VPC violation happens when a workload inside the perimeter tries to use a supported Google Cloud service that wasn't added to the perimeter's list of restricted services. To fix this, an administrator must add the missing service to the perimeter's configuration. Violations with a caller IP of private mean the request came from within Google's network, often from a Google service or a VPC outside the perimeter; for authorized Google services, you must add the specific Google service account to an ingress allowlist.
To enable secure access in multi-project and hybrid setups, you configure ingress and egress policies on the service perimeter. Ingress policies control access into the perimeter from outside, like from the internet or on-premises networks. You can base these on identities, IP ranges, or Access Context Manager access levels. Egress policies control traffic from resources inside the perimeter to resources outside, like specific projects or Google APIs. When integrating security services, you create ingress rules that allow the service's specific service agent identity to access all projects within the perimeter.
When connecting multiple perimeters or enabling hybrid access, you choose between using perimeter bridges and granular ingress/egress rules. A perimeter bridge merges two or more perimeters, allowing free communication between all resources within them as if they were one perimeter. This simplifies architecture but reduces control. Alternatively, you can use fine-grained ingress/egress rules to allow specific communication between projects in separate perimeters or from outside. This gives more precise security but increases configuration complexity. Choose bridges when you have high trust between all projects in the bridged set; choose granular rules when you need to limit access to specific services or between specific projects.
Restricted VIP is a virtual IP address range that enables API access to Google Cloud services supported by VPC Service Controls while blocking access to unsupported services. The restricted VIP uses the IPv4 CIDR block 199.36.153.4/30. Routing traffic through this VIP lets VPC Service Controls enforce perimeter protection by ensuring requests come from within the perimeter.
The restricted VIP supports a specific set of Google Cloud services compatible with VPC Service Controls. These include Cloud Composer, Cloud Data Fusion, Dataproc, Container Registry, Cloud Run, Artifact Registry, Cloud Storage, and Cloud DNS, among others. When you configure your VPC to use the restricted VIP, traffic to these services routes through the protected IP addresses, allowing VPC Service Controls to apply its policies. Services not on the supported list cannot be accessed through the restricted VIP and will be blocked when enforcement is active.
Use restricted.googleapis.com when you need to enforce VPC Service Controls perimeter protection and all your required APIs are supported. Use private.googleapis.com (which uses 199.36.153.8/30) when you either don't use VPC Service Controls, or you use them but also need access to Google APIs that are not supported by VPC Service Controls. The private VIP provides access using IP addresses only routable from within Google Cloud but does not enable the perimeter protection features that restrict data exfiltration.
To route API traffic through the restricted VIP, you must configure your VPC network. First, enable Private Google Access on your VPC subnets. Then, configure Cloud DNS to resolve API requests to the restricted VIP addresses instead of the default public endpoints. For on-premises systems connecting via Cloud VPN or Cloud Interconnect, you must also configure routing so traffic destined for Google APIs flows through the restricted VIP range 199.36.153.4/30. This ensures both cloud-based VMs and on-premises systems communicate with Google APIs through the protected path that VPC Service Controls can monitor.
Cloud DNS supports multiple routing policies to direct traffic to the restricted VIP. You can create a private zone that resolves Google API domains to the restricted VIP addresses. For complex scenarios, you can configure DNS forwarding to send queries to on-premises name servers, or use outbound server policies to redirect all DNS traffic to alternative resolvers. Be aware that using an outbound server policy for alternative name servers means VMs can no longer resolve records in Cloud DNS private zones, forwarding zones, peering zones, or Compute Engine internal DNS zones, so you must plan your DNS architecture carefully.
After configuring restricted VIP routing, you must verify that your VPC instances and on-premises systems can successfully communicate with Google APIs through the restricted endpoints. Test connectivity to supported services to ensure they work correctly within the perimeter. Also, verify that any services your workloads depend on are actually supported by VPC Service Controls—if a required service is not supported, you will need to use the private VIP or configure ingress/egress rules to allow access. Organizations using Shared VPC must ensure the host project is included in the service perimeter along with any service projects that belong to the Shared VPC.
VPC Service Controls (VPC SC) establishes a secure boundary around Google Cloud services to prevent data exfiltration. Access Context Manager (ACM) works alongside VPC SC to define contextual access levels based on attributes like client IP ranges and device state. Directional ingress and egress rules selectively permit traffic into or out of a perimeter without exposing the entire protected environment.
Access Context Manager (ACM) defines attribute-based access levels that evaluate if a request meets specific trust conditions before granting access to perimeter resources. Administrators configure basic access levels that evaluate caller identity, allowed public IP subnetworks, and client device configurations. Requests from outside allowed IP ranges or that fail device posture checks are blocked at the perimeter edge, even if the caller has valid Identity and Access Management (IAM) permissions.
Device posture conditions require Chrome Enterprise Premium to evaluate endpoint signals during an active session. Trust conditions can enforce Verified Chrome OS for verified Chromebook hardware, require Cloud Identity administrator approval for new devices, or match operating system serial numbers against corporate-owned inventory. These ensure only trusted endpoints used by authorized organization accounts can reach sensitive APIs.
Managing access levels requires assigning specific IAM roles at the organization level. To avoid unintended privilege escalation, administrators must avoid overlapping access bindings across groups, since multiple bindings evaluate using logical OR conditions. Organizations should also secure enforcement groups in Cloud Identity to prevent users from removing themselves from restrictive policies.
Ingress policies and egress policies define explicit, directional exceptions to VPC Service Controls boundaries. By default, a service perimeter denies all incoming API traffic from outside and blocks all outbound API requests to resources outside. Directional rules let administrators punch granular holes through the perimeter by specifying permitted sources, identities, destinations, and API operations.
An ingress policy controls traffic entering the perimeter. It uses an ingressFrom source block to identify allowed caller identities and sources, which can be defined by specific ACM access levels or external Google Cloud projects. It also uses an ingressTo target block to specify the target projects inside the perimeter and restrict access to particular API services and method selectors.
An egress policy governs traffic leaving the perimeter. It uses an egressFrom origin block to identify the internal identities or service accounts starting the API call. It uses an egressTo destination block to designate the external project resources and allowed external service operations. This enables services like Security Command Center service agents to scan perimeter resources securely without opening outbound access to the rest of the public cloud.
Dry-run mode is a testing state that lets administrators model and validate perimeter configurations without enforcing restrictions on live traffic. When a perimeter is in dry-run mode, VPC Service Controls evaluates API requests against the rules and records potential violations in Cloud Audit Logs while still allowing the requests to succeed. This stage ensures legitimate workloads are not interrupted by policy changes.
To analyze dry-run behavior, teams configure a log sink that exports audit logs from all perimeter projects into BigQuery. Analysts query these logs to find blocked requests, inspecting the caller identity, requested API method, target resource, and the specific violationReason. Finding violations where the dryRun metadata field is populated lets teams craft the needed ingress or egress rules before active enforcement starts.
After log queries confirm no unauthorized violations or application breaks, administrators promote the dry-run configuration to an enforced perimeter. Changes can take up to 30 minutes to propagate. After propagation, any request that fails the enforced perimeter rules is denied with an HTTP 403: Request is prohibited by organization's policy error.
StudyCerts
StudyCertsdryRun field is false to find actual enforcement blocks.199.36.153.4/30) routes traffic for Google Cloud services supported by VPC Service Controls, enabling perimeter protection, while the private VIP is used for services not supported by VPC Service Controls.A perimeter bridge merges two or more perimeters, allowing free communication between all resources within them as if they were a single perimeter, which simplifies architecture but reduces control. Granular ingress/egress rules allow specific communication between projects in separate perimeters or from outside, providing more precise security but increasing configuration complexity.
Use the restricted VIP (restricted.googleapis.com) when you need to enforce VPC Service Controls perimeter protection and all the Google APIs your workloads require are supported by VPC Service Controls. Use the private VIP (private.googleapis.com) when you either do not use VPC Service Controls, or you use them but also need access to Google APIs that are not supported by VPC Service Controls.
Dry-run mode allows you to test your perimeter configuration by logging potential violations without actually blocking any API calls. This lets you identify unexpected access patterns, like calls from unauthorized IPs or service accounts, and adjust your ingress or egress rules before you start enforcing the perimeter and potentially disrupt production workloads.
SERVICE_NOT_ALLOWED_FROM_VPC violation, and how do I fix it?A SERVICE_NOT_ALLOWED_FROM_VPC violation occurs when a workload inside a VPC Service Controls perimeter tries to use a Google Cloud service that is supported by VPC Service Controls but was not added to the perimeter's list of restricted services. To fix it, an administrator must add the missing service (for example, IAM.googleapis.com) to the perimeter's configuration.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills