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 that PAM defines and manages entirely on its own terms and schedule
- Permanent over-privilege, where engineers hold powerful roles 24/7 even though they need them only occasionally and could request them on demand instead
- 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 who happens to find them sitting in a public code repository somewhere
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 to them once it decides
- 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 recorded
- An entitlement is simply the legacy term for the concept; grant is the modern equivalent and entitlements are now deprecated in the console entirely
- 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 for the auditors
- 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 are charged
- 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 of the role involved or the approver who signed the request off
- An 8-hour grant for a 5-minute task is effectively a standing binding for that whole day, leaving the exposure unchanged even though the audit trail says PAM was used
- Any sufficiently long grant silently disables the approval workflow, regardless of how the entitlement was originally configured by the admin
- 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 that the whole team uses all day, every day, as an ordinary part of their daily work on the platform every week
- Day-to-day developer access in the various non-production and staging environments that engineers touch continuously while they build, test, and debug new features every single day
- Production write access, IAM admin, billing admin, and other powerful roles that engineers actually need only a handful of times each month
- 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