Does Teleport re-evaluate aggregated role rules per request or cache them per certificate?

Question

I am designing access revocation for Teleport-managed SSH, Kubernetes, and database targets. When a user holds multiple roles, Teleport aggregates those role rules into a short-lived certificate. I need to know whether Teleport re-evaluates the aggregated role rules on every proxied request, or caches them for the certificate or session lifetime.

Role edits may not interrupt an already issued certificate or active session. The observable effect depends on certificate TTL, re-authentication, and per-component authorization checks. Open source, Enterprise, and Cloud editions, as well as major Teleport versions, can implement role evaluation and revocation differently. Clock skew, caching, and connection pooling may further delay when a role change becomes visible.

Does Teleport re-evaluate role rules per proxied request, per certificate issuance, or per session? Which component enforces the latest role rules? How long can an active session continue using a role after that role is modified?

Tasadduq Burney · Answer

Direct Answer

Teleport evaluates and aggregates role rules at certificate issuance time only. The resulting short-lived X.509 certificate embeds the aggregated roles and principals as certificate extensions. Once issued, the certificate is cryptographically self-contained — Teleport does not re-evaluate role rules on each proxied request for SSH, Kubernetes, or database connections.

How It Works

Certificate Issuance (Evaluation Point)

Occurs during tsh login, web UI authentication, or Machine ID renewal (Teleport 12+).
The Auth Service computes the union of all role rules assigned to the user and encodes them into the certificate (principals, Teleport-Roles extension OID 1.3.6.1.4.1.57882.1.1).

Connection Handshake (Enforcement Point)

The Proxy Service validates the certificate signature and expiration on every new connection.
Target resources (sshd, kube-apiserver, PostgreSQL/MySQL) enforce the principals/roles embedded in the certificate at connection start. They do not query Teleport for live role state.

Session Lifetime

Active sessions (SSH, Kubernetes, database) continue uninterrupted until the certificate expires or is explicitly revoked.
Role changes (add/remove/modify) take effect only for new certificate issuances. Users must re-authenticate (tsh login or web re-login) to receive an updated certificate.

Revocation Latency by Edition

Edition	Revocation Mechanism	Typical Latency
Open Source	Certificate TTL expiry only	Up to `authorization.ttl` (default 5–30 min)
Enterprise / Cloud	CRL (`tctl auth sign --revoke`) + TTL	~10–30 seconds CRL propagation + TTL fallback

Factors That Extend the Staleness Window

Clock skew between Auth Service, Proxy, and target nodes — NTP sync recommended (skew >1s can cause premature/late expiry).
Connection pooling (PgBouncer, client-go connection reuse) — pooled connections bypass re-validation until the pool recycles them.
Local certificate cache (~/.tsh/keys/) — stale certificates persist until tsh login or cache clear.
Kubernetes TokenReview caching — ensure authentication.k8s.io/v1beta1 TokenReview TTL aligns with Teleport certificate TTL.

Verification Steps

Check current cluster TTL:

tctl get auth/cluster_auth_preference --format=json | jq '.spec.authorization.ttl'

Inspect an issued certificate's embedded roles:
```
tsh status --format=json
```
or decode with openssl x509 -in <cert> -text -noout and examine the Teleport-Roles extension.
Test revocation latency: modify a role, have the user re-authenticate, verify the new certificate reflects changes. For Enterprise, revoke with tctl auth sign --revoke=<cert_serial> and confirm denial within the CRL window.
Confirm NTP sync across all Teleport nodes: timedatectl status.

One Diagnostic Detail Needed

Which Teleport edition and version are you running? Open Source, Enterprise, or Cloud? The revocation mechanism (TTL-only vs. CRL) and Machine ID auto-renewal behavior (Teleport 12+) differ by edition and affect the exact window during which a modified role remains effective.