Access Context Manager

Access Context Manager allows Google Cloud organization administrators to define fine-grained, attribute based access control for projects, apps, and resources.

Access Context Manager – VPC Service Controls

~ Last updated on : ~ jayendrapatil

Google Cloud Access Context Manager

  • Access Context Manager allows Google Cloud organization administrators to define fine-grained, attribute-based access control for projects and resources in Google Cloud.
  • Access Context Manager is the zero trust policy engine of Chrome Enterprise Premium (formerly BeyondCorp Enterprise), enabling context-aware access control for applications and Google Cloud resources.
  • Access Context Manager helps prevent data exfiltration.
  • Access Context Manager helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
  • Access Context Manager helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.
  • Access Context Manager is an integral part of Google’s BeyondCorp zero trust effort.

Access Policies

  • An access policy is an organization-wide container for access levels and service perimeters.
  • Administrators first define an access policy, then configure access levels and service perimeters within it.
  • Scoped Policies (GA – March 2022)
    • To delegate administration, you can create access policies scoped to specific folders or projects.
    • Delegated administrators can manage only their scoped policy, not the organization-level policy.
    • Useful for decentralized management of VPC Service Controls perimeters and access levels.
  • An access policy is versioned using an etag to prevent unintended overwrites and conflicts when multiple sources modify it.

Access Levels

  • Access levels are used for permitting access to resources based on contextual information about the request.
  • Access is granted based on the context of the request, such as device type, user identity, IP address, and more, while still checking for corporate network access when necessary.
  • Access Context Manager provides two ways to define access levels: basic and custom.
    • Basic Access Level
      • is a collection of conditions that are used to test requests.
      • Conditions are a group of attributes to be tested, such as device type, IP address, user identity, or geographic region.
      • Conditions can be combined using AND (all must be true – default, stricter) or OR (any one must be true – less restrictive).
      • Supports internal IP addresses when specifying IP address ranges (GA – June 2024).
    • Custom Access Levels
      • are created using a subset of Common Expression Language (CEL).
      • helps to permit requests based on data from third-party services.
      • In addition to the request context used for basic access levels, custom access levels can evaluate data from external sources.
  • Access levels can be nested—one access level can depend on another (e.g., “High_Trust” requires “Medium_Trust” plus additional conditions).
  • Access levels support the following attributes:
    • IP address – specified as CIDR blocks; supports both public and internal (private) IP ranges
    • Device type – uses Endpoint Verification to gather OS, device type, encryption status, admin approval, and corp-owned status
    • User identity – specific users or service accounts (useful with VPC Service Controls)
    • Geographic regions – request origin region
    • Time and date conditions – restrict access to specific time windows

Service Perimeters

  • Service perimeters define sandboxes of resources that can freely exchange data within the perimeter but are not allowed to export data outside of it.
  • Service perimeters are used with VPC Service Controls to protect Google Cloud resources and prevent data exfiltration.
  • Ingress and Egress Rules (GA – April 2021)
    • Ingress rules control calls from services outside a perimeter to resources inside the perimeter.
    • Egress rules control calls from inside the perimeter to resources outside the perimeter.
    • Access levels can be used by ingress policies but cannot be used by egress policies (egress policies use contextual information directly).
  • Individual VPC Networks (GA – February 2023)
    • You can now add individual VPC networks as members of a perimeter (previously the entire VPC host project was added).
    • You can create ingress rules to authorize individual VPC networks to access a perimeter.
  • Dry Run Mode – allows testing changes to perimeters before enforcing them, helping identify potential impact without disrupting access.

Context-Aware Access

  • Context-Aware Access is a security approach where you control users’ access based on authentication strength, device posture, network location, geographic location, or other attributes.
  • Access Bindings apply access policies to user groups, enabling enforcement of context-aware access for specific groups of users.
  • App Allowlist (GA – October 2024)
    • You can create an access binding with a map of applications to access levels.
    • This allows applying access levels to specific applications, avoiding unintended effects on other applications.
  • Certificate-Based Access (CBA)
    • Uses mutual TLS (mTLS) to verify device certificates before granting access.
    • Can be enforced for user groups, with VPC Service Controls, for client applications, web applications, and VMs.
    • Supports enterprise certificates and Endpoint Verification certificates.
  • Chrome Browser Attributes
    • Zero trust policies can verify that the user’s browser has Chrome Enterprise Premium threat and data protection capabilities turned on.
    • Chrome attributes are only effective for browser-based traffic and have no effect on requests from gcloud CLI or Google Cloud SDKs.
  • Session Controls – configure re-authentication requirements for ongoing sessions.
  • Credential Strength Policy – enforce specific authentication strength (e.g., multi-factor authentication).

