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 Trusted Cloud by S3NS, there are several ways that you can manage this kind of temporary elevated access.
IAM Conditions
You can use IAM Conditions to grant users expiring access to Trusted 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.
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
- Set up Privileged Access Manager for temporary elevated access.
- Use IAM Conditions to grant temporary access to a principal.
- Manually create short-lived credentials to impersonate a service account.