mirror of
https://github.com/gravitational/teleport.git
synced 2026-11-05 03:33:24 +08:00
Paul Gottschling
e777e7abbe
* Reorganize early-stage docs sections Closes #18127 Currently, there are two sections of the docs related to the earliest stages of setting up Teleport, "Try out Teleport" and "Deploy a Cluster". While the organization of our top-level docs sections attempts to correspond to the stages a user goes through when setting up Teleport, these combine some tasks that should probably be separated: - **Choosing an edition and deploying a production cluster**: While the "Deploy a Cluster" section includes our deployment guides as well as our edition guides, user will likely commit to setting up Teleport Cloud, Open Source, or Enterprise before they plan a full HA production deployment. - **Deploying a production cluster and deploying a small-scale Teleport cluster:** While the "Deploy a Cluster" section includes the Linux Server and Digital Ocean 1-Click guides, these two guides are more for small-scale deployments than full production clusters. This change improves the early-stage docs experience for new Teleport users by: Splitting the "Deploy a Cluster" section ---------------------------------------- The "Deploy a Cluster" section includes subsections related to choosing a Teleport edition as well as subsections related to deploying a production cluster. The problem with this approach is that it leaves no room for adding introductory guides to help users with these two purposes. By splitting the "Deploy a Cluster" section into two top-level sections, one related to choosing an edition and the other to dpeloying to production, we can add introductory pages that put the subsections of these sections in context. _This change accompanies the work on #16751 to write a general guide to HA Teleport deployments, since the new guide will have a prominent place in the reorganized "Deploy a Cluster" section._ Adding introductory pages ------------------------- Sections related to getting started with Teleport, "Try out Teleport" and "Deploy a Cluster", were missing introductory pages. This change adds them, and also adds one to the new "Choose an Edition" section. Moving the Linux Server and Digital Ocean guides ------------------------------------------------ Move these to "Try out Teleport". The Digital Ocean guide didn't fit with the rest of the deployment guides, since it's not about architecting an HA deployment. This is also a better home for the "Linux Server" guide, so this change moves that as well. Removing the "getting-started.mdx" page --------------------------------------- This page is not reachable via the navigation menu. * Respond to PR feedback * Respond to PR feedback Also minor text tweaks
222 lines
8.7 KiB
Plaintext
222 lines
8.7 KiB
Plaintext
---
|
|
title: Teleport Core Concepts
|
|
description: Learn the the key components that make up Teleport.
|
|
---
|
|
|
|
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](./try-out-teleport/linux-server.mdx).
|
|
|
|
### 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](./architecture/authorization.mdx) and
|
|
[authentication](./architecture/authentication.mdx) 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](./architecture/proxy.mdx).
|
|
|
|
## 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](./reference/cli.mdx#teleport).
|
|
|
|
### 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](./application-access/introduction.mdx).
|
|
|
|
### Teleport Database Service
|
|
|
|
Proxies TCP traffic in the native protocols of popular databases, including
|
|
PostgreSQL and MySQL.
|
|
|
|
Read more about the [Teleport Database
|
|
Service](./database-access/introduction.mdx).
|
|
|
|
### Teleport Desktop Service
|
|
|
|
Proxies Remote Desktop Protocol traffic to Windows desktops.
|
|
|
|
Read more about the [Teleport Desktop
|
|
Service](./desktop-access/introduction.mdx).
|
|
|
|
### Teleport Kubernetes Service
|
|
|
|
Proxies HTTP traffic to the Kubernetes API server.
|
|
|
|
Read more about the [Teleport Kubernetes
|
|
Service](./kubernetes-access/introduction.mdx)
|
|
|
|
### 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](./server-access/introduction.mdx).
|
|
|
|
### 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](./machine-id/introduction.mdx).
|
|
|
|
### 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 three **editions**. All editions include the same open
|
|
source core, which is available at the
|
|
[`gravitational/teleport`](https://github.com/gravitational/teleport) repository
|
|
on GitHub.
|
|
|
|
You can find a detailed comparison of Teleport's editions in our [Frequently
|
|
Asked Questions](./faq.mdx#how-is-open-source-different-from-enterprise) page.
|
|
|
|
### 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.
|
|
|
|
### 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 more in our [Teleport Enterprise
|
|
guide](./choose-an-edition/teleport-enterprise/introduction.mdx).
|
|
|
|
### 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
|
|
guide](./choose-an-edition/teleport-cloud/introduction.mdx).
|
|
|
|
## 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](./reference/resources.mdx).
|
|
|
|
### 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](./access-controls/guides/role-templates.mdx).
|
|
|
|
### 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](./reference/authentication.mdx) and how [SSO
|
|
authentication works in Teleport](./access-controls/sso.mdx).
|
|
|
|
### 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](./reference/authentication.mdx).
|
|
|
|
### Trusted Cluster
|
|
|
|
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](./architecture/trustedclusters.mdx) for how Trusted Clusters work and our
|
|
[how-to guide](./management/admin/trustedclusters.mdx) for how to configure
|
|
Trusted Clusters.
|