Access Context Manager in GCP - Commands & Configuration

Introduction

Access Context Manager helps you control who can access your Google Cloud resources based on conditions like location or device security. It solves the problem of allowing access only when certain rules are met, improving security.

When you want to allow employees to access cloud apps only from the office network.

When you need to block access from devices that are not secure or managed.

When you want to restrict access to sensitive data based on user location.

When you want to enforce multi-factor authentication only in risky situations.

When you want to create rules that combine user identity and device security for access.

Config File - access_policy.yaml

access_policy.yaml

accessPolicies:
- name: accessPolicies/1234567890
  title: "Example Access Policy"
  scopes:
  - "organizations/1234567890"
  accessLevels:
  - name: accessPolicies/1234567890/accessLevels/office_access
    title: "Office Access Level"
    basic:
      conditions:
      - ipSubnetworks:
        - "192.168.1.0/24"
        devicePolicy:
          requireScreenLock: true
          osConstraints:
          - osType: "DESKTOP_WINDOWS"
            minimumVersion: "10"
  servicePerimeters:
  - name: accessPolicies/1234567890/servicePerimeters/perimeter1
    title: "Example Perimeter"
    status:
      resources:
      - "projects/1234567890"
      restrictedServices:
      - "storage.googleapis.com"
      accessLevels:
      - "accessPolicies/1234567890/accessLevels/office_access"

This YAML file defines an Access Context Manager policy for an organization.

• accessPolicies: The main container for access rules.
• accessLevels: Define conditions like allowed IP ranges and device security.
• servicePerimeters: Define boundaries that restrict access to services unless conditions are met.

Commands

Lists all Access Context Manager policies in your organization to see existing policies.

Terminal

gcloud access-context-manager policies list

Expected Output

NAME            TITLE

1234567890      Example Access Policy

Creates a new Access Context Manager policy for your organization with a title.

Terminal

gcloud access-context-manager policies create --organization=1234567890 --title="Example Access Policy"

Expected Output

Created access policy [1234567890].

→

--organization - Specifies the organization ID where the policy is created

→

--title - Sets a friendly name for the policy

Creates an access level named 'office_access' that allows access only from the specified IP range and requires device screen lock.

Terminal

gcloud access-context-manager levels create office_access --policy=1234567890 --title="Office Access Level" --basic-ip-subnetworks=192.168.1.0/24 --basic-device-require-screenlock

Expected Output

Created access level [office_access].

→

--policy - Specifies the policy ID to attach the access level

→

--basic-ip-subnetworks - Defines allowed IP address ranges

→

--basic-device-require-screenlock - Requires devices to have screen lock enabled

Creates a service perimeter named 'perimeter1' that restricts access to the storage service unless the 'office_access' level conditions are met.

Terminal

gcloud access-context-manager perimeters create perimeter1 --policy=1234567890 --title="Example Perimeter" --resources=projects/1234567890 --restricted-services=storage.googleapis.com --access-levels=office_access

Expected Output

Created service perimeter [perimeter1].

→

--policy - Specifies the policy ID to attach the perimeter

→

--resources - Lists the projects or resources inside the perimeter

→

--restricted-services - Specifies which services are restricted by this perimeter

→

--access-levels - Links access levels that allow crossing the perimeter

Lists all service perimeters under the specified policy to verify creation.

Terminal

gcloud access-context-manager perimeters list --policy=1234567890

Expected Output

NAME        TITLE

perimeter1  Example Perimeter

→

--policy - Specifies the policy ID to list perimeters

Key Concept

If you remember nothing else from this pattern, remember: Access Context Manager lets you set rules that control access to cloud resources based on user location, device security, and other conditions.

Common Mistakes

Not specifying the correct organization ID when creating policies.

The policy will not be created or will be created in the wrong place, causing access rules to not apply.

Always use the correct organization ID with the --organization flag.

Creating access levels without proper IP ranges or device requirements.

Access levels will be too open or too restrictive, defeating the purpose of conditional access.

Define clear IP subnetworks and device policies that match your security needs.

Not linking access levels to service perimeters.

Service perimeters will block access even if users meet access level conditions.

Always specify access levels when creating or updating service perimeters.

Summary

Use gcloud commands to create and manage Access Context Manager policies, access levels, and service perimeters.

Access levels define conditions like allowed IP ranges and device security for access.

Service perimeters restrict access to services unless users meet access level conditions.

Practice

1. What is the main purpose of Access Context Manager in Google Cloud?

easy

A. To manage billing accounts and payments

B. To monitor network traffic in real-time

C. To deploy virtual machines automatically

D. To control access to resources based on user context like location and device security

Solution

1. Step 1: Understand Access Context Manager's role

   It controls access by considering user context such as location and device security, not just identity.

2. Step 2: Compare with other options

   Billing, VM deployment, and network monitoring are unrelated to Access Context Manager's function.

3. Final Answer:

   To control access to resources based on user context like location and device security -> Option D

4. Quick Check:

   Access Context Manager controls access context = B [OK]

Hint: Access Context Manager controls access by context, not billing or VMs [OK]

Common Mistakes:

• Confusing Access Context Manager with billing or VM services
• Thinking it manages network traffic monitoring
• Assuming it only uses usernames and passwords

2. Which of the following is the correct way to define an Access Level in Access Context Manager using YAML?

easy

A. accessLevels:
- name: 'accessPolicies/123/accessLevels/level1'
title: 'Office Access'
basic:
conditions:
- ipSubnetworks: ['192.168.1.0/24']
devicePolicy:
osConstraints:
- osType: 'DESKTOP_MAC'
minimumVersion: '10.15'

B. accessLevels:
- id: 'level1'
description: 'Office Access'
conditions:
ipRanges: ['192.168.1.0/24']
device: 'MAC'

