Skip to main content

Just-in-Time Access

Just-in-time access lets a user hold the minimum permanent role they need and request a higher-privilege role for a bounded window when a specific task requires it. After approval, the requester refreshes their short-lived certificate with the elevated role attached. The certificate expires automatically when the granted window closes. Permanent administrative access becomes the exception, not the default.

How it works​

Two people are involved: a requester who needs elevation and a reviewer who approves or denies it. The requester files an Access Request naming the role they need and the reason. The request lives in the cluster as an AccessRequest resource and moves through three states: PENDING, APPROVED, or DENIED. Once enough reviewers approve, the requester can refresh their certificate with the elevated role on top of their baseline roles. The elevation authorizes new connections only while that certificate is valid. After expiry, the user obtains a new certificate with their baseline roles. Ending active sessions at expiry also requires disconnectExpiredCert.

Reviewers can approve or deny requests from the alma CLI or the Web UI. Chat and ticketing integrations notify reviewers and keep their messages or issues in sync with the request state, but manual reviews still happen in AlmaForge. The CLI provides the same review workflow without the Web UI.

Prerequisites​

  • An SSO connector configured so requesters and reviewers can log in.
  • The elevated role the request will grant. The examples below call this role dba.

Configuration​

The minimum setup is three roles: the elevated role itself, a requester role that allows asking for it, and a reviewer role that allows approving it.

The elevated role controls what holders can do once a request is approved:

dba-role.yaml:

examples/access-requests/dba-role.yaml
# Elevated role granted through just-in-time access requests.
# Holders get SSH and database admin on production hosts and databases,
# but only for the duration of an approved request.
apiVersion: almaforge.com/v1
kind: Role
metadata:
  name: dba
spec:
  options:
    maxSessionTTL: 2h # cap the elevated certificate at 2 hours
  allow:
    serverLogins: ['dba'] # Linux account used on SSH targets
    serverLabels:
      role: ['database'] # restrict to hosts labeled role=database
    databaseLabels:
      env: ['prod'] # restrict to production databases
    databaseUsers: ['*'] # any database user can be assumed
    databaseNames: ['*'] # any database name can be opened

The requester role is assigned to users who should be able to ask for elevation alongside their baseline role:

dba-requester-role.yaml:

examples/access-requests/dba-requester-role.yaml
# Lets the holder request elevation to the `dba` role.
# Assign alongside the user's baseline (non-elevated) role through
# SSO claim mapping or directly on the User resource.
apiVersion: almaforge.com/v1
kind: Role
metadata:
  name: dba-requester
spec:
  allow:
    request:
      roles: ['dba'] # role names this user is allowed to request
      maxDuration: 2h # cap on the window the user may ask for

The reviewer role is assigned to the people authorized to approve:

dba-reviewer-role.yaml:

examples/access-requests/dba-reviewer-role.yaml
# Lets the holder approve or deny requests for the `dba` role.
# Assign to on-call rotations, team leads, or any group authorized
# to grant temporary database admin.
apiVersion: almaforge.com/v1
kind: Role
metadata:
  name: dba-reviewer
spec:
  allow:
    reviewRequests:
      roles: ['dba'] # role names this user is allowed to review

Apply all three files:

Terminal
alma apply -f dba-role.yamlalma apply -f dba-requester-role.yamlalma apply -f dba-reviewer-role.yaml

Attach dba-requester and dba-reviewer to the appropriate users through the SSO connector's claimsToRoles mapping. The requester role and the reviewer role are independent. A user can hold neither, one, or both.

The example roles above are deliberately minimal. For the full field reference for thresholds, claimsToRoles, annotations, and where predicates on reviewers, see RBAC: Access Requests. That RBAC claimsToRoles field is separate from the SSO connector's role mapping. Use it when requestable role names must be derived from the requester's SSO claims.

Security patterns​

  • Block specific escalations. Add deny.request.roles: ['admin'] to a role to prevent its holders from ever requesting admin, even by accident or after a credential theft. deny wins over allow. See RBAC: spec.allow and spec.deny.
  • Peer review without a dedicated reviewer role. Put both request: and reviewRequests: for the elevated role on the baseline user role and set thresholds.approve: 2. Any two baseline users can approve another user's request, with no standing reviewer role to steal or impersonate. A requester cannot review their own request.

Requesting access​

Alice holds the dba-requester role. To ask for elevation to dba:

Terminal
alma request create \  --roles=dba \  --reason="incident-42: investigate replication lag"Creating request...Waiting for request approval...

The command blocks until the request is reviewed, then refreshes Alice's local certificate with the elevated role. The same action is available in the Web UI: open Access Requests, click New Request, pick the role, fill in the reason, and submit.

Add --reviewers="bob,carol" to suggest specific reviewers. They see the request filtered in alma request ls --suggested.

To return immediately instead of blocking, pass --nowait. Alice can pick up the approved request later with:

