This document describes how you can use context-aware access to secure differenttypes of apps and resources. Context-aware access is a security approach whereyou control users' access based on their authentication strength, deviceposture, network location, geographic location, or other attributes. Thisapproach goes beyond using basic user identities for security access, and it canhelp you implement azero-trust security model to enhance your overall security posture. For details about bestpractices, seeBest practices for securing apps and resources by using context-aware access.

To help secure your apps and Google Cloud resources, you can define granularaccess controls based on a variety and combination of contextual factors.You can use Access Context Manager to define access policies, which containaccesslevels and service parameters.

This document is intended for any security professional who's responsible forIdentity and Access Management (IAM) and the security of Google Cloud resources andapps. This document assumes that you're already familiar with Access Context Manager,Google Cloud, and IAM management.

Access levels

Access levels let you define a set of requirements that users and their devicesmust satisfy to meet a certain level of trust.

For example, you can useAccess Context Manager to configure the following access levelsfor your organization:

• Basic: A basic set of requirements that you consider to be theminimum level.
• Medium: A more stringent set of requirements that you expectemployees and corporate devices to meet. This access level might excludeextended workforce users and non-corporate devices.
• High: Strict requirements that only certain employees and devices meet.

An access level by itself doesn't have any immediate effect on users ordevices. The access level specifies requirements, but it doesn't define theusers, apps, or resources that those requirements should be enforced upon. Anaccess level is like a reusable piece of configuration that you can refer towhen you configure access to specific apps or resources.

Google Cloud lets you use access levels for several different types ofapps or resources, including the following, which are described in thisdocument:

• Google Workspace and other apps and services outside of Google Cloud
• The Google Cloud console and Google Cloud APIs
• Virtual Private Cloud (VPC) service perimeters
• Identity-Aware Proxy (IAP) for SSH and RDP access
• IAP for web apps

Apps and resources

The following sections describe how you can apply access levels to thedifferent types of apps and resources and how the processes differ across thedifferent types.

Google Workspace and other apps and services outside of Google Cloud

Apps and services outside of Google Cloud that support context-awareaccess include the following:

• Google Admin console
• Google Workspace apps such as Gmail, Google Meet, and Google Calendar
• Other Google apps such as Gemini or Looker Studio
• Custom SAML apps

To restrict access to Google Workspace and apps and services outside ofGoogle Cloud,configure context-aware access for each service or app individually in theAdmin console. In the Admin console, you do thefollowing:

• Define the scope for which you want to apply an access level. A scopeis a combination of the following:

  • A specific service or SAML app to protect.
  • An organizational unit (OU) or a group that contains relevant users.

• Select the access level to apply to the selected scope.

When you assign an access level, you can also change that access level'ssettings. You can specify that the access level only applies when users accessthe web app directly. Or, you can specify that the level also applies whenmobile apps and other apps access the API. For details, seeApp behavior based on access level settings in "Assign Context-Aware access levels to apps".

There could be more than one assignment that applies to a particular user andapp. For example, a user might be a member of theEmployees OU and a member oftheall-apac team. The respective OU and group might have different accesslevels assigned to them. In this case, Cloud Identity andGoogle Workspace apply only one of the assignments, which isthe one with the highest priority:

• Group-based assignments have a higher priority than OU-based assignments.
• Within groups, you can customize their relative priority.
• Within OUs, the root OU has the lowest relative priority.

Cloud Identity and Google Workspace let you review and analyzecontext-aware access events in theContext Aware Access log.

The Google Cloud console and Google Cloud APIs

You can configure context-aware access to the Google Cloud console andGoogle Cloud APIs by usingaccess bindings.

Google Cloud APIs use OAuth 2.0 for authentication. To use a Google CloudAPI, users need a valid, Google-issued OAuth access token, and the token must beissued for one of theGoogle Cloud OAuth scopes.Access bindings restrict users' ability to acquire such access tokens. As aresult, access bindings limit access to the Google Cloud console and toall OAuth apps that use Google Cloud OAuth scopes, like the following:

• The gcloud CLI
• Third-party tools such as Terraform
• OAuth apps that you created yourself and that use a Google Cloud OAuth scope

An access binding links a group to an access level. Each group can have onlyone access binding. Each access binding can define the followingconfigurations:

• AscopedAccessSettings listthat assigns access levels to individual OAuth apps.
• A default access level.

If an access binding specifies both a scoped access setting and a defaultaccess level, then the two access levels are combined by usingOR semantics.Then, a user needs to meet only one of the access levels to access the OAuthapp.

