[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-21。"],[[["\u003cp\u003eTemporary access to sensitive resources can be managed through several methods, including Privileged Access Manager, Google groups, IAM Conditions, Just-In-Time Access, and service account impersonation.\u003c/p\u003e\n"],["\u003cp\u003ePrivileged Access Manager (PAM) allows for just-in-time privilege elevation, requires justifications, and provides audit logs to track temporary access.\u003c/p\u003e\n"],["\u003cp\u003eGoogle groups can be utilized to manage temporary elevated access by adding and removing users, with optional membership expiration and requiring external tooling to record justifications.\u003c/p\u003e\n"],["\u003cp\u003eIAM Conditions enable time-bound access to resources, but justifications and removal of expired role bindings must be managed separately.\u003c/p\u003e\n"],["\u003cp\u003eJust-in-time access is an open-source solution that provides temporary access, requires users to justify the need, and replaces existing bindings to keep IAM allow policy within size constraints.\u003c/p\u003e\n"]]],[],null,["# Temporary elevated access overview\n\nOne way to protect sensitive resources is to limit access to them. However,\nlimiting access to sensitive resources also creates friction for anyone who\noccasionally needs to access those resources. For example, a user might need\nbreak-glass, or emergency, access to sensitive resources to resolve an incident.\n\nIn these situations, we recommend giving the user permission to access the\nresource temporarily. We also recommend that, to improve auditing, you record\nthe user's justification for accessing the resource.\n\nIn Google Cloud, there are several ways that you can manage this kind of\ntemporary elevated access.\n\nPrivileged Access Manager\n-------------------------\n\nYou can use Privileged Access Manager (PAM) to manage just-in-time temporary privilege\nelevation for select principals, and to view audit logs afterwards to find out\nwho had access to what and when.\n\nYou might want to provide temporary privilege elevation through\nPrivileged Access Manager in the following situations:\n\n- **Grant emergency access**: Allow select emergency responders to perform critical\n tasks without having to wait for approval. You can mandate justifications for\n additional context on why the emergency access is needed.\n\n- **Control access to sensitive resources**: Tightly control access to sensitive\n resources, requiring approvals and business justifications. Privileged Access Manager\n can also be used to audit how this access was used---for example, when\n granted roles were active for a user, which resources were accessible during\n that time, the justification for access, and who approved it.\n\n For example, you can use Privileged Access Manager to do the following:\n - Give developers temporary access to production environments for\n troubleshooting or deployments.\n\n - Give support engineers access to sensitive customer data for specific\n tasks.\n\n - Give database administrators elevated privileges for maintenance or\n configuration changes.\n\n- **Help secure service accounts**: Instead of permanently granting roles to\n service accounts, allow service accounts to self-elevate and assume roles only\n when needed for automated tasks.\n\n- **Manage access for contractors and extended workforce**: Grant contractors or\n members of the extended workforce temporary, time-bound access to resources,\n with approvals and justifications required.\n\nFor more information on setting up Privileged Access Manager, see\n[Privileged Access Manager overview](/iam/docs/pam-overview).\n\nFor more information on requesting temporary elevation, see\n[Request temporary elevated access](/iam/docs/pam-request-temporary-elevated-access).\n\nGoogle groups\n-------------\n\nOne way to manage temporary elevated access is to grant a Google group access\nto sensitive resources, then add and remove users from that group to control\ntheir access.\n\nTo set up a Google group for temporary elevated access, first [create a\ngroup](https://support.google.com/groups/answer/2464926), then grant it the roles that you want to temporarily give\nto users. If you use [deny policies](/iam/docs/deny-overview), also consider making the\ngroup [exempt from any relevant deny rules](/iam/docs/deny-overview#deny-rules) to\navoid unexpected denials.\n\nAfter you set up your group, you can add and remove users to modify their\naccess. If you use the Google Groups API, you can temporarily add users to a\ngroup by using [membership expiration](/identity/docs/how-to/manage-expirations).\n\nIf you want to record the user's justifications for accessing sensitive\nresources, you must define your own operational processes and tooling.\n\nFor example, to manage emergency access to Compute Engine resources, you could\ncreate a group, `emergency-compute-access@example.com`, and grant it the Compute\nAdmin role (`roles/compute.admin`). If a user needs emergency administrative\naccess to compute resources, you can add them to the\n`emergency-compute-access@example.com` group. After the emergency is resolved,\nyou can remove them from the group.\n\nIAM Conditions\n--------------\n\nYou can use IAM Conditions to grant users expiring access to\nGoogle Cloud resources. For more information, see [Configure temporary\naccess](/iam/docs/configuring-temporary-access).\n\nIf you want to record the user's justifications for accessing sensitive\nresources, you must define your own operational processes and tooling.\n\nExpired role bindings aren't automatically removed from your allow policies.\nTo ensure that your allow policies don't exceed the maximum size for allow\npolicies, we recommend periodically removing expired role bindings.\n\nDeny policies don't support time-based conditions. As a result, you can't use\nconditions in deny policies to temporarily exempt a user from a deny rule.\n\nJust-in-time privileged access\n------------------------------\n\nJust-In-Time Access is an open source application that uses IAM\nConditions to grant users just-in-time privileged access to Google Cloud\nresources. This application is designed to run on\nApp Engine or Cloud Run.\n\nThis application has the following benefits over manually adding conditional\nrole bindings:\n\n- Users can search for roles that they can activate with Just-In-Time Access.\n- Users are required to provide justifications before getting access.\n- The application replaces the existing conditional binding instead of creating new bindings, which helps maintain your IAM allow policy size.\n\nFor more information about Just-In-Time Access, see [Manage just-in-time\nprivileged access to projects](/architecture/manage-just-in-time-privileged-access-to-project).\n| **Note:** The Just-In-Time Access application can't give a user access if they've been [explicitly denied](/iam/docs/deny-overview).\n\nService account impersonation\n-----------------------------\n\n\nWhen an authenticated principal, such as a user or another service account, authenticates as a\nservice account to gain the service account's permissions, it's called *impersonating* the\nservice account. Impersonating a service account lets an authenticated principal access whatever\nthe service account can access. Only authenticated principals with the appropriate permissions can\nimpersonate service accounts.\n\nTo set up a service account for temporary elevated access, [create the service\naccount](/iam/docs/service-accounts-create), then grant it the roles that you want to\ntemporarily give to a user. If you use [deny policies](/iam/docs/deny-overview), also\nconsider adding the service account [exempt from any relevant deny\nrules](/iam/docs/deny-overview#deny-rules) to avoid unexpected denials.\n\nAfter you set up the service account, you can give users temporary elevated\naccess by letting them [impersonate the service\naccount](/iam/docs/service-account-impersonation). There are several ways you can let users\nimpersonate service accounts:\n\n- Grant users a role that lets them create short-lived credentials\n for the service account. Users can then use the short-lived\n credentials to impersonate the service account.\n\n - Grant the [Service Account OpenID Connect Identity Token Creator\n role](/iam/docs/service-account-permissions#id-token-creator-role)\n (`roles/iam.serviceAccountOpenIdTokenCreator`) to let the user create\n short-lived OpenID Connect (OIDC) ID tokens for the service account.\n\n - Grant the [Service Account Token Creator\n role](/iam/docs/service-account-permissions#token-creator-role)\n (`roles/iam.serviceAccountTokenCreator`) to let the user create the\n following types of service account credentials:\n\n - OAuth 2.0 access tokens, which you can use to authenticate with Google APIs\n - OIDC ID tokens\n - Signed JSON Web Tokens (JWTs) and binary blobs\n\n If you grant a user one of these roles, they can impersonate the service\n account *at any time* to elevate their own access. However, they're less\n likely to access or modify sensitive resources unintentionally.\n\n To learn how to impersonate service accounts, see [Use service account\n impersonation](/docs/authentication/use-service-account-impersonation).\n- Create a token broker service that gives users [short-lived\n credentials](/iam/docs/service-account-creds#short-lived-credentials) for the service account after they\n authenticate and provide a justification. Users can then use the short-lived\n credentials to impersonate the service account.\n\n With this method, you can decide when to let users impersonate the service\n account.\n\n To learn how to generate short-lived credentials, see [Create short-lived\n credentials for a service account](/iam/docs/create-short-lived-credentials-direct).\n\nTo learn more about service account impersonation, see [Service account\nimpersonation](/iam/docs/service-account-impersonation).\n\nWhat's next\n-----------\n\n- Set up Privileged Access Manager for [temporary elevated access](/iam/docs/pam-overview).\n- Use IAM Conditions to [grant temporary access](/iam/docs/configuring-temporary-access) to a principal.\n- Deploy the [Just-In-Time Access application](/architecture/manage-just-in-time-privileged-access-to-project).\n- [Manually create short-lived credentials](/iam/docs/create-short-lived-credentials-direct) to impersonate a service account."]]
