Create Context-Aware access levels

1. Select Access levels.
   You see a list of defined access levels. Access levels are a shared resource between Google Workspace and Google Cloud, so you might see access levels that you didn’t create in the list. To indicate which team created an access level, consider making the platform part of the access-level name.
2. On the top right, select Create access level.
   Basic mode is selected by default. You’ll define the access level by adding one or more conditions to it. Then define each condition by specifying one or more attributes.

   Note: We recommend that you do not use the Google Cloud Platform (GCP) interface to add or modify Context-Aware access levels if you are a Workspace-only customer. If you add or change access levels using a method other than the Context-Aware access interface, this error message may result: Unsupported attributes are being used on Google Workspace, and users can be blocked.

3. Add an access level name and optional description.
4. For the access level condition you add, specify if the condition applies when users:
   • Meet attributes—Users must satisfy all the attributes in the condition.
   • Don’t meet attributes—Users don’t meet any of the attributes in the condition. This option specifies the opposite of the condition and is most frequently used for IP subnet attributes. For example, if you specify an IP subnet and “don’t meet,” only users with IP addresses outside of the specified range will match the condition.
5. Click Add Attribute to add one or more attributes to the access level condition. The attributes you can add are:
   • IP subnet—IPv4 or IPv6 address or routing prefix in CIDR block notation.
     • Private IP addresses are not supported (including user's home networks). 
     • Static IP addresses are supported.
     • To use a dynamic IP address, you must define a static IP subnet for the access level. If you know the range of the dynamic IP address and the defined static IP address in the access level covers that range, access is granted. Access is denied when the dynamic IP address is not in the defined static IP subnet. 
   • Location—Countries/regions where the user is accessing Google Workspace services. Devices with internal IP addresses are not supported because those IP addresses are not globally unique.
   • Device policy (only choose the devices policies you need to implement)—
     • Admin approval is required (if required, the device must be approved)
     • Company owned device is required
     • Screen password protected

       Note: For Windows OS, this attribute checks if the sign-in screen is displayed after an inactivity timeout, which is true if either the "Require sign-in" setting (in Sign-in options) or "On resume, display login screen" setting (in Screen saver settings), is turned on. It doesn't check whether the password is set.

     • Device encryption (Not supported, Not encrypted, Encrypted)
   • Device OS (users can only access Google Workspace with the operating systems you select. Set a minimum operating system version, or allow any version. Use the format major.minor.patch for the operating system version)—
     • macOS
     • Windows
     • Linux
     • Chrome OS
     • iOS
     • Android
   • Access level (must meet the requirements of an existing access level).
6. To add another condition to the access level, click Add condition and add attributes to it.
7. Indicate the conditions users must meet:
   • And—Users must meet the first condition and the added condition.
   • Or—Users must meet only one of the conditions.
8. When you’ve finished adding access level conditions, save the access level definition by clicking Save.
9. Choose what to do with the access level:
   • Assign this access level to apps.
   • Create a data protection rule with this access level. If you choose this option, you'll start the rule creation wizard. Learn more about combining data protection rules with Context-Aware Access levels.

Sample access level—created in Basic mode

This example shows an access level called “corp_access.” If “corp_access” is applied to Gmail, users can access Gmail only from an encrypted and company-owned device, and only from the US or Canada.

Access level name	corp_access
A user gets access if they	Satisfy all the attributes in the condition
Condition 1 attribute	Device policy    Device encryption = encrypted    Company-owned device = required
Join condition 1 and condition 2 with	AND
A user gets access if they	Satisfy all the attributes in the condition
Condition 2 attribute	Geographic origin    Countries = US, Canada

For more examples, see Context-Aware Access examples for Basic mode.

This mode allows you to create access levels that can’t be created in the Context-Aware Access interface condition builder. For example:

• The administrator might need to create access levels that include vendor conditions for third-party integrations.
• Some advanced attributes are not accessible from the Basic mode condition interface, such as the ability to use certificate-based authentication.

In this mode, you build your custom access level in an editing window using Common Expression Language (CEL). 

To define access levels using Advanced mode:

1. Select Access levels.
   You see a list of defined access levels. Access levels are a shared resource among Google Workspace, Cloud Identity, and Google Cloud, so you might see access levels that you didn’t create in the list. To indicate which team created an access level, consider making the platform part of the access-level name.
2. Select Create access level.
3. Select Advanced Mode.
4. Add an access-level name and optional description.
   You define the access level by writing a CEL expression.
5. Build your custom access level in the CEL expression editor. 
   To do so, you need some experience with CEL. For guidance and examples of supported expressions for creating custom access levels, go to the Custom access level specification .
6. Click Save.
   The expression is compiled and any syntax errors are reported.
   • If there are no syntax errors, your custom access level is saved, and you can assign it to apps.
   • If there are syntax errors, you see the message Fix errors to continue with compiler errors (in English only) specific to the expression you just created. You can correct the error and save again. When the custom access level contains no errors and is saved, you can assign this access level to apps.

Sample access level—created in Advanced mode

This example shows an access level that requires the following conditions be met in order to allow a request:

• The originating device is encrypted.
• One or more of the following is true:
  • The request originated in the United States.
  • The device that the request originated from is approved by the domain administrator.

 device.encryption_status == DeviceEncryptionStatus.ENCRYPTED && (origin.region_code in ["US"] || device.is_admin_approved_device)

For more examples, see Context-Aware Access examples for Advanced mode.