Policy Enforcement Points

  • Access Context Manager defines policies; enforcement happens at various integration points:
    • VPC Service Controls – enforces service perimeters and ingress/egress rules for Google Cloud APIs
    • Identity-Aware Proxy (IAP) – enforces context-aware access for web applications and VMs
    • Context-Aware Access for Google Workspace – controls access to Google Workspace applications
    • Identity and Access Management (IAM) Conditions – uses access levels as conditions in IAM policies

Custom Organization Policies (GA – March 2025)

  • Access Context Manager now supports custom organization policies.
  • Organization Policy administrators can define custom constraints for Access Context Manager resources.
  • Custom constraints allow more granular control over the specific fields that are restricted in access policies.
  • Built-in managed constraints are available, but custom constraints provide finer control.

Bulk Operations

  • The Access Context Manager Bulk API can replace all of your organization’s access levels in one operation.
  • Useful for large-scale access level management and policy migrations.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to prevent data exfiltration from their Google Cloud environment. They need to ensure that data within a set of projects cannot be accessed from outside the organization, even by users with valid IAM permissions. Which combination of services should they use?
    1. Access Context Manager and Cloud IAM only
    2. VPC Service Controls with service perimeters defined using Access Context Manager
    3. Cloud Armor and Identity-Aware Proxy
    4. Organization Policy Service with resource location constraints

    Answer: b. VPC Service Controls with service perimeters prevent data exfiltration even from authorized users by restricting data movement outside the perimeter boundary.

  2. An organization wants to grant access to sensitive resources only when requests come from corporate-managed devices running an approved OS version AND from the corporate network IP range. How should they configure Access Context Manager?
    1. Create two separate basic access levels and use OR combining
    2. Create a single basic access level with multiple conditions using AND combining (default)
    3. Create a custom access level with CEL expressions only
    4. Use IAM conditions without Access Context Manager

    Answer: b. A basic access level with AND combining (the default) requires all conditions to be true, ensuring both device posture and IP range are verified.

  3. A multinational organization wants to delegate VPC Service Controls administration to regional teams managing their own folders. Which Access Context Manager feature enables this?
    1. Custom access levels with CEL
    2. Nested access levels
    3. Scoped access policies
    4. Access bindings with app allowlists

    Answer: c. Scoped policies allow creating access policies scoped to specific folders or projects, enabling delegated administration to folder-level administrators.

  4. Which of the following statements about Access Context Manager is correct? (Choose TWO)
    1. Access Context Manager directly enforces access control policies
    2. Access Context Manager is the zero trust policy engine of Chrome Enterprise Premium
    3. Custom access levels can use data from third-party services
    4. Access levels can be used in both ingress and egress policies equally
    5. Access Context Manager requires a VPC network to function

    Answer: b, c. ACM defines policies but does not enforce them (a is incorrect). ACM is the zero trust engine of Chrome Enterprise Premium (b is correct). Custom access levels use CEL and can evaluate third-party data (c is correct). Access levels can only be used by ingress policies, not egress (d is incorrect).

  5. A company wants to apply different access levels to different SaaS applications accessed through Chrome Enterprise Premium. Some applications should require stricter device posture than others. What feature should they use?
    1. Service perimeters with VPC Service Controls
    2. Access bindings with a map of applications to access levels
    3. Multiple organization-level access policies
    4. IAM conditions with resource-level granularity

    Answer: b. The app allowlist feature (GA October 2024) allows creating access bindings with a map of applications to access levels, applying different access levels to specific applications.

  6. An organization needs to verify that users accessing sensitive resources through a browser have Chrome Enterprise Premium threat protection enabled. Which Access Context Manager feature should they configure?
    1. Basic access levels with device attributes
    2. Chrome browser attributes in access levels
    3. Certificate-based access with enterprise certificates
    4. Custom access levels with endpoint verification data

    Answer: b. Chrome browser attributes allow setting zero trust policies that verify the browser has threat and data protection capabilities enabled. Note: these attributes only apply to browser-based traffic.

