Google Cloud PAM: Request Temporary Elevated Access and Troubleshoot Grants

Welcome to DevOps Inside, where we go beyond the surface to understand how modern DevOps systems actually work under the hood. 👋

Imagine you're on call when a production incident requires elevated permissions in Google Cloud. You need to inspect a sensitive resource, change a configuration, or troubleshoot a service. Your account has the permissions needed for day-to-day work, but not the additional privileges required to fix the incident.

Traditionally, teams have handled this by granting administrative roles permanently or asking an administrator to modify IAM policies manually. Both approaches can introduce unnecessary exposure or operational delays.

Google Cloud Privileged Access Manager (PAM) offers another approach: just-in-time (JIT) access. Eligible principals can request temporary permissions through a predefined entitlement, obtain approval when required, and receive access for a limited duration.

The important engineering details go beyond submitting a request. What happens between requesting a grant and successfully using the permissions? Why might an approved grant not work immediately? And how can infrastructure automation interfere with temporary access?

This guide explains how Google Cloud PAM works, how to request temporary elevated access using the console or gcloud, and how to troubleshoot grant activation, IAM permission errors, and Terraform conflicts.

What Is Google Cloud Privileged Access Manager?

Google Cloud Privileged Access Manager is an IAM capability for controlling temporary privilege elevation. It allows organizations to define who can request additional permissions, which roles they can receive, how long access can last, and whether approval is required.

PAM revolves around two central concepts: entitlements and grants.

An administrator configures the entitlement before a requester can use it. PAM doesn't automatically give every engineer the ability to elevate their permissions.

For example, a platform team could configure an entitlement that allows designated on-call engineers to request a temporary role for production troubleshooting. The entitlement could require a justification, impose a maximum duration, and require approval for sensitive environments.

The engineer requests access when needed rather than holding the elevated role continuously.

Google Cloud supports PAM entitlements at the project, folder, and organization levels. The roles and resource scope available to a requester depend on the entitlement's configuration and the supported IAM capabilities of the target resource.

Official reference: Google Cloud Privileged Access Manager overview.

How Does Google Cloud PAM Work Under the Hood?

Understanding how PAM implements temporary access helps explain why an approved grant doesn't necessarily make every operation available immediately.

PAM manages temporary access by adding and removing role bindings in IAM allow policies. Its temporary role bindings use time-based IAM Conditions to limit access to the grant's validity period.

1. Administrator configures an entitlement
2. Eligible principal requests a PAM grant
3. Approval, if required
4. PAM activates the grant and applies a time-based IAM binding
5. IAM policy changes propagate
6. Principal uses the role until the grant ends

Illustrative workflow. Exact transitions depend on the entitlement configuration, activation schedule, and grant outcome.

1. Entitlements define the permitted elevation

An entitlement is the control point for temporary privilege elevation. It specifies which principals can request access and which roles can be granted.

Administrators can configure a maximum grant duration, require a justification, and define an approval workflow. Supported IAM Conditions can further restrict the resources accessible through granted roles.

This is where least privilege starts. A temporary grant should not become an unrestricted route to a broad administrator role when a narrower role can solve the problem.

Reference: Configure temporary access.

2. IAM Conditions make the grant time-bound

PAM uses time-based IAM Conditions on the role bindings it manages. Access is therefore tied to the grant's validity period rather than being intended as a permanent assignment.

PAM doesn't simply create a separate cloud identity or guarantee a new authenticated session. It changes the effective authorization available through IAM.

An active grant can provide the required IAM permissions, but it doesn't automatically override other authorization restrictions.

3. Activation and expiration depend on propagation

Google documents that PAM grant activation and role removal are subject to standard access-change propagation.

A grant may be approved or enter an activation-related state before all relevant operations work as expected. Similarly, when a grant ends, the removal of its permissions can take time to propagate.

References: PAM overview and IAM Conditions overview.

How to Request Temporary Elevated Access in Google Cloud

Before requesting a grant, make sure PAM has been configured for the relevant resource and that your principal is eligible to request access through an entitlement.

You can request grants only against entitlements to which you've been added. If the required entitlement isn't available, contact the principal administering it.

Option 1: Request a grant in the Google Cloud Console

1. Open the Privileged Access Manager page.
2. Select the relevant organization, folder, or project.
3. Open the My entitlements tab.
4. Find the entitlement that covers your task and click Request grant.
5. Specify the requested duration, subject to the entitlement's maximum.
6. Provide a justification if required.
7. If appropriate, schedule activation for a future time.
8. Add additional notification recipients if necessary.
9. Submit the request.

If approval is required, the request must be approved before its deadline:

