[[["易于理解","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-09-04。"],[[["\u003cp\u003ePrivileged Access Manager (PAM) allows for temporary privilege elevation for specific users, with detailed audit logs showing who accessed what and when.\u003c/p\u003e\n"],["\u003cp\u003ePAM uses entitlements to define who can request temporary access, what roles are granted, the duration of the access, and whether approvals or justifications are needed.\u003c/p\u003e\n"],["\u003cp\u003ePAM is useful in various scenarios, including granting emergency access, controlling access to sensitive resources, securing service accounts, and managing access for contractors.\u003c/p\u003e\n"],["\u003cp\u003ePAM supports various resources, roles, and identities, and it automatically manages the temporary addition and removal of role bindings in IAM policies.\u003c/p\u003e\n"],["\u003cp\u003ePAM sends email notifications to relevant stakeholders about entitlement and grant changes, and integrates with Cloud Asset Inventory to provide notifications about all grant changes through Pub/Sub.\u003c/p\u003e\n"]]],[],null,["# Privileged Access Manager overview\n\nYou can use Privileged Access Manager (PAM) to control just-in-time temporary privilege\nelevation for select principals, and to [view audit logs](/iam/docs/pam-audit-entitlement-events)\nafterwards to find out who had access to what and when.\n\nTo allow temporary elevation, you [create an *entitlement*](/iam/docs/pam-create-entitlements)\nin Privileged Access Manager, and add the following attributes to it:\n\n- A set of principals who are allowed to request a grant against the\n entitlement.\n\n- Whether a justification is required for that grant.\n\n- A set of [roles](/iam/docs/roles-overview) to temporarily grant.\n [IAM conditions](/iam/docs/conditions-overview) can be set on\n the roles.\n\n- The maximum duration a grant can last.\n\n- Optional: Whether requests need [approval from a select set of principals](/iam/docs/pam-approve-deny-grants),\n and whether those principals need to justify their approval.\n\n- Optional: Additional stakeholders to be notified about important events,\n such as grants and pending approvals.\n\nA principal that's been added as a requester to an entitlement can\n[request a grant against that entitlement](/iam/docs/pam-request-temporary-elevated-access).\nIf successful, they are granted the roles listed in the entitlement\nuntil the end of the grant duration, after which the roles are revoked by\nPrivileged Access Manager.\n\nUse cases\n---------\n\nTo effectively use Privileged Access Manager, start by identifying specific use cases\nand scenarios where it can address your organization's needs. Tailor your\nPrivileged Access Manager entitlements based on these use cases and necessary\nrequirements and controls. This involves mapping out the users, roles,\nresources, and durations involved, along with any necessary justifications and\napprovals.\n\nWhile Privileged Access Manager can be used as a general best practice to grant\ntemporary rather than permanent privileges, here are some scenarios where it may\nbe commonly used:\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\nCapabilities and limitations\n----------------------------\n\nThe following sections describe the different capabilities and limitations of\nPrivileged Access Manager.\n\n### Supported resources\n\nPrivileged Access Manager supports creating entitlements and requesting grants for\nprojects, folders, and organizations.\n\nIf you want to limit access to a subset of resources within a project, folder,\nor organization, you can add [IAM\nConditions](/iam/docs/conditions-overview) to the entitlement.\nPrivileged Access Manager supports all condition attributes that are supported\nin allow policy role bindings.\n| **Note:** In Privileged Access Manager entitlements, using conditions that check the [tags](/iam/docs/tags-access-control#control-access) for a resource is in [preview](/products#product-launch-stages).\n\n### Supported roles\n\nPrivileged Access Manager supports [predefined roles](/iam/docs/roles-overview#predefined),\n[custom roles](/iam/docs/roles-overview#custom), and the Admin, Writer, and\nReader [Basic roles](/iam/docs/roles-overview#basic). Privileged Access Manager\ndoesn't support [legacy basic roles](/iam/docs/roles-overview#legacy-basic)\n(Owner, Editor, and Viewer).\n\n### Supported identities\n\nPrivileged Access Manager supports all types of identities, including\n[Cloud Identity](/identity/docs),\n[Workforce Identity Federation](/iam/docs/workforce-identity-federation),\nand [Workload Identity Federation](/iam/docs/workload-identity-federation).\n\n### Audit logging\n\nPrivileged Access Manager events, such as creation of entitlements, requisition or\nreview of grants, are logged to [Cloud Audit Logs](/logging/docs/audit). For\na complete list of events that Privileged Access Manager generates logs for,\nsee the [Privileged Access Manager audit logging\ndocumentation](/iam/docs/audit-logging/audit-logging-pam). To learn\nhow to view these logs, see [Audit entitlement and grant events in\nPrivileged Access Manager](/iam/docs/pam-audit-entitlement-events).\n\n### Grant retention\n\nGrants are automatically deleted from Privileged Access Manager\n30 days after they are denied, revoked, or have expired\nor ended. Logs for grants are kept in Cloud Audit Logs for the\n[log retention duration of the `_Required` bucket](/logging/quotas#logs_retention_periods).\nTo learn how to view these logs, see\n[Audit entitlement and grant events in Privileged Access Manager](/iam/docs/pam-audit-entitlement-events).\n\n### Privileged Access Manager and IAM policy modifications\n\nPrivileged Access Manager manages temporary access by adding and removing\n[role bindings](/iam/docs/allow-policies#structure) from resources' IAM\npolicies. If these role bindings are modified by something other than\nPrivileged Access Manager, then Privileged Access Manager might not work as expected.\n\nTo avoid this issue, we recommend doing the following:\n\n- Don't manually modify role bindings that are managed by Privileged Access Manager.\n- If you use [Terraform](https://www.terraform.io/) to manage your IAM policies, ensure that you're using [non-authoritative resources](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam) instead of authoritative resources. This ensures that Terraform won't override Privileged Access Manager role bindings, even if they aren't in the declarative IAM policy configuration.\n\nNotifications\n-------------\n\nPrivileged Access Manager can notify you about various events happening in\nPrivileged Access Manager as described in the following sections.\n\n### Email notifications\n\nPrivileged Access Manager sends emails notifications to the relevant stakeholders\nfor an entitlement and grant changes. The sets of recipients are as follows:\n\n- **Eligible requesters of an entitlement**:\n\n - Email addresses of Cloud Identity users and [groups](/identity/docs/groups) specified as requesters in the entitlement\n - Manually configured email addresses in the entitlement: When using Google Cloud console, these email addresses are listed in the **Notify about an eligible entitlement** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `requesterEmailRecipients` field.\n- **Grant approvers for an entitlement**:\n\n - Email addresses of Cloud Identity users and groups specified as approvers in the entitlement.\n - Manually configured email addresses in the entitlement: When using the Google Cloud console, these email addresses are listed in the **Notify when a grant is pending approval** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `approverEmailRecipients` field of the approval workflow steps.\n- **Administrator of the entitlement**:\n\n - Manually configured email addresses in the entitlement: When using the Google Cloud console, these email addresses are listed in the **Notify when access is granted** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `adminEmailRecipients` field.\n- **Requester of a grant**:\n\n - Email address of the grant requester if they are a Cloud Identity user.\n - Additional email addresses added by the requester while requesting the grant: When using Google Cloud console, these email addresses are listed in the **Email addresses to receive updates about this grant** field. When using gcloud CLI or the REST API, these email addresses are listed in the `additionalEmailRecipients` field.\n\nPrivileged Access Manager sends emails to these email addresses for the following\nevents:\n\n### Pub/Sub notifications\n\nPrivileged Access Manager is integrated with [Cloud Asset Inventory](/asset-inventory/docs/overview).\nYou can use [Cloud Asset Inventory feeds](/asset-inventory/docs/monitoring-asset-changes)\nfeature to receive notifications about all grant changes through\nPub/Sub. The asset type to use for grants is\n`privilegedaccessmanager.googleapis.com/Grant`.\n\nWhat's next\n-----------\n\n- [Privileged Access Manager permissions and setup](/iam/docs/pam-permissions-and-setup)"]]