An access binding applies to both direct and indirect members of the group. Ifa user is a member of multiple groups, multiple access bindings could apply tothem, which could result in multiple access levels. In this case, the accesslevels are also combined by usingOR semantics, which means that the user needsto meet only one of the access levels.

Note: In this context, the evaluation of access levels and access bindingsis different from how they're evaluated in other contexts. ForCloud Identity and Google Workspace,only the access level with the highest priority is applied. Forsession length controls,only the most recently created access binding is applied.

VPC service perimeters

When youcreate a VPC service perimeter,you specify a list of restricted services. Restricted services can be accessedfrom within the service perimeter, but by default they can't be accessed from outside theservice perimeter.

To allow access from outside the service perimeter, you useingress rules.Ingress rules let you specify the conditions under which you want to allowexternal access. You can use access levels to let an ingress rule enforcecontext-aware access.

A VPC service perimeter can have multiple ingress rules. As a result, more thanone ingress rule might apply to a particular user and app, and these ingressrules might require different access levels. In this case, the access levels areevaluated usingOR semantics and the user needs to meet only one of the accesslevels.

Note: In this context, the evaluation of access levels is similar to howaccess bindings are combined by usingOR semantics forthe Google Cloud console and Google Cloud APIs.However, this behavior is different from how Cloud Identity andGoogle Workspace apply only the access level with the highestpriority.

You can combine access bindings with VPC service perimeter ingress rules. Ifthe access bindings and ingress rules specify different access levels for aparticular user and app, then the levels are combined by usingAND semantics. Inthat case, the user must meet both access levels.

To review and analyze the attempts to access resources in a VPC serviceperimeter, you can use theVPC Service Controls audit logs orVPC Service Controls violation analyzer.

SSH and RDP access to VMs

You can configure context-aware access for SSH and RDP access to VMs by usingIAP TCP forwarding.

IAP TCP forwarding supports access bindings and VPC serviceperimeter ingress rules. Your access bindings for the Google Cloud consoleand Cloud APIs automatically apply to IAP TCP forwarding.

If your service perimeter includes theiaptunnel.googleapis.com service as a restricted service, then your ingress rulesautomatically apply to IAP TCP forwarding. For details about bestpractices, seeInclude IAP TCP forwarding as a restricted service.

You can also configure context-aware access by using IAMconditions. You can use IAM conditions as an alternative toaccess bindings and VPC service perimeter ingress rules, or use all of themtogether.

• Grant a user or group the IAP-secured Tunnel User role(roles/iap.tunnelResourceAccessor). Then, in the role binding, add anIAM condition expression that requires the user to meet acertain access level. For example, the expression could look similar to thefollowing:

  "accessPolicies/123/accessLevels/fully-trusted"inrequest.auth.access_levels

• Optionally, you can customize the IAM condition torequire multiple access levels or to include other checks.

A particular user and app can be subject to an access binding,an ingress rule, and an IAM condition when the user and appaccess IAP TCP forwarding. In this scenario, access levels arecombined by usingAND semantics and the user must meet all of the accesslevels.

To review and analyze the attempts to access IAP TCP forwarding,you mustenable data access audit logs for IAP.

Web apps

You can configure context-aware access for web appsby using IAP.

IAP for web apps differs from its IAP TCPforwarding counterpart:

• Access bindings don't apply to web apps that are configured withIAP because the OAuth app that IAP usesdoesn't use any Google Cloud OAuth scopes.
• VPC service perimeter ingress rules don't apply to web apps that areconfigured with IAP because IAP isn't aGoogle Cloud API and it can't be configured as a restricted service.

To configure context-aware access for web apps by using IAP, youmust use IAM conditions:

• Grant a user or group the IAP-secured Web App User role(roles/iap.httpsResourceAccessor). Then, in the role binding, add anIAM condition expression that requires the user to meet acertain access level. For example, the expression could look similar to thefollowing:

  "accessPolicies/123/accessLevels/fully-trusted"inrequest.auth.access_levels

• Optionally, you can customize the IAM condition torequire multiple access levels or to include other checks.

To review and analyze the attempts to access web apps that are configured withIAP, you mustenable data access audit logs for IAP.

Note: You can't use context-aware access forinstances that use external identities.

What's Next?

• Best practices for securing apps and resources by using context-aware access.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Author:Johannes Passing | Cloud Solutions Architect

Other contributor:Ido Flatow | Cloud Solutions Architect