Privileged Access Manager overview

You can use Privileged Access Manager (PAM) to control 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.

To allow temporary elevation, you create an entitlement in Privileged Access Manager, and add the following attributes to it:

  • A set of principals who are allowed to request a grant against the entitlement.

  • Whether a justification is required for that grant.

  • A set of roles to temporarily grant. IAM conditions can be set on the roles.

  • The maximum duration a grant can last.

  • Optional: Whether requests need approval from a select set of principals, and whether those principals need to justify their approval.

  • Optional: Additional stakeholders to be notified about important events, such as grants and pending approvals.

A principal that's been added as a requester to an entitlement can request a grant against that entitlement. If successful, they are granted the roles listed in the entitlement until the end of the grant duration, after which the roles are revoked by Privileged Access Manager.

Use cases

To effectively use Privileged Access Manager, start by identifying specific use cases and scenarios where it can address your organization's needs. Tailor your Privileged Access Manager entitlements based on these use cases and necessary requirements and controls. This involves mapping out the users, roles, resources, and durations involved, along with any necessary justifications and approvals.

While Privileged Access Manager can be used as a general best practice to grant temporary rather than permanent privileges, here are some scenarios where it may be commonly used:

  • 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.

  • Implement granular least privilege: Assigning administrative roles or broad access to all users can increase the attack surface. To prevent this, administrators can assign least privilege permanent roles and use Privileged Access Manager to provide temporary, time-bound elevated access for specific tasks when needed. Administrators can create entitlements with tag-based conditions and enforce requesters to create grant requests with customized scope and withdraw grants after the task is completed. This significantly reduces opportunities for misuse and reinforces the principle of "just-in-time" access.

  • Automate privileged access approvals: To enhance efficiency, you can configure service accounts as approvers within your DevOps pipelines. These accounts can automate programmatic approvals by validating tickets directly from ITSM systems, thereby eliminating slow manual checks.

  • 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.

  • Mitigate insider threats and accidental misuse: With multi-party approvals, you can add two levels of approvals in decision making. This reduces the risk associated with a single administrator or a compromised approver account approving a malicious access request.

  • 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.

Capabilities and limitations

The following sections describe the different capabilities and limitations of Privileged Access Manager.

Supported resources

Privileged Access Manager supports creating entitlements and requesting grants for projects, folders, and organizations.

If you want to limit access to a subset of resources within a project, folder, or organization, you can add IAM Conditions to the entitlement. Privileged Access Manager supports all condition attributes that are supported in allow policy role bindings.

Supported roles

Privileged Access Manager supports predefined roles, custom roles, and the Admin, Writer, and Reader Basic roles. Privileged Access Manager doesn't support legacy basic roles (Owner, Editor, and Viewer).

Supported identities

Privileged Access Manager supports all types of identities, including Cloud Identity, Workforce Identity Federation, and Workload Identity Federation.

Audit logging

Privileged Access Manager events, such as creation of entitlements, requisition or review of grants, are logged to Cloud Audit Logs. For a complete list of events that Privileged Access Manager generates logs for, see the Privileged Access Manager audit logging documentation. To learn how to view these logs, see Audit entitlement and grant events in Privileged Access Manager.

Multi-level and multi-party approvals

Privileged Access Manager administrators can set up multi-level and multi-party approvals. This is useful for use cases that involve the following:

  • High-risk operations such as modifying critical infrastructure or accessing sensitive data
  • Enforcing of segregation of duties
  • Automating multi-level approval processes in dynamic workflows using service accounts as intelligent approvers

With this feature, Privileged Access Manager administrators can mandate more than one approval level per entitlement, allowing up to two levels of sequential approvals for each entitlement. Administrators can mandate up to five approvals per level. For more information, see Create entitlements.

Scope customization

Requesters can customize the scope of their grant requests to include only the specific roles and resources that they need within the scope of their entitlement. For more information, see Request temporary elevated access.

Service account approvals

Privileged Access Manager administrators can enable service accounts as eligible approvers. This lets administrators add service accounts and identities in workload identity pools as approvers when creating or modifying entitlements. For more information, see Configure Privileged Access Manager settings.

