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.
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
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 a 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.
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
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.
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
rather than the
Read more in our Machine ID guide.
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 is available in three editions. All editions include the same open
source core, which is available at the
You can find a detailed comparison of Teleport's editions in our Choose an Edition documentation.
Teleport Team makes it easier for small organizations to get started with enabling secure access to their infrastructure. It includes a subset of Teleport Enterprise Cloud features, and teams can switch to Teleport Enterprise Cloud as they scale up their Teleport usage.
Read more about Teleport Team.
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
Read more in our Teleport Enterprise Cloud guide.
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 more in our Teleport Enterprise guide.
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.
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.
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 allows for two kinds of users:
- Local users correspond to a
userconfiguration 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.
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.
A Trusted Cluster is a remote Teleport cluster joined to your own cluster via a trust relationship. Users in your Teleport cluster can access resources in a Trusted Cluster.
In a Trusted Cluster relationship, the remote cluster is called a leaf cluster. Your cluster, if you are adding a leaf cluster to it, is called a root cluster.
Read our Trusted Clusters architecture guide for how Trusted Clusters work and our how-to guide for how to configure Trusted Clusters.