{"id":789,"date":"2026-04-16T04:08:27","date_gmt":"2026-04-16T04:08:27","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-access-context-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/"},"modified":"2026-04-16T04:08:27","modified_gmt":"2026-04-16T04:08:27","slug":"google-cloud-access-context-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-access-context-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/","title":{"rendered":"Google Cloud Access Context Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Access Context Manager is a Google Cloud Security service for defining <strong>context-based access policies<\/strong> for your organization. It lets you control <em>where requests come from<\/em> and <em>under what conditions<\/em> users and services can access Google Cloud resources\u2014beyond what Identity and Access Management (IAM) can express on its own.<\/p>\n\n\n\n<p>In simple terms: <strong>IAM answers \u201cwho can do what.\u201d Access Context Manager adds \u201cfrom where, and under what conditions.\u201d<\/strong> You define conditions such as source IP ranges, device posture signals (when available), user identity attributes, and then apply those conditions to protect sensitive Google Cloud services.<\/p>\n\n\n\n<p>Technically, Access Context Manager is the policy engine used to create:\n&#8211; <strong>Access levels<\/strong> (for context-aware access decisions)\n&#8211; <strong>Service perimeters<\/strong> and related rules (used by <strong>VPC Service Controls<\/strong>) to reduce data exfiltration risk from Google Cloud managed services (like Cloud Storage and BigQuery) and to enforce stronger security boundaries around projects.<\/p>\n\n\n\n<p>It solves a common problem in cloud security: <strong>perimeter-based controls don\u2019t map cleanly to identity-first cloud access.<\/strong> Access Context Manager helps you implement a modern, conditional, centrally governed access model across your Google Cloud organization\u2014especially for high-value data services.<\/p>\n\n\n\n<blockquote>\n<p>Service status note: <strong>Access Context Manager is an active, current Google Cloud service name<\/strong> and is the official place to configure access levels and VPC Service Controls perimeters. Some capabilities around device signals may depend on your identity\/device management setup; verify exact prerequisites in official docs if you plan to use device-based conditions.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Access Context Manager?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Access Context Manager provides an <strong>organization-level policy framework<\/strong> to define and enforce <strong>context-aware access<\/strong> across Google Cloud. It is commonly used in two major areas:\n1. <strong>Context-aware access<\/strong> (via <em>Access levels<\/em>)\n2. <strong>VPC Service Controls<\/strong> (via <em>Service perimeters<\/em>, ingress\/egress rules, and dry-run modes)<\/p>\n\n\n\n<p>Official docs: https:\/\/cloud.google.com\/access-context-manager\/docs\/overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define <strong>Access Policies<\/strong> at the organization level (the container for context policies)<\/li>\n<li>Create <strong>Access Levels<\/strong> that describe conditions a request must satisfy (for example, IP ranges, identity attributes, and other supported signals)<\/li>\n<li>Create <strong>Service Perimeters<\/strong> (and bridges) to protect Google Cloud services and reduce data exfiltration risk (VPC Service Controls)<\/li>\n<li>Define <strong>Ingress\/Egress rules<\/strong> to carefully allow required access paths while blocking everything else by default<\/li>\n<li>Run <strong>dry-run<\/strong> (test) mode to observe enforcement impact before turning it on<\/li>\n<li>Manage policies through Cloud Console, API, CLI, and Infrastructure as Code tooling (for example, Terraform)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it is<\/th>\n<th>Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Access Policy<\/strong><\/td>\n<td>Top-level container in Access Context Manager<\/td>\n<td>Centralizes rules at the org level; required for access levels\/perimeters<\/td>\n<\/tr>\n<tr>\n<td><strong>Access Level<\/strong><\/td>\n<td>A set of conditions describing \u201ctrusted access\u201d<\/td>\n<td>Reusable building blocks for context-aware access and VPC SC<\/td>\n<\/tr>\n<tr>\n<td><strong>Service Perimeter<\/strong><\/td>\n<td>A boundary around one or more projects and services<\/td>\n<td>Core of VPC Service Controls; reduces data exfiltration<\/td>\n<\/tr>\n<tr>\n<td><strong>Perimeter Bridge<\/strong><\/td>\n<td>A special perimeter to connect multiple perimeters<\/td>\n<td>Enables controlled communication between protected environments<\/td>\n<\/tr>\n<tr>\n<td><strong>Ingress\/Egress Rules<\/strong><\/td>\n<td>Fine-grained allow rules for traffic crossing a perimeter boundary<\/td>\n<td>Avoids overly broad exceptions<\/td>\n<\/tr>\n<tr>\n<td><strong>Dry-run<\/strong><\/td>\n<td>Non-enforcing mode that logs what would be blocked<\/td>\n<td>Safer rollout and change management<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policy\/configuration service<\/strong> used by enforcement points in Google Cloud (for example, VPC Service Controls and context-aware access integrations).<\/li>\n<li>It is not a data plane service that processes your application traffic like a proxy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (org\/global vs project)<\/h3>\n\n\n\n<p>Access Context Manager is primarily <strong>organization-scoped<\/strong>:\n&#8211; Policies, access levels, and service perimeters are typically defined at the <strong>Organization<\/strong> level and can include multiple projects.\n&#8211; You generally need a <strong>Google Cloud Organization<\/strong> (often backed by Cloud Identity or Google Workspace) to use it effectively.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Access Context Manager works alongside:\n&#8211; <strong>IAM<\/strong>: identity and permissions (\u201cwho can do what\u201d)\n&#8211; <strong>VPC Service Controls<\/strong>: service perimeter enforcement to protect Google-managed services\n&#8211; <strong>Cloud Identity \/ Google Workspace<\/strong>: user and device management signals (when applicable)\n&#8211; <strong>Cloud Logging \/ Cloud Audit Logs<\/strong>: observability, troubleshooting, evidence for compliance\n&#8211; <strong>Security Command Center<\/strong>: security posture visibility and findings (integration depends on your setup)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Access Context Manager?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce the likelihood and blast radius of <strong>data exfiltration<\/strong><\/li>\n<li>Enforce consistent access policy across business units using <strong>central governance<\/strong><\/li>\n<li>Support compliance goals by limiting access to sensitive systems to approved contexts (IP ranges, trusted networks, managed devices\u2014depending on what you implement)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add <strong>conditional access<\/strong> controls that complement IAM<\/li>\n<li>Define <strong>service perimeters<\/strong> around projects that host sensitive data (for example, analytics data in BigQuery or regulated objects in Cloud Storage)<\/li>\n<li>Create <strong>reusable access levels<\/strong> and apply them consistently to multiple protected environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Central place to manage context-based access boundaries<\/li>\n<li><strong>Dry-run mode<\/strong> supports safer rollouts and reduces outage risk during enforcement<\/li>\n<li>Auditability through logged violations and access decisions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Helps implement <strong>BeyondCorp-style<\/strong> access patterns (trust based on context rather than network location alone)<\/li>\n<li>Adds layered defense: IAM + context + perimeter controls<\/li>\n<li>Supports separation of environments (prod vs non-prod) with stronger control planes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Policy-driven enforcement scales across many projects without requiring custom proxies for every workload<\/li>\n<li>Reduces complexity compared to per-application conditional checks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You have an Organization and need <strong>organization-wide<\/strong> guardrails<\/li>\n<li>You handle sensitive data in Google-managed services (Cloud Storage, BigQuery, Pub\/Sub, etc.)<\/li>\n<li>You want to reduce risk from stolen credentials or overly broad API access by adding context constraints<\/li>\n<li>You need controlled collaboration between teams\/projects without opening everything to the internet<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only have a single project with no Organization (Access Context Manager is generally org-centric)<\/li>\n<li>Your workload doesn\u2019t use Google-managed APIs where VPC Service Controls applies, and you only need IAM<\/li>\n<li>You\u2019re looking for a network firewall for VM-to-VM traffic (use VPC firewall rules, Cloud Firewall policies, or third-party firewalls instead)<\/li>\n<li>You cannot invest in design\/testing; a poorly planned perimeter can block legitimate workflows<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Access Context Manager used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services (PCI, fraud analytics, sensitive customer data)<\/li>\n<li>Healthcare and life sciences (regulated data, HIPAA-aligned controls)<\/li>\n<li>Public sector (data sovereignty and strict access constraints)<\/li>\n<li>Retail\/e-commerce (customer PII, payment workflows)<\/li>\n<li>SaaS companies (multi-environment hardening and internal access rules)<\/li>\n<li>Education (research data governance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security engineering and cloud security teams<\/li>\n<li>Platform engineering teams operating shared cloud foundations<\/li>\n<li>SRE\/DevOps teams managing production environments<\/li>\n<li>Compliance and governance teams defining policy baselines<\/li>\n<li>Data engineering teams protecting analytics platforms<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data lakes and analytics stacks (Cloud Storage + BigQuery)<\/li>\n<li>Event-driven architectures (Pub\/Sub, Dataflow) where data boundaries matter<\/li>\n<li>Shared services platforms hosting internal APIs<\/li>\n<li>Multi-project landing zones with centralized governance<\/li>\n<li>Hybrid access models (corporate network + remote workforce)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Protecting a regulated \u201cdata project\u201d from accidental exposure<\/li>\n<li>Segmentation between dev\/test\/prod using separate perimeters<\/li>\n<li>Controlled partner or vendor access with context rules and explicit exceptions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: Use dry-run mode and narrow perimeters to learn access patterns.<\/li>\n<li><strong>Production<\/strong>: Use layered controls, explicit ingress\/egress policies, and change management with logging-based validation.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Access Context Manager is a good fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Restrict Cloud Storage access to trusted contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Buckets with sensitive data are accessible from anywhere if credentials leak.<\/li>\n<li><strong>Why it fits:<\/strong> Access levels + VPC Service Controls can enforce additional conditions beyond IAM.<\/li>\n<li><strong>Example:<\/strong> Allow access to <code>gs:\/\/regulated-data<\/code> only from corporate IP ranges and approved workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Reduce BigQuery data exfiltration risk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Analysts can export\/query data from untrusted environments.<\/li>\n<li><strong>Why it fits:<\/strong> A service perimeter can restrict BigQuery API calls and control export paths.<\/li>\n<li><strong>Example:<\/strong> Keep regulated datasets inside a perimeter; allow only specific egress to approved destinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Protect managed services in a \u201csecure analytics project\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Central analytics project becomes a high-value target.<\/li>\n<li><strong>Why it fits:<\/strong> Put the entire project into a service perimeter and restrict services like Storage\/BigQuery\/Pub\/Sub.<\/li>\n<li><strong>Example:<\/strong> A \u201cPII Analytics\u201d project is placed in a perimeter; only a few ingress paths are allowed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Implement a prod perimeter separate from non-prod<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dev tooling and experiments increase risk in non-prod; prod needs stricter boundaries.<\/li>\n<li><strong>Why it fits:<\/strong> Separate service perimeters for <code>prod<\/code> and <code>nonprod<\/code>, plus bridges if required.<\/li>\n<li><strong>Example:<\/strong> CI pipelines can deploy into prod through a controlled egress rule.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Allow a partner to access only a specific API from specific networks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Partner integration needs narrow access without broad exposure.<\/li>\n<li><strong>Why it fits:<\/strong> Ingress rules and access levels can allow limited entry to selected services\/projects.<\/li>\n<li><strong>Example:<\/strong> Vendor can upload files to a single bucket only from a fixed IP range.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Control SaaS admin access with context-aware rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Privileged admin access is risky if done from unmanaged endpoints.<\/li>\n<li><strong>Why it fits:<\/strong> Context-aware access (via access levels) can be applied to supported entry points.<\/li>\n<li><strong>Example:<\/strong> Require admins to come from a managed device and corporate IP (verify device-signal support in your setup).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Enforce \u201cno public internet access\u201d for sensitive APIs (logical boundary)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to ensure sensitive data APIs aren\u2019t usable from arbitrary locations.<\/li>\n<li><strong>Why it fits:<\/strong> Perimeter + access levels can block requests that don\u2019t satisfy required context.<\/li>\n<li><strong>Example:<\/strong> Only allow API calls that meet approved context; log and block everything else.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Prevent accidental data movement to consumer accounts\/projects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Developers copy data to personal projects for debugging.<\/li>\n<li><strong>Why it fits:<\/strong> VPC Service Controls can block certain cross-boundary accesses.<\/li>\n<li><strong>Example:<\/strong> Block <code>gsutil cp<\/code> from protected buckets to non-perimeter destinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Govern access for shared internal tooling (central platform team)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Shared tooling needs access to many projects but must remain controlled.<\/li>\n<li><strong>Why it fits:<\/strong> Use perimeters and explicit egress rules for platform services.<\/li>\n<li><strong>Example:<\/strong> A central \u201cBuild\/Deploy\u201d project has egress rules to deploy to production perimeters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Meet compliance requirements for \u201caccess from approved locations only\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Compliance mandates restricting access to approved networks.<\/li>\n<li><strong>Why it fits:<\/strong> Access levels can incorporate network-based context.<\/li>\n<li><strong>Example:<\/strong> Enforce access from office\/VPN IP ranges for sensitive services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Safer policy rollouts using dry-run logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Turning on controls can break pipelines and apps unexpectedly.<\/li>\n<li><strong>Why it fits:<\/strong> Dry-run mode provides evidence before enforcement.<\/li>\n<li><strong>Example:<\/strong> Run a perimeter in dry-run for two weeks, fix violations, then enforce.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Centralize policy across multiple folders\/business units<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Each team implements its own inconsistent controls.<\/li>\n<li><strong>Why it fits:<\/strong> Org-level policies can standardize patterns while still allowing exceptions.<\/li>\n<li><strong>Example:<\/strong> A shared \u201cregulated-data\u201d baseline perimeter pattern is applied across business units.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Access Policies (org-level container)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides the top-level container for access levels and service perimeters.<\/li>\n<li><strong>Why it matters:<\/strong> Establishes centralized governance across many projects.<\/li>\n<li><strong>Practical benefit:<\/strong> One place to manage security boundaries for the organization.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Generally requires an Organization; project-only usage is limited.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Access Levels (basic and custom)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines conditions that a request must meet to be considered \u201ctrusted.\u201d<\/li>\n<li><strong>Why it matters:<\/strong> Enables context-aware decisions beyond IAM.<\/li>\n<li><strong>Practical benefit:<\/strong> Reuse the same access level across multiple perimeters and integrations.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> The available signals depend on what Google Cloud supports and what your identity\/device setup provides. Verify supported conditions in official docs.<\/li>\n<\/ul>\n\n\n\n<p>Docs: https:\/\/cloud.google.com\/access-context-manager\/docs\/create-access-level<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Custom access levels using CEL (Common Expression Language)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you define more flexible logic than basic lists using CEL.<\/li>\n<li><strong>Why it matters:<\/strong> Real-world conditions often require boolean logic (AND\/OR\/NOT).<\/li>\n<li><strong>Practical benefit:<\/strong> Fine-grained policies like \u201c(corp IP OR managed device) AND user in group.\u201d<\/li>\n<li><strong>Limitations\/caveats:<\/strong> CEL expressions must be tested carefully; mistakes can block access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Service Perimeters (VPC Service Controls)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines a security boundary around Google Cloud projects and supported services to reduce data exfiltration.<\/li>\n<li><strong>Why it matters:<\/strong> Limits risk even if credentials are compromised, by enforcing boundary rules at Google-managed service front-ends.<\/li>\n<li><strong>Practical benefit:<\/strong> Strong protection for data services without building custom proxies.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Only supported services can be restricted; some workflows require explicit ingress\/egress exceptions.<\/li>\n<\/ul>\n\n\n\n<p>Docs: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Perimeter Bridges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Connects multiple service perimeters so they can communicate in a controlled way.<\/li>\n<li><strong>Why it matters:<\/strong> Enterprises often segment environments but still need specific cross-perimeter flows.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables shared services patterns without collapsing segmentation.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Bridges must be designed carefully to avoid creating overly permissive paths.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Ingress and Egress rules (fine-grained exceptions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows explicit access <em>into<\/em> protected projects (ingress) and <em>out of<\/em> them (egress) under defined constraints.<\/li>\n<li><strong>Why it matters:<\/strong> Real environments need exceptions for CI\/CD, monitoring, shared services, and partner integrations.<\/li>\n<li><strong>Practical benefit:<\/strong> Replace broad \u201callow everything\u201d exceptions with least-privilege rules.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Incorrect rules can either break workloads or weaken security. Test with dry-run.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Dry-run mode (safe testing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Logs violations that <em>would<\/em> occur under enforcement, without blocking (depending on how you configure it).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents outages during rollout.<\/li>\n<li><strong>Practical benefit:<\/strong> You can inventory required exceptions before turning on enforcement.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Dry-run results must be analyzed; \u201cno violations\u201d doesn\u2019t automatically mean \u201csafe,\u201d because not all workflows may have been exercised.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Central management via Console, API, and automation tooling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Manage policies through UI and programmatic interfaces.<\/li>\n<li><strong>Why it matters:<\/strong> Enterprise environments require versioning, review, and repeatability.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate with change management, CI\/CD, and Terraform workflows.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> API\/CLI syntax evolves; always validate against current official docs.<\/li>\n<\/ul>\n\n\n\n<p>Docs: https:\/\/cloud.google.com\/access-context-manager\/docs\/reference\/rest<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Logging and auditing of policy enforcement<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Violations and enforcement outcomes appear in Cloud Logging (Audit Logs metadata for VPC Service Controls).<\/li>\n<li><strong>Why it matters:<\/strong> Security controls must be observable and auditable.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster troubleshooting and compliance evidence.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Logging volume can increase; plan retention and cost.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Access Context Manager stores policy definitions. Enforcement happens in:\n&#8211; Google-managed service front-ends (for VPC Service Controls restricted services)\n&#8211; Integrated access points for context-aware access (depending on the product integration)<\/p>\n\n\n\n<p>A typical protected request flow:\n1. A user\/service authenticates (IAM identity).\n2. The request reaches a Google Cloud API (for example, Storage API).\n3. The enforcement layer evaluates:\n   &#8211; IAM permissions\n   &#8211; Service perimeter boundary rules (if the target project\/service is in a perimeter)\n   &#8211; Access levels and ingress\/egress policies (if configured)\n4. The request is allowed or denied, and relevant audit metadata is logged.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC Service Controls<\/strong>: primary consumer of service perimeters.<\/li>\n<li><strong>Cloud Logging \/ Cloud Audit Logs<\/strong>: captures violations and relevant metadata.<\/li>\n<li><strong>IAM<\/strong>: still required\u2014Access Context Manager doesn\u2019t replace IAM.<\/li>\n<li><strong>Organization \/ Folders \/ Projects<\/strong>: perimeters include project resources; governance is org-level.<\/li>\n<li><strong>Cloud Identity \/ Google Workspace<\/strong>: may provide identity and device posture signals (verify exact requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Access Context Manager API<\/strong> (to manage policies)<\/li>\n<li>Target restricted services (for example, <code>storage.googleapis.com<\/code>, <code>bigquery.googleapis.com<\/code>) if you use perimeters<\/li>\n<li>Cloud Logging for analysis and auditing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Administrators manage Access Context Manager via IAM roles on the Organization\/access policy.<\/li>\n<li>Users\/workloads must still be authorized via IAM to access resources.<\/li>\n<li>VPC Service Controls adds an additional gate based on perimeter and policy conditions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (important nuance)<\/h3>\n\n\n\n<p>VPC Service Controls is not a traditional network firewall. It works at the <strong>Google API\/service front-end<\/strong> layer:\n&#8211; It helps prevent data access\/exfiltration through Google Cloud APIs even if access is attempted from outside a trusted boundary.\n&#8211; It does not directly control VM-to-VM traffic in your VPC (use VPC firewall rules for that).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor Cloud Logging for VPC Service Controls violations.<\/li>\n<li>Use dry-run mode to baseline legitimate access patterns.<\/li>\n<li>Apply org policy and tagging\/labeling practices so teams know which projects are \u201cinside perimeters.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Workload Identity] --&gt;|Auth (IAM)| API[Google Cloud API&lt;br\/&gt;(e.g., Cloud Storage)]\n  API --&gt;|Context + Perimeter check| ACM[Access Context Manager&lt;br\/&gt;Access Levels + Perimeters]\n  ACM --&gt;|Allow \/ Deny decision| API\n  API --&gt;|Audit metadata| LOG[Cloud Logging]\n  API --&gt; R[Protected Resource&lt;br\/&gt;(Project in Service Perimeter)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    ACM[Access Context Manager&lt;br\/&gt;Access Policy]\n    AL[Access Levels&lt;br\/&gt;(IP \/ identity \/ custom CEL)]\n    SP1[Service Perimeter: prod-data]\n    SP2[Service Perimeter: nonprod]\n    BR[Perimeter Bridge (optional)]\n    ACM --&gt; AL\n    ACM --&gt; SP1\n    ACM --&gt; SP2\n    SP1 --- BR\n    SP2 --- BR\n  end\n\n  subgraph Prod[Prod Folder \/ Projects]\n    P1[Project: prod-analytics&lt;br\/&gt;BigQuery + Cloud Storage]\n    P2[Project: prod-app&lt;br\/&gt;Pub\/Sub + Storage]\n  end\n\n  subgraph NonProd[Non-Prod Folder \/ Projects]\n    D1[Project: dev&lt;br\/&gt;Test datasets]\n  end\n\n  subgraph Shared[Shared Services]\n    CI[CI\/CD Project]\n    MON[Monitoring\/Logging Project]\n  end\n\n  EXT[External users \/ internet] --&gt;|API request| GAPI[Google APIs Front Ends]\n  CI --&gt;|deploy\/read artifacts| GAPI\n  MON --&gt;|read logs\/metrics| GAPI\n\n  GAPI --&gt;|Enforcement via VPC Service Controls| SP1\n  SP1 --&gt; P1\n  SP1 --&gt; P2\n  SP2 --&gt; D1\n\n  GAPI --&gt; LOGS[Cloud Logging&lt;br\/&gt;Audit Logs + VPC SC metadata]\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/organization requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud Organization<\/strong> is strongly recommended and commonly required for real Access Context Manager usage.<\/li>\n<li>Ability to manage organization-level policies (often requires Cloud Identity \/ Google Workspace-backed org).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; View and manage Access Context Manager policies and access levels\n&#8211; Create and manage VPC Service Controls service perimeters\n&#8211; Manage IAM on the test project (to grant yourself access to a bucket, for example)<\/p>\n\n\n\n<p>Official IAM roles doc (verify exact role IDs and least-privilege mapping):<br\/>\nhttps:\/\/cloud.google.com\/access-context-manager\/docs\/iam<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access Context Manager policy configuration is typically not billed as a standalone meter, but the lab uses other services (Cloud Storage, Logging).<\/li>\n<li>Ensure <strong>billing is enabled<\/strong> on your test project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Console access<\/li>\n<li>Optional: <code>gcloud<\/code> CLI for inspection and validation<\/li>\n<li>Optional: <code>gsutil<\/code> (usually installed with the Google Cloud SDK)<\/li>\n<\/ul>\n\n\n\n<p>Install\/verify <code>gcloud<\/code>: https:\/\/cloud.google.com\/sdk\/docs\/install<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access Context Manager is an organization-level control plane service (not region-specific in the way compute resources are).<\/li>\n<li>Your protected resources (buckets, datasets, etc.) are regional\/multi-regional based on their own configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>There are limits on numbers of access levels, perimeters, and complexity. <strong>Verify current limits in official docs<\/strong> because they can change:<\/li>\n<li>https:\/\/cloud.google.com\/access-context-manager\/quotas (verify URL in official docs if it differs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the hands-on tutorial:\n&#8211; Cloud Storage API enabled on a test project\n&#8211; Access Context Manager API enabled (to manage policies programmatically; Console may still work without explicit enablement depending on your org setup, but enabling is a good practice)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (accurate framing)<\/h3>\n\n\n\n<p>Access Context Manager is primarily a <strong>policy definition<\/strong> service. Google Cloud generally does not position it like a standalone consumption-billed product (for example, \u201c$X per rule evaluated\u201d). Instead:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\n<p><strong>Direct charges:<\/strong> Often <strong>no separate line-item usage charge<\/strong> for Access Context Manager configuration itself.<br\/>\n<strong>Verify in official docs\/pricing<\/strong>, because licensing and integrations can evolve.<\/p>\n<\/li>\n<li>\n<p><strong>Related\/indirect costs<\/strong> come from:<\/p>\n<\/li>\n<li><strong>Protected services<\/strong> you use (Cloud Storage, BigQuery, Pub\/Sub, etc.)<\/li>\n<li><strong>Cloud Logging<\/strong> (log ingestion\/retention\/queries can incur cost depending on your tier and usage)<\/li>\n<li><strong>Network egress<\/strong> and inter-region transfer (depending on your workload design)<\/li>\n<li><strong>Identity\/device management licensing<\/strong> if you use advanced context signals (this may involve Cloud Identity \/ BeyondCorp \/ Workspace licensing; verify based on your environment)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Official sources to check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access Context Manager documentation hub (pricing notes may appear in related sections):<br\/>\n  https:\/\/cloud.google.com\/access-context-manager\/docs\/overview<\/li>\n<li>VPC Service Controls overview and docs:<br\/>\n  https:\/\/cloud.google.com\/vpc-service-controls\/docs\/overview<\/li>\n<li>Google Cloud Pricing Calculator (estimate the services you\u2019re protecting\/using):<br\/>\n  https:\/\/cloud.google.com\/products\/calculator<\/li>\n<li>BeyondCorp Enterprise pricing (if you use BeyondCorp enterprise features around context-aware access\/device signals):<br\/>\n  https:\/\/cloud.google.com\/beyondcorp-enterprise\/pricing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to consider<\/h3>\n\n\n\n<p>Even if Access Context Manager itself is not directly billed, your design affects costs through:\n&#8211; <strong>Log volume<\/strong>: more violations and audit metadata \u2192 higher logging ingestion and storage\n&#8211; <strong>Project segmentation<\/strong>: more projects can mean more operational overhead and possibly more logs\n&#8211; <strong>Data access patterns<\/strong>: restrictions can cause retries\/failures that increase API calls and logs\n&#8211; <strong>Network design<\/strong>: if you redesign data flows to stay within boundaries, you might reduce egress costs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Any \u201cfree tier\u201d concept usually applies to underlying services (Cloud Storage free usage tiers in limited cases, logging allowances, etc.), not Access Context Manager itself.<\/li>\n<li>Always validate free tier details for each dependent service in official pricing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Logging retention and exports (especially if exporting to BigQuery)<\/li>\n<li>Increased troubleshooting time during rollout (engineering time is a real cost)<\/li>\n<li>Potential need for separate projects\/environments for proper segmentation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operational overhead<\/strong>: policy design, change reviews, exception management<\/li>\n<li><strong>Break-glass testing<\/strong> and incident response exercises<\/li>\n<li><strong>CI\/CD adjustments<\/strong>: pipelines may need updates to run within allowed contexts<\/li>\n<li><strong>Partner integrations<\/strong>: may require managed egress solutions or re-architecture<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>dry-run<\/strong> first to avoid outages and reduce repeated trial-and-error<\/li>\n<li>Keep perimeters <strong>as small as practical<\/strong> (start with the most sensitive project)<\/li>\n<li>Reduce noisy logs by fixing systemic violations rather than accepting broad exceptions<\/li>\n<li>Set appropriate log retention and consider log sinks strategically<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A starter lab typically includes:\n&#8211; 1 test project\n&#8211; 1 Cloud Storage bucket with a few objects\n&#8211; Audit logs and VPC SC metadata logs for a limited time<\/p>\n\n\n\n<p>Costs are dominated by:\n&#8211; Cloud Storage (minimal)\n&#8211; Cloud Logging (depends on ingestion and retention)<\/p>\n\n\n\n<p>No exact number is provided here because logging and storage pricing can vary by region and usage. Use the calculator and check your current logging allocation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations (conceptual)<\/h3>\n\n\n\n<p>In production, plan for:\n&#8211; Multiple protected services (Storage, BigQuery, Pub\/Sub)\n&#8211; Increased log volume (violations, audits, investigations)\n&#8211; Potential BigQuery costs if exporting logs to BigQuery\n&#8211; Engineering time for ongoing exceptions and policy evolution<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a <strong>VPC Service Controls service perimeter<\/strong> using Access Context Manager to protect a project containing a Cloud Storage bucket, validate behavior in <strong>dry-run<\/strong>, then <strong>enforce<\/strong> the perimeter and observe access being blocked when requests do not meet the policy\u2014followed by safe cleanup.<\/p>\n\n\n\n<p>This lab is intentionally designed to be:\n&#8211; Beginner-friendly (uses Cloud Console for policy creation)\n&#8211; Low-cost (small Cloud Storage usage)\n&#8211; Safe (starts with dry-run and includes cleanup)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare a test project and bucket\n2. Identify (or create) an Access Context Manager access policy\n3. Create a service perimeter around the test project\n4. Start in dry-run and generate a \u201cwould be denied\u201d event\n5. Enforce the perimeter and observe a real deny\n6. Use Cloud Logging to verify violations\n7. Clean up by removing the project from the perimeter or deleting the perimeter<\/p>\n\n\n\n<blockquote>\n<p>Important: VPC Service Controls can block legitimate access. Do this only in a <strong>non-production<\/strong> project.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Prepare your test project and Cloud Storage bucket<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">1.1 Select or create a project<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In Cloud Console, select an existing <strong>test<\/strong> project, or create a new project such as <code>acm-vpcsc-lab<\/code>.<\/li>\n<\/ul>\n\n\n\n<p>Expected outcome:\n&#8211; You have a project you can safely lock down temporarily.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">1.2 Enable required APIs<\/h4>\n\n\n\n<p>In Cloud Console:\n&#8211; Go to <strong>APIs &amp; Services \u2192 Enabled APIs &amp; services<\/strong>\n&#8211; Enable:\n  &#8211; <strong>Cloud Storage API<\/strong>\n  &#8211; <strong>Access Context Manager API<\/strong> (recommended)<\/p>\n\n\n\n<p>Optional CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable storage.googleapis.com accesscontextmanager.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; APIs are enabled without errors.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">1.3 Create a test bucket<\/h4>\n\n\n\n<p>In Cloud Console:\n&#8211; Go to <strong>Cloud Storage \u2192 Buckets \u2192 Create<\/strong>\n&#8211; Name it globally unique, for example: <code>acm-vpcsc-lab-&lt;unique-suffix&gt;<\/code>\n&#8211; Choose a location (any is fine for the lab)\n&#8211; Keep defaults unless your org policies require something else<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; Bucket exists.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">1.4 Upload a test object<\/h4>\n\n\n\n<p>Upload a small text file.<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; You can see an object in the bucket.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">1.5 Confirm you currently have access<\/h4>\n\n\n\n<p>From Cloud Shell (or your workstation), try listing the bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls gs:\/\/acm-vpcsc-lab-&lt;unique-suffix&gt;\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Command succeeds and lists objects (or returns empty list if none).<\/p>\n\n\n\n<p>If it fails with IAM permission errors:\n&#8211; Ensure your user has appropriate permissions (for example, Storage Object Viewer on the bucket\/project).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Identify your Organization and Access Policy<\/h3>\n\n\n\n<p>Access Context Manager policies live at the Organization level.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2.1 Find your Organization ID<\/h4>\n\n\n\n<p>In Cloud Console:\n&#8211; Go to <strong>IAM &amp; Admin \u2192 Manage Resources<\/strong>\n&#8211; Note the <strong>Organization ID<\/strong> (for example, <code>123456789012<\/code>)<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; You know your Organization ID.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2.2 Check for an existing Access Policy<\/h4>\n\n\n\n<p>In Cloud Console:\n&#8211; Search for <strong>Access Context Manager<\/strong>.\n&#8211; Open it and check if an <strong>Access Policy<\/strong> already exists.<\/p>\n\n\n\n<p>If you prefer CLI for listing (optional; requires permissions):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud access-context-manager policies list --organization=ORGANIZATION_ID\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; You see an access policy (many orgs have exactly one).<\/p>\n\n\n\n<p>If you do not have an access policy:\n&#8211; Create one in the Access Context Manager UI (if allowed in your org).\n&#8211; If you can\u2019t create it, you likely need additional organization-level permissions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a service perimeter (start with dry-run)<\/h3>\n\n\n\n<p>This is where Access Context Manager configures a VPC Service Controls perimeter around your test project.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3.1 Gather the project number<\/h4>\n\n\n\n<p>VPC Service Controls typically references projects by <strong>project number<\/strong>.<\/p>\n\n\n\n<p>In Cloud Console:\n&#8211; Go to <strong>IAM &amp; Admin \u2192 Settings<\/strong> (or project dashboard)\n&#8211; Copy the <strong>Project number<\/strong><\/p>\n\n\n\n<p>Optional CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects describe YOUR_PROJECT_ID --format=\"value(projectNumber)\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; You have the project number.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3.2 Create the perimeter in Access Context Manager<\/h4>\n\n\n\n<p>In Cloud Console:\n1. Go to <strong>Security \u2192 Access Context Manager<\/strong>\n2. Select your <strong>Access Policy<\/strong>\n3. Go to <strong>Service perimeters<\/strong>\n4. Click <strong>Create perimeter<\/strong>\n5. Name: <code>acm-vpcsc-lab-perimeter<\/code>\n6. Perimeter type: <strong>Regular<\/strong>\n7. Add <strong>Resources<\/strong>:\n   &#8211; Add your project using the project number (the UI will guide you)\n8. Add <strong>Restricted services<\/strong>:\n   &#8211; Add <strong>Cloud Storage<\/strong> (<code>storage.googleapis.com<\/code>)<\/p>\n\n\n\n<p>Now choose a safe rollout approach:\n&#8211; Configure <strong>Dry-run<\/strong> \/ <strong>Test<\/strong> mode if the UI provides it as a distinct option.\n&#8211; If the UI represents dry-run as a separate spec, enable it accordingly.<\/p>\n\n\n\n<p>Because the exact UI wording can change, use the current official guidance for dry-run configuration:\n&#8211; VPC Service Controls dry-run concepts: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/dry-run<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; Perimeter is created successfully and includes your test project and Cloud Storage as a restricted service.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Generate and observe dry-run violations<\/h3>\n\n\n\n<p>Dry-run is intended to show you what enforcement <em>would<\/em> block.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.1 Attempt an access that would be restricted under enforcement<\/h4>\n\n\n\n<p>From Cloud Shell (or your workstation), try:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls gs:\/\/acm-vpcsc-lab-&lt;unique-suffix&gt;\n<\/code><\/pre>\n\n\n\n<p>Expected outcome in dry-run:\n&#8211; The command should still succeed (because it\u2019s dry-run), but a violation log entry should be generated indicating the request would be denied under enforcement.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.2 Find VPC Service Controls violation logs<\/h4>\n\n\n\n<p>In Cloud Console:\n&#8211; Go to <strong>Logging \u2192 Logs Explorer<\/strong>\n&#8211; Select the project that receives relevant logs (often the same project, but audit logs can be centralized\u2014use your org\u2019s logging setup)<\/p>\n\n\n\n<p>Use a query pattern for VPC SC audit metadata. One common approach is to search for the VPC Service Controls audit metadata type:<\/p>\n\n\n\n<pre><code class=\"language-text\">protoPayload.metadata.@type=\"type.googleapis.com\/google.cloud.audit.VpcServiceControlAuditMetadata\"\n<\/code><\/pre>\n\n\n\n<p>You can also narrow by service:<\/p>\n\n\n\n<pre><code class=\"language-text\">protoPayload.serviceName=\"storage.googleapis.com\"\nprotoPayload.metadata.@type=\"type.googleapis.com\/google.cloud.audit.VpcServiceControlAuditMetadata\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; You find log entries that indicate a VPC Service Controls check and the dry-run outcome.<\/p>\n\n\n\n<p>If you cannot find logs:\n&#8211; Confirm Audit Logs are enabled\/retained for the project.\n&#8211; Confirm you\u2019re looking in the correct logging scope (project vs aggregated sink).\n&#8211; Wait a few minutes; logs can be delayed slightly.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Enforce the perimeter and confirm access is blocked<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">5.1 Switch from dry-run to enforced mode<\/h4>\n\n\n\n<p>In Access Context Manager:\n&#8211; Edit the perimeter and enable <strong>enforcement<\/strong> (turn on the enforced status).<\/p>\n\n\n\n<p>Follow official guidance for enabling enforcement:\n&#8211; https:\/\/cloud.google.com\/vpc-service-controls\/docs\/enable-service-perimeters<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; Perimeter is enforced.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.2 Attempt bucket access again<\/h4>\n\n\n\n<p>Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls gs:\/\/acm-vpcsc-lab-&lt;unique-suffix&gt;\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; The request is denied with an error indicating a VPC Service Controls violation (commonly a 403 with a message referencing VPC Service Controls).<\/p>\n\n\n\n<p>The exact error text can vary, but you should see:\n&#8211; Permission denied \/ request prohibited by organization policy \/ VPC Service Controls<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.3 Confirm enforced violations in Cloud Logging<\/h4>\n\n\n\n<p>Return to Logs Explorer and re-run the query:<\/p>\n\n\n\n<pre><code class=\"language-text\">protoPayload.metadata.@type=\"type.googleapis.com\/google.cloud.audit.VpcServiceControlAuditMetadata\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; New entries show <strong>enforced<\/strong> denials (not just dry-run).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: (Optional) Add an access level exception path (advanced concept)<\/h3>\n\n\n\n<p>In real deployments, you usually add <strong>Access Levels<\/strong> and\/or <strong>Ingress rules<\/strong> so legitimate users and automation can access protected services.<\/p>\n\n\n\n<p>Rather than providing a brittle one-size-fits-all exception here, use these official guides to design a proper exception:\n&#8211; Access levels: https:\/\/cloud.google.com\/access-context-manager\/docs\/create-access-level\n&#8211; Ingress\/egress rules: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/ingress-egress-rules<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; You understand that perimeters are not \u201cset and forget\u201d; you must explicitly allow legitimate entry\/exit paths.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully completed the lab if:\n1. The project is included in a service perimeter.\n2. Cloud Storage is listed as a restricted service.\n3. In dry-run, access attempts produce violation metadata logs.\n4. In enforced mode, <code>gsutil ls<\/code> (or similar Cloud Storage API calls) are blocked and produce enforced violation logs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: \u201cI don\u2019t see Access Context Manager in the console\u201d \/ can\u2019t create policies<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You may not have an Organization, or you lack organization-level permissions.<\/li>\n<li>Confirm your org exists under <strong>IAM &amp; Admin \u2192 Manage Resources<\/strong>.<\/li>\n<li>Verify roles in: https:\/\/cloud.google.com\/access-context-manager\/docs\/iam<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: \u201cPerimeter blocks everything, including my admin access\u201d<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>That\u2019s expected if you didn\u2019t create ingress rules or access levels for your admin workflows.<\/li>\n<li>Use break-glass procedures approved by your organization.<\/li>\n<li>For the lab: proceed to cleanup by removing the project from the perimeter (see Cleanup).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: No logs appear<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Check you are using the correct Logs Explorer scope.<\/li>\n<li>Confirm audit logs are enabled and not excluded by sinks\/exclusions.<\/li>\n<li>Wait several minutes and retry the operation to generate new events.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Errors differ from expected examples<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Error text varies between clients and APIs.<\/li>\n<li>Focus on the presence of VPC Service Controls metadata in Cloud Logging and consistent 403\/denied behavior under enforcement.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid leaving your test project inaccessible:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In <strong>Access Context Manager \u2192 Service perimeters<\/strong>, edit <code>acm-vpcsc-lab-perimeter<\/code>.<\/li>\n<li>Either:\n   &#8211; Remove the test project from the perimeter resources, <strong>or<\/strong>\n   &#8211; Delete the perimeter entirely (best for a lab)<\/li>\n<\/ol>\n\n\n\n<p>Then validate:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls gs:\/\/acm-vpcsc-lab-&lt;unique-suffix&gt;\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Access works again (subject to IAM).<\/p>\n\n\n\n<p>Finally:\n&#8211; Optionally delete the test bucket and objects to avoid ongoing storage cost.\n&#8211; Optionally delete the test project if it was created solely for this lab.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with a <strong>small, high-value target<\/strong> project (for example, a data project) before scaling to many projects.<\/li>\n<li>Design perimeters around <strong>data domains<\/strong> (PII, PCI, clinical) rather than around org charts.<\/li>\n<li>Use separate perimeters for <strong>prod vs non-prod<\/strong>; bridge only what you must.<\/li>\n<li>Prefer <strong>explicit ingress\/egress rules<\/strong> over broad exceptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Access Context Manager as a second layer\u2014not a replacement for IAM.<\/li>\n<li>Use least privilege for policy admins; restrict who can modify perimeters.<\/li>\n<li>Separate duties:<\/li>\n<li>Platform\/security team manages perimeters and baseline policies<\/li>\n<li>Application teams manage IAM within allowed boundaries (as appropriate)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Control log volume:<\/li>\n<li>Use dry-run for testing, but don\u2019t leave noisy dry-run configurations indefinitely.<\/li>\n<li>Set appropriate retention and consider log sinks carefully.<\/li>\n<li>Avoid re-architectures that increase network egress unless required; use the pricing calculator to model tradeoffs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expect some overhead in troubleshooting and rollout, not runtime latency \u201cperformance.\u201d<\/li>\n<li>Keep policies understandable; reduce unnecessary complexity that slows incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use dry-run and phased rollouts to prevent production outages.<\/li>\n<li>Keep a documented <strong>break-glass<\/strong> procedure for perimeter misconfiguration.<\/li>\n<li>Maintain tested \u201cknown-good\u201d policy definitions in version control (IaC) where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor for violations and trends:<\/li>\n<li>sudden spikes may indicate misconfiguration or malicious attempts<\/li>\n<li>Keep an inventory:<\/li>\n<li>which projects are inside which perimeter<\/li>\n<li>which services are restricted<\/li>\n<li>which exceptions exist and why<\/li>\n<li>Establish change management:<\/li>\n<li>peer review for perimeter changes<\/li>\n<li>maintenance windows for enforcement flips<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name perimeters consistently (examples: <code>sp-prod-pii<\/code>, <code>sp-nonprod<\/code>, <code>sp-shared-services<\/code>)<\/li>\n<li>Use labels\/tags at the project level to identify regulated environments<\/li>\n<li>Document exception rationale (ticket IDs, risk acceptance)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM decides whether an identity <em>can<\/em> call an API.<\/li>\n<li>Access Context Manager (via VPC Service Controls and access levels) decides whether the request context is acceptable.<\/li>\n<\/ul>\n\n\n\n<p>Key point: <strong>You need both<\/strong>.\n&#8211; If IAM is too broad, Access Context Manager can reduce risk by restricting context.\n&#8211; If IAM is too tight, Access Context Manager won\u2019t grant access by itself.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access Context Manager doesn\u2019t encrypt data; underlying services handle encryption at rest and in transit.<\/li>\n<li>Ensure you configure encryption and key management in the services you protect (for example, CMEK with Cloud KMS where required).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC Service Controls is not a replacement for:<\/li>\n<li>VPC firewall rules<\/li>\n<li>Private Service Connect<\/li>\n<li>Cloud NAT\/egress controls<\/li>\n<li>Cloud Armor (for internet-facing HTTP(S))<\/li>\n<li>Use it as part of a layered security posture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding credentials in scripts for perimeter testing.<\/li>\n<li>Use short-lived credentials and standard auth (gcloud auth, Workload Identity).<\/li>\n<li>Consider Secret Manager for application secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Audit Logs and Logs Explorer to investigate denied requests.<\/li>\n<li>Consider centralizing logs in a dedicated security project with appropriate retention.<\/li>\n<li>Treat violation logs as potential security signals (misuse or attempted exfiltration).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access Context Manager can support compliance objectives by restricting access contexts and by providing audit evidence.<\/li>\n<li>Compliance requires process and documentation\u2014include:<\/li>\n<li>policy intent<\/li>\n<li>change approvals<\/li>\n<li>exception justification<\/li>\n<li>monitoring and incident response procedures<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforcing perimeters without dry-run and without exception rules (causing outages)<\/li>\n<li>Creating overly broad ingress\/egress exceptions (\u201callow all\u201d) that undermine the control<\/li>\n<li>Not restricting who can edit perimeters<\/li>\n<li>Forgetting to monitor logs and assuming \u201cenabled\u201d means \u201ceffective\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use dry-run \u2192 analyze violations \u2192 implement least-privilege rules \u2192 enforce<\/li>\n<li>Keep policies in version control and deploy via CI\/CD when possible<\/li>\n<li>Use separate perimeters for distinct trust zones and data classifications<\/li>\n<li>Regularly review exceptions and remove those no longer required<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Organization-centric<\/strong>: Many Access Context Manager capabilities require org-level setup.<\/li>\n<li><strong>Supported services only<\/strong>: VPC Service Controls applies to a defined set of Google services. Always verify the current supported services list in official docs.<\/li>\n<li><strong>Rollout risk<\/strong>: Enforcement can block admins, CI\/CD pipelines, third-party tools, and even routine operations if exceptions aren\u2019t planned.<\/li>\n<li><strong>Complex exception management<\/strong>: Ingress\/egress rules require careful design and testing.<\/li>\n<li><strong>Logging noise<\/strong>: Dry-run and enforcement can increase log volume.<\/li>\n<li><strong>Confusing \u201cperimeter\u201d expectations<\/strong>: It\u2019s not a network perimeter in the traditional sense; it\u2019s API-based enforcement at Google service boundaries.<\/li>\n<li><strong>Cross-project workflows<\/strong>: Data movement patterns (exports, transfers, cross-project reads) can break unless designed for perimeters.<\/li>\n<li><strong>Third-party integrations<\/strong>: Vendor tools that call Google APIs may be blocked unless explicitly allowed.<\/li>\n<li><strong>Change propagation<\/strong>: Policy changes can take some time to propagate; test systematically.<\/li>\n<li><strong>Quotas\/limits<\/strong>: Numbers of perimeters, access levels, and complexity are limited; verify current quotas.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Access Context Manager is not a general-purpose security service; it\u2019s specific to context and perimeter controls. Here\u2019s how it compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Access Context Manager<\/strong> (Google Cloud)<\/td>\n<td>Org-wide context access + VPC Service Controls perimeters<\/td>\n<td>Central policy, reusable access levels, strong anti-exfiltration controls for supported services<\/td>\n<td>Requires careful design; org-centric; supported-services scope<\/td>\n<td>You need conditional access and strong data boundary controls in Google Cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>IAM + IAM Conditions<\/strong> (Google Cloud)<\/td>\n<td>Attribute-based authorization on IAM bindings<\/td>\n<td>Fine-grained resource-level authorization; integrates directly with IAM<\/td>\n<td>Doesn\u2019t create service perimeters; not equivalent to VPC SC<\/td>\n<td>You need conditional authorization for specific resources without perimeter controls<\/td>\n<\/tr>\n<tr>\n<td><strong>Organization Policy Service<\/strong> (Google Cloud)<\/td>\n<td>Enforcing org-wide configuration constraints<\/td>\n<td>Great for guardrails (e.g., restrict public IPs, allowed regions)<\/td>\n<td>Not a context-aware request gate; doesn\u2019t do per-request evaluation like access levels<\/td>\n<td>You need governance constraints across projects\/folders<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC firewall rules \/ Cloud Firewall policies<\/strong> (Google Cloud)<\/td>\n<td>Network-layer VM traffic control<\/td>\n<td>Strong L3\/L4 control in VPC<\/td>\n<td>Doesn\u2019t protect Google-managed service APIs from credential misuse<\/td>\n<td>You need network segmentation and VM traffic control<\/td>\n<\/tr>\n<tr>\n<td><strong>Identity-Aware Proxy (IAP)<\/strong> (Google Cloud)<\/td>\n<td>Protecting web apps and TCP services<\/td>\n<td>Strong identity gate for app access; integrates with Google identity<\/td>\n<td>Not a substitute for data service perimeter controls<\/td>\n<td>You need secure access to applications without VPN<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Verified Access \/ AWS IAM + SCP + VPC endpoints<\/strong><\/td>\n<td>Conditional access and boundary controls in AWS<\/td>\n<td>Strong AWS-native approach; endpoint\/private access patterns<\/td>\n<td>Different model; doesn\u2019t map 1:1 to VPC SC<\/td>\n<td>Your workloads are primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Entra Conditional Access + Private Link<\/strong><\/td>\n<td>Conditional access and private connectivity in Azure<\/td>\n<td>Mature conditional access; strong private service access patterns<\/td>\n<td>Different enforcement architecture<\/td>\n<td>Your workloads are primarily on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed proxies + OPA policies<\/strong><\/td>\n<td>Custom enforcement for bespoke systems<\/td>\n<td>Highly customizable<\/td>\n<td>High ops burden; hard to match cloud-native service controls<\/td>\n<td>You need custom policy enforcement not covered by cloud-native controls<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated analytics platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company stores PII in Cloud Storage and BigQuery. They worry about credential theft and accidental data export to non-approved destinations.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Organization with a dedicated <strong>prod-data folder<\/strong><\/li>\n<li>Access Context Manager <strong>service perimeter<\/strong> around analytics projects<\/li>\n<li>Restricted services: Storage, BigQuery (and other supported services as needed)<\/li>\n<li>Ingress rules allowing:<ul>\n<li>approved CI\/CD project for deployments<\/li>\n<li>specific analyst workflows from approved contexts<\/li>\n<\/ul>\n<\/li>\n<li>Dry-run \u2192 policy tuning \u2192 enforced rollout<\/li>\n<li>Centralized logging and security monitoring<\/li>\n<li><strong>Why Access Context Manager was chosen:<\/strong><\/li>\n<li>Provides a cloud-native anti-exfiltration boundary for Google-managed services<\/li>\n<li>Allows centralized policy governance across many projects<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced data exfiltration pathways through Google APIs<\/li>\n<li>Improved auditability of policy violations<\/li>\n<li>Stronger separation between prod and non-prod environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: protect a customer data bucket<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A SaaS startup has a single sensitive bucket with customer exports. They want an extra guardrail beyond IAM to prevent misuse from arbitrary locations.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>One perimeter around the project containing the sensitive bucket<\/li>\n<li>Restricted service: Cloud Storage<\/li>\n<li>Dry-run to observe current access patterns<\/li>\n<li>Minimal, explicit exceptions for build\/deploy and operational access<\/li>\n<li><strong>Why Access Context Manager was chosen:<\/strong><\/li>\n<li>Faster and more robust than building custom proxy layers for Storage API calls<\/li>\n<li>Policy is centralized and auditable<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Stronger default-deny posture for sensitive data access paths<\/li>\n<li>Clear violation logging when policies would have been breached<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) What does Access Context Manager actually enforce?<\/h3>\n\n\n\n<p>It defines policies (access levels and perimeters). Enforcement occurs in integrated Google Cloud control points\u2014most notably <strong>VPC Service Controls<\/strong> for protected services and other supported context-aware access integrations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is Access Context Manager the same as VPC Service Controls?<\/h3>\n\n\n\n<p>No. Access Context Manager is where you <strong>configure<\/strong> service perimeters and access levels. <strong>VPC Service Controls<\/strong> is the enforcement mechanism that uses those perimeters to protect supported services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I still need IAM if I use Access Context Manager?<\/h3>\n\n\n\n<p>Yes. IAM remains the primary authorization layer. Access Context Manager adds conditional\/perimeter constraints; it does not grant permissions by itself.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Is Access Context Manager project-scoped?<\/h3>\n\n\n\n<p>Typically no. It is primarily <strong>organization-scoped<\/strong> through an access policy, and then perimeters include projects.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Can I use Access Context Manager without an Organization?<\/h3>\n\n\n\n<p>In most real deployments, you need an Organization. If you don\u2019t have one, your options are limited; verify current requirements in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Does it protect VM-to-VM traffic in my VPC?<\/h3>\n\n\n\n<p>No. For VM network traffic, use VPC firewall rules, Cloud Firewall policies, and network segmentation patterns. VPC Service Controls focuses on Google-managed service APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Which services can be restricted by a service perimeter?<\/h3>\n\n\n\n<p>Only specific supported services. Always check the current supported services list in official VPC Service Controls documentation because it changes over time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) What is dry-run mode and why is it important?<\/h3>\n\n\n\n<p>Dry-run helps you see what would be blocked <em>before<\/em> you enforce. It\u2019s critical for avoiding outages and for discovering hidden dependencies and workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Can I allow exceptions for CI\/CD systems?<\/h3>\n\n\n\n<p>Yes. Use ingress\/egress rules and\/or access levels to allow required service-to-service interactions while keeping default-deny.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How do I troubleshoot a denied request?<\/h3>\n\n\n\n<p>Use <strong>Cloud Logging<\/strong> and look for VPC Service Controls audit metadata. Identify which perimeter and rule caused the deny and adjust ingress\/egress\/access levels accordingly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) Can Access Context Manager enforce MFA?<\/h3>\n\n\n\n<p>Not directly. MFA is typically enforced through identity providers and account policies. Access Context Manager focuses on context conditions and perimeters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Is Access Context Manager a replacement for VPN?<\/h3>\n\n\n\n<p>No. It supports BeyondCorp-style access patterns for certain scenarios but doesn\u2019t replace all VPN use cases. For application access, consider IAP\/BeyondCorp approaches.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) Can I apply different rules to dev vs prod?<\/h3>\n\n\n\n<p>Yes. Use separate perimeters and potentially separate access levels and exceptions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Will enabling a perimeter break third-party tools?<\/h3>\n\n\n\n<p>It can. Any tool calling restricted services from outside allowed contexts can be blocked. Use dry-run to discover these dependencies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) What\u2019s the safest way to roll out in production?<\/h3>\n\n\n\n<p>Dry-run \u2192 analyze logs \u2192 implement least-privilege exceptions \u2192 staged enforcement (pilot projects first) \u2192 continuous monitoring and periodic review.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Can I manage Access Context Manager with Terraform?<\/h3>\n\n\n\n<p>Yes, commonly. Use the official Google provider resources (verify current names and fields in provider docs). Always test changes in non-prod first.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) What\u2019s the difference between a regular perimeter and a bridge?<\/h3>\n\n\n\n<p>A regular perimeter defines a boundary. A bridge connects perimeters to allow controlled communication between them (use sparingly and design carefully).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Access Context Manager<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Access Context Manager overview<\/td>\n<td>Best starting point for concepts, components, and workflows: https:\/\/cloud.google.com\/access-context-manager\/docs\/overview<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Access levels documentation<\/td>\n<td>How to define and manage access levels: https:\/\/cloud.google.com\/access-context-manager\/docs\/create-access-level<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>VPC Service Controls overview<\/td>\n<td>Explains service perimeters and enforcement model: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/overview<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>VPC Service Controls dry-run<\/td>\n<td>Safe rollout guidance and how to interpret logs: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/dry-run<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Ingress and egress rules<\/td>\n<td>Designing least-privilege exceptions: https:\/\/cloud.google.com\/vpc-service-controls\/docs\/ingress-egress-rules<\/td>\n<\/tr>\n<tr>\n<td>Reference<\/td>\n<td>Access Context Manager API reference<\/td>\n<td>Programmatic management details: https:\/\/cloud.google.com\/access-context-manager\/docs\/reference\/rest<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Google Cloud Pricing Calculator<\/td>\n<td>Estimate underlying service and logging costs: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>BeyondCorp Enterprise pricing<\/td>\n<td>If using BeyondCorp enterprise context features: https:\/\/cloud.google.com\/beyondcorp-enterprise\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud YouTube channel<\/td>\n<td>Search for VPC Service Controls and context-aware access explainers: https:\/\/www.youtube.com\/@googlecloud<\/td>\n<\/tr>\n<tr>\n<td>Trusted community (verify)<\/td>\n<td>Terraform Google provider docs<\/td>\n<td>IaC examples for access levels and perimeters (validate fields): https:\/\/registry.terraform.io\/providers\/hashicorp\/google\/latest\/docs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, platform teams<\/td>\n<td>Google Cloud operations, security fundamentals, DevOps practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps\/SCM foundations, cloud and automation basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>Cloud operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations, platform engineers<\/td>\n<td>Site reliability engineering, incident response, production readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and SRE teams<\/td>\n<td>AIOps concepts, monitoring analytics, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify offerings)<\/td>\n<td>Students and engineers seeking guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course catalog)<\/td>\n<td>Beginners to intermediate DevOps practitioners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps guidance\/services (treat as resource platform)<\/td>\n<td>Teams seeking practical DevOps help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify scope)<\/td>\n<td>Engineers needing hands-on support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services)<\/td>\n<td>Architecture, implementation support, operational improvements<\/td>\n<td>Designing org structure, CI\/CD, cloud governance foundations<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training (verify offerings)<\/td>\n<td>Platform engineering enablement, DevOps process improvements<\/td>\n<td>CI\/CD rollout, operational readiness, security posture basics<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact services)<\/td>\n<td>DevOps transformation and delivery pipelines<\/td>\n<td>Pipeline modernization, automation, production support models<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Access Context Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud resource hierarchy: Organization \u2192 Folders \u2192 Projects<\/li>\n<li>IAM fundamentals (roles, bindings, service accounts)<\/li>\n<li>Cloud Audit Logs and Cloud Logging basics<\/li>\n<li>Cloud Storage and BigQuery fundamentals (if you protect data services)<\/li>\n<li>Networking basics (VPC, private access patterns) to avoid misinterpreting what perimeters do<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Access Context Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC Service Controls advanced patterns:<\/li>\n<li>ingress\/egress rules design<\/li>\n<li>bridges and shared services architectures<\/li>\n<li>BeyondCorp\/IAP for application access<\/li>\n<li>Security Command Center and threat detection workflows<\/li>\n<li>Policy-as-code and automation (Terraform, CI\/CD for policy rollout)<\/li>\n<li>Incident response and forensics in Google Cloud<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Security Engineer<\/li>\n<li>Platform Engineer (Cloud Foundations)<\/li>\n<li>Site Reliability Engineer (in regulated environments)<\/li>\n<li>Cloud Architect \/ Security Architect<\/li>\n<li>Governance, Risk, and Compliance (GRC) engineer (technical)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications that commonly align with this skillset (verify current names and availability in official certification catalog):\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud Architect<\/p>\n\n\n\n<p>Official Google Cloud certifications: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cregulated data zone\u201d with:<\/li>\n<li>one perimeter around a data project<\/li>\n<li>dry-run analysis<\/li>\n<li>minimal ingress\/egress exceptions for CI\/CD<\/li>\n<li>Create separate perimeters for prod\/non-prod and implement a controlled bridge for shared services.<\/li>\n<li>Set up centralized logging and create saved queries\/alerts for VPC Service Controls violations.<\/li>\n<li>Implement policy-as-code with Terraform and peer-reviewed pull requests for perimeter changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Access Context Manager:<\/strong> Google Cloud service for defining access policies, access levels, and service perimeters used for context-aware access and VPC Service Controls.<\/li>\n<li><strong>Access Policy:<\/strong> Top-level container in Access Context Manager that holds access levels and service perimeters.<\/li>\n<li><strong>Access Level:<\/strong> A named set of conditions that define when access should be considered from a trusted context.<\/li>\n<li><strong>CEL (Common Expression Language):<\/strong> Expression language used to define custom logical conditions in policies.<\/li>\n<li><strong>VPC Service Controls (VPC SC):<\/strong> Google Cloud capability that uses service perimeters to reduce data exfiltration risk from supported Google-managed services.<\/li>\n<li><strong>Service Perimeter:<\/strong> A boundary around projects and services that restricts access based on policy.<\/li>\n<li><strong>Ingress Rule:<\/strong> An allow rule that permits requests from outside a perimeter to reach resources inside, under defined conditions.<\/li>\n<li><strong>Egress Rule:<\/strong> An allow rule that permits requests from inside a perimeter to access resources outside, under defined conditions.<\/li>\n<li><strong>Dry-run:<\/strong> Mode that records what would be blocked without enforcing (useful for safe rollout).<\/li>\n<li><strong>Organization (Google Cloud):<\/strong> Top-level resource container above folders and projects; required for many org-wide security features.<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Logs that record administrative activity and data access in Google Cloud services.<\/li>\n<li><strong>Data exfiltration:<\/strong> Unauthorized movement of data out of a trusted environment.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Access Context Manager is Google Cloud\u2019s organization-level <strong>Security<\/strong> service for defining <strong>context-aware access<\/strong> and <strong>service perimeters<\/strong> (used by VPC Service Controls). It matters because IAM alone can\u2019t fully express \u201ctrusted access\u201d\u2014especially for sensitive data services\u2014while Access Context Manager adds conditions and boundaries that reduce data exfiltration risk.<\/p>\n\n\n\n<p>It fits best in organizations that need centralized policy governance across many projects, especially where Cloud Storage, BigQuery, and other supported managed services host sensitive data. Cost is usually driven less by Access Context Manager itself and more by indirect factors like Cloud Logging volume and the protected services you use\u2014so plan log retention, rollout phases, and exception design carefully.<\/p>\n\n\n\n<p>Use Access Context Manager when you need a strong, auditable, policy-driven boundary for data services in Google Cloud, and adopt dry-run-first rollout with explicit ingress\/egress rules. Next step: deepen your understanding of <strong>VPC Service Controls ingress\/egress rules<\/strong> and practice a staged deployment pattern in a non-production environment.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,10],"tags":[],"class_list":["post-789","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-security"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=789"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/789\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}