C. accessLevel:
- name: 'level1'
title: 'Office Access'
conditions:
ipSubnet: ['192.168.1.0/24']
devicePolicy:
osType: 'MAC'

D. accessLevels:
- name: 'accessPolicies/123/accessLevels/level1'
title: 'Office Access'
conditions:
ipSubnetworks: ['192.168.1.0/24']
devicePolicy:
osConstraints:
- osType: 'DESKTOP_MAC'
minimumVersion: '10.15'

Solution

1. Step 1: Review correct YAML structure for Access Level

   The correct syntax uses 'accessLevels' list with 'name', 'title', and 'basic' containing 'conditions' with 'ipSubnetworks' and 'devicePolicy' including 'osConstraints'.

2. Step 2: Identify errors in other options

   accessLevels: - id: 'level1' description: 'Office Access' conditions: ipRanges: ['192.168.1.0/24'] device: 'MAC' uses wrong keys like 'ipRanges' and 'device'. accessLevel: - name: 'level1' title: 'Office Access' conditions: ipSubnet: ['192.168.1.0/24'] devicePolicy: osType: 'MAC' uses 'accessLevel' singular and wrong keys. accessLevels: - name: 'accessPolicies/123/accessLevels/level1' title: 'Office Access' conditions: ipSubnetworks: ['192.168.1.0/24'] devicePolicy: osConstraints: - osType: 'DESKTOP_MAC' minimumVersion: '10.15' misses 'basic' wrapper around 'conditions'.

3. Final Answer:

   accessLevels: - name: 'accessPolicies/123/accessLevels/level1' title: 'Office Access' basic: conditions: - ipSubnetworks: ['192.168.1.0/24'] devicePolicy: osConstraints: - osType: 'DESKTOP_MAC' minimumVersion: '10.15' -> Option A

4. Quick Check:

   Correct YAML keys and structure = A [OK]

Hint: Look for 'basic' and 'conditions' keys in YAML for Access Level [OK]

Common Mistakes:

• Using singular 'accessLevel' instead of 'accessLevels'
• Missing 'basic' wrapper for conditions
• Incorrect keys like 'ipRanges' or 'device' instead of 'ipSubnetworks' and 'devicePolicy'

3. Given this Access Context Manager policy snippet, what will happen if a user tries to access a resource from IP 203.0.113.5?

accessLevels:
- name: 'accessPolicies/456/accessLevels/levelA'
  basic:
    conditions:
    - ipSubnetworks: ['192.168.0.0/16']
      devicePolicy:
        osConstraints:
        - osType: 'DESKTOP_WINDOWS'
          minimumVersion: '10'

medium

A. Access will be denied because the IP is outside the allowed subnet

B. Access will be allowed because device OS matches

C. Access will be allowed because IP is public

D. Access will be denied because OS version is too low

Solution

1. Step 1: Check IP subnet condition

   The allowed IP subnet is '192.168.0.0/16', which covers private IPs only. The user's IP '203.0.113.5' is public and outside this range.

2. Step 2: Evaluate access decision

   Since IP does not match allowed subnet, access is denied regardless of device OS.

3. Final Answer:

   Access will be denied because the IP is outside the allowed subnet -> Option A

4. Quick Check:

   IP outside allowed subnet = Access denied [OK]

Hint: Check IP subnet first; outside means deny access [OK]

Common Mistakes:

• Ignoring IP subnet and trusting device OS alone
• Assuming public IPs are always allowed
• Confusing IP ranges with device policies

4. You created an Access Level but users report they cannot access resources even when meeting conditions. Which is the most likely error in your Access Context Manager configuration?

medium

A. The device OS version is set too low

B. The Access Level is not attached to any Access Policy

C. The IP subnet range is too broad

D. The Access Level name is missing

Solution

1. Step 1: Understand Access Level usage

   Access Levels must be part of an Access Policy to enforce rules on resources.

2. Step 2: Analyze impact of missing Access Policy attachment

   If Access Level is not attached to any Access Policy, it has no effect, so users cannot access resources despite meeting conditions.

3. Final Answer:

   The Access Level is not attached to any Access Policy -> Option B

4. Quick Check:

   Access Level without policy attachment = no access enforced [OK]

Hint: Access Levels must be linked to Access Policies to work [OK]

Common Mistakes:

• Assuming broad IP ranges cause denial
• Thinking device OS version too low blocks access
• Ignoring the need to attach Access Levels to Policies

5. You want to create a service perimeter that restricts access to a Google Cloud Storage bucket only to users accessing from your corporate network and using compliant devices. Which combination of Access Context Manager components should you configure?

hard

A. Use only IAM roles to restrict access based on user identity and device type

B. Create a firewall rule blocking all external IPs and enable device compliance in IAM roles

C. Create an Access Policy with an Access Level defining IP subnet and device compliance, then apply it in a Service Perimeter around the bucket

D. Configure VPC Service Controls without Access Context Manager components

Solution

1. Step 1: Understand components needed

   Access Context Manager uses Access Policies and Access Levels to define conditions like IP subnet and device compliance.

2. Step 2: Apply conditions with Service Perimeter

   Service Perimeters enforce these Access Levels around resources like Cloud Storage buckets to restrict access accordingly.

3. Final Answer:

   Create an Access Policy with an Access Level defining IP subnet and device compliance, then apply it in a Service Perimeter around the bucket -> Option C

4. Quick Check:

   Access Policy + Access Level + Service Perimeter = A [OK]

Hint: Combine Access Policy, Access Level, and Service Perimeter for resource protection [OK]

Common Mistakes:

• Relying only on firewall or IAM roles without Access Context Manager
• Using VPC Service Controls alone without Access Levels
• Not defining device compliance in Access Levels