Inheritance support

Entitlements and grants that are set up at the organization- or folder-level are visible from their descendent folders and projects in the Trusted Cloud by S3NS console. Requesters can request access to the child resources based on those entitlements directly within those child resources. For more information, see Request temporary elevated access with Privileged Access Manager.

Notification preferences customization

Privileged Access Manager settings administrators can customize resource-wide notification preferences for various Privileged Access Manager events. These settings let administrators selectively disable notifications for specific events and specific personas, or disable all notifications. For more information, see Configure Privileged Access Manager settings.

Grant withdrawal

Requesters can withdraw grant requests that are pending approval or end their active grants when their privileged task is complete or when the access is no longer required. Organizations can recommend this as a best practice to limit the duration of privileged access to only the time it's actively needed. For more information, see Withdraw grants.

Grant retention

Grants are automatically deleted from Privileged Access Manager 30 days after they are denied, revoked, withdrawn, expired, or ended. Logs for grants are kept in Cloud Audit Logs for the log retention duration of the _Required bucket. To learn how to view these logs, see Audit entitlement and grant events in Privileged Access Manager.

Privileged Access Manager and IAM policy modifications

Privileged Access Manager manages temporary access by adding and removing role bindings from resources' IAM policies. If these role bindings are modified by something other than Privileged Access Manager, then Privileged Access Manager might not work as expected.

To avoid this issue, we recommend doing the following:

  • Don't manually modify role bindings that are managed by Privileged Access Manager.
  • If you use Terraform to manage your IAM policies, ensure that you're using non-authoritative resources instead of authoritative resources. This helps ensure that Terraform won't override Privileged Access Manager role bindings, even if they aren't in the declarative IAM policy configuration.

Notifications

Privileged Access Manager can notify you about various events happening in Privileged Access Manager as described in the following sections.

Email notifications

Privileged Access Manager sends emails notifications to the relevant stakeholders for an entitlement and grant changes. The sets of recipients are as follows:

  • Eligible requesters of an entitlement:

    • Email addresses of Cloud Identity users and groups specified as requesters in the entitlement.
    • Manually configured email addresses in the entitlement: When using Trusted Cloud console, these email addresses are listed in the Requester email recipients field in the Add requesters section. When using the gcloud CLI or the REST API, these email addresses are listed in the requesterEmailRecipients field.

  • Grant approvers for an entitlement:

    • Email addresses of Cloud Identity users and groups specified as approvers in the approval level.
    • Manually configured email addresses in the entitlement: When using the Trusted Cloud console, these email addresses are listed in the Approval email recipients field in the Add approvers section. When using the gcloud CLI or the REST API, these email addresses are listed in the approverEmailRecipients field of the approval workflow steps.

  • Administrator of the entitlement:

    • Manually configured email addresses in the entitlement: When using the Trusted Cloud console, these email addresses are listed in the Admin email recipients field in the Entitlement details section. When using the gcloud CLI or the REST API, these email addresses are listed in the adminEmailRecipients field.

  • Requester of a grant:

    • Email address of the grant requester if they are a Cloud Identity user.
    • Additional email addresses added by the requester while requesting the grant: When using Trusted Cloud console, these email addresses are listed in the Additional email address(es) field. When using gcloud CLI or the REST API, these email addresses are listed in the additionalEmailRecipients field.

Privileged Access Manager sends emails to these email addresses for the following events:

Recipients Event
Eligible requesters of an entitlement When the entitlement is assigned and available for use to the requester
Grant approvers for an entitlement When a grant is requested and it requires approval
Requester of a grant
  • When the grant is successfully activated or fails to be activated
  • When the grant ends
  • When the grant is denied
  • When the grant expires (it was not approved or denied within 24 hours)
  • When the grant revoked
Administrator of the entitlement
  • When the grant is successfully activated or fails to be activated
  • When the grant ends

Pub/Sub notifications

Privileged Access Manager is integrated with Cloud Asset Inventory. You can use Cloud Asset Inventory feeds feature to receive notifications about all grant changes through Pub/Sub. The asset type to use for grants is privilegedaccessmanager.googleapis.com/Grant.

What's next