Manage access bindings
Stay organized with collections
Save and categorize content based on your preferences.
This page explains how to manage your existing access bindings, which define how
access policies are applied to your user groups. You can view, modify, and
delete these bindings as needed. Access bindings determine how access levels and
session controls are applied to a user group.
After the access bindings are created for a group of users, access to the
Google Cloud console and Google Cloud APIs are controlled based
on satisfaction of the bound access level.
You can view the details of the access binding that you created, edit it, or
delete it.
ACCESS_BINDING is in the form
organizations/ORG_ID/gcpUserAccessBindings/ACCESS_BINDING_NAME.
BINDING_FILE_PATH: The path to the YAML file that contains the access binding scheme.
The binding file supports only scopedAccessSettings.
DEFAULT_ACCESS_LEVEL: The optional access level name, which takes the form
accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Replace POLICY_ID
with the access policy ID, and ACCESS_LEVEL_NAME with the access level name.
DEFAULT_DRY_RUN_ACCESS_LEVEL_2: An optional access level name in the form
`accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME`.
Include this flag to apply the specified dry run access level to all applications by default if
they aren't specified in the YAML.
DEFAULT_SESSION_LENGTH: The optional session duration in the hour format,
such as 15h for 15 hours, or 2h for two hours.
DEFAULT_SESSION_REAUTH_METHOD: The optional method to challenge users to re-verify their
identity, which must be one of the following:
LOGIN: Apply the standard login, which can include MFA or other
Workspace-defined factors.
PASSWORD: Only require a password, even if other factors are defined. If passwords
are managed using an external IdP, users are redirected to the IdP. If the IdP session is live,
users are implicitly re-authenticated. If the IdP is not live, users must sign in through the IdP.
SECURITY_KEY: Require a hardware security key.
How the --level and --binding-file arguments work together
If you only use --binding-file, only the applications in the file
have the policies applied.
If you only use --level, the access level applies to all applications.
If you use both, the rules are combined. The --level
value applies to all applications, whereas the policies in the YAML file
specified by --binding-file only apply to the applications as defined
in the file.
Working with session controls
To set default session controls for all applications, use
--session-length and --session-reauth-method.
If you also define session controls in the YAML file, those session
controls override the default settings for those specific
applications.
You must use --session-length and --session-reauth-method
together.
To remove a default access level or a default dry run access level, provide an
empty string, such as --level= or --dry-run-level=. When these arguments
are not provided, the update command won't make any changes.
To remove a session control, set --session-length=0.
DEFAULT_ACCESS_LEVEL: The optional access level name, which takes the form
accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Replace POLICY_ID
with the access policy ID, and ACCESS_LEVEL_NAME with the access level name.
CLIENT_ID: The OAuth client ID. You must use clientId when
an application contains sessionSettings.
ACCESS_LEVEL_A: An access level name in the format
accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
SESSION_LENGTH: The session duration using ISO 8601 duration
format, such as 30m for 30 minutes, or 2h for
two hours.
SESSION_REAUTH_METHOD: The optional method to challenge users
to re-verify their identity, which must be one of the following:
LOGIN: Apply the standard login, which can include MFA or other
Workspace-defined factors.
PASSWORD: Only require a password, even if other factors are
defined. If passwords are managed using an external IdP, users are
redirected to the IdP. If the IdP session is live, users are implicitly
re-authenticated. If the IdP is not live, users must sign in through the
IdP.
SECURITY_KEY: Require a hardware security key.
CLIENT_NAME: The client name. If the application contains
sessionSettings, you cannot use the client name. Instead, use the
OAuth client ID.
ACCESS_LEVEL_C: An access level name in the format
accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
ACCESS_BINDING is in the form
organizations/ORG_ID/gcpUserAccessBindings/ACCESS_BINDING_NAME.
FIELD_MASK: A required, comma-separated list of fields that
you want to update. This tells the API which parts of the access binding
to modify.
fieldMask should contain the top-level JSON keys in the request body
that you want to update, which can contain accessLevels,
dryRunAccessLevels, and scopedAccessSettings.
If successful, you should receive a representation of the JSON object.
If there is a problem, you receive an error message.
Delete access bindings
Console
In the Google Cloud console, go to the Access Context Manager page.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-09 UTC."],[],[]]