Terminal
alma request assume <request-id>

Five commands take a unique prefix of an ID as well as the whole one: request show, request review, request assume, request drop and login --request-id. The first few characters from the ID column are enough, and a prefix matching more than one request is rejected with the candidates listed.

Or combine login and request in one step when Alice is not yet logged in:

Terminal
alma login --request-roles=dba --request-reason="incident-42"

After approval, alma status lists the active access requests attached to the current certificate.

Reviewing access​

Bob holds the dba-reviewer role. To list pending requests he can act on:

Terminal
alma request ls --reviewable

--suggested filters to requests where Bob is named as a suggested reviewer. --my-requests lists requests Bob filed himself.

Show the full request details, including requester identity, requested roles, reason, and current approval count against the threshold:

Terminal
alma request show <request-id>

Approve or deny, with a reason for the audit log:

Terminal
alma request review <request-id> --approve \  --reason="paged for incident-42"alma request review <request-id> --deny \  --reason="use a read replica instead"

The same actions are available in the Web UI: open Access Requests, switch to the Needs Review tab, open the request, add a review reason, and click Approve Request or Reject Request. Chat and ticketing integrations can post or update a message for each request, but they do not accept manual approve or deny actions in this release. See Integrations.

A role can require multiple approvers through thresholds. If a stolen credential files a request, a second reviewer can verify out-of-band with the real user before granting. The request stays PENDING until enough reviewers have approved. A single denial that satisfies the deny threshold rejects the request.

Request lifetimes​

Three durations shape how long a request and the elevation last:

FlagWhat it controls
--request-ttlHow long the PENDING request stays valid before it expires unreviewed.
--session-ttlLifetime of each elevated certificate. Capped by the current certificate lifetime and the requested roles' TTL caps.
--max-durationMaximum approved access window. Capped by maxDuration on the requester role.

maxDuration on the requester role is itself capped at 7 days. The elevated certificate can still have a shorter TTL inside that window. The defaults are conservative. Raise them deliberately, per role.

An approved request can support further credential issuance within its access window. Expired credentials remain files on the client until replaced or removed, but no longer authorize new connections.

Returning to baseline access​

Alice can shed accumulated approved requests from her current identity without waiting for the elevation window to close:

Terminal
alma request drop                   # drop every active requestalma request drop <id> [<id> ...]   # drop specific requests

The command reissues Alice's certificate without the dropped request IDs. Dropping every request returns her to baseline roles. Dropping only some preserves elevation from the requests she keeps. This does not terminate connections already opened with the previous certificate.

Integrations​

AlmaForge ships chat and ticketing integrations that deliver each access request to the tools reviewers already watch, then update the message or ticket as reviews land in AlmaForge. See Slack, Telegram, Jira, and PagerDuty for setup. A cluster can run several integrations at once. Each one observes every request and acts independently.

For programmatic review flows, such as tying approvals to a CMDB, an identity-governance platform, or an in-house portal, AlmaForge exposes Access Requests through its API. Custom integrations are supported. Contact us for guidance.

Auto-approval​

The PagerDuty integration can auto-approve a request when the requester is currently on call for a named PagerDuty service. Turn it on with spec.approveOnCall: true on the connector. It is off until you do. This ties the approval signal directly to the operational accountability already encoded in the on-call rotation. The on-call engineer elevates during an incident without waiting for a human reviewer.

Audit​

The role-request path emits these event codes:

EventTrigger
AccessRequestCreateA user files a new request.
AccessRequestReviewA reviewer submits an approval or denial review.
AccessRequestUpdateThe direct state-setter path changes a request's state.
AccessRequestDeleteA request is removed from the cluster.

Sessions opened under an elevated certificate carry the originating request ID in their own audit events, so the chain from business reason to session is traceable end-to-end.

Troubleshooting​

Create waits forever​

If alma request create remains pending, either no reviewer is configured for the requested role or the notification path is not running. Confirm that at least one role has matching reviewRequests.roles. As a reviewer, run alma request ls --reviewable to confirm the request is visible. As an operator, check the integration plugin's logs.

Role is not requestable​

If alma request create says the user cannot request the role, the user's effective roles do not include any role whose request.roles matches the requested role. Confirm the requester role is assigned and that the requested role name is spelled correctly. Glob and anchored regular expression matchers are supported in request.roles.

After approval, access is still denied​

Run alma request show <id> to confirm the request is APPROVED, rather than still awaiting additional reviews. Then run alma request assume <id> and check alma status. If the request is active on the certificate, inspect the granted role's target labels and principals. Approval grants the role's permissions, not unrestricted access to every resource.

Web UI shows no reviewable requests​

If the Web UI shows the Access Requests view but no requests appear, the viewer's role may have no reviewRequests field. Reviewable status is driven entirely by RBAC, not by a UI permission toggle.

References​