Privileged Access Manager (PAM)
Privileged Access Manager (PAM) is just-in-time access elevation for sensitive operations on Google Cloud. Instead of granting a user a permanent Owner or Editor role on a production project — and accepting that they hold the role 24 hours a day, 365 days a year, even when they only need it for occasional emergencies — PAM lets that user request the role on demand, optionally requires approval from a peer or manager, grants the role for a bounded duration (an hour, four hours), and automatically revokes it when the window expires. Every grant has a justification and an audit trail.
PAM closes the chapter by tying the rest of it together. Cloud Identity gives you identities; IAM gives those identities permissions; Secret Manager and KMS protect data; IAP, Cloud Armor, and SCC keep watch on access and risk; and PAM is the operational pattern that lets you maintain a tight permission baseline while still allowing the rare necessary escalation. Permanent over-privilege is the failure mode PAM exists to prevent.
Just-in-Time Privileged Access
The reasoning is straightforward. Permissions that someone needs occasionally — to investigate an outage, perform a database migration, debug a production issue — should not be active when they are not in use. The longer a privileged binding sits, the larger the blast radius of credential compromise, the harder the audit, the easier the lateral-movement target. JIT access is the operational pattern that solves this: grant the role when needed, revoke it when not.
PAM implements this on top of IAM. The user holds no production roles by default; their day-to-day access is read-only or scoped to non-production environments. When they need to act, they request through PAM, the system grants the appropriate IAM role for a bounded window, and revokes automatically.
Entitlements and Grants
Two key concepts. An entitlement is a reusable policy template — "users in the prod-on-call group can request roles/storage.admin on the production project for up to 2 hours, with approval from a peer". An entitlement defines who can request, what role they get, the maximum duration, and the approval workflow. Entitlements are configured once.
A grant is an instance of using that entitlement — alice@example.com requested the role for one hour at 14:30 with justification "incident INC-4471". The grant has a start time, end time, requester, approver (if applicable), and justification. PAM tracks every grant for audit. Entitlements are templates; grants are uses.
Approval Workflows
Each entitlement specifies whether grants require approval and from whom. Three common patterns:
- Auto-approve — the grant is created without human review. Useful for low-risk roles where the audit trail and time-bound nature are enough security, or for development-environment access where friction costs more than the residual risk.
- Single approver — one peer or manager in an approval group reviews and approves. The right default for sensitive production access during business hours.
- Multi-approver — two or more approvers from different groups. The right pattern for break-glass access to the most sensitive resources, where one compromised approver should not be sufficient to grant elevated access.
Time-Bounded Grants
Every grant has a maximum duration set at the entitlement level and an actual duration set by the requester. Tight grants matched to the task — 30 minutes for a hotfix, 4 hours for a migration window — keep the blast-radius window small. The temptation is to set the maximum at the entitlement level high (8 hours, 24 hours) for convenience; resist it. A grant that "might be needed for the whole day" is almost always actually needed for 30 minutes, with the remaining 7 hours and 30 minutes of unnecessary elevation.
PAM vs Permanent IAM Bindings
Permanent IAM binding — the user holds the role continuously. Right for roles that are used many times daily, where the friction of requesting each time would outweigh the security benefit. Examples: read access to dashboards, day-to-day developer access in non-production environments.
PAM entitlement and grant — the user requests the role when needed, holds it briefly, and is revoked automatically. Right for roles that are powerful but rarely used: production write access, IAM admin, billing admin, break-glass for the rare incident response. Permanent bindings here are the failure mode PAM was built to fix.
- Permanent Owner or Editor bindings on engineers "just in case they need it for incident response". The baseline over-privilege blast radius is massive and the actual escalations are infrequent — exactly the case PAM is built for.
- No PAM in place at all. Emergency access is created as one-off IAM edits with no audit trail, no justification, no auto-revocation. Days later, the role is still bound and nobody remembers why.
- PAM configured with all entitlements auto-approve for sensitive roles. The JIT and time-bounded aspects survive; the human-in-the-loop check that catches misuse is gone.
- Grant duration set so long it is effectively permanent (8 hours for a 5-minute task). The audit trail says PAM was used, but the security posture is the same as a permanent binding.
- No justification requirement. The audit trail says "alice requested role X at 14:30"; six months later in incident review, no one knows why.
- Entitlements too broad — granting Owner over a whole folder when only one project's storage admin role is actually needed.
- PAM entitlements for every sensitive role — production write access, IAM admin, billing, break-glass. Permanent bindings reserved for genuinely day-to-day roles.
- Approval workflow required for production access. Auto-approve is acceptable for non-prod or low-risk roles where audit and time-bound nature are enough.
- Multi-approver entitlement for the break-glass case — one compromised approver should not be enough to grant the most sensitive access.
- Grant duration matched to the realistic task length, not "the day". 15-30 minutes for a hotfix, a few hours for migrations, never a full day for routine work.
- Justification required on every grant request. The justification is what makes the audit trail useful later.
- Narrow entitlements — the smallest role on the smallest scope that gets the work done. Folder-level Owner is almost never what you actually need.
- Quarterly review of grant patterns. Users who escalate repeatedly for the same task suggest the baseline permission is wrong; users who never escalate suggest the entitlement is over-provisioned.
Knowledge Check
What problem does Privileged Access Manager solve?
- Replacing IAM altogether with a stronger access control model built around a separate set of non-IAM principals
- Permanent over-privilege — engineers holding powerful roles 24/7 even when they only need them occasionally. PAM lets them request the role on demand, time-bounded and audited.
- Detecting compromised credentials by continuously analyzing usage patterns over time and then automatically revoking the access the moment any suspicious activity is first observed
- Encrypting service account keys at rest so that any keys that do leak cannot be used directly by an attacker
What is the relationship between an entitlement and a grant in PAM?
- An entitlement is the human principal actually asking for access, while a grant is the response that the IAM service sends back
- An entitlement is a reusable policy template (who can request what role for how long, with what approval); a grant is one instance of using that entitlement, with its own start, end, and justification
- An entitlement is simply the legacy term for the concept; grant is the modern equivalent and entitlements are now deprecated
- A grant is the live IAM binding that PAM creates on demand; an entitlement is the after-the-fact audit record that PAM writes out once that binding has fully expired and been quietly cleaned up afterward
When does enabling PAM with auto-approve defeat its purpose for sensitive roles?
- Auto-approve quietly disables Cloud Audit Logs for those grants, so they end up leaving no trail at all
- The JIT and time-bounded aspects survive, but the human-in-the-loop check that catches misuse, social engineering, or compromised credentials is gone
- Auto-approve grants are billed at a noticeably higher per-grant rate than manually approved grants
- Auto-approve grants do not actually create any real IAM bindings on the backend; the requesting user only ever sees a confirmation banner in the console
Why is grant duration matched to the realistic task length, not "the day"?
- Long grants are simply not supported in PAM at all; the maximum allowed grant duration is hard-capped at four hours regardless
- An 8-hour grant for a 5-minute task is effectively a permanent binding for that day — the audit trail says PAM was used, but the security posture is the same as never having installed PAM
- Any sufficiently long grant silently disables the approval workflow, regardless of how the entitlement was configured
- Any grant longer than a short window is automatically flagged as an anomaly by Security Command Center, which then triggers a constant storm of noisy P0 on-call pages for the security team
Which IAM bindings are good candidates to convert from permanent to PAM-managed?
- Read-only viewer access to shared dashboards and common internal tooling used all day
- Day-to-day developer access in the various non-production and staging environments
- Production write access, IAM admin, billing admin, and other powerful roles that are used rarely — exactly the roles where permanent bindings are over-privilege most of the time
- Service-account bindings for automated background workloads and pipelines, since PAM is specifically designed to mediate every single automated workload's authentication call in real time
You got correct