Teleport JIT Access Requests: Trading Standing Admin Roles for Auditable, Time-Bound Grants

The standing-admin trap

Most infrastructure teams start with good intentions: a handful of permanent admin roles for on-call engineers. Over months, the list grows. Someone leaves, but their role stays. A contractor gets cluster-admin just for the migration. When an incident happens, you cannot answer a simple question: who actually has elevated access right now?

Teleport's Just-In-Time (JIT) access requests flip that model. Instead of holding a standing role, an engineer asks for elevated permissions for a bounded window. A designated approver reviews the request, and Teleport issues a short-lived certificate that expires on its own. The default window is one hour, though you can tune it.

How the request-approval flow works

Teleport already handles authentication through your SAML or OIDC identity provider and enforces MFA. JIT adds an authorization gate on top of that session. When a user needs more than their baseline role allows, they submit an access request through the web UI or the tctl CLI.

The auth service turns that submission into a pending request and notifies the approvers you configured—typically a Slack channel, an email list, or the Teleport UI itself. An approver reviews the context (who, what role, how long) and approves or denies. If approved, the auth service mints a certificate scoped to the requested role and TTL. The user picks it up, works, and the certificate expires automatically. No cron jobs, no manual revocation.

Every step lands in the audit log: the request, the approval decision, and the certificate issuance. That gives you a compliance trail without bolting on extra tooling.

Configuring the auth service

JIT approval is wired into the auth service configuration file, usually /etc/teleport.yaml on the auth server. You need root or the teleport service account to edit it, and you must restart the auth service afterward.

Two areas matter: the jwt section, which carries your SSO/OIDC claim mapping, and the roles section, where you define which roles can be requested and under what constraints. The exact field names shift between major releases, so treat the snippet below as a map of what to look for rather than a drop-in file. Back up the existing file before editing; a YAML syntax error will keep the auth service from restarting.

# /etc/teleport.yaml — run on the auth server; requires root or teleport user
auth_service:
  jwt:
    # SSO/OIDC claims used during request review
    # e.g., email, groups

roles:
  - name: 'admin'
    request_approval:
      required: true
      approvers:
        - 'security-team'
      max_ttl: '1h'

In this example, the admin role cannot be assumed directly. A user must submit a request, and only members of the security-team group can approve it. The max_ttl caps how long the resulting certificate lives.

Testing the workflow

Before rolling this out broadly, run a controlled test. From a workstation that already has tctl configured with admin credentials, create a request:

tctl request create --role=admin --ttl=1h

Required permissions: the caller needs create access on the access_request resource, typically held by an admin role. Expected checks: the request should appear in your configured approver channel within seconds. After an approver accepts it, run tctl request ls to confirm the state moved to approved, and check that the user can now assume the role for the requested window.

If the request never reaches the approvers, the most likely cause is a misconfigured approval plugin—check the auth service logs for delivery errors. If approval succeeds but no certificate is issued, compare the requested TTL against the role's max_ttl; a request longer than the cap will be rejected or truncated depending on policy.

Trade-offs and operational limits

JIT is not free. The biggest constraint is the version floor: the built-in approval UI requires Teleport 6.0 or newer. Older clusters need external scripts to bridge the gap, which adds maintenance burden.

The second trade-off is dependency on your approval channel. If Slack or email is down, requests stall and engineers are locked out until someone intervenes manually. That makes the approval path a critical piece of infrastructure, not a nice-to-have.

Finally, TTL selection is a balancing act. A one-hour default keeps the blast radius small, but it can interrupt long-running incidents. A four-hour window reduces friction but widens the exposure. There is no universal answer; pick a value that matches your incident tempo and review it quarterly.

Where to start

Do not convert every role at once. Pick one high-risk role—say, production database admin—and require approval for it. Keep a documented break-glass path outside the JIT flow for true emergencies. Then watch two metrics for a week: how long requests sit pending, and how often approvers deny them. Those numbers tell you whether your thresholds and approver groups are tuned correctly. Once the workflow feels boring, roll it out to the next role.