See also: Google Cloud Security Services Cheat Sheet

References

Google Cloud Security Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Cloud Armor

  • Cloud Armor protects the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
  • Cloud Armor is offered in two service tiers: Cloud Armor Standard and Cloud Armor Enterprise (previously Managed Protection Plus).
  • Cloud Armor Standard includes:
    • Pay-as-you-go pricing
    • Always-on L3/L4 volumetric and protocol-based DDoS protection
    • Global and regional security policies
    • Preconfigured WAF rules (OWASP Top 10)
  • Cloud Armor Enterprise includes all Standard features plus:
    • Adaptive Protection with full ML-based L7 DDoS detection and suggested rules
    • Advanced network DDoS protection for external network LBs, protocol forwarding, and VMs with public IPs
    • Threat intelligence integration
    • Bot management with reCAPTCHA Enterprise integration
    • DDoS bill protection
    • Named IP lists
  • Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Security policies protect applications running behind a load balancer from DDoS and other web-based attacks
  • Backend service can have only one security policy associated with it
  • Prioritized rules define configurable match conditions, actions (allow or deny) and order in a security policy
  • Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.
  • Hierarchical Security Policies (GA Oct 2025) facilitate centralized control at the organization and folder level, enabling policy delegation and consistent enforcement across projects.
  • Enhanced WAF inspection (GA Feb 2026) expands request body inspection from 8 KB to 64 KB for all preconfigured WAF rules, improving detection of sophisticated malicious content.
  • Adaptive Protection uses ML to automatically detect and suggest mitigations for L7 DDoS attacks. Full alerts (with suggested rules) require Cloud Armor Enterprise; Standard provides basic alerts only.
  • Rate Limiting supports throttle and ban actions based on per-client request rates.

Cloud Identity-Aware Proxy

  • Identity-Aware Proxy (IAP) allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
  • IAP is based on the BeyondCorp zero-trust security model, establishing a zero-trust perimeter on the public internet for secure remote work without the need for a traditional VPN.
  • IAP intercepts web requests sent to the application, authenticates the user making the request using Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
  • IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
  • IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, GitHub, Microsoft, SAML, etc.
  • IAP can be configured to use JSON Web Tokens (JWT) as signed headers to make sure that a request to the app is authorized and doesn’t bypass IAP.
  • IAP for Cloud Run (2025) enables IAP directly on Cloud Run services in a single click, with no load balancers required and at no added cost for IAP itself.
  • Google Cloud does not charge for IAP (with some exceptions for programmatic workloads at high scale).
  • Note: The IAP OAuth Admin API was deprecated in January 2025 and shut down in September 2025. Use the IAM API for IAP resource management.

Sensitive Data Protection (formerly Cloud DLP)

  • Cloud Data Loss Prevention (Cloud DLP) has been renamed to Sensitive Data Protection (SDP), now encompassing a broader family of services for discovering, classifying, and protecting sensitive data.
  • Sensitive Data Protection is a fully managed service designed to help discover, classify, and protect the most sensitive data.
  • provides two key features:
    • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
    • De-identification is the process of removing, masking, replacing information from data.
  • uses information types – or infoTypes – to define what it scans like credit card numbers, email addresses, etc.
  • provides various built-in infoType detectors and supports custom ones
  • supports inspection rules to fine-tune scan results using:
    • Exclusion rules decrease the number of findings
    • Hotword rules increase the quantity or change the likelihood value of findings
  • provides likelihood, which indicates how likely it is that a piece of data matches a given infoType like VERY_LIKELY or POSSIBLE, etc.
  • supports Text Classification and Reduction
  • supports Image Classification and Reduction, where the image is handled using its base64 encoded version
  • supports storage classification with scans on data stored in Cloud Storage, BigQuery, Datastore, and Cloud SQL
  • supports scanning of binary, text, image, Microsoft Word, PDF, and Apache Avro files
  • supports Templates to decouple configuration from implementation and manage large-scale rollouts
  • Discovery Service (continuous monitoring) automatically discovers, classifies, and profiles data across the organization, folder, or project, identifying where sensitive and high-risk data reside.
  • Discovery for Vertex AI (2025) extends automated data discovery to Vertex AI datasets and tuning jobs, helping understand data sensitivity in AI training and fine-tuning data.
  • Conversational content inspection (2026) supports inspecting and de-identifying conversational content within ContentItem requests.
  • Sensitive Data Protection is deeply integrated with Security Command Center, feeding data risk insights into the SCC risk engine.
  • Note: Integration with Data Catalog was deprecated (Sept 2025) and discontinued (Jan 2026). SDP discovery results now flow to Security Command Center instead.

