Access Context Manager allows Google Cloud organization administrators to define fine-grained, attribute based access control for projects and resources in Google Cloud.
Access levels describe the requirements for requests to be honored. Examples include:
- Device type and operating system
- IP address
- User identity
Service perimeters define sandboxes of resources which can freely exchange data within the perimeter, but are not allowed to export data outside of it. Access Context Manager isn't responsible for policy enforcement. Its purpose is to describe the desired rules. Policy is configured and enforced across various points, such as VPC Service Controls. You can read more about these services in their respective user guides.
Why Access Context Manager
Many companies rely on a perimeter security model — for example, firewalls — to secure internal resources. This model is similar to a medieval castle: a fortress with thick walls, surrounded by a moat, with a heavily guarded single point of entry and exit. Anything located outside the wall is considered dangerous. Anything inside is trusted.
Firewalls and the perimeter security model work well if there is a precise boundary around specific users and services. However, if a workforce is mobile, the variety of devices increases as users bring their own devices (BYOD) and utilize cloud-based services. This scenario results in additional attack vectors that are not considered by the perimeter model. The perimeter is no longer just the physical location of the enterprise, and what lies inside cannot be assumed as safe.
Access Context Manager lets you reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network. Instead, you can grant access based on the context of the request, such as device type, user identity, and more, while still checking for corporate network access when necessary.
Access Context Manager is an integral part of the BeyondCorp effort at Google. To learn more, see BeyondCorp.
You can create an access policy in the context of an organization and use the organization-level access policy anywhere in your organization. To delegate administration of an access policy, you can create a scoped access policy and set the scope of the policy at the folder or project level. The delegated administrator to whom the scoped policy is assigned can manage only the scoped access policy and not the organization-level access policy.
An access policy is versioned using an
You can use
etag to target changes to your access policy, such as modifications to
access levels, to a specific version of the policy. If multiple sources change
your access policy, using the
etag field for the
gcloud command-line tool and API calls ensures
that unintended overwrites and conflicts don't occur.
To learn how to create access policies, see Creating an access policy.
Access levels are used for permitting access to resources based on contextual
information about the request. Using access levels, you can start to organize
tiers of trust. For example, you might create an access level called
High_Level that will permit requests from a small group of highly-privileged
individuals. You might also identify a more general group to trust, such as an
IP range that you want to permit requests from. In that case, you might create
an access level called
Medium_Level to permit those requests.
Once you have defined access levels, enforcement services can use them to determine whether to honor a request. For example, you might specify that while many resources are available to "Medium_Trust," certain more sensitive resources require the "High_Trust" level. These checks are applied in addition to standard Identity and Access Management policy.
Access levels are customizable; the
levels are examples. You can specify multiple access levels as part of an
Access Context Manager provides two ways to define access levels: basic and custom.
A basic access level is a collection of conditions that are used to test requests. Conditions are a group of attributes that you want to test, such as device type, IP address, or user identity. The attributes are combined as either an AND operation (all must be true) or a NAND operation (none must be true) to determine whether the condition is met.
Custom access levels are created using a subset of Common Expression Language. In addition to the request context used for basic access levels, you can also use custom access levels to permit requests based on data from third-party services. For more information, see Custom Access Levels.
You can grant an access level based on the IP address of the originating request. The range of IPs to allow is specified in the form of a Classless Inter-Domain Routing (CIDR) block, which allows for simple, yet fine-grained control over the IPs allowed.
A single access level can contain multiple IP ranges.
See Creating an Access Level for Corporate Network Access to learn how to create an access level that only allows access to a specified range of IP addresses (for example, those within a corporate network).
Access Context Manager uses Endpoint Verification to gather information regarding user devices, including operating system and version. You can grant an access level based on this data; for example, you might decide to grant a more permissive access level to devices running the latest version of the primary operating system deployed at your company.
Read Creating an Access Level for User Devices for more information on how to grant an access level to certain devices.
In some scenarios, you may wish to grant an access level to specific entities. In this case, the identity of the caller determines whether the condition is met.
This scenario is often used in conjunction with Service Accounts and VPC Service Controls; for example, to enable a Cloud Function to access data protected by VPC Service Controls.
You can create and manage identity-only access levels with the
gcloud command-line tool, but not with
the Google Cloud console.
Learn how to work with identities and access levels in Including Identities in Access Levels with Networks.
A single access level can contain multiple conditions. The conditions can be
evaluated using either the
OR operator. You can specify the mode when
creating or updating an access level.
AND case is the stricter (and default) option. It only grants the Access
Level if all conditions pass. For example, you might require a request come from
within the corporate network and from a device running a latest
OR is a less restrictive option. It only requires one of many conditions to be
true. This is sometimes valuable when dealing with user identities; for example,
to exclude specific entities (such as Service Accounts) from the normal
Conditions can be nested such that one condition depends on another condition. For example, if you have two access levels, "Medium" and "High" trust, you can set the requirements for "High" to require "Medium," plus some other conditions.
Nesting conditions can make managing access levels more convenient. For example, imagine your most permissive access level contains a minimum operating system version, and you set your more restrictive levels to depend on it. Now if you update the minimum version in the future, you only have to update a single condition, rather than every access level in the policy.
- Quickstart: Create an access level for Access Context Manager
- Create a basic access level
- Creating an Access Level for Corporate Network Access
- Creating an Access Level for User Devices
- Including Identities in Access Levels with Networks