Teleport Review 2026: Zero Trust Access for DevOps Teams

Managing SSH keys across a 50-node fleet is a nightmare. Rotating them when an engineer leaves is worse. Teleport (goteleport.com) promises to replace all of that with certificate-based, zero-trust access. After running it in production for six months, here is the honest picture.

What Problem Does Teleport Solve?

Traditional infrastructure access has three problems:

• SSH keys never expire and are hard to rotate when someone leaves the team
• There is no audit trail of what commands were run during an SSH session
• Access is binary — you either have the SSH key or you do not, with no RBAC

Teleport replaces long-lived SSH keys with short-lived certificates (default TTL: 12 hours). Every access request goes through an auth server that checks identity (SSO, MFA) and RBAC roles before issuing a certificate. Every session is recorded and searchable.

What Teleport Covers

Teleport is not just SSH. The same platform handles:

• SSH to servers (Linux and macOS)
• Kubernetes — kubectl access with RBAC synced to Teleport roles
• Databases — PostgreSQL, MySQL, MongoDB, Redis, and more
• Web applications — internal tools, Grafana, Argo, Vault UI
• Windows RDP (Enterprise)

One auth server, one audit log, one access control policy for all of it.

Setup Complexity

Self-Hosted

Teleport has three services: auth (issues certificates, stores audit log), proxy (internet-facing), and node/agent (runs on each target host).

The quickest path for a small team (under 50 nodes) is a single binary on a VM:

# On your auth/proxy server (needs a public FQDN)
curl https://goteleport.com/static/install.sh | bash
 
teleport configure \
  --cluster-name teleport.yourdomain.com \
  --public-addr teleport.yourdomain.com:443 \
  --acme \
  --acme-email admin@yourdomain.com \
  > /etc/teleport.yaml
 
systemctl enable --now teleport

Teleport handles Let's Encrypt automatically via --acme. The proxy listens on port 443 and multiplexes SSH, Kubernetes API, and web traffic on the same port.

Adding a Node

On each server you want to access:

curl https://goteleport.com/static/install.sh | bash
 
# Get join token from auth server
tctl tokens add --type=node
 
# On the target node
teleport start \
  --roles=node \
  --token=<join-token> \
  --auth-server=teleport.yourdomain.com:443

That is it. The node registers with the auth server and is immediately accessible via tsh.

Kubernetes Integration

# On the Teleport auth server, enable Kubernetes
# In teleport.yaml add:
kubernetes_service:
  enabled: true
  listen_addr: 0.0.0.0:3027
  kube_cluster_name: prod-cluster
 
# Users then access K8s via:
tsh kube login prod-cluster
kubectl get pods  # uses Teleport-issued certificate, full audit logging

The tsh CLI Experience

tsh is the client-side CLI that replaces ssh:

# Login (opens SSO browser flow)
tsh login --proxy=teleport.yourdomain.com
 
# List accessible nodes
tsh ls
 
# SSH to a node
tsh ssh ubuntu@web-server-01
 
# SSH with port forwarding
tsh ssh -L 5432:localhost:5432 ubuntu@db-server
 
# Open a database session
tsh db login prod-postgres
tsh db connect prod-postgres
 
# List Kubernetes clusters
tsh kube ls
 
# Login to a Kubernetes cluster
tsh kube login prod-eks

The certificate it issues is valid for your configured TTL. When it expires, tsh login again. If you step away for 12 hours, your access lapses — no permanently compromised keys.

Session Recording

Every SSH and Kubernetes exec session is recorded. In the Teleport web UI you can:

• Search sessions by user, node, date, or command text
• Play back sessions frame by frame like a terminal recording
• Export sessions as text audit logs for compliance

# List recorded sessions
tctl session ls --from=2026-06-01
 
# Play back a session
tsh play <session-id>

This is genuinely useful during incident response. When an outage happens at 3am and three engineers all log into the same server, you can see exactly what each person ran.

Teleport vs Tailscale vs HashiCorp Boundary

Tailscale is simpler if you just need to connect your machines without public exposure. It does not give you session recording or per-command audit logs.

HashiCorp Boundary is a better fit if you are already using Vault for secrets and want to broker dynamic credentials. It does less hand-holding for the SSH and K8s cases.

Teleport wins when you need a complete audit trail, database access, and want everything under one platform.

Pricing

The Community edition is fully functional for small teams but lacks session recording, which is often the main reason to use Teleport in the first place. Budget for at least the Starter tier.

Pain Points

• The initial teleport.yaml is verbose. First-time setup is not as quick as Tailscale. The documentation is good but dense.
• Rolling upgrades require care. Auth server, proxy, and agents all need to be within one major version of each other. Upgrading a cluster without a maintenance window is nerve-wracking.
• Resource usage. The auth server needs at least 2 vCPUs and 4GB RAM for a small cluster. Not heavy, but not trivial.
• Machine ID (bot access) for CI/CD is a newer feature and the documentation still has gaps.

Verdict

Score: 8/10

Teleport delivers on its core promise. Certificate-based auth, real session recording, and unified access across SSH, K8s, and databases in a single product is genuinely hard to beat. For teams in regulated industries (fintech, health, SOC2) the audit trail alone justifies the cost.

The setup complexity is higher than Tailscale but the operational payoff — never rotating a leaked SSH key again, being able to pull up any session from six months ago during an audit — is real.

If you manage more than 10 engineers with production access and you care about compliance, Teleport is worth deploying. For teams of 1-3 where simplicity matters more than audit depth, Tailscale is still the easier choice.

For zero-trust secrets management, see our HashiCorp Vault setup guide.