Security Command Center – SCC

  • is a Security and risk management platform for Google Cloud
  • helps generate curated insights that provide a unique view of incoming threats and attacks to the assets, which include organization, projects, instances, and applications
  • displays possible security risks, called findings, that are associated with each asset.
  • is available in three tiers: Standard, Premium, and Enterprise (Enterprise is deprecated, shutting down May 21, 2027)
  • SCC Standard Tier (Enhanced, April 2026) is now automatically enabled for eligible customers and includes:
    • AI Protection dashboard with detection of unprotected Gemini inference and guardrail violations
    • 44+ misconfiguration checks based on Google Cloud Security Essentials (GCSE) framework
    • Agentless critical vulnerability scanning
    • Graph-driven risk insights
    • Data Security Posture Management (DSPM) for Vertex AI, BigQuery, and Cloud Storage
    • Compliance Manager with automated monitoring against GCSE
  • SCC Premium Tier adds:
    • Full Security Health Analytics vulnerability scanning
    • Event Threat Detection
    • Container Threat Detection
    • Virtual Machine Threat Detection
    • Cloud Run Threat Detection
    • Attack path simulation and risk scoring
  • provides built-in services:
    • Security Health Analytics provides managed vulnerability assessment scanning that can automatically detect the highest severity vulnerabilities and misconfigurations across assets.
    • Web Security Scanner custom scans provide granular information about application vulnerability findings like outdated libraries, XSS, etc.
    • Sensitive Data Protection (formerly Cloud DLP) discovers, classifies, and protects sensitive data
    • Cloud Armor protects Google Cloud deployments against threats
    • Container Threat Detection can detect the most common container runtime attacks
    • Virtual Machine Threat Detection scans VMs to detect potentially malicious applications such as cryptocurrency mining software, kernel-mode rootkits, and malware
    • Cloud Run Threat Detection continuously monitors Cloud Run resources to detect common runtime attacks
    • Event Threat Detection monitors the organization’s Cloud Logging stream and consumes logs to detect Malware, Cryptomining, brute-force attacks, and identity-based attacks
    • Phishing Protection helps prevent users from accessing phishing sites by classifying malicious content that uses the brand and reporting the unsafe URLs to Google Safe Browsing
    • Continuous Exports, which automatically manage the export of new findings to Pub/Sub.
  • Note: The Anomaly Detection service has been replaced by Event Threat Detection and VM Threat Detection capabilities.
  • Note: Forseti Security (open-source toolkit) has been archived and is no longer maintained. Use SCC built-in services instead.
  • Note: SCC Enterprise tier was deprecated May 21, 2026 and will shut down May 21, 2027. Organizations will automatically move to Premium tier.

DDoS Protection and Mitigation

  • Distributed Denial of Service (DDoS) Protection and Mitigation is a shared responsibility between Google Cloud and the Customer
  • DDoS attack is an attempt to render the service or application unavailable to the end-users using multiple sources
  • DDoS Protection and Mitigation Best Practices
    • Reduce the Attack Surface
      • Isolate and secure network using VPC, subnets, firewall rules, tags and IAM
      • Google provides Anti-spoofing protection and Automatic isolation between virtual networks
    • Isolate Internal Traffic
      • Use private IPs and avoid using Public IPs
      • Use NAT Gateway and Bastion host
      • Use Internal Load Balancer for internal traffic
    • Enable Proxy-based Load Balancing
      • HTTP(S) or SSL proxy load balancer uses GFE that helps mitigate and absorb layer 4 and other attacks
      • Disperse traffic across multiple regions
    • Scale to Absorb the Attack
      • Use GFE for protection
      • Use Anycast-based load balancing to provide single anycast IP to FE
      • Use Autoscaling to scale backend services as per the demand
    • Protection using CDN Offloading
      • CDN acts as a proxy and can help render cache content reducing the load on the origin servers
    • Deploy Cloud Armor for WAF and DDoS Protection
      • Cloud Armor Enterprise provides advanced DDoS protection, adaptive protection, and DDoS bill protection
    • App Engine Deployment
      • A fully multi-tenant system with isolation
    • Google Cloud Storage
      • Use signed URLs to access Google Cloud Storage
    • API Rate Limiting
      • Define rate limiting based on the number of allowed requests
      • API Rate limits are per applied per-project basis
      • Cloud Armor supports rate limiting with throttle and ban actions
    • Resource Quotas
      • Quotas help prevent unforeseen spikes in usage

