Temporary elevated access overview

One way to protect sensitive resources is to limit access to them. However, limiting access to sensitive resources also creates friction for anyone who occasionally needs to access those resources. For example, a user might need break-glass, or emergency, access to sensitive resources to resolve an incident.

In these situations, we recommend giving the user permission to access the resource temporarily. We also recommend that, to improve auditing, you record the user's justification for accessing the resource.

In Google Cloud, there are several ways that you can manage this kind of temporary elevated access.

Privileged Access Manager

You can use Privileged Access Manager (PAM) to manage just-in-time temporary privilege elevation for select principals, and to view audit logs afterwards to find out who had access to what and when.

You might want to provide temporary privilege elevation through Privileged Access Manager in the following situations:

  • Grant emergency access: Allow select emergency responders to perform critical tasks without having to wait for approval. You can mandate justifications for additional context on why the emergency access is needed.

  • Control access to sensitive resources: Tightly control access to sensitive resources, requiring approvals and business justifications. Privileged Access Manager can also be used to audit how this access was used—for example, when granted roles were active for a user, which resources were accessible during that time, the justification for access, and who approved it.

    For example, you can use Privileged Access Manager to do the following:

    • Give developers temporary access to production environments for troubleshooting or deployments.

    • Give support engineers access to sensitive customer data for specific tasks.

    • Give database administrators elevated privileges for maintenance or configuration changes.

  • Help secure service accounts: Instead of permanently granting roles to service accounts, allow service accounts to self-elevate and assume roles only when needed for automated tasks.

  • Manage access for contractors and extended workforce: Grant contractors or members of the extended workforce temporary, time-bound access to resources, with approvals and justifications required.

For more information on setting up Privileged Access Manager, see Privileged Access Manager overview.

For more information on requesting temporary elevation, see Request temporary elevated access.

Google groups

One way to manage temporary elevated access is to grant a Google group access to sensitive resources, then add and remove users from that group to control their access.

To set up a Google group for temporary elevated access, first create a group, then grant it the roles that you want to temporarily give to users. If you use deny policies, also consider making the group exempt from any relevant deny rules to avoid unexpected denials.

After you set up your group, you can add and remove users to modify their access. If you use the Google Groups API, you can temporarily add users to a group by using membership expiration.

If you want to record the user's justifications for accessing sensitive resources, you must define your own operational processes and tooling.

For example, to manage emergency access to Compute Engine resources, you could create a group, emergency-compute-access@example.com, and grant it the Compute Admin role (roles/compute.admin). If a user needs emergency administrative access to compute resources, you can add them to the emergency-compute-access@example.com group. After the emergency is resolved, you can remove them from the group.

IAM Conditions

You can use IAM Conditions to grant users expiring access to Google Cloud resources. For more information, see Configure temporary access.

If you want to record the user's justifications for accessing sensitive resources, you must define your own operational processes and tooling.

Expired role bindings aren't automatically removed from your allow policies. To ensure that your allow policies don't exceed the maximum size for allow policies, we recommend periodically removing expired role bindings.

Deny policies don't support time-based conditions. As a result, you can't use conditions in deny policies to temporarily exempt a user from a deny rule.

Just-in-time privileged access

Just-In-Time Access is an open source application that uses IAM Conditions to grant users just-in-time privileged access to Google Cloud resources. This application is designed to run on App Engine or Cloud Run.

This application has the following benefits over manually adding conditional role bindings:

  • Users can search for roles that they can activate with Just-In-Time Access.
  • Users are required to provide justifications before getting access.
  • The application replaces the existing conditional binding instead of creating new bindings, which helps maintain your IAM allow policy size.

For more information about Just-In-Time Access, see Manage just-in-time privileged access to projects.

Service account impersonation

When an authenticated principal, such as a user or another service account, authenticates as a service account to gain the service account's permissions, it's called impersonating the service account. Impersonating a service account lets an authenticated principal access whatever the service account can access. Only authenticated principals with the appropriate permissions can impersonate service accounts.

To set up a service account for temporary elevated access, create the service account, then grant it the roles that you want to temporarily give to a user. If you use deny policies, also consider adding the service account exempt from any relevant deny rules to avoid unexpected denials.

After you set up the service account, you can give users temporary elevated access by letting them impersonate the service account. There are several ways you can let users impersonate service accounts:

  • Grant users a role that lets them create short-lived credentials for the service account. Users can then use the short-lived credentials to impersonate the service account.

    • Grant the Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) to let the user create short-lived OpenID Connect (OIDC) ID tokens for the service account.

    • Grant the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) to let the user create the following types of service account credentials:

      • OAuth 2.0 access tokens, which you can use to authenticate with Google APIs
      • OIDC ID tokens
      • Signed JSON Web Tokens (JWTs) and binary blobs

    If you grant a user one of these roles, they can impersonate the service account at any time to elevate their own access. However, they're less likely to access or modify sensitive resources unintentionally.

    To learn how to impersonate service accounts, see Use service account impersonation.

  • Create a token broker service that gives users short-lived credentials for the service account after they authenticate and provide a justification. Users can then use the short-lived credentials to impersonate the service account.

    With this method, you can decide when to let users impersonate the service account.

    To learn how to generate short-lived credentials, see Create short-lived credentials for a service account.

To learn more about service account impersonation, see Service account impersonation.

What's next