• Immediate activation: Approval or denial must occur within 24 hours of the request.
• Scheduled activation: Approval or denial must occur before the scheduled activation time.

If the deadline passes without a decision, the request expires.

Scheduled grants and preview features

PAM supports scheduling a grant for activation up to seven days in advance. If scheduling isn't used, the grant activates after creation or the required approvals.

Other capabilities have different availability conditions:

• Inherited entitlements: Requesting a grant against an inherited entitlement at a child resource scope is documented as a preview feature.
• Customizable grant scopes: Selecting specific roles and resources within a grant request is documented as a preview feature and requires the applicable Security Command Center Premium or Enterprise tier.
• Advanced approval configuration: Some multi-level or multi-approver workflow changes are also documented as preview capabilities.

Don't describe all PAM features as preview, and don't assume that a preview feature is generally available. Check the current documentation and applicable Pre-GA terms before incorporating these capabilities into a production workflow.

Reference: Request temporary elevated access.

Option 2: Request a grant using the gcloud CLI

The Google Cloud CLI supports grant creation through the gcloud alpha pam grants create command.

Because this command is in the Alpha command group, its interface can change. Check the syntax supported by your installed CLI version before using it:

gcloud alpha pam grants create --help

The following is an example of the documented grant-creation workflow for a project-level entitlement:

gcloud alpha pam grants create \
  --entitlement=ENTITLEMENT_ID \
  --requested-duration="3600s" \
  --justification="Investigate production incident INC-1234" \
  --location=global \
  --project=PROJECT_ID

Replace ENTITLEMENT_ID with the entitlement ID and PROJECT_ID with the target Google Cloud project ID.

The requested duration of 3600s represents one hour. The entitlement must allow that duration, and the requester must be eligible to request the grant.

The resource-scope flag must match the entitlement's scope:

• --project=PROJECT_ID for a project-level entitlement.
• --folder=FOLDER_ID for a folder-level entitlement.
• --organization=ORGANIZATION_ID for an organization-level entitlement.

Use only the appropriate resource flag for the request. Alternatively, supply the fully qualified entitlement identifier as supported by the CLI.

To schedule activation, use the optional --scheduled-activation-time flag with an RFC 3339 timestamp. The activation time can be up to seven days in the future. If the flag isn't specified, activation occurs after creation or required approvals.

The command requests a grant; it doesn't guarantee immediate access. If approval is required, the approver must act before the applicable deadline.

To confirm the account used by the CLI, run:

gcloud auth list

To inspect the configured default project, run:

gcloud config get-value project

These checks help identify whether you're using the intended account and project. An explicit resource flag in the grant request must still match the entitlement you're targeting.

For complete syntax and supported options, see the official gcloud PAM grants create reference.

The command examples are based on Google's documentation. They have not been executed against a live Google Cloud project.

How to Check Whether a PAM Grant Is Active

A successfully submitted request is only the beginning. Before performing the privileged operation, confirm the grant's current state.

Check grant status in the console

1. Open the PAM page.
2. Select the relevant organization, folder, or project.
3. Open the Grants tab and locate the relevant grant.
4. Inspect its state, duration, scope, and details.

The console displays human-readable status labels. The underlying API uses enum values such as APPROVAL_AWAITED and ACTIVATION_FAILED.

The exact state names and transitions should be checked against Google's current documentation. A grant's status and the effective permissions on a target resource are related, but they're not the same thing.

Check grant status with gcloud

The documented gcloud alpha pam grants search command can search grants that you've created, can approve, or have already approved or denied.

For example, to search for grants you created under a project-level entitlement:

gcloud alpha pam grants search \
  --entitlement=ENTITLEMENT_ID \
  --caller-relationship=had-created \
  --location=global \
  --project=PROJECT_ID

Replace the placeholders with the relevant entitlement and project identifiers. For folder- or organization-level entitlements, use the corresponding resource flag.

The --caller-relationship flag supports these values:

• had-created: Grants you've created.
• had-approved: Grants you've approved or denied.
• can-approve: Grants you're authorized to approve or deny.

Inspect the returned state field to determine the grant's status. The search command is useful for investigation, but it doesn't replace checking whether the original operation is authorized.

Reference: View grants in Privileged Access Manager.

Troubleshooting: PAM Grant Approved but Access Is Denied

One of the most confusing situations is a grant that appears to have succeeded while the engineer still receives a permission-denied error.

Don't immediately request a broader role or modify IAM manually. Work through the following checks.

Step 1: Confirm the grant is active

Check the grant's current status and verify that its activation time has arrived.

If the status is APPROVAL_AWAITED, access hasn't been granted through that request. If it's SCHEDULED, wait until the configured activation time. If it's ACTIVATING, the change is still in progress.

