Most Google Cloud organisations still hand out powerful roles as permanent IAM bindings, so a single stolen session or key carries standing admin rights at all hours. Google Cloud Privileged Access Manager (PAM) replaces those standing bindings with entitlements: policies that let named principals request a role for a bounded time, optionally with approval, and that PAM removes automatically when the grant ends. This guide explains how entitlements and grants work, how to design them, what to log and measure, and how to roll PAM out without breaking operations. It is written for cloud platform, IAM and security engineers who run Google Cloud organisations, folders and projects.
This is an independent guide from NHI Mgmt Group, based on Google Cloud's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google Cloud's current documentation.
Key takeaways
- Entitlements are the policy, grants are the event. An entitlement defines who may ask, which roles they get, for how long and who approves; a grant is one approved, time-boxed use of it.
- PAM works by editing allow policies. It adds role bindings with time-based IAM Conditions and removes them at the end, so anything else that rewrites those bindings (a manual edit, an authoritative Terraform resource) can break it.
- Creating an entitlement does not remove standing access. You must delete the permanent bindings separately, or the entitlement is just paperwork.
- Some roles defeat the time limit. A temporary role that carries setIamPolicy or iam.roles.update lets the holder write themselves a permanent binding, so keep those out of entitlements or pair them with tight approval and alerting.
- Every lifecycle step is logged. Grant requests, approvals, denials and revocations are Admin Activity audit logs under privilegedaccessmanager.googleapis.com, and activation and expiry appear as system events, which gives you a clean detection and reporting feed.
How Privileged Access Manager works
PAM is part of Google Cloud IAM. It controls just in time, temporary privilege elevation for selected principals and records who had access to what and when. The model has two objects. See the JIT Access Guide for the vendor-neutral concepts behind it.
- Entitlement: created at organisation, folder or project level. It lists eligible requesters, the roles to grant (with optional IAM Conditions), the maximum grant duration, whether the requester must give a justification, optional approvers and whether they must justify their decision, and extra people to notify.
- Grant: a request made against an entitlement by an eligible requester. Once approved (or immediately, if the entitlement allows activation without approval), PAM applies the roles for the requested duration and then removes them.
- Service agent: PAM acts through the organisation-level service agent
service-org-ORGANIZATION_NUMBER@gcp-sa-pam.iam.gserviceaccount.com, which holds the Privileged Access Manager Service Agent role. Folder and project-level agents are not used. - Inheritance: roles granted at a folder or organisation flow down the resource hierarchy, exactly as permanent bindings do, so an organisation-level entitlement is very broad.
Because PAM changes access through ordinary allow policy bindings, grants follow normal IAM access change propagation: access does not appear or disappear instantly, and users should expect a short delay after the status moves from Activating to Active.
Entitlement design: limits and settings
The table lists the entitlement settings documented by Google Cloud and the decisions each one forces.
| Setting | Documented limit or behaviour | Design decision |
|---|---|---|
| Scope | Organisation, folder or project; child resources inherit | Create at the lowest level that does the job; reserve organisation entitlements for platform admins |
| Roles | Up to 30 per entitlement; predefined or custom roles on services that support IAM Conditions; basic Admin, Writer and Reader roles allowed; legacy Owner, Editor and Viewer not supported; service agent roles not allowed | Build task-shaped custom roles rather than stacking many predefined roles |
| IAM Conditions on roles | Supported, apply only while the grant is active; access level attributes not supported | Narrow to a resource name prefix or tag where possible |
| Maximum grant duration | 30 minutes to 168 hours (seven days) through gcloud or REST | Default to one to four hours for operations work; longer only for scheduled projects |
| Requesters | Up to 20 principals; any type except allUsers and allAuthenticatedUsers; group members can request but only the individual gets access | Use groups, not individuals, so joiners and leavers are handled in the directory |
| Requester justification | Optional, free text | Require it and ask for a ticket or incident reference |
| Approval | Optional ("Activate access without approvals"); up to 20 approvers per level | Require approval for production write and IAM-changing roles |
| Multi-level approval | Preview: up to two sequential levels and up to five approvals per level; needs Security Command Center Premium or Enterprise | Use for organisation-wide or break-glass style entitlements |
| Approver justification | Optional | Require it for high-impact entitlements so denials and approvals are explained in the record |
| Notifications | Email to requesters, approvers, admins; extra addresses allowed | Add a team mailbox; allow-list [email protected] |
| Name | 4 to 63 characters, starts with a lowercase letter, lowercase letters, numbers and hyphens only | Adopt a pattern such as prod-gke-admin-4h |
Roles to keep out, or to guard closely
Google Cloud's documentation warns that roles containing setIamPolicy or iam.roles.update (for example Role Administrator) let a requester keep permanent access after the grant expires, because they can add their own binding while elevated. Treat these as the most sensitive entitlements: require two approvers, keep the duration short, and alert on any SetIamPolicy call made by a principal during an active grant. The same reasoning applies to roles that can create service account keys or impersonate service accounts, which can mint credentials that outlive the grant. See the Google Cloud IAM and Service Accounts Guide and the Google Cloud Service Account Keys Security Guide.
Requests, approvals and the grant lifecycle
A requester can only request against entitlements they have been added to. The request carries a duration within the entitlement maximum, a justification if required, optional extra email recipients and, in Preview, a scheduled activation time up to seven days ahead. Google documents a limit of 10 open grants per entitlement per user (Active, Scheduled or Approval awaited) with no duplicate scopes among them.
- Request: in the console, or with
gcloud pam grants create(Google's examples show the alpha release track) using--entitlement,--requested-duration,--justificationand--location=global. - Approve or deny: approvers are notified by email. A request for immediate activation must be decided within 24 hours, or before the scheduled time, or it becomes Expired. With two levels, second-level approvers are only notified once the first level completes, and any denial ends the request.
- Activate: PAM adds the bindings with a time-based condition. The grant moves through Activating to Active.
- End: the grant ends when its duration runs out (Expired or Ended), when the requester withdraws or ends it early (Preview), or when an administrator revokes it.
- Revoke: any principal with
privilegedaccessmanager.grants.revokecan revoke an active grant withgcloud pam grants revoke GRANT_ID --entitlement=ENTITLEMENT_ID --reason="..." --location=global. A reason is mandatory and stored in the grant timeline. The console also offers "Revoke all grants" on an entitlement, which is your fastest containment action. - Retention: grants are deleted from PAM 30 days after they are denied, revoked, withdrawn, expired or ended; the audit log entries remain in Cloud Audit Logs for the retention period of the
_Requiredbucket.
One configuration trap is worth calling out: if a group is an approver, the number of required approvals must not exceed the number of group members, or grants stay stuck in "approval awaited".
Choosing an approval model
| Model | Fits | Trade-off |
|---|---|---|
| Self-activation, no approval, justification required | Read-heavy diagnostic roles, low-impact project writes, on-call engineers at night | Fast, still removes standing access and leaves an audit trail; relies on detection rather than prevention |
| Single approver from a peer group | Production writes, GKE cluster admin, database admin | Two-person rule with little friction; needs approver cover across time zones |
| Two-level approval (Preview, SCC Premium or Enterprise) | Organisation Admin, Security Admin, roles that change IAM or KMS | Strongest separation of duties; slowest, so pair with a documented break-glass path |
| Automated approval by a service account or agent identity (Preview) | Approvals driven by a ticketing or change system that checks an open change record | Removes human delay but turns the approving workload into a privileged identity that must be secured itself |
Small organisations: start with a handful of project-level entitlements, self-activation with justification, and an alert on every grant. Large organisations: manage entitlements as code per folder, use approver groups per business unit, and keep organisation-level entitlements to a very small platform team. Whatever the size, keep one or two break-glass accounts outside PAM so a PAM or IdP failure cannot lock everyone out. See the Break-Glass Account Guide.
Implementation: a phased rollout
- Inventory standing privilege. List every principal holding Owner, Editor, IAM admin, Security Admin, KMS admin and service account admin roles at organisation, folder and project level. Policy Analyzer and the IAM recommender are useful here; the Cloud IAM Review Checklist gives a review structure.
- Set up PAM. Open the Privileged Access Manager page, choose the resource, click "Set up PAM" and grant the service agent its role. If you use IAM deny policies, add the service agent to
exceptionPrincipals; if you use VPC Service Controls, add it to an access level or ingress rule. The administrator needs Privileged Access Manager Admin (roles/privilegedaccessmanager.admin) plus Security Admin, Folder IAM Admin or Project IAM Admin at the matching scope. - Design task roles. Replace Owner and Editor with custom roles shaped around real tasks (deploy, restart, read logs, rotate a secret). Google's best practice guidance is to consolidate roles, grant at the minimum scope and prefer tag conditions over long OR lists of resource names, which also keeps allow policies under their size limit.
- Pilot one team. Create entitlements for one platform or SRE team on non-production projects, keep their standing bindings for two weeks, and compare what they request with what they actually used.
- Remove standing bindings. Once the pilot works, delete the permanent bindings for those roles. Rollback is simple: re-add the binding for a named user while you fix the entitlement.
- Codify. Manage entitlements with Terraform or Config Connector. Use non-authoritative IAM resources (member-level rather than policy-level) for the same resources, because authoritative resources overwrite PAM-managed bindings.
- Expand. Move production, then folder and organisation-level admin roles, adding approval as you go.
Where identity fits: humans, workloads and agents
Google documents support for Cloud Identity users and groups, Workforce Identity Federation and Workload Identity Federation principals, and agent identities. Service accounts and agent identities can also act as approvers (Preview, enabled in PAM settings). That opens two patterns for non-human identities.
- JIT for automation: a pipeline or AI agent that needs a destructive role occasionally can request a grant through the API instead of holding it permanently. Keep the entitlement narrow, require justification and alert on every grant. See the Google Cloud Agent Identity guide.
- Machine approvers: an approver service account must be treated as privileged, because whoever controls it controls approvals. Use attached service accounts or workload identity federation rather than keys. See the Cloud Workload Identity Guide.
Detection and measurement
PAM writes to Cloud Audit Logs under the service name privilegedaccessmanager.googleapis.com. Method names are prefixed with google.cloud.privilegedaccessmanager.v1.PrivilegedAccessManager. (or v1alpha, v1beta). Route them to your SIEM with an aggregated log sink. See the Google Cloud Audit Logs and Log Sinks Guide.
| Event | Log type | What to alert on |
|---|---|---|
| CreateEntitlement, UpdateEntitlement, DeleteEntitlement | Admin Activity | Any change outside the infrastructure-as-code pipeline identity |
| CreateGrant | Admin Activity | Grants on organisation-level or IAM-changing entitlements; grants outside working hours |
| ApproveGrant, DenyGrant | Admin Activity | Self-approval attempts via shared groups; approvals within seconds of the request |
| RevokeGrant | Admin Activity | Every revoke, as it usually signals an incident |
| PAMActivateGrant, PAMExpireGrant, PAMEndGrant | System event | Use to compute grant duration and correlate activity during the window |
| PAMReportExternalGrantModification | System event | Something other than PAM changed a PAM-managed binding |
| SetIamPolicy by a principal with an active grant | Admin Activity (Cloud Resource Manager or service API) | Possible persistence: a temporary user writing a permanent binding |
Read operations such as GetGrant and ListEntitlements land in Data Access logs only if you enable them; SearchEntitlements and SearchGrants are not audit logged. In ATT&CK terms, the detections above target T1098.003 Additional Cloud Roles and abuse of T1078.004 Cloud Accounts.
Metrics that show it is working:
- Standing privileged bindings: count of permanent Owner, Editor and IAM admin bindings, trending to near zero apart from break-glass.
- Share of privileged access via PAM: proportion of privileged role use that happened inside a grant.
- Median grant duration versus maximum: if users always take the maximum, the maximum is too high.
- Time to approval: median and 95th percentile; long waits drive people back to standing access.
- Unused grants: grants activated with no subsequent Admin Activity from the requester, which point to over-broad entitlements.
- External modification events: should be zero.
Common failure patterns
- Entitlement added, standing binding kept. Teams create entitlements but never delete the permanent Owner binding, so nothing changes in practice.
- Authoritative Terraform overwriting grants. A policy-level IAM resource applied mid-grant strips active PAM bindings or, worse, re-adds bindings PAM removed. Use non-authoritative resources.
- IAM-changing roles inside entitlements. Role Administrator or Project IAM Admin granted for four hours becomes permanent the moment the user adds their own binding.
- Organisation-level entitlement for routine work. Inheritance turns a convenience entitlement into access to every project.
- Stuck approvals. A required approval count higher than the approver group size, or approvers who all sit in one time zone, leaves on-call staff waiting during incidents.
- Blocked notifications. Mail filters drop messages from
[email protected], so approvers never see requests.
Framework mapping
| Framework | Reference | How PAM contributes |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2(2) Automated Temporary and Emergency Account Management | Time-bound grants removed automatically |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, AC-6(1) Authorize Access to Security Functions, AC-6(5) Privileged Accounts | Privileged roles only on request, scoped and approved |
| NIST SP 800-53 Rev. 5 | AU-2 Event Logging, AU-6 Audit Record Review, Analysis, and Reporting | Grant lifecycle audit logs and review |
| NIST CSF 2.0 | PR.AA-05, DE.CM-03 | Least privilege and separation of duties enforced; personnel activity monitored |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Removes standing admin access and documents its grant |
| ISO/IEC 27001:2022 | Annex A 8.2 Privileged access rights, 5.18 Access rights | Controlled allocation and removal of privileged rights |
| MITRE ATT&CK | T1078.004 Cloud Accounts, T1098.003 Additional Cloud Roles | Shrinks the value of stolen accounts and makes role additions visible |
For the wider Google Cloud control set around PAM, see the Google Cloud Organization Policy Guide and the Google Cloud Enterprise Foundations Blueprint Guide.
Practitioner checklist
- Inventory every standing Owner, Editor and IAM admin binding and record an owner for each.
- Set up PAM, grant the service agent its role, and add it to deny policy exceptions and VPC Service Controls perimeters.
- Allow-list
[email protected]and add a team mailbox to notifications. - Build custom task roles and keep setIamPolicy and iam.roles.update permissions out of routine entitlements.
- Require justification on every entitlement and approval on production write and IAM-changing roles.
- Delete the matching standing bindings once each entitlement is proven, keeping one or two break-glass accounts outside PAM.
- Manage entitlements as code with non-authoritative IAM resources.
- Export PAM audit logs to the SIEM and alert on grants to sensitive entitlements, revokes and external modification events.
- Review entitlements and requester lists quarterly alongside access reviews.
- Practise "Revoke all grants" in an incident exercise.
Standards and references
- Google Cloud: Privileged Access Manager overview
- Google Cloud: Create entitlements in Privileged Access Manager
- Google Cloud: Privileged Access Manager permissions and setup
- Google Cloud: Request temporary elevated access with Privileged Access Manager
- Google Cloud: Revoke grants with Privileged Access Manager
- Google Cloud: Privileged Access Manager audit logging
- Google Cloud: Privileged Access Manager best practices
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: JIT Access Guide · Privileged Access Management Guide · Google Cloud Security Guide · Zero Standing Privilege vs Least Privilege