Designing a Minimal Teleport Deployment Around Short-Lived Certificates

The problem this design solves

Teams that grow past a handful of servers usually end up with the same mess: SSH keys copied onto machines by hand, a shared bastion host everyone tunnels through, kubeconfigs and database passwords sitting on laptops, and no reliable record of who did what. The useful takeaway of Teleport's design is that you can replace all of those durable secrets with short-lived certificates issued by one internal certificate authority, so access expires on its own and every session is attributable to an identity. This note walks through the requirements, the smallest topology that satisfies them, where the trust boundaries actually sit, and the failure modes you should test before relying on it.

Requirements

The design targets a fairly common set of needs:

• SSH, Kubernetes, database and internal HTTP access without distributing long-lived private keys or shared credentials.
• A single identity source: local users, or SSO via OIDC/SAML, optionally backed by hardware keys.
• Per-session auditability, including recorded terminal sessions where required.
• Low standing privilege: elevation should be a time-bounded, approved event rather than a permanent role.

The smallest suitable design

Teleport has three core roles:

• Auth Service — the cluster certificate authority (CA) and state store. It holds the CA private keys, user and role definitions, join tokens and the audit log.
• Proxy Service — the public ingress. It terminates TLS, serves the web UI, and accepts reverse tunnels from agents so that nodes behind NATs never need inbound connectivity.
• Agents/Nodes — the enforcement points. An agent dials outward to the Proxy, receives short-lived host certificates, and enforces RBAC and session recording at the resource.

The minimal lab topology is a single host running all three services (an "all-in-one" deployment). That is enough to evaluate the model. For production, split Auth and Proxy onto separate machines and run at least two Auth instances, because the Auth Service is the availability-critical component: if it is down, no new logins or certificate renewals can happen.

How issuance works, and why revocation is mostly TTLs

When a user runs tsh login, the client authenticates against the Auth Service (directly or via your SSO provider). The Auth Service returns short-lived SSH and X.509 certificates. Role-derived principals and extensions are embedded in the certificate itself, which means the node can make authorization decisions locally without calling back to a central policy service on every connection.

The consequence that shapes the whole design: there is no practical revocation list. If a credential is compromised, your mitigation is that it expires soon. That makes certificate TTL a security control, not just an operational detail. Keep user certificate TTLs short enough that a leaked credential has limited value, and treat any request to lengthen them as a risk decision.

You can verify what was actually issued rather than trusting configuration. After a login, inspect the identity file with:

ssh-keygen -L -f ~/.tsh/keys/<proxy-address>/<user>

Run this on any client machine where you have logged in; it needs no special permissions. Check the validity window, the listed principals and any critical options. If the TTL or principals don't match what you intended, the role mapping — not the node — is where to look.

Trust and data boundaries

Three boundaries matter:

• The Auth Service must never be reachable from untrusted networks. It holds the CA keys and all cluster state. Only the Proxy should face the internet or other untrusted segments.
• The join boundary is the one to harden. Nodes and agents join using a join token or a cloud-provider identity-based method (for example, an instance identity document from the cloud metadata service). A leaked long-lived join credential is effectively cluster membership, so scope tokens narrowly, keep their lifetimes short, and audit the cloud join rules — misconfigured metadata-based joins are a common source of both join outages and over-permissive membership.
• The access-request path is a separate boundary. Elevated roles are granted through an approval workflow with time-bounded leases, often integrated with ticketing or chat tooling. Approvers are part of your trust model; review who can approve which roles.

Audit and recording placement

Session recording can happen at the node, at the proxy, or both, with modes from disabled to strict. The trade-off is real: proxy-side recording cannot see traffic that bypasses the proxy (for example, an agent reached directly), while node-side recording is stronger but depends on the agent host itself not being compromised. Recordings and audit events flow through the Auth Service's audit log and can be forwarded to external storage for retention.

Exercise the path before you need it: start a test session, confirm the event appears in the audit log, replay the recording, and verify which storage backend actually holds it. An audit pipeline that has never been replayed is an assumption, not a control.

Operational checks

• Read the Teleport configuration file on each host and confirm which services (auth, proxy, node, app, db, kube) are enabled where. The running topology should match the intended one.
• Inspect issued certificates with ssh-keygen -L as above to confirm TTLs and principals.
• Enumerate join tokens and cloud join rules regularly; remove anything broader than required.
• Confirm recordings land in the expected external storage, not only on the Auth host.

Failure modes to test deliberately

• Auth outage: stop the Auth Service in a test environment. Existing sessions and already-issued certificates keep working until expiry; new logins and renewals fail. A single-node all-in-one deployment has exactly this exposure, which is why production replicates Auth.
• Certificate expiry: let a client certificate expire and confirm re-issuance requires re-authentication, not silent renewal.
• Proxy bypass: if nodes are also directly reachable, proxy-side recording has a blind spot. Either restrict direct network paths or use node-side recording.

Conditions that would change the design

• Hard availability requirements on access itself push you to replicated Auth with a highly available state backend, and to thinking about what happens to emergency access during a full control-plane outage.
• Compliance-driven recording pushes recording to the node in strict mode and forces network controls that prevent proxy bypass.
• Very large or multi-region fleets may justify separating clusters per trust zone rather than stretching one control plane, since the Auth Service is a single failure and latency domain.
• Long-lived automation that cannot re-authenticate interactively needs machine identity with its own short-lived credentials, not shared user certificates with inflated TTLs.

One caveat: Teleport ships frequently, and configuration schema, join methods, recording options and defaults change between major versions. Treat every field name and default here as version-sensitive and confirm it against the documentation for the exact release you deploy.