Access requests are how PAM enforces least-privilege. Users hold non-privileged bindings by default and request elevation into a privileged role for a bounded window. Every request has a reason, one or more approvers, and an expiry.

​
Requesting

tash request create \
  --role=prod-sre \
  --reason="incident #4821 — DB perf investigation" \
  --duration=2h
# → req_xxx (pending)
Or in the UI: PAM → Access → Request.

​
Approving

tash-admin requests ls --pending
tash-admin requests approve req_xxx --note="approved on call"
tash-admin requests deny    req_xxx --note="use read-only role"
Approvals can require N-of-M with configurable approver groups per role — set on the role spec: 
options:
  require_approval_for: [database]
  approval:
    thresholds:
      - approve: 2
        deny: 1
        roles: [prod-sre-approvers]

​
What happens at approval time

  1. The user’s session receives the requested role for duration.
  2. A time-bounded binding is written to the audit log.
  3. When the window closes, the binding expires — no cleanup needed.
  4. Every action taken during the elevated window is annotated with the request id in the audit stream.

​
Access lists (standing pre-approved sets)

For scoped, standing access that avoids per-session approvals, define an access list: 
apiVersion: resources.tigeraccess.dev/v1alpha1
kind: TigerAccessAccessList
metadata: { name: payments-oncall }
spec:
  roles: [payments-prod-read]
  members:
    users: [[email protected], [email protected]]
    groups: [payments-oncall]
  audit:
    recurrence: quarterly    # membership must be re-attested
Members are re-attested on the recurrence. Missing attestation drops the member automatically.

Roles & bindings

Where require_approval_for and thresholds live.

Sessions

Elevated sessions are annotated with the request id.