If the grant is ACTIVE, continue investigating rather than assuming every operation must succeed.

Step 2: Allow for IAM propagation

PAM uses time-based IAM Conditions, and policy changes are subject to standard access-change propagation.

If the grant has only just become active, allow time for propagation and retry the original operation. The precise delay depends on the relevant access-change path and isn't guaranteed to be identical for every service.

Avoid repeatedly changing role bindings simply because access hasn't appeared immediately. Additional policy changes can complicate the investigation.

Step 3: Check the role and resource scope

An active grant can still be insufficient for a particular operation.

• Is the required role included in the entitlement?
• Does that role contain the permission required by the failed API operation?
• Is the grant scoped to the correct project, folder, organization, or supported resource subset?
• Is the command targeting a different project or resource from the one covered by the grant?
• Are IAM Conditions, deny policies, or service-specific access controls affecting the request?

For example, an engineer might receive a temporary role in a staging project but accidentally run a command against production. The grant can be valid while the operation still fails.

Use the exact resource identified in the error message when reviewing the effective permissions.

Step 4: Inspect the effective IAM policy

In the Google Cloud Console, open the relevant resource's IAM page and inspect the principal's role bindings and applicable conditions.

PAM-created temporary bindings can be identified by the condition description Created by: PAM in the principal-based IAM view.

Look for the expected role and verify that the binding hasn't been changed externally. Also consider other authorization controls that might constrain access.

Step 5: Inspect the grant's details and history

If a grant remains in an activation-related state, inspect its details and history for additional information.

An ACTIVATION_FAILED state indicates a non-retriable activation error. Waiting alone may not resolve it.

Record the entitlement, requested role, target resource, and failure details. Then inspect the relevant IAM configuration and check whether Terraform or another automation system has modified the policy.

If the cause isn't clear, correlate the grant details with available Cloud Audit Logs and the failed operation's error message.

The goal is to identify the failing layer before attempting remediation.

Troubleshooting: PAM Grant Activation Failed

Activation failure requires a different approach from a grant that is merely waiting for propagation.

1. Open the failed grant and inspect its details and history.
2. Record the entitlement, requested role, target resource, and available failure information.
3. Inspect the target resource's IAM policy for unexpected changes to relevant bindings.
4. Check whether Terraform, another automation system, or a manual policy edit has modified IAM.
5. Correct the underlying policy-management conflict or configuration problem.
6. Submit a new request only after the entitlement and resource configuration are ready.

Don't treat every activation failure as a missing-permission problem. Use the recorded failure information to determine the next diagnostic step.

The Terraform Problem: When IAM Automation Fights PAM

This is an important consideration for teams managing Google Cloud IAM with Terraform.

Google Cloud provides different Terraform IAM resource patterns, and they don't all have the same ownership semantics.

PAM creates temporary role bindings outside the normal Terraform configuration. If an authoritative IAM resource doesn't account for those bindings, a later Terraform apply can overwrite policy changes and remove bindings that PAM manages.

That can interfere with the grant lifecycle or cause unexpected access behavior.

Google's PAM guidance recommends using non-authoritative IAM resources when managing IAM policies alongside PAM, rather than authoritatively managing bindings that PAM needs to control.

What should you do?

For IAM associations that must coexist with PAM-managed bindings, use a compatible non-authoritative management pattern where appropriate, such as google_project_iam_member, and define clear ownership boundaries.

For example:

resource "google_project_iam_member" "application_reader" {
  project = var.project_id
  role    = "roles/viewer"
  member  = "group:[email protected]"
}

This illustrative resource manages the specified member-role association. It doesn't manage every member of the role and shouldn't be treated as a complete replacement for all IAM policy management.

Before changing an existing production configuration:

1. Identify which Terraform resources currently manage the project's IAM policy.
2. Determine which bindings PAM creates and which resources are owned by Terraform.
3. Review the proposed plan for unintended removals or policy changes.
4. Migrate ownership carefully, accounting for existing Terraform state and the documented behavior of each resource.
5. Apply the change through your normal review and deployment process.
6. Test a PAM grant and verify that a subsequent Terraform plan doesn't attempt to remove PAM-managed access unexpectedly.

References: PAM overview and Google Cloud Terraform best practices.

Security Practices for Temporary Elevated Access

PAM reduces the need for permanent privileged access, but it doesn't eliminate the need for careful IAM design.

Keep entitlements narrowly scoped

Give requesters only the roles and resources they need for their work. A short-lived grant for an unnecessarily powerful role can still create substantial risk while active.

Set realistic maximum durations

A grant should last long enough to complete the approved task, but no longer than necessary. Set maximum durations based on operational requirements and risk.

Require meaningful justifications and approvals

A useful justification explains the task, target resource, and reason elevated permissions are needed. For sensitive environments, require approval from appropriate principals and consider separation of duties.

Review grant activity and audit logs

Use PAM grant details and Cloud Audit Logs to investigate who requested access, which permissions were granted, and when access was active.

PAM grant records have a limited retention period. Google documents that grants are automatically deleted 30 days after they are denied, revoked, withdrawn, expired, or ended. Cloud Audit Logs have separate retention behavior, so configure logging and retention to meet your organization's investigation and compliance requirements.

Protect the grant lifecycle from manual changes

Avoid modifying PAM-managed role bindings directly through IAM or automation. Define clear ownership boundaries so Terraform and other policy-management tools don't unexpectedly interfere with temporary access.

Verify access removal

When a grant ends, confirm that PAM has completed the removal and that the relevant role binding is no longer effective. Remember that standard propagation behavior still applies.

Temporary access is a control on authorization, not a substitute for incident review, auditability, or least-privilege design.

Frequently Asked Questions

What is Google Cloud Privileged Access Manager?

Google Cloud PAM is a service for controlling just-in-time, temporary privilege elevation. Administrators configure entitlements that define who can request access, which roles can be granted, how long access can last, and whether approval is required.

How do I request temporary elevated access in Google Cloud?

Open the Privileged Access Manager page in the Google Cloud Console, select the relevant resource, open My entitlements, and request a grant from an eligible entitlement. Alternatively, use the documented gcloud alpha pam grants create command with the appropriate entitlement, duration, and resource scope.

Why is my Google Cloud PAM grant active but access still denied?

An active grant doesn't override every authorization restriction. Check IAM propagation, the granted role, the target resource, IAM Conditions, deny policies, and service-specific controls. Confirm that the failed operation targets the resource covered by the grant.

How long does a PAM grant take to become active?

Activation depends on the request and approval workflow, followed by normal IAM access-change propagation. Approval or submission alone doesn't guarantee immediate access to every operation.

What happens when a PAM grant expires?

PAM removes the role bindings associated with the grant when it ends. The effective removal is subject to normal IAM propagation behavior.

Can Terraform interfere with Google Cloud PAM?

Yes. Authoritative IAM policy and role-binding management can overwrite bindings managed by PAM. Review resource ownership and Terraform plans before making changes, and use compatible non-authoritative resource patterns where appropriate.

Are Google Cloud PAM scheduled grants generally available?

Scheduling a grant up to seven days in advance is documented in the request workflow. Some related capabilities, such as inherited entitlements and customizable grant scopes, are explicitly marked as preview. Check the current documentation for the availability of each feature.

Does PAM support the Owner, Editor, and Viewer roles?

PAM's time-based role bindings rely on IAM Conditions, which don't support legacy basic roles such as Owner, Editor, and Viewer. Use an appropriate supported predefined or custom role instead.

Does PAM replace permanent IAM roles?

No. Engineers still need appropriate baseline permissions for routine work. PAM complements those permissions by providing controlled, time-bound elevation when additional access is justified.

Key Takeaways

• Google Cloud PAM provides just-in-time temporary privilege elevation through entitlements and grants.
• Entitlements define eligible requesters, roles, maximum duration, and optional approval requirements.
• PAM uses time-based IAM Conditions, so activation and removal are subject to standard IAM propagation.
• Legacy basic roles such as Owner, Editor, and Viewer aren't supported for conditional role bindings.
• An active grant doesn't guarantee that every operation is authorized. Verify the role, scope, and effective access controls.
• Activation failures require investigation of grant details and the underlying configuration, not simply more waiting.
• Terraform's authoritative IAM resources can conflict with PAM-managed bindings if policy ownership isn't designed carefully.
• Grant history, audit logs, and verification of access removal are essential parts of an operational JIT access workflow.

Final Thoughts

Temporary elevated access is most useful when it fits naturally into how engineers troubleshoot and operate cloud infrastructure. Google Cloud PAM provides the mechanisms to request, approve, activate, and end temporary permissions. The engineering challenge is ensuring those permissions are appropriately scoped, become effective when needed, and remain compatible with the systems that manage IAM.

When a grant fails, start with its state and recorded details. Check the target resource, effective permissions, and any external IAM changes before attempting remediation. That approach turns privilege elevation into an explicit, time-bound, and auditable part of operating Google Cloud.

Official References

• Google Cloud PAM overview
• Request temporary elevated access
• gcloud PAM grants create reference
• View grants
• Configure temporary access
• IAM Conditions overview
• Google Cloud Terraform best practices