Access Context Manager

  • Access Context Manager allows organization administrators to define fine-grained, attribute-based access control for projects and resources
  • helps prevent data exfiltration
  • helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
  • helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.
  • supports custom organization policies (GA 2025) for creating custom constraints beyond the built-in access levels.
  • supports individual VPC network members in a perimeter and ingress rules to authorize specific VPC networks to access a perimeter.
  • works with Chrome Enterprise Premium (formerly BeyondCorp Enterprise) for context-aware access that integrates device trust, user identity, and location into access decisions.

Model Armor (New – 2025)

  • Model Armor is a Google Cloud service designed to enhance the security and safety of AI applications that use Large Language Models (LLMs).
  • Works by proactively screening LLM prompts and responses, protecting against various risks and ensuring responsible AI practices.
  • Key capabilities:
    • Prompt injection detection — detects and blocks prompt injection and jailbreak attempts
    • Sensitive data protection — detects and prevents exposure of PII, financial info, and credentials in prompts and responses
    • Content safety — filters harmful, toxic, or inappropriate content
    • Policy enforcement — identifies and reports potential policy violations and can actively block actions
  • Protects all LLMs (including Gemini, OpenAI, Anthropic, Llama, and more) via a REST API.
  • Offers no-code in-line protection integrated with Google Cloud services including Gemini Enterprise Agent Platform.
  • Can integrate with Agent Gateway for securing agentic AI workflows (2026).
  • Integrated with Security Command Center for AI security posture visibility.

FIPS 140-2 / 140-3 Validated

  • The NIST developed the Federal Information Processing Standard (FIPS) Publication 140-2 (and its successor FIPS 140-3) as a security standard that sets forth requirements for cryptographic modules, including hardware, software, and/or firmware, for U.S. federal agencies.
  • FIPS 140-2/140-3 Validated certification was established to aid in the protection of digitally stored unclassified, yet sensitive, information.
  • Google Cloud Platform uses a FIPS 140-2 validated encryption module called BoringCrypto in its production environment.
  • Google’s BoringCrypto module has also received a FIPS 140-3 certificate (#4735), reflecting the transition to the newer standard.
  • Certifications issued under FIPS 140-2 remain valid and acceptable for federal compliance programs until their expiration date.
  • Data in transit to the customer and between data centers, and data at rest are encrypted using FIPS 140-2 validated encryption (or newer).
  • BoringCrypto module that achieved FIPS 140-2/140-3 validation is part of the BoringSSL library.
  • BoringSSL library as a whole is not FIPS validated
  • In order to operate using only FIPS-validated implementations:
    • Google’s Local SSD storage product is automatically encrypted with NIST approved ciphers, but Google’s current implementation for this product doesn’t have a FIPS validation certificate. If you require FIPS-validated encryption on Local SSD storage, you must provide your own encryption with a FIPS-validated cryptographic module.
    • Google automatically encrypts traffic between VMs that travels between Google data centers using NIST-approved encryption algorithms, but this implementation does not have a FIPS validation certificate. If you require this traffic to be encrypted with a FIPS-validated implementation, you must provide your own.
    • Clients connecting to Google infrastructure with TLS clients must be configured to require use of secure FIPS-compliant algorithms; if the TLS client and GCP’s TLS services agree on an encryption method that is incompatible with FIPS, a non-validated encryption implementation will be used.
    • Applications built and operated on GCP might include their own cryptographic implementations; in order for the data they process to be secured with a FIPS-validated cryptographic module, you must integrate such an implementation yourself.
  • All Google Cloud regions and zones currently support FIPS 140-2 validated encryption.
  • GKE supports FIPS 140-2 validated encryption using BoringCrypto, with nodes configured to use FIPS-compliant cryptographic modules.

Related Posts