Skip to main content
Version: 19.x (unreleased)

Teleport Core Concepts

Report an issue with this page

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.

As part of the Teleport control plane, the Auth Service is a core system that manages identity, access, and trust within your cluster. If you are a Teleport Cloud customer, this service is fully managed for you.

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.

As a key component of the Teleport control plane, the Proxy Service handles secure routing and session recording for all incoming connections. For Teleport Cloud users, the Proxy Service is fully managed and hosted by Teleport.

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, etc.

Each Teleport process can run one or more services. Different services enable different Teleport functions. For example, the SSH Service provides SSH access to a resource, and the Database Service proxies connections to databases. Read about all subcommands of teleport in our CLI Reference.

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. The SSH service is enabled by default.

Read more about the Teleport SSH Service.

Teleport Kubernetes Service​

Proxies HTTP traffic to the Kubernetes API server. Use for Access control and session tracking for Kubernetes.

Read more about the Teleport Kubernetes Service

Teleport Application Service​

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

Read more about the Teleport Application Service.

Teleport Database Service​

Proxies TCP traffic in the native protocols of popular databases, including PostgreSQL and MySQL. Use to enforce role-based access to databases with full audit logging.

Read more about the Teleport Database Service.

Teleport Discovery Service​

The Teleport Discovery Service automates the process of finding and enrolling cloud resources such as AWS EC2 instances and Azure VMs into a Teleport cluster. It continuously scans supported cloud environments and adds matching resources based on configured rules, reducing the need for manual node registration.

Read more about the Teleport Discovery Service.

Teleport Desktop Service​

Proxies Remote Desktop Protocol (RDP) traffic to Windows desktops. Enables access control and session recording for Windows systems

Read more about the Teleport Desktop Service.

Teleport Jamf Service​

The Jamf Service integrates with Jamf to enrolls trusted devices for macOS endpoints. Before a user is granted access, Teleport checks the device's compliance status with Jamf. This service is ideal for organizations that need to verify macOS device posture as part of their access control strategy, ensuring only trusted devices are allowed to connect. Read more about the Jamf Service.

Teleport Debug Service​

Provides internal diagnostics, exposing metrics, performance profiling tools, and debugging endpoints. It is designed for measuring performance, troubleshooting scenarios, and enabling operators to change the logging level without restarting teleport. This can be helpful for analyzing bottlenecks, or diagnosing unexpected behavior in a controlled environment. The debug service is exposed locally by default. Read more about the Debug Service.

Agent​

A Teleport instance that runs one or more services to provide access to infrastructure resources. It can be hosted separately from the resources it manages, but all agents must run within the same network as their target resources.

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.

tbot​

tbot is a lightweight agent designed to provision short-lived credentials to workloads and automation systems like CI/CD pipelines. It enables secure machine and workload authentication without relying on long-lived secrets. This makes it ideal for infrastructure automation and Zero Trust deployments.

Read more in our Machine ID guide.

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 on the Feature Matrix .

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.

Teleport clients​

A Teleport client connects to a Teleport cluster to authenticate, request access, or interact with resources such as servers, databases, Kubernetes clusters, desktops, or internal web apps. Clients use short-lived certificates and Teleport’s Role-Based Access Control (RBAC) to ensure secure, auditable access. All clients rely on the Teleport Auth Service to verify identity and issue credentials, and they may connect through the Proxy Service when accessing resources behind firewalls or in private networks.

tsh​

tsh is the command-line tool used by Teleport users to authenticate, connect to infrastructure resources, and manage active sessions. It supports SSH, Kubernetes, databases, and applications. This tool is commonly used by engineers and operators who prefer terminal-based workflows.

tctl​

tctl is the administrative command-line interface for managing a Teleport cluster. It allows administrators to configure roles, manage users, and work with resources such as tokens, trusted clusters, and audit logs. It's typically used during initial cluster setup and for ongoing administrative tasks.

Teleport Connect​

Teleport Connect is a graphical desktop application that provides an intuitive interface for accessing infrastructure resources such as servers, databases, applications, and desktops. It's ideal for engineers who prefer GUI-based access for their day-to-day tasks, offering the same secure, certificate-based access as other Teleport clients.

Teleport Kubernetes Operator​

The Teleport Kubernetes Operator is a controller that runs in your Kubernetes cluster to automate the configuration of Teleport resources, such as users, roles, and access requests, using Kubernetes custom resources.

Teleport Terraform Provider​

The Teleport Terraform Provider allows you to manage Teleport resources such as users, roles, and connectors using Terraform. It enables infrastructure-as-code workflows for configuring access and automating resource provisioning in Teleport.

Further reading: