Teleport Core Concepts

Here are the core concepts that describe a Teleport deployment. You will see these terms often when setting up and managing Teleport, so you should get familiar with them before following other pages in the documentation.

Teleport cluster

The key concept of Teleport's architecture is the cluster. A Teleport cluster consists of the Teleport Auth Service and Teleport Proxy Service, plus the Teleport services that manage traffic to resources within your infrastructure, such as Kubernetes clusters and Windows desktops.

A minimal Teleport cluster consists of the Teleport Auth Service and Teleport Proxy Service. In a demo environment, you can run these two services from a single teleport process on a Linux host.

Teleport Auth Service

The Teleport Auth Service manages local users and configuration resources within a Teleport cluster. It maintains certificate authorities that enable users and services to authenticate to your cluster. The Auth Service issues certificates to clients and maintains an audit log.

The Auth Service is the only component of a cluster that has to be connected to a backend, which it uses to store cluster state and the certificate authorities' private keys. Teleport services are stateless and interact with the Auth Service via a gRPC API.

You can run multiple Auth Service instances in a cluster for high availability.

Read our guides to how authorization and authentication work in Teleport.

Teleport Proxy Service

The Teleport Proxy Service allows for secure access to resources in your infrastructure from the public internet without the need for a VPN.

It establishes reverse tunnels to the Teleport Auth Service and Teleport Services, which can run in private networks. This means that, in the Proxy Service's minimal configuration, you can expose only port 443 to the internet and run the rest of your infrastructure in private networks.

You can also configure clients to bypass Proxy Service instances and connect to resources with Teleport-issued certificates directly.

Read our guide to how the Teleport Proxy Service works.

Teleport services

A Teleport service manages access to resources in your infrastructure, such as Kubernetes clusters, Windows desktops, internal web applications, and databases.

A single running teleport process can run one or more Teleport services, depending on the user's configuration. Read about all subcommands of teleport in our CLI Reference.

Teleport Application Service

Proxies HTTP and TCP traffic to user-configured endpoints, e.g., internal web applications or the AWS Console.

Read more about the Teleport Application Service.

Teleport Database Service

Proxies TCP traffic in the native protocols of popular databases, including PostgreSQL and MySQL.

Read more about the Teleport Database Service.

Teleport Desktop Service

Proxies Remote Desktop Protocol traffic to Windows desktops.

Read more about the Teleport Desktop Service.

Teleport Kubernetes Service

Proxies HTTP traffic to the Kubernetes API server.

Read more about the Teleport Kubernetes Service

Teleport SSH Service

An SSH server implementation that allows users to execute commands on remote machines while taking advantage of Teleport's built-in access controls, auditing, and session recording.

Read more about the Teleport SSH Service.

Machine ID

Allows machines and services—called bot users—to communicate securely with resources in your infrastructure by automatically provisioning and renewing credentials.

Bot users can connect to resources in your infrastructure without relying on static credentials (e.g., certificates and private keys) that become more vulnerable to attacks the longer they remain in use.

Unlike other Teleport services, Machine ID runs via the tbot binary, rather than the teleport binary.

Read more in our Machine ID guide.

Agent

An instance of a Teleport service is called an agent. For all Teleport services besides the Teleport SSH Service, an agent can enable access to multiple resources, and can run on a separate host from the resources it enables access to. All agents must run in the same network as their target resources.

Teleport editions

Teleport is available in several editions. All editions include the same open source core, which is available at the gravitational/teleport repository on GitHub.

You can find a detailed comparison of the features available in each Teleport edition in Frequently Asked Questions.

Teleport Enterprise Cloud

Teleport Enterprise Cloud is a managed deployment of the Teleport Auth Service and Teleport Proxy Service.

Our team at Teleport handles all tasks related to running the Auth Service and Proxy Service, including upgrades and certificate management. Each customer account, known as a Teleport Enterprise Cloud tenant, has its own subdomain of .teleport.sh, e.g., mytenant.teleport.sh.

Read more in our Teleport Enterprise (Cloud) getting started guide.

Teleport Enterprise

Teleport Enterprise is a paid plan that includes all of the features of Teleport Community Edition, plus advanced features for organizations with advanced security needs, such as support for Federal Information Processing Standards (FIPS) and a hardware security module (HSM). Teleport Enterprise includes a support agreement with Teleport.

Read the documentation on self-hosting Teleport.

Teleport Community Edition

Teleport Community Edition is a free, open source distribution of Teleport that anyone can download, install, and host on their own infrastructure.

Configuration resources

A configuration resource is a document stored on the Teleport Auth Service backend that specifies settings for your Teleport cluster. Examples include roles, local users, and authentication connectors

Read more in our resource reference.

Role

A role is a configuration resource that grants Teleport users privileges within a cluster. Teleport's role-based access control (RBAC) is restrictive by default, and a user needs explicit permissions before they can access a resource or perform management tasks on a cluster.

Read our guide to Teleport roles.

Teleport users

Teleport allows for two kinds of users:

• Local users correspond to a user configuration resource stored on the Auth Service backend.
• Single Sign-On (SSO) users are stored on the backend of your SSO solution, e.g., Okta or GitHub. When a user authenticates to Teleport via your SSO solution, Teleport issues a certificate for the user and creates a temporary local user that is valid for the lifetime of the certificate.

Ultimately, a Teleport user is the subject of a certificate issued by the Teleport Auth Service. The Auth Service verifies that a client or service attempting to connect has a valid Teleport-issued certificate. It then uses the subject of the certificate—including its username and Teleport roles—to authorize the user.

Read more about local users and how SSO authentication works in Teleport.

Authentication connector

An authentication connector is a configuration resource that allows users to authenticate to Teleport via a Single Sign-On (SSO) solution.

See our guide to Authentication Options.

Trusted clusters

Teleport allows you to configure a trusted cluster relationship between a root cluster and one or more leaf clusters that trust the root cluster certificate authority. The trust relationship between the root and leaf clusters enables users authenticated in the root cluster to access resources in leaf cluster. The root and leaf cluster operate independently with their own users, roles, and resources, but the trust relationship allows users with certain roles in the root cluster to be mapped to roles and permissions defined in the leaf cluster.

For more information about how to configure a trust relationship between clusters, see Configure Trusted Clusters. For an overview of the architecture used in a trusted cluster relationship, see Trusted Cluster Architecture.