Simplifying Zero Trust Security for AWS with Teleport
Jan 23
Virtual
Register Now
Support
LOG IN
Teleport logoTry For Free
Contact SalesTry for Free
Support
LOG IN
Fork me on GitHub

Teleport

Teleport Architecture

Version 16.x

This guide explains the technical architecture of Teleport. Before reading this guide, we recommend that you read the Core Concepts page, which describes the components of a Teleport cluster.

Teleport control plane

The Teleport control plane consists of the Teleport Auth Service and Teleport Proxy Service. On Teleport Enterprise (Cloud), the control plane is fully managed on Teleport infrastructure. Read about Teleport Enterprise (Cloud) Architecture.

Teleport Auth Service

The Teleport Auth Service performs three main functions:

  • Maintains certificate authorities that sign host and client certificates for components of your Teleport cluster as well as (for certain self-hosted resources) your own infrastructure.
  • Stores cluster configurations as dynamic resources, including roles, local users, and certain kinds of Teleport-protected infrastructure resources.
  • Collects cluster data such as audit events and session recordings.

Cluster components communicate with the Auth Service to manage certificates, dynamic resources, audit events, and session recordings through a gRPC API.

For more information about the Teleport Auth Service, read the following guides:

Teleport Proxy Service

The Teleport Proxy Service enables components in a Teleport cluster to communicate securely with the Teleport Auth Service. With the Proxy Service, users can use the public internet to access infrastructure in private networks.

The Proxy Service implements an SSH server. Teleport Agents establish reverse tunnels with the SSH server to receive traffic from (and return traffic to) Teleport users. Auth Service clients like the Event Handler and Access Request plugins also route traffic through the Proxy Service's SSH server, and authenticate to the Proxy Service with an SSH client certificate.

The Proxy Service serves the Teleport Web UI, which in Teleport Enterprise (Cloud), is available at the address of your Teleport account (e.g., example.teleport.sh).

Read more about Teleport Proxy Service Architecture. You can also read about the architecture of Teleport Proxy Service features:

Enrolling resources

Administrators can enroll infrastructure resources with a Teleport cluster to provide secure access, RBAC, and auditing. There are three ways to enroll infrastructure resources with a Teleport cluster:

  • Teleport Agents proxy traffic from human users to and from Teleport-protected infrastructure resources.
  • Machine ID Bots receive short-lived credentials from the tbot binary so service accounts can access infrastructure.
  • Trusted clusters allow a user of one Teleport cluster to access infrastructure that is enrolled with another Teleport cluster by federating trust across multiple Teleport clusters.

Teleport Agents

Teleport Agents proxy traffic from users to resources in your infrastructure. Agents are instances of the teleport binary configured to run certain services, e.g., the Teleport SSH Service and Teleport Kubernetes Service, and administrators deploy Agents on their own infrastructure.

Agents verify a user's certificate against a certificate authority maintained by the Teleport Auth Service. Since a user's Teleport roles are encoded in their certificate, a Teleport Agent can check a user's Teleport roles and permit or deny access to a resource.

Agents must establish trust with the Teleport Auth Service when first joining a cluster, and there is are variety of methods that Agents use for this.

Read more about Teleport Agent Architecture. You can also read about the architecture of Teleport Agent features:

Machine ID

Machine ID is a Teleport system that enables automated services to access Teleport-protected infrastructure with regularly updated credentials. Administrators register a Bot user with Teleport that, like a human user, is assigned Teleport roles.

Instances of the tbot binary communicate with the Teleport Auth Service to continuously refresh credentials. As with Agents, administrators must deploy tbot instances on their own infrastructure, including on CI/CD platforms such as GitHub Actions, and join them to a cluster.

Read more about Machine ID Architecture.

Trusted clusters

On self-hosted Teleport clusters, you can federate access between Teleport clusters by enrolling a trusted cluster with the Teleport Auth Service. Users can access resources in a trusted cluster, also called a leaf cluster , by authenticating with a root cluster.

When an administrator joins a leaf cluster to a root cluster, Auth Service instances of the two clusters communicate to establish trust. Read more about Trusted Cluster Architecture.