How Teleport Works

Teleport is a certificate authority and identity-aware access proxy that implements protocols such as SSH, RDP, HTTPS, Kubernetes API, and a variety of SQL and NoSQL database protocols. It is completely transparent to client-side tools and designed to work with everything in today's DevOps ecosystem.

Certificate-based authentication

Certificate-based authentication is the most secure form of authentication, but historically, it has been the most complicated to manage. Teleport securely automates certificate issuance, making certificate-based authentication easy. Teleport operates a number of internal Certificate Authorities (CA). Each certificate is used to prove identity, cluster membership, and manage access. Admins can configure a time to live (TTL) for certificates, and rotate CAs to invalidate previously issued certificates.

Here is an example of the Teleport authentication flow:

# First, 'tsh' commands authenticates users and configures other# CLI tools with a client's certificate:
$ tsh login --proxy=proxy.example.com
# SSH access as usual:
$ ssh user@host
# Kubernetes access as usual:
$ kubectl get pods
# Database access as usual:
$ psql

Clients authenticate with Teleport and receive a client certificate, which automatically works for all resources protected by Teleport. After authentication, the ssh, kubectl, psql, mysql and other remote access commands will be configured with the user's identity. Teleport offers a built-in database for user management, and for production use, you can integrate it with enterprise SSO based on Okta, GitHub, Google Workspace, Active Directory, and other identity providers.

When accessing a remote desktop protected by Teleport, a user can use the remote desktop protocol (RDP) client included in the Teleport Web UI. There is no need for a separate RDP client.

The Teleport cluster

The key concept of Teleport's architecture is the cluster. The concept of a cluster is the foundation of the Teleport security model. Users and servers must all join the same cluster before access can be granted. To join a cluster, both users and servers must authenticate. This model prevents honeypot attacks and eliminates the issue of trust on first use. This also allows users to enumerate all servers and other resources that are currently online.

A Teleport cluster consists of the following components:

• Teleport Auth Service. The certificate authority of the cluster. It issues certificates to users and Teleport services, and maintains an audit log.
• Teleport Proxy Service. Allows access to cluster resources from the outside. Typically it is the only service available from the public network. It routes client traffic to and from resources in your infrastructure, relaying connections without providing any decryption or authentication.
• Teleport Agents. A Teleport Agent runs in the same network as a target resource and speaks its native protocol, such as the SSH, Kubernetes API, HTTPS, PostgreSQL, and MySQL wire protocols. Think of it as a smart sidecar that routes user requests to its target resource. Agents check certificates to ensure that users have adequate permissions to access infrastructure resources.

Teleport clusters can be configured to trust each other. This allows users from one organization to access designated servers inside of another organization's cloud or on-premise environment.

Access for edge networks

Teleport allows users to access resources running on devices that are located anywhere in the world, for example, devices on third-party networks, servers behind NAT, or devices connected via a cellular connection. Examples of this include self-driving vehicles, network equipment, retail locations, and medical devices.

The underlying technology behind this is reverse tunnels. A reverse tunnel is a secure connection established by an edge site into a Teleport cluster via the cluster's proxy.

This approach is superior to distributed VPN technology because Teleport is application-aware. Enforcing security on a higher level of the OSI model adheres to the principles of Zero Trust, where networks, including VPNs, are considered inherently untrustworthy. Being application-aware allows Teleport to provide more flexibility for configuring role-based access control and implement rich audit logging.

To make this work, each remote device must be configured to point at the public address of a Teleport Proxy Service, e.g., proxy.example.com. This allows each device to establish and maintain a permanent reverse tunnel to the cluster to which it belongs. This tunnel is used to proxy user connections into devices. The tunnel is automatically re-established if network connectivity is intermittent.

Reverse tunnels enable Teleport users to:

• Manage IoT devices via SSH.
• Access Kubernetes clusters located on the edge or on IoT platforms.
• Access web applications running on 3rd party private networks.
• Access MySQL and PostgreSQL databases running in remote environments.

The diagram below shows the Teleport cluster accessible via a proxy on proxy.example.com. This cluster has two regular nodes (A and B) and one remote node (R1).

From a user's perspective, there is no difference between the nodes on the private network and the remote box node-R1.

Audit log

The Teleport Auth Service maintains an audit log of all activity inside the Teleport cluster. The audit log consists of two components:

• The audit log: Well-documented JSON records of security events. Examples of such events include login attempts, file transfers, code execution, filesystem changes, and network activity.
• Recorded sessions: Recordings of interactive sessions established via SSH, RDP and kubectl commands. The recorded sessions can be replayed for audit purposes. When users create interactive sessions via ssh or via kubectl exec -ti, these sessions are recorded and can be replayed later via a Youtube-like web interface with features like pause and rewind.

The Teleport Auth Service stores both types of audit data on a local file system by default, but can be configured to use S3, DynamoDB, and other suitable data stores.

Recorded sessions are stored as flat ASCII files and can be easily analyzed by third-party software. For example, a user can replay a session by dumping a session file to stdout using the cat command. Here is an example of playing back a recorded session:

More information

For more information on how Teleport works, check out the documentation.