Request temporary resource access

A developer may need to inspect a production secret while investigating an incident. Giving the entire team permanent read access would make that temporary need permanent authority. An access package instead defines who may request access, who must approve, which resource it covers, and when the grant ends.

#Understand: eligibility is not a grant

Runtime uses grants belong to your running application. Resource Access grants belong to a person for a limited time. Neither a hosted Fluffy login nor membership in a requester group is itself permission to read the resource.

Google Privileged Access Manager (PAM) owns the provider approval and grant lifecycle. Control Room shows the package and reconciled status, and links to the exact PAM workflow. It does not impersonate the requester or approver.

The animation in How access works concerns runtime permissions. Revoking a person's temporary grant does not change the API's uses, and generating an SDK does not approve a human request.

#Configure: let developers request one secret

Install Premium with Resource Access enabled in an organization-backed GCP project. Deploy the target application successfully before configuring its package: Premium resolves the logical resource against that exact application's accepted deployment state.

At the workspace root, add or merge fluffy-chainsaw.access.yaml:

apiVersion: fluffy-chainsaw.dev/access/v1
packages:
  - name: read-api-key
    application: example-app
    environment: prod
    resource: secrets/api-key
    profile: secret.read
    requesterGroup: developers@your-company.com
    approverGroup: approvers@your-company.com
    approvals: 1
    maximumDuration: 2h

Use your application, environment, declared secret, and real Google group addresses. Declare referenced groups in the installation's fluffy-chainsaw.integrations.yaml. The groups above are distinct; membership is maintained outside Fluffy.

Preview and apply the installation change:

fluffy-chainsaw-premium install --check
fluffy-chainsaw-premium install

Review the resolved physical resource, eligible principals, approvers, and duration. A logical name alone is insufficient: an absent, ambiguous, or incompatible deployed resource cannot become an access package.

#Request and approve

Open the package in customer Control Room and follow its Google PAM link. Sign in with the eligible human identity, provide a justification, and request a duration within the package limit. A separate eligible approver follows PAM to approve or deny.

After PAM reports active access and permissions have propagated, use normal provider tools against the package's exact resource. Check that the intended read works. Finish by ending the grant through PAM or letting it expire; verify the grant has ended and the permission is no longer effective.

If the person still has access, inspect other IAM grants too. Removing this package's grant cannot remove unrelated authority granted elsewhere.

#Emergency access

Break-glass requires separate emergency principals and an explicit opt-in on a supported package. Add these fields to the access document only when you have an emergency-access policy:

breakglass:
  emergencyGroup: incident-commanders@your-company.com

Set breakglass: true on the intended package. Its emergency principals must be separate from the package's requester and approver principals. Emergency requests are bounded to 30–60 minutes and also respect the package maximum. They create incidents for retrospective review. Do not put the ordinary requester group into this field to bypass routine approval.

#Reference: supported resources and configuration

The current closed profile catalog is:

These profiles support package durations from 30 minutes through 8 hours and optional break-glass. There is no arbitrary IAM-role field. Database administration is not one of these profiles. The bucket profile covers its objects; it does not inherit a runtime's uses.buckets.prefix.

Principal lists accept unique user:person@company.com and group:team@company.com entries. A group shorthand takes the email address without group:. Requester and approver principal lists must not overlap. Configuration checks exact principals; operators must also maintain the intended separation of the humans behind their Google groups.

Multiple required approvals use the explicitly enabled provider-native pre-GA capability. Omitting the opt-in with approvals: 2 is rejected; it does not silently become one approval. Resource Access configuration is rejected when that capability is disabled in the installation.

#Resolve a failed request at its boundary

Use PAM to correct provider decisions. Editing a Control Room record does not approve, revoke, or recreate a cloud grant. Continue with Control Room to understand its operational view.