Move cluster deployment docs into Installation (#65844)

Implements part of RFD 246

Help new users understand what is involved in deploying a Teleport
cluster by moving the self-hosting documentation into the Installation
section. This way, we can include all information related to running
Teleport processes in the same part of the docs.

Docs related to Teleport features but not first-time deployments do not
belong in the Installation section, so this change moves them into the
Management section instead:
- Configure Trusted Clusters
- TLS Routing Migration
- Guides in `zero-trust-access/deploy-a-cluster/reliability`

Also edit the Installation landing page  to make self-hosting guidance
clearer. Merge the H2 sections re: self-hosting and cluster setup and
provide a clearer experience for users, with a table of cluster
components.
This commit is contained in:
Paul Gottschling
2026-04-22 17:18:07 +00:00
committed by GitHub
parent 88e883fd16
commit 149340f6d5
77 changed files with 343 additions and 220 deletions
+5 -5
View File
@@ -3015,7 +3015,7 @@ customers running **Teleport Enterprise Self-Hosted**. No action is required for
customers running Teleport Enterprise (Cloud) or Teleport Community Edition.
If, after updating to Teleport 16, you receive an error message regarding an
outdated license file, follow our step-by-step [guide](docs/pages/zero-trust-access/deploy-a-cluster/license.mdx)
outdated license file, follow our step-by-step [guide](docs/pages/installation/self-hosted/license.mdx)
to update your license file.
#### Multi-factor authentication is now required for local users
@@ -8590,7 +8590,7 @@ Learn more about [Teleport's RBAC Resources](docs/pages/zero-trust-access/authen
#### Cluster Labels
Teleport 5.0 also adds the ability to set labels on Trusted Clusters. The labels are set when creating a trusted cluster invite token. This lets teams use the same RBAC controls used on nodes to approve or deny access to clusters. This can be especially useful for MSPs that connect hundreds of customers' clusters - when combined with access workflows, cluster access can be delegated. Learn more by reviewing our [Truster Cluster Setup & RBAC Docs](docs/pages/zero-trust-access/deploy-a-cluster/trustedclusters.mdx)
Teleport 5.0 also adds the ability to set labels on Trusted Clusters. The labels are set when creating a trusted cluster invite token. This lets teams use the same RBAC controls used on nodes to approve or deny access to clusters. This can be especially useful for MSPs that connect hundreds of customers' clusters - when combined with access workflows, cluster access can be delegated. Learn more by reviewing our [Truster Cluster Setup & RBAC Docs](docs/pages/zero-trust-access/management/trustedclusters.mdx)
Creating a trusted cluster join token for a production environment:
@@ -8959,7 +8959,7 @@ the “prefix” config value when storing data. Upgrading from 4.2 to 4.3 will
migrate the data as needed at startup. Make sure you follow our Teleport
[upgrade guidance](docs/pages/upgrading/upgrading.mdx).
**Note: If you use an etcd backend with a non-default prefix and need to downgrade from 4.3 to 4.2, you should [backup Teleport data and restore it](docs/pages/zero-trust-access/deploy-a-cluster/reliability/backup-restore.mdx) into the downgraded cluster.**
**Note: If you use an etcd backend with a non-default prefix and need to downgrade from 4.3 to 4.2, you should [backup Teleport data and restore it](docs/pages/zero-trust-access/management/backup-restore.mdx) into the downgraded cluster.**
## 4.2.12
@@ -9081,7 +9081,7 @@ This is a minor Teleport release with a focus on new features and bug fixes.
* Alpha: Enhanced Session Recording lets you know what's really happening during a Teleport Session. [#2948](https://github.com/gravitational/teleport/issues/2948)
* Alpha: Workflows API lets admins escalate RBAC roles in response to user requests. [Read the docs](docs/pages/identity-governance/access-requests/access-requests.mdx). [#3006](https://github.com/gravitational/teleport/issues/3006)
* Beta: Teleport provides HA Support using Firestore and Google Cloud Storage using Google Cloud Platform. [Read the docs](docs/pages/zero-trust-access/deploy-a-cluster/deployments/gcp.mdx). [#2821](https://github.com/gravitational/teleport/pull/2821)
* Beta: Teleport provides HA Support using Firestore and Google Cloud Storage using Google Cloud Platform. [Read the docs](docs/pages/installation/self-hosted/deployments/gcp.mdx). [#2821](https://github.com/gravitational/teleport/pull/2821)
* Remote tctl execution is now possible. [Read the docs](./docs/pages/reference/cli/tctl.mdx). [#1525](https://github.com/gravitational/teleport/issues/1525) [#2991](https://github.com/gravitational/teleport/issues/2991)
### Fixes
@@ -9090,7 +9090,7 @@ This is a minor Teleport release with a focus on new features and bug fixes.
### Documentation
* Adopting root/leaf terminology for trusted clusters. [Trusted cluster documentation](docs/pages/zero-trust-access/deploy-a-cluster/trustedclusters.mdx).
* Adopting root/leaf terminology for trusted clusters. [Trusted cluster documentation](docs/pages/zero-trust-access/management/trustedclusters.mdx).
* Documented Teleport FedRAMP & FIPS Support. [FedRAMP & FIPS documentation](docs/pages/zero-trust-access/compliance-frameworks/fedramp.mdx).
## 4.1.13
+202 -47
View File
@@ -107,7 +107,7 @@
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/ibm/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/ibm/",
"destination": "/installation/self-hosted/helm-deployments/ibm/",
"permanent": true
},
{
@@ -932,7 +932,7 @@
},
{
"source": "/reference/architecture/proxy-peering/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/proxy-peering/",
"destination": "/zero-trust-access/management/proxy-peering/",
"permanent": true
},
{
@@ -1257,42 +1257,42 @@
},
{
"source": "/admin-guides/deploy-a-cluster/aws-kms/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/aws-kms/",
"destination": "/installation/self-hosted/private-keys/aws-kms/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/",
"destination": "/zero-trust-access/deploy-a-cluster/",
"destination": "/installation/self-hosted/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment/",
"destination": "/installation/self-hosted/deployments/aws-gslb-proxy-peering-ha-deployment/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/aws-ha-autoscale-cluster-terraform/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/aws-ha-autoscale-cluster-terraform/",
"destination": "/installation/self-hosted/deployments/aws-ha-autoscale-cluster-terraform/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/aws-starter-cluster-terraform/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/aws-starter-cluster-terraform/",
"destination": "/installation/self-hosted/deployments/aws-starter-cluster-terraform/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/",
"destination": "/installation/self-hosted/deployments/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/deployments/gcp/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/gcp/",
"destination": "/installation/self-hosted/deployments/gcp/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/gcp-kms/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/gcp-kms/",
"destination": "/installation/self-hosted/private-keys/gcp-kms/",
"permanent": true
},
{
@@ -1302,77 +1302,77 @@
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/aws/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/aws/",
"destination": "/installation/self-hosted/helm-deployments/aws/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/azure/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/azure/",
"destination": "/installation/self-hosted/helm-deployments/azure/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/custom/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/custom/",
"destination": "/installation/self-hosted/helm-deployments/custom/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/digitalocean/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/digitalocean/",
"destination": "/installation/self-hosted/helm-deployments/digitalocean/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/disaster-recovery/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/disaster-recovery/",
"destination": "/installation/self-hosted/helm-deployments/disaster-recovery/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/gcp/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/gcp/",
"destination": "/installation/self-hosted/helm-deployments/gcp/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/",
"destination": "/installation/self-hosted/helm-deployments/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/ibm/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/ibm/",
"destination": "/installation/self-hosted/helm-deployments/ibm/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/kubernetes-cluster/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/kubernetes-cluster/",
"destination": "/installation/self-hosted/helm-deployments/kubernetes-cluster/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp/",
"destination": "/installation/self-hosted/helm-deployments/migration-kubernetes-1-25-psp/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/high-availability/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/high-availability/",
"destination": "/installation/self-hosted/deployments/high-availability/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/hsm/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/hsm/",
"destination": "/installation/self-hosted/private-keys/hsm/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/license/",
"destination": "/zero-trust-access/deploy-a-cluster/license/",
"destination": "/installation/self-hosted/license/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/multi-region-blueprint/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/multi-region-blueprint/",
"destination": "/installation/self-hosted/deployments/multi-region-blueprint/",
"permanent": true
},
{
"source": "/admin-guides/deploy-a-cluster/separate-proxy-service-endpoints/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/separate-proxy-service-endpoints/",
"destination": "/installation/self-hosted/deployments/separate-proxy-service-endpoints/",
"permanent": true
},
{
@@ -1392,7 +1392,7 @@
},
{
"source": "/admin-guides/management/admin/self-signed-certs/",
"destination": "/zero-trust-access/deploy-a-cluster/self-signed-certs/",
"destination": "/installation/self-hosted/self-signed-certs/",
"permanent": true
},
{
@@ -1402,7 +1402,7 @@
},
{
"source": "/admin-guides/management/admin/trustedclusters/",
"destination": "/zero-trust-access/deploy-a-cluster/trustedclusters/",
"destination": "/zero-trust-access/management/trustedclusters/",
"permanent": true
},
{
@@ -1562,12 +1562,12 @@
},
{
"source": "/admin-guides/management/operations/backup-restore/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/backup-restore/",
"destination": "/zero-trust-access/management/backup-restore/",
"permanent": true
},
{
"source": "/zero-trust-access/management/operations/breakglass-access/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/breakglass-access/",
"destination": "/zero-trust-access/management/breakglass-access/",
"permanent": true
},
{
@@ -1587,7 +1587,7 @@
},
{
"source": "/admin-guides/management/operations/proxy-peering/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/proxy-peering/",
"destination": "/zero-trust-access/management/proxy-peering/",
"permanent": true
},
{
@@ -1597,7 +1597,7 @@
},
{
"source": "/admin-guides/management/operations/tls-routing/",
"destination": "/zero-trust-access/deploy-a-cluster/tls-routing/",
"destination": "/zero-trust-access/management/tls-routing/",
"permanent": true
},
{
@@ -2667,12 +2667,12 @@
},
{
"source": "/zero-trust-access/deploy-a-cluster/aws-kms/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/aws-kms/",
"destination": "/installation/self-hosted/private-keys/aws-kms/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/gcp-kms/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/gcp-kms/",
"destination": "/installation/self-hosted/private-keys/gcp-kms/",
"permanent": true
},
{
@@ -3082,17 +3082,17 @@
},
{
"source": "/zero-trust-access/deploy-a-cluster/high-availability/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/high-availability/",
"destination": "/installation/self-hosted/deployments/high-availability/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/multi-region-blueprint/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/multi-region-blueprint/",
"destination": "/installation/self-hosted/deployments/multi-region-blueprint/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/separate-proxy-service-endpoints/",
"destination": "/zero-trust-access/deploy-a-cluster/deployments/separate-proxy-service-endpoints/",
"destination": "/installation/self-hosted/deployments/separate-proxy-service-endpoints/",
"permanent": true
},
{
@@ -3422,17 +3422,17 @@
},
{
"source": "/zero-trust-access/management/admin/self-signed-certs/",
"destination": "/zero-trust-access/deploy-a-cluster/self-signed-certs/",
"destination": "/installation/self-hosted/self-signed-certs/",
"permanent": true
},
{
"source": "/zero-trust-access/management/admin/trustedclusters/",
"destination": "/zero-trust-access/deploy-a-cluster/trustedclusters/",
"destination": "/zero-trust-access/management/trustedclusters/",
"permanent": true
},
{
"source": "/zero-trust-access/management/operations/tls-routing/",
"destination": "/zero-trust-access/deploy-a-cluster/tls-routing/",
"destination": "/zero-trust-access/management/tls-routing/",
"permanent": true
},
{
@@ -3447,7 +3447,7 @@
},
{
"source": "/zero-trust-access/management/operations/backup-restore/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/backup-restore/",
"destination": "/zero-trust-access/management/backup-restore/",
"permanent": true
},
{
@@ -3457,7 +3457,7 @@
},
{
"source": "/zero-trust-access/management/operations/proxy-peering/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/proxy-peering/",
"destination": "/zero-trust-access/management/proxy-peering/",
"permanent": true
},
{
@@ -3472,7 +3472,7 @@
},
{
"source": "/zero-trust-access/management/admin/trusted-cluster-address-lookup/",
"destination": "/zero-trust-access/deploy-a-cluster/trustedclusters/",
"destination": "/zero-trust-access/management/trustedclusters/",
"permanent": true
},
{
@@ -3482,22 +3482,22 @@
},
{
"source": "/zero-trust-access/deploy-a-cluster/hsm/",
"destination": "/zero-trust-access/deploy-a-cluster/private-keys/hsm/",
"destination": "/installation/self-hosted/private-keys/hsm/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/backup-restore/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/backup-restore/",
"destination": "/zero-trust-access/management/backup-restore/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/breakglass-access/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/breakglass-access/",
"destination": "/zero-trust-access/management/breakglass-access/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/proxy-peering/",
"destination": "/zero-trust-access/deploy-a-cluster/reliability/proxy-peering/",
"destination": "/zero-trust-access/management/proxy-peering/",
"permanent": true
},
{
@@ -3547,7 +3547,7 @@
},
{
"source": "/installation/helm/",
"destination": "/zero-trust-access/deploy-a-cluster/helm-deployments/",
"destination": "/installation/self-hosted/helm-deployments/",
"permanent": true
},
{
@@ -3629,6 +3629,161 @@
"source": "/installation/single-machine/amazon-ecs/",
"destination": "/installation/agents/amazon-ecs/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/trustedclusters/",
"destination": "/zero-trust-access/management/trustedclusters/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/tls-routing/",
"destination": "/zero-trust-access/management/tls-routing/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/reliability/backup-restore/",
"destination": "/zero-trust-access/management/backup-restore/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/reliability/breakglass-access/",
"destination": "/zero-trust-access/management/breakglass-access/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/reliability/proxy-peering/",
"destination": "/zero-trust-access/management/proxy-peering/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/reliability/",
"destination": "/installation/self-hosted/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/",
"destination": "/installation/self-hosted/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment/",
"destination": "/installation/self-hosted/deployments/aws-gslb-proxy-peering-ha-deployment/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/aws-ha-autoscale-cluster-terraform/",
"destination": "/installation/self-hosted/deployments/aws-ha-autoscale-cluster-terraform/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/aws-starter-cluster-terraform/",
"destination": "/installation/self-hosted/deployments/aws-starter-cluster-terraform/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/",
"destination": "/installation/self-hosted/deployments/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/gcp/",
"destination": "/installation/self-hosted/deployments/gcp/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/high-availability/",
"destination": "/installation/self-hosted/deployments/high-availability/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/multi-region-blueprint/",
"destination": "/installation/self-hosted/deployments/multi-region-blueprint/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/deployments/separate-proxy-service-endpoints/",
"destination": "/installation/self-hosted/deployments/separate-proxy-service-endpoints/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/aws/",
"destination": "/installation/self-hosted/helm-deployments/aws/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/azure/",
"destination": "/installation/self-hosted/helm-deployments/azure/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/custom/",
"destination": "/installation/self-hosted/helm-deployments/custom/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/digitalocean/",
"destination": "/installation/self-hosted/helm-deployments/digitalocean/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/disaster-recovery/",
"destination": "/installation/self-hosted/helm-deployments/disaster-recovery/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/gcp/",
"destination": "/installation/self-hosted/helm-deployments/gcp/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/",
"destination": "/installation/self-hosted/helm-deployments/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/ibm/",
"destination": "/installation/self-hosted/helm-deployments/ibm/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/kubernetes-cluster/",
"destination": "/installation/self-hosted/helm-deployments/kubernetes-cluster/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp/",
"destination": "/installation/self-hosted/helm-deployments/migration-kubernetes-1-25-psp/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/license/",
"destination": "/installation/self-hosted/license/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/private-keys/aws-kms/",
"destination": "/installation/self-hosted/private-keys/aws-kms/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/private-keys/gcp-kms/",
"destination": "/installation/self-hosted/private-keys/gcp-kms/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/private-keys/hsm/",
"destination": "/installation/self-hosted/private-keys/hsm/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/private-keys/",
"destination": "/installation/self-hosted/private-keys/",
"permanent": true
},
{
"source": "/zero-trust-access/deploy-a-cluster/self-signed-certs/",
"destination": "/installation/self-hosted/self-signed-certs/",
"permanent": true
}
]
}
@@ -226,7 +226,7 @@ this by setting the environment variables `TELEPORT_PROXY` and `TELEPORT_CLUSTER
Additionally, Teleport Connect prepends the `PATH` environment variable in the session with the
directory containing the tsh binary, even if [tsh is not globally available](#using-tsh-outside-of-teleport-connect).
When using [trusted clusters](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx), the cluster selector allows
When using [trusted clusters](../../zero-trust-access/management/trustedclusters.mdx), the cluster selector allows
you to determine which cluster the shell session will be bound to. The selected cluster will be
reflected in both the tab title and the status bar.
@@ -855,7 +855,7 @@ see them only after you restart the app.
You can open Teleport Connect in insecure mode, which skips TLS certificate verification when
talking to a Teleport Proxy Service. This is useful in [test environments with self-signed
certificates](../../zero-trust-access/deploy-a-cluster/self-signed-certs.mdx) or for demo purposes. We do not recommend
certificates](../../installation/self-hosted/self-signed-certs.mdx) or for demo purposes. We do not recommend
using this mode in production.
<Tabs>
@@ -697,7 +697,7 @@ Teleport supports creating clusters of servers located behind firewalls
tunnels from behind-firewall environments into a Teleport Proxy Service you have access to.
To learn more about setting up a trust relationship between clusters behind firewalls, see
[Configure Trusted Clusters](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx).
[Configure Trusted Clusters](../../zero-trust-access/management/trustedclusters.mdx).
<Admonition type="note" >
Trusted clusters are only available for self-hosted Teleport clusters.
+1 -1
View File
@@ -124,7 +124,7 @@ your GUI client below. When entering the hostname, use `localhost` rather than
### Remote host and port
If you are self-hosting Teleport and not using [TLS
routing](../../zero-trust-access/deploy-a-cluster/tls-routing.mdx), run the
routing](../../zero-trust-access/management/tls-routing.mdx), run the
following command to see the database connection information:
```code
+2 -2
View File
@@ -180,7 +180,7 @@ 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](zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx) on
[Read the documentation](installation/self-hosted/self-hosted.mdx) on
self-hosting Teleport.
### Teleport Community Edition
@@ -251,7 +251,7 @@ users, roles, and resources, but the trust relationship allows users with certai
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](zero-trust-access/deploy-a-cluster/trustedclusters.mdx). For an overview of the architecture used in a trusted cluster relationship, see [Trusted Cluster Architecture](reference/architecture/trustedclusters.mdx).
see [Configure Trusted Clusters](zero-trust-access/management/trustedclusters.mdx). For an overview of the architecture used in a trusted cluster relationship, see [Trusted Cluster Architecture](reference/architecture/trustedclusters.mdx).
## Teleport clients
@@ -136,7 +136,7 @@ an address for the TUN device from a range offered by one of those clusters.
### Configuring leaf cluster apps
To make a [leaf cluster](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx) app accessible over a custom
To make a [leaf cluster](../../zero-trust-access/management/trustedclusters.mdx) app accessible over a custom
`public_addr`, you need to follow the same steps while being logged in directly to the leaf cluster.
```code
@@ -162,7 +162,7 @@ access see the [RBAC](../database-access/rbac.mdx) documentation.
When TLS Routing is disable by default, the Teleport Proxy Service returns `8.0.0-Teleport` as the MySQL server version. In some cases, like connecting with a GUI Client, this can result in obtaining an `Unknown system variable 'query_cache_size'` error that indicates that MySQL capabilities were not properly negotiated between the MySQL client and server.
One way to solve this issue is to [use the TLS Routing
feature](../../zero-trust-access/deploy-a-cluster/tls-routing.mdx), where the Teleport Proxy
feature](../../zero-trust-access/management/tls-routing.mdx), where the Teleport Proxy
Service propagates the correct MySQL server version via TLS Routing extensions.
If migration to TLS Routing is not possible, another way to bypass this error is
@@ -20,7 +20,7 @@ Teleport provides secure access to Kubernetes clusters:
The guides in this section show you how to protect Kubernetes clusters with
Teleport. For instructions on self-hosting Teleport Community Edition or
Teleport Enterprise on Kubernetes, see the [Kubernetes Deployment
Guides](../../zero-trust-access/deploy-a-cluster/helm-deployments/helm-deployments.mdx).
Guides](../../installation/self-hosted/helm-deployments/helm-deployments.mdx).
Here is an example of using Teleport to access a Kubernetes cluster, execute
commands, and view your `kubectl` activity in Teleport's audit log:
@@ -57,9 +57,9 @@ Session recording encryption keys are provisioned using the same key storage
backend configured for CAs. Software keys stored in Teleport's backend storage
are the default, but other backends can also be configured:
- [AWS KMS](../../../../zero-trust-access/deploy-a-cluster/private-keys/aws-kms.mdx)
- [Google Cloud KMS](../../../../zero-trust-access/deploy-a-cluster/private-keys/gcp-kms.mdx)
- [HSM](../../../../zero-trust-access/deploy-a-cluster/private-keys/hsm.mdx)
- [AWS KMS](../../../../installation/self-hosted/private-keys/aws-kms.mdx)
- [Google Cloud KMS](../../../../installation/self-hosted/private-keys/gcp-kms.mdx)
- [HSM](../../../../installation/self-hosted/private-keys/hsm.mdx)
If your cluster is already configured to use any of these backends, you should
ensure Teleport has permission to use their decryption functions. For example,
+1 -1
View File
@@ -20,7 +20,7 @@ the stability of Teleport from a security perspective.
## Can I connect to nodes behind a firewall?
Yes, Teleport supports reverse SSH tunnels out of the box. To configure
behind-firewall clusters, see [Configure Trusted Clusters](zero-trust-access/deploy-a-cluster/trustedclusters.mdx).
behind-firewall clusters, see [Configure Trusted Clusters](zero-trust-access/management/trustedclusters.mdx).
## How is Teleport's Community Edition different from Enterprise?
+2 -2
View File
@@ -162,7 +162,7 @@ and non-human identities.
| ITSM: ServiceNow, JIRA | ✔ | ✔ | ✖ |
| Access Request Integration: Slack, Teams, Discord, Mattermost, PagerDuty, Opsgenie, Email | ✔ | ✔ | ✔ |
| [Hardware Private Key Support](zero-trust-access/authentication/hardware-key-support.mdx) (e.g., via YubiKey) | ✔ (External-connected HSM/KMS coming soon) | ✔ | ✖ |
| [Hardware Security Module support](zero-trust-access/deploy-a-cluster/private-keys/hsm.mdx) for encryption at rest | ✔ (External-connected HSM/KMS coming soon) | ✔ | ✖ |
| [Hardware Security Module support](installation/self-hosted/private-keys/hsm.mdx) for encryption at rest | ✔ (External-connected HSM/KMS coming soon) | ✔ | ✖ |
| **Management and licensing:** ||||
| Annual or multi-year contracts, volume discounts | ✔ | ✔ | ✖ |
| Anonymized Usage Tracking | ✔ | ✔ | Opt-in |
@@ -176,6 +176,6 @@ and non-human identities.
| **Deployment options:** ||||
| Teleport cloud deployment | ✔ | ✖ | ✖ |
| Self-hosted deployment| ✖ | ✔ | ✔ |
| Multi-Region High Availability | ✔ (Teleport service) | ✔ (Customer-implemented, via a [supported blueprint](zero-trust-access/deploy-a-cluster/deployments/multi-region-blueprint.mdx)) | ✖ |
| Multi-Region High Availability | ✔ (Teleport service) | ✔ (Customer-implemented, via a [supported blueprint](installation/self-hosted/deployments/multi-region-blueprint.mdx)) | ✖ |
| FIPS-compliant binaries available for FedRAMP, including Low, Moderate & High | ✖ | ✔ | ✖ |
@@ -39,7 +39,7 @@ chart.
- Helm >= (=helm.version=)
- A running Teleport Enterprise cluster v18.0.0 or later.
- For the purposes of this guide, we assume that the Teleport cluster is set up
[using the `teleport-cluster` Helm chart](../../zero-trust-access/deploy-a-cluster/helm-deployments/helm-deployments.mdx)
[using the `teleport-cluster` Helm chart](../../installation/self-hosted/helm-deployments/helm-deployments.mdx)
in the same Kubernetes cluster that will be used to deploy Access Graph.
- An updated Teleport Enterprise license file with Teleport Identity Security enabled.
- A PostgreSQL database server v14 or later.
@@ -9,7 +9,7 @@ certificates, however Teleport requires TLS certificates not only for
authentication, but also to route database connections.
If you
[enable TLS Routing in Teleport](../../zero-trust-access/deploy-a-cluster/tls-routing.mdx)
[enable TLS Routing in Teleport](../../zero-trust-access/management/tls-routing.mdx)
then `tsh db connect` will automatically start a local proxy for every
connection.
Alternatively, you can connect via
@@ -934,7 +934,7 @@ PodSecurityPolicy resources (PSP) have been removed in Kubernetes 1.25
and replaced since 1.23 by PodSecurityAdmission (PSA). If you are running on
Kubernetes 1.23 or later, it is recommended to disable PSPs and use PSAs.
The steps are documented in the
[PSP removal guide](../../zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp.mdx).
[PSP removal guide](../../installation/self-hosted/helm-deployments/migration-kubernetes-1-25-psp.mdx).
This value will be removed in a future chart version.
+2 -3
View File
@@ -1,12 +1,11 @@
---
title: Joining Teleport Agents
sidebar_label: Teleport Agents
title: Deploying Teleport Agents
sidebar_label: Deploying Agents
description: Deploy Agents to enroll resources in your infrastructure with Teleport. You can run multiple Teleport services per Agent.
tags:
- how-to
- zero-trust
- infrastructure-identity
sidebar_position: 2
---
You can use Teleport to protect infrastructure resources like servers and
@@ -366,4 +366,4 @@ $ tctl tokens rm <Var name="token-to-delete"/>
## Next steps
- If you have workloads split across different networks or clouds, we recommend
setting up trusted clusters. Read how to get started in [Configure Trusted Clusters](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx).
setting up trusted clusters. Read how to get started in [Configure Trusted Clusters](../../zero-trust-access/management/trustedclusters.mdx).
@@ -34,7 +34,7 @@ as the Auth Service.
## Prerequisites
- A running Teleport cluster in Kubernetes. For details on how to set this up,
see [Guides for running Teleport using Helm](../../zero-trust-access/deploy-a-cluster/helm-deployments/helm-deployments.mdx).
see [Guides for running Teleport using Helm](../self-hosted/helm-deployments/helm-deployments.mdx).
- Editor access to the Kubernetes cluster running the Teleport cluster.
You must be able to create Namespaces and Deployments.
- A Teleport user with `access` role, or any other role that allows access to
+22 -25
View File
@@ -15,13 +15,6 @@ you install Teleport depends on:
- If you are self-hosting, how you choose to deploy the Teleport Auth Service
and Proxy Service
## Client tools
If you want to download client tools to access Teleport from your workstation,
visit [Download Client Tools](https://goteleport.com/download/client-tools/).
This page also includes client tool downloads for Windows, which does not
support the `teleport` daemon.
## Teleport cluster setup
The easiest way to get started with Teleport is to [sign
@@ -29,29 +22,33 @@ up](https://goteleport.com/signup/) for a Teleport Cloud account. From there,
you can [install Teleport Agents](agents/agents.mdx) so you can enroll your
infrastructure with Teleport.
For instructions on installing a `teleport` binary on a single machine, see
[Install Teleport on a Single Machine](single-machine/single-machine.mdx). The
Teleport Auth Service, Teleport Proxy Service, and Teleport Agent services all
share a binary, though you will need to create a configuration file for each
instance and configure them to communicate with one another as a cluster.
## Self-hosted Teleport clusters
Read [Deploy Teleport Community
Edition](../get-started/deploy-community.mdx) to get started with a
small self-hosted demo cluster.
Read [Deploy Teleport Community Edition](../get-started/deploy-community.mdx) to
get started with a small self-hosted demo cluster.
For self-hosted Teleport Enterprise accounts, deployments typically take place
in conversation with the team at Teleport. We recommend [reaching out to us
directly](https://goteleport.com/contact-us/) to learn more about getting
started with this deployment option and start planning your approach.
started with this deployment option and start planning your approach. You can
read more about setting up a self-hosted cluster in [Deploy a
Cluster](self-hosted/self-hosted.mdx).
You can read more about setting up a self-hosted cluster in [Deploy a
Cluster](../zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx).
## Client tools
## Other installation scenarios
Visit [Download Client Tools](https://goteleport.com/download/client-tools/) to
download the latest versions of `tsh` and `tctl` for your platform.
- [Installing `tbot`](../machine-workload-identity/deployment/deployment.mdx)
- [Teleport Event Handler](../zero-trust-access/export-audit-events/export-audit-events.mdx)
- [Access Request Plugins](../identity-governance/access-requests/plugins/plugins.mdx)
You can learn about the available client tool binaries, and other binaries
available in a Teleport installation, by reading [Installing Teleport on a
Single Machine](single-machine/single-machine.mdx).
## Cluster components
Besides Teleport Agents, you can install other cluster components to protect your
infrastructure with Teleport:
|Component|Installation|
|---|---|
|[`tbot` daemon](../machine-workload-identity/deployment/deployment.mdx)|Enables automated services and workloads to connect to Teleport-protected resources. |
|[Teleport Event Handler](../zero-trust-access/export-audit-events/export-audit-events.mdx)|Exports Teleport audit events to a third-party log-management solution|
|[Access Request Plugins](../identity-governance/access-requests/plugins/plugins.mdx)|Allow users to create and review Access Requests with third-party communication services|
@@ -20,7 +20,7 @@ the [Multi-region Blueprint](./multi-region-blueprint.mdx).
It features two important design decisions:
- Amazon Route 53 latency-based routing is used to ensure that users and agents connect to the closest available proxy.
- Teleport's [Proxy Peering](../reliability/proxy-peering.mdx) is used to reduce the total number of tunnel connections in the Teleport cluster.
- Teleport's [Proxy Peering](../../../zero-trust-access/management/proxy-peering.mdx) is used to reduce the total number of tunnel connections in the Teleport cluster.
This deployment architecture isn't recommended for use cases where your users or resources are
clustered in a single region, or for Managed Service Providers needing to provide separate clusters
@@ -41,7 +41,7 @@ deployment.
- High-availability Auto Scaling group of Proxy Service instances deployed across multiple regions
- [Amazon Route 53 latency-based routing](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html)
- [Teleport TLS Routing](../../../reference/architecture/tls-routing.mdx) to reduce the number of ports needed to use Teleport
- [Teleport Proxy Peering](../reliability/proxy-peering.mdx) for reducing the number of resource connections
- [Teleport Proxy Peering](../../../zero-trust-access/management/proxy-peering.mdx) for reducing the number of resource connections
- [AWS Network Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
- [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) for cluster state storage
- [AWS S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) for session recording storage
@@ -196,7 +196,7 @@ additional settings.
## Configure Proxy Peering
In this deployment architecture, [Proxy Peering](../reliability/proxy-peering.mdx) is used to restrict the number of connections made from
In this deployment architecture, [Proxy Peering](../../../zero-trust-access/management/proxy-peering.mdx) is used to restrict the number of connections made from
resources to proxies in the Teleport Cluster.
### Auth Service Proxy Peering configuration
@@ -872,7 +872,7 @@ spec:
```
You can generate a token for adding the trusted cluster using `tctl tokens add --type=trusted_cluster` after connecting
to a Teleport Auth Service instance. Follow the instructions in our [Trusted Clusters guide](../trustedclusters.mdx).
to a Teleport Auth Service instance. Follow the instructions in our [Trusted Clusters guide](../../../zero-trust-access/management/trustedclusters.mdx).
## Script to quickly connect to instances
@@ -70,7 +70,7 @@ GCP relies heavily on [Health Checks](https://cloud.google.com/load-balancing/do
this is helpful when adding new instances to an instance group.
To enable health checks in Teleport start with `teleport start --diag-addr=0.0.0.0:3000`
see [Admin Guide: Troubleshooting](../../management/diagnostics/troubleshooting.mdx) for more information.
see [Admin Guide: Troubleshooting](../../../zero-trust-access/management/diagnostics/troubleshooting.mdx) for more information.
### Storage: Cloud Firestore
@@ -352,6 +352,6 @@ proxy_service:
**4. Add Users**
Follow our [Local Users](../../rbac-get-started/users.mdx) guide or integrate
with [Google Workspace](../../sso/integrate-idp/google-workspace.mdx) to
Follow our [Local Users](../../../zero-trust-access/rbac-get-started/users.mdx) guide or integrate
with [Google Workspace](../../../zero-trust-access/sso/integrate-idp/google-workspace.mdx) to
provide SSO access.
@@ -75,7 +75,7 @@ solution) to ensure availability.
#### TLS Routing
The way you configure the Proxy Service load balancer depends on whether you
will enable [TLS Routing](../tls-routing.mdx) in your
will enable [TLS Routing](../../../zero-trust-access/management/tls-routing.mdx) in your
Teleport cluster.
With TLS Routing, the Teleport Proxy Service uses application-layer protocol
@@ -555,7 +555,7 @@ You should also get familiar with how to ensure that your Teleport deployment is
performing as expected:
- [Scaling a Teleport cluster](../../../reference/deployment/scaling.mdx)
- [Monitoring a Teleport cluster](../../management/diagnostics/diagnostics.mdx)
- [Monitoring a Teleport cluster](../../../zero-trust-access/management/diagnostics/diagnostics.mdx)
### Deploy Teleport services
@@ -55,7 +55,7 @@ for more details.
A multi-region Teleport deployment is composed of several regional Teleport
deployments. Teleport stores its state in a multi-region backend and uses
[Proxy Peering](../reliability/proxy-peering.mdx) to connect users to resources
[Proxy Peering](../../../zero-trust-access/management/proxy-peering.mdx) to connect users to resources
hosted in a different region.
The only option for a multi-region backend is [the CockroachDB
@@ -603,7 +603,7 @@ followed above:
## Next steps
Now that you have deployed a Teleport cluster, read the [Manage
Access](../../authentication/authentication.mdx) section to get started enrolling
Access](../../../zero-trust-access/authentication/authentication.mdx) section to get started enrolling
users and setting up RBAC.
See the [high availability section of our Helm chart reference](../../../reference/helm-reference/teleport-cluster.mdx) for more details on high availability.
@@ -372,7 +372,7 @@ $ helm --namespace <Var name="teleport-ns" /> uninstall <Var name="teleport-rele
## Next steps
Now that you have deployed a Teleport cluster, read the [Manage
Access](../../authentication/authentication.mdx) section to get started enrolling
Access](../../../zero-trust-access/authentication/authentication.mdx) section to get started enrolling
users and setting up RBAC.
See the [high availability section of our Helm chart reference](../../../reference/helm-reference/teleport-cluster.mdx) for more details on high availability.
@@ -278,7 +278,7 @@ install a new version with the appropriate values.
## Next steps
Now that you have deployed a Teleport cluster, read the [Manage
Access](../../authentication/authentication.mdx) section to get started enrolling
Access](../../../zero-trust-access/authentication/authentication.mdx) section to get started enrolling
users and setting up RBAC.
To see all of the options you can set in the values file for the
@@ -346,7 +346,7 @@ $ tctl get lock --format=json \
## Further reading
- Read the [Backup and Restore](../reliability/backup-restore.mdx)
- Read the [Backup and Restore](../../../zero-trust-access/management/backup-restore.mdx)
guide for general information on backing up your Teleport cluster backends.
- For more information on preventing Teleport roles from making changes to your
cluster state backend, read [Session and Identity
@@ -505,7 +505,7 @@ $ helm --namespace cert-manager uninstall cert-manager
## Next steps
Now that you have deployed a Teleport cluster, read the [Manage
Access](../../authentication/authentication.mdx) section to get started enrolling
Access](../../../zero-trust-access/authentication/authentication.mdx) section to get started enrolling
users and setting up RBAC.
See the [high availability section of our Helm chart reference](../../../reference/helm-reference/teleport-cluster.mdx) for more details on high availability.
@@ -319,4 +319,4 @@ As next steps you can:
[applications](../../../enroll-resources/application-access/getting-started.mdx),
or [Windows desktops](../../../enroll-resources/desktop-access/desktop-access.mdx) into your Teleport cluster
- check the [`teleport-cluster` Helm reference](../../../reference/helm-reference/teleport-cluster.mdx) for a list of supported values
- use [the Teleport Kubernetes operator](../../infrastructure-as-code/teleport-operator/teleport-operator.mdx) to control Teleport resources
- use [the Teleport Kubernetes operator](../../../zero-trust-access/infrastructure-as-code/teleport-operator/teleport-operator.mdx) to control Teleport resources
@@ -255,5 +255,5 @@ their Teleport roles will also see a cluster alert reminding them to rotate the
CAs.
CA rotation can be performed manually or semi-automatically. See our admin guide
on [Certificate rotation](../../management/security/ca-rotation.mdx).
on [Certificate rotation](../../../zero-trust-access/management/security/ca-rotation.mdx).
All CAs listed in the output of `tctl status` must be rotated.
@@ -267,5 +267,5 @@ their Teleport roles will also see a cluster alert reminding them to rotate the
CAs.
CA rotation can be performed manually or semi-automatically, see our admin guide
on [Certificate rotation](../../management/security/ca-rotation.mdx).
on [Certificate rotation](../../../zero-trust-access/management/security/ca-rotation.mdx).
All CAs listed in the output of `tctl status` must be rotated.
@@ -14,7 +14,7 @@ hardware security module (HSM) to store and handle private keys.
## How it works
The Teleport Auth Service maintains several [certificate
authorities](../../management/security/ca-rotation.mdx) that it
authorities](../../../zero-trust-access/management/security/ca-rotation.mdx) that it
uses for critical cluster operations, such as issuing certificates to users to
authenticate to Teleport-protected resources. Each certificate authority uses a
private key to sign certificates. On self-hosted clusters, you can instruct the
@@ -368,7 +368,7 @@ their Teleport roles will also see a cluster alert reminding them to rotate the
CAs.
CA rotation can be performed manually or semi-automatically. See our admin guide
on [Certificate rotation](../../management/security/ca-rotation.mdx).
on [Certificate rotation](../../../zero-trust-access/management/security/ca-rotation.mdx).
All CAs listed in the output of `tctl status` must be rotated.
## Step 5/5. Confirm that Teleport is using your HSM
@@ -1,8 +1,8 @@
---
title: Self-Hosting Teleport
sidebar_label: Self-Hosting
sidebar_position: 6
description: "Guides to running a self-hosted Teleport cluster in production."
sidebar_position: 3
tags:
- platform-wide
---
@@ -57,7 +57,7 @@ For example, this Teleport Proxy Service configuration would use self-signed cer
scope={["enterprise"]} label="Enterprise">
- A running Teleport cluster. For details on how to set this up, see our Enterprise
[Getting Started](deploy-a-cluster.mdx) guide.
[Getting Started](self-hosted.mdx) guide.
- A Teleport Proxy Service which does not have certificates or ACME automatic certificates configured.
For example, this Teleport Proxy Service configuration would use self-signed certs:
@@ -1,6 +1,7 @@
---
title: Installing Teleport on Amazon EC2
description: Deploy Teleport on Amazon EC2 using pre-built AMIs with Teleport pre-installed, either with Terraform or manual configuration.
sidebar_label: Amazon EC2
tags:
- platform-wide
- reference
@@ -13,8 +14,8 @@ Teleport pre-installed.
These images are primarily intended for deploying a Teleport cluster using our
[reference Terraform code](https://github.com/gravitational/teleport/tree/branch/v(=teleport.major_version=)/examples/aws/terraform).
See the [AWS Single-Instance Deployment](../../zero-trust-access/deploy-a-cluster/deployments/aws-starter-cluster-terraform.mdx)
and the [Running Teleport Enterprise in High Availability mode on AWS using Terraform](../../zero-trust-access/deploy-a-cluster/deployments/aws-ha-autoscale-cluster-terraform.mdx)
See the [AWS Single-Instance Deployment](../self-hosted/deployments/aws-starter-cluster-terraform.mdx)
and the [Running Teleport Enterprise in High Availability mode on AWS using Terraform](../self-hosted/deployments/aws-ha-autoscale-cluster-terraform.mdx)
guides for detailed usage examples.
<Admonition type="warning">
@@ -46,7 +46,7 @@ script, which finds an appropriate package manager and uses it to install the
If you are self-hosting a Teleport cluster, take a look at our [Linux
Demo](../../get-started/deploy-community.mdx) for the Teleport Community Edition or
our [Self-Hosting
Teleport](../../zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx) section in
Teleport](../self-hosted/self-hosted.mdx) section in
the docs for more information on Self-Hosted Teleport Enterprise.
</Admonition>
@@ -117,7 +117,7 @@ See the following guides for help setting up a configuration file:
Teleport configuration file as well as further configuration options for your
cluster.
- [Self-Hosted Demo
Cluster](../../zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx): If
Cluster](../self-hosted/self-hosted.mdx): If
you are deploying the Teleport Auth Service and Proxy Service, read this guide
for an example of a configuration file.
@@ -213,7 +213,7 @@ See the following guides for examples of setting up a configuration file:
up Teleport Agents in order to enroll infrastructure resources in your cluster. These
guides include examples of setting up Teleport configuration files.
- [Self-Hosted Demo
Cluster](../../zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx): If you are
Cluster](../self-hosted/self-hosted.mdx): If you are
deploying the Teleport Auth Service and Proxy Service, read this guide for an
example of a configuration file.
- [Teleport Configuration Reference](../../reference/deployment/config.mdx): A guide to all
@@ -537,4 +537,4 @@ On cloud-hosted Teleport Enterprise you can visit a download page in the Web UI.
Select the user name in the upper right and select Downloads from the menu.
Customers who self-host Teleport Enterprise can access Enterprise downloads and their license
file from their [dedicated account dashboard](../../zero-trust-access/deploy-a-cluster/license.mdx).
file from their [dedicated account dashboard](../self-hosted/license.mdx).
@@ -163,7 +163,7 @@ macOS is primarily used for client access and local development. For production
For guidance on configuring and running Teleport, see:
- [Teleport daemon on macOS via launchd](../../enroll-resources/server-access/macos-launchd.mdx)
- [Deploy a Cluster](../../zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx) for self-hosted deployments
- [Deploy a Cluster](../self-hosted/self-hosted.mdx) for self-hosted deployments
- [Machine ID Getting Started](../../machine-workload-identity/workload-identity/getting-started.mdx) for workload identity
<Admonition type="danger">
@@ -1,7 +1,7 @@
---
title: Installing Teleport on a Single Machine
sidebar_label: Single Machine
description: How to install Teleport and Teleport's client tools on your platform, including binaries and instructions for Docker and Helm.
description: How to install Teleport and Teleport's client tools on your platform, including binaries and instructions for Docker.
videoBanner: fjk29wqXm1A
tags:
- reference
@@ -1,5 +1,6 @@
---
title: Installing Teleport on Windows
sidebar_label: Windows
description: How to install Teleport's client tools (tsh, tctl, tbot) and Teleport Connect on Windows.
tags:
- reference
@@ -1,7 +1,8 @@
---
title: Uninstall Teleport
sidebar_label: Uninstalling
description: How to remove Teleport from your system
sidebar_position: 3
sidebar_position: 4
tags:
- how-to
- platform-wide
+3 -3
View File
@@ -14,7 +14,7 @@ We recommend that you try out a Teleport [demo
cluster](./get-started/deploy-community.mdx) with Teleport Community Edition,
migrate to [Teleport Enterprise (Cloud)](./get-started/deploy-cloud.mdx) to roll out
Teleport across your organization, and deploy a
[self-hosted](zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx) Teleport Enterprise cluster
[self-hosted](installation/self-hosted/self-hosted.mdx) Teleport Enterprise cluster
if you have security and compliance requirements that Teleport Enterprise
(Cloud) cannot address.
@@ -72,7 +72,7 @@ migrating from Teleport Enterprise to Teleport Community Edition.
1. If you are migrating to a self-hosted Teleport Enterprise account, plan and
execute the deployment with the help of your Account Management team. To
assist with this, read the documentation on [Self-Hosting
Teleport](zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx).
Teleport](installation/self-hosted/self-hosted.mdx).
1. Ensure you are running Teleport Enterprise agents with versions that are
the same major or just one major version lower than the new Teleport
@@ -402,4 +402,4 @@ documentation on [signing up for a cloud-hosted Teleport Enterprise
account](./get-started/deploy-cloud.mdx).
Read the documentation on [Self-Hosting Teleport
Enterprise](zero-trust-access/deploy-a-cluster/deploy-a-cluster.mdx).
Enterprise](installation/self-hosted/self-hosted.mdx).
@@ -764,7 +764,7 @@ Labels for resources enrolled with Teleport:
|Role Field|Teleport Resource|
|---|---|
|`app_labels`|[Applications](../../enroll-resources/application-access/configuration/controls.mdx)|
|`cluster_labels`|[Trusted Clusters](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx)|
|`cluster_labels`|[Trusted Clusters](../../zero-trust-access/management/trustedclusters.mdx)|
|`db_labels`|[Databases](../../enroll-resources/database-access/rbac.mdx)|
|`db_service_labels`|[Database Service](../../enroll-resources/database-access/database-access.mdx) instances|
|`kubernetes_labels`|[Kubernetes clusters](../../enroll-resources/kubernetes-access/controls.mdx)|
@@ -820,7 +820,7 @@ sign-on provider.
|`{{internal.jwt}}`|JWT header used for app access.|
|`{{internal.kubernetes_groups}}`|List of allowed Kubernetes groups for the user.|
|`{{internal.kubernetes_users}}`|List of allowed Kubernetes users for the user.|
|`{{internal.logins}}` | Substituted with a value stored in Teleport's local user database and logins from a root cluster. <br/><br/>For local users, Teleport will substitute this with the "allowed logins" parameter used in the `tctl users add [user] <allowed logins>` command. <br/><br/>If the role is within a leaf cluster in a [trusted cluster](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx), Teleport will substitute the logins from the root cluster whether the user is a local user or from an SSO provider. <br/><br/>As an example, if the user has the `ubuntu` login in the root cluster, then `ubuntu` will be substituted in the leaf cluster with this variable. |
|`{{internal.logins}}` | Substituted with a value stored in Teleport's local user database and logins from a root cluster. <br/><br/>For local users, Teleport will substitute this with the "allowed logins" parameter used in the `tctl users add [user] <allowed logins>` command. <br/><br/>If the role is within a leaf cluster in a [trusted cluster](../../zero-trust-access/management/trustedclusters.mdx), Teleport will substitute the logins from the root cluster whether the user is a local user or from an SSO provider. <br/><br/>As an example, if the user has the `ubuntu` login in the root cluster, then `ubuntu` will be substituted in the leaf cluster with this variable. |
|`{{internal.windows_logins}}`|List of allowed Windows logins for the user.|
|`{{external.xyz}}` | Substituted with a value from an external [SSO provider](https://en.wikipedia.org/wiki/Single_sign-on). If using SAML, this will be expanded with "xyz" assertion value. For OIDC, the variable is expanded to the value of the "xyz" claim. See the next section for more information on referring to the `external` variable in Teleport roles. |
@@ -57,7 +57,7 @@ Read more about [Teleport Proxy Service Architecture](proxy.mdx). You can also
read about the architecture of Teleport Proxy Service features:
- [TLS Routing](tls-routing.mdx)
- [Proxy Peering](../../zero-trust-access/deploy-a-cluster/reliability/proxy-peering.mdx)
- [Proxy Peering](../../zero-trust-access/management/proxy-peering.mdx)
## Enrolling resources
+2 -2
View File
@@ -51,7 +51,7 @@ Before a Relay instance shuts down, it will inform all connected agents that it'
{/* TODO: link appropriate deployment guides */}
When connected to a Relay group, Teleport agents will include the group name and the list of Relay instances that they have connected to in the heartbeat for their served resources. It's possible to see this by reading the appropriate resource heartbeat through `tctl` (e.g. `tctl get node/<host ID>`) or, for SSH servers, `tsh ls --format=json`. The list of Relay instance IDs is also used internally by the Relay service to route connections if an agent serving the requested resource is not connected to all Relay instances: in such a case, the Relay instance forwarding a connection from a client will pass the connection along to a Relay instance that has a tunnel from the agent serving the resource - this is the same mechanism used for connection routing in the control plane when using [Proxy Peering](../../zero-trust-access/deploy-a-cluster/reliability/proxy-peering.mdx).
When connected to a Relay group, Teleport agents will include the group name and the list of Relay instances that they have connected to in the heartbeat for their served resources. It's possible to see this by reading the appropriate resource heartbeat through `tctl` (e.g. `tctl get node/<host ID>`) or, for SSH servers, `tsh ls --format=json`. The list of Relay instance IDs is also used internally by the Relay service to route connections if an agent serving the requested resource is not connected to all Relay instances: in such a case, the Relay instance forwarding a connection from a client will pass the connection along to a Relay instance that has a tunnel from the agent serving the resource - this is the same mechanism used for connection routing in the control plane when using [Proxy Peering](../../zero-trust-access/management/proxy-peering.mdx).
When a Relay instance receives a request to open a connection to a resource, it'll run the same connection routing logic used by the Proxy service, resulting in one or more registered resources as a target for the connection. It will then check if the resource is available through an agent that has a tunnel opened directly with the instance; if so, the connection is then forwarded directly to the agent, otherwise, if the resource is available through a Relay instance of the same Relay group, the connection is forwarded to one of the other Relay instances, which will then pass the connection along to the appropriate agent through a tunnel. If the connection request is for a resource that is not available through the Relay group, an error is returned to the client.
@@ -116,4 +116,4 @@ The [`ssh-multiplexer`](../machine-workload-identity/configuration.mdx#ssh-multi
- [Architecture Overview](../../core-concepts.mdx)
- [Teleport Proxy](proxy.mdx)
- [Proxy Peering](../../zero-trust-access/deploy-a-cluster/reliability/proxy-peering.mdx)
- [Proxy Peering](../../zero-trust-access/management/proxy-peering.mdx)
@@ -70,7 +70,7 @@ Teleport cluster. It can be configured by setting `session_recording`
in the `auth_service` section of your `teleport.yaml`, or dynamically using
the `session_recording_config` resource. If you need to apply different
recording configurations to different sets of resources, you can set up
[trusted clusters](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx) with their own
[trusted clusters](../../zero-trust-access/management/trustedclusters.mdx) with their own
recording configurations.
<Admonition type="note">
@@ -266,6 +266,6 @@ behind layer 7 load balancers.
## Next steps
- See [migration guide](../../zero-trust-access/deploy-a-cluster/tls-routing.mdx) to learn how to
- See [migration guide](../../zero-trust-access/management/tls-routing.mdx) to learn how to
upgrade an existing cluster to use TLS routing.
- Read through TLS routing design document [RFD](https://github.com/gravitational/teleport/blob/master/rfd/0039-sni-alpn-teleport-proxy-routing.md).
@@ -77,5 +77,5 @@ Read the rest of the Architecture Guides:
- See how Teleport uses [Certificates](authentication.mdx) for authentication.
- Reduce your surface of attack using [TLS routing](./tls-routing.mdx).
- Follow our [guide](../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx) to set up trusted clusters.
- Follow our [guide](../../zero-trust-access/management/trustedclusters.mdx) to set up trusted clusters.
+1 -1
View File
@@ -13,7 +13,7 @@ self-hosted deployments of Teleport.
## Hardware recommendations
Set up Teleport with a [High Availability configuration](../../zero-trust-access/deploy-a-cluster/deployments/high-availability.mdx).
Set up Teleport with a [High Availability configuration](../../installation/self-hosted/deployments/high-availability.mdx).
| Scenario | Max Recommended Count | Proxy Service | Auth Service | AWS Instance Types |
|-----------------------------------------------------------------------|-----------------------|-----------------------|-----------------------|--------------------|
@@ -243,7 +243,7 @@ For these reasons we recommend continuing to use the `legacy` algorithm suite.
### My YubiHSM2 authentication key does not have capabilities for ECDSA keys, what do I do?
Our [YubiHSM2 guide](../../zero-trust-access/deploy-a-cluster/private-keys/hsm.mdx) recommends
Our [YubiHSM2 guide](../../installation/self-hosted/private-keys/hsm.mdx) recommends
creating an
[authentication key](https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-concepts.html#authentication-key)
to be used by the Teleport Auth Service to authenticate with the YubiHSM2.
@@ -9,7 +9,7 @@ tags:
The `teleport-cluster` Helm chart deploys a Teleport cluster on Kubernetes.
This includes deploying proxies, auth servers, and [kubernetes-access](../../enroll-resources/kubernetes-access/introduction.mdx).
See the [Teleport HA Architecture page](../../zero-trust-access/deploy-a-cluster/deployments/high-availability.mdx)
See the [Teleport HA Architecture page](../../installation/self-hosted/deployments/high-availability.mdx)
for more details.
You can
@@ -39,11 +39,11 @@ Get started with a guide for each mode:
| `chartMode` | Purpose | Guide |
| - | - | - |
| `standalone` | Runs by relying only on Kubernetes resources. | [Getting Started - Kubernetes](../../zero-trust-access/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx) |
| `aws` | Leverages AWS managed services to store data. | [Running an HA Teleport cluster using an AWS EKS Cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx) |
| `gcp` | Leverages GCP managed services to store data. | [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx) |
| `azure` | Leverages Azure managed services to store data. | [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/azure.mdx) |
| `scratch` (v12 and above) | Generates empty Teleport configuration. User must pass their own config. This is discouraged, use `standalone` mode with [`auth.teleportConfig`](#authteleportconfig) and [`proxy.teleportConfig`](#proxyteleportconfig) instead. | [Running a Teleport cluster with a custom config](../../zero-trust-access/deploy-a-cluster/helm-deployments/custom.mdx) |
| `standalone` | Runs by relying only on Kubernetes resources. | [Getting Started - Kubernetes](../../installation/self-hosted/helm-deployments/kubernetes-cluster.mdx) |
| `aws` | Leverages AWS managed services to store data. | [Running an HA Teleport cluster using an AWS EKS Cluster](../../installation/self-hosted/helm-deployments/aws.mdx) |
| `gcp` | Leverages GCP managed services to store data. | [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../installation/self-hosted/helm-deployments/gcp.mdx) |
| `azure` | Leverages Azure managed services to store data. | [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../installation/self-hosted/helm-deployments/azure.mdx) |
| `scratch` (v12 and above) | Generates empty Teleport configuration. User must pass their own config. This is discouraged, use `standalone` mode with [`auth.teleportConfig`](#authteleportconfig) and [`proxy.teleportConfig`](#proxyteleportconfig) instead. | [Running a Teleport cluster with a custom config](../../installation/self-hosted/helm-deployments/custom.mdx) |
<Admonition type="warning" title="Version Compatibility">
The chart is versioned with Teleport. No compatibility guarantees are ensured
@@ -957,7 +957,7 @@ PodSecurityPolicy resource has been removed in Kubernetes 1.25
and replaced since 1.23 by PodSecurityAdmission. If you are running on
Kubernetes 1.23 or later it is recommended to disable PSPs and use PSAs.
The steps are documented in the
[PSP removal guide](../../zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp.mdx).
[PSP removal guide](../../installation/self-hosted/helm-deployments/migration-kubernetes-1-25-psp.mdx).
To disable PSP creation, you can set `enabled` to `false`.
@@ -1004,11 +1004,11 @@ policies to define access rules for the cluster.
| `chartMode` | Guide |
|--------------|--------------------------------------------------------------------------------------------------------------------|
| `standalone` | [Getting Started - Kubernetes](../../zero-trust-access/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx) |
| `aws` | [Running an HA Teleport cluster using an AWS EKS Cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx) |
| `gcp` | [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx) |
| `azure` | [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/azure.mdx) |
| `scratch` | [Running a Teleport cluster with a custom config](../../zero-trust-access/deploy-a-cluster/helm-deployments/custom.mdx) |
| `standalone` | [Getting Started - Kubernetes](../../installation/self-hosted/helm-deployments/kubernetes-cluster.mdx) |
| `aws` | [Running an HA Teleport cluster using an AWS EKS Cluster](../../installation/self-hosted/helm-deployments/aws.mdx) |
| `gcp` | [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../installation/self-hosted/helm-deployments/gcp.mdx) |
| `azure` | [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../installation/self-hosted/helm-deployments/azure.mdx) |
| `scratch` | [Running a Teleport cluster with a custom config](../../installation/self-hosted/helm-deployments/custom.mdx) |
<Admonition type="warning">
Using the `scratch` chart mode is discouraged. Precise chart and Teleport
@@ -1140,7 +1140,7 @@ You can set `volumeSize` to request a different size of persistent volume when i
## `aws`
`aws` settings are described in the AWS guide: [Running an HA Teleport cluster using an AWS EKS Cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx)
`aws` settings are described in the AWS guide: [Running an HA Teleport cluster using an AWS EKS Cluster](../../installation/self-hosted/helm-deployments/aws.mdx)
### `aws.region`
@@ -1255,11 +1255,11 @@ queries.
## `gcp`
`gcp` settings are described in the GCP guide: [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx)
`gcp` settings are described in the GCP guide: [Running an HA Teleport cluster using a Google Cloud GKE cluster](../../installation/self-hosted/helm-deployments/gcp.mdx)
## `azure`
`azure` settings are described in the Azure guide: [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../zero-trust-access/deploy-a-cluster/helm-deployments/azure.mdx)
`azure` settings are described in the Azure guide: [Running an HA Teleport cluster using a Microsoft Azure AKS cluster](../../installation/self-hosted/helm-deployments/azure.mdx)
## `highAvailability`
@@ -1383,7 +1383,7 @@ cluster deployed in HA mode.
You must install and configure `cert-manager` in your Kubernetes cluster yourself.
See the [cert-manager Helm install instructions](https://cert-manager.io/docs/installation/kubernetes/#option-2-install-crds-as-part-of-the-helm-release)
and the relevant sections of the [AWS](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx) and [GCP](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx) guides for more information.
and the relevant sections of the [AWS](../../installation/self-hosted/helm-deployments/aws.mdx) and [GCP](../../installation/self-hosted/helm-deployments/gcp.mdx) guides for more information.
</Admonition>
### `highAvailability.certManager.addCommonName`
@@ -1398,7 +1398,7 @@ Setting `highAvailability.certManager.addCommonName` to `true` will instruct `ce
You must install and configure `cert-manager` in your Kubernetes cluster yourself.
See the [cert-manager Helm install instructions](https://cert-manager.io/docs/installation/kubernetes/#option-2-install-crds-as-part-of-the-helm-release)
and the relevant sections of the [AWS](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx) and [GCP](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx) guides for more information.
and the relevant sections of the [AWS](../../installation/self-hosted/helm-deployments/aws.mdx) and [GCP](../../installation/self-hosted/helm-deployments/gcp.mdx) guides for more information.
</Admonition>
`values.yaml` example:
@@ -1443,7 +1443,7 @@ Sets the name of the `cert-manager` `Issuer` or `ClusterIssuer` to use for issui
You must install configure an appropriate `Issuer` supporting a DNS01 challenge yourself.
Please see the [cert-manager DNS01 docs](https://cert-manager.io/docs/configuration/acme/dns01/#supported-dns01-providers) and the relevant sections
of the [AWS](../../zero-trust-access/deploy-a-cluster/helm-deployments/aws.mdx) and [GCP](../../zero-trust-access/deploy-a-cluster/helm-deployments/gcp.mdx) guides for more information.
of the [AWS](../../installation/self-hosted/helm-deployments/aws.mdx) and [GCP](../../installation/self-hosted/helm-deployments/gcp.mdx) guides for more information.
</Admonition>
`values.yaml` example:
@@ -55,7 +55,7 @@ Here's the list of resources currently exposed via [`tctl`](../../cli/tctl.mdx):
| connector | Authentication connectors for [Single Sign-On](../../../zero-trust-access/sso/sso.mdx) (SSO) for SAML, OIDC and GitHub. |
| node | A registered SSH node. The same record is displayed via `tctl nodes ls`. |
| windows_desktop | A registered Windows desktop. |
| cluster | A trusted cluster. See [here](../../../zero-trust-access/deploy-a-cluster/trustedclusters.mdx) for more details on connecting clusters together. |
| cluster | A trusted cluster. See [here](../../../zero-trust-access/management/trustedclusters.mdx) for more details on connecting clusters together. |
| [login_rule](login-rules.mdx) | A Login Rule, see the [Login Rules guide](../../../zero-trust-access/sso/login-rules/login-rules.mdx) for more info. |
| [device](device.mdx) | A Teleport Trusted Device, see the [Device Trust guide](../../../zero-trust-access/device-trust/guide.mdx) for more info. |
| [ui_config](ui-config.mdx) | Configuration for the Web UI served by the Proxy Service. |
+2 -2
View File
@@ -53,7 +53,7 @@ Teleport cluster.
1. Back up your Teleport cluster state as a precaution against any unforeseen
incidents while upgrading the Auth Service, which may perform data
migrations on its backend. Follow the instructions in [Backup and
Restore](../zero-trust-access/deploy-a-cluster/reliability/backup-restore.mdx).
Restore](../zero-trust-access/management/backup-restore.mdx).
1. Upgrade all **Auth Service** instances to the **target version first**.
Auth Service instances may be upgraded in any sequence or at the same time. After
the upgrade **confirm** that the cluster is in a healthy state before continuing.
@@ -93,7 +93,7 @@ you must restore the Teleport backend to the back up taken prior to upgrading. F
roll back all components to the exact version they were running prior to the upgrade in
reverse order of the upgrade sequence above until only the Auth Service instances are running
the new major version. Then stop the Auth Service and follow the
[Backup and Restore](../zero-trust-access/deploy-a-cluster/reliability/backup-restore.mdx) guidance
[Backup and Restore](../zero-trust-access/management/backup-restore.mdx) guidance
to restore the backend to a point in time prior to the upgrade. Once the backup has been
restored, downgrade the Auth Service instances to the exact version of Teleport
they were running prior to the upgrade attempt, then start them again.
@@ -250,7 +250,7 @@ unless the mapped leaf role also requires moderation. To require moderated sessi
you must include the `require_session_join` policy in the mapped role defined on the leaf cluster.
For more information about configuring trust relationships and role mapping between root and leaf
clusters, see [Configure Trusted Clusters](../deploy-a-cluster/trustedclusters.mdx).
clusters, see [Configure Trusted Clusters](../management/trustedclusters.mdx).
### Multifactor authentication
@@ -36,7 +36,7 @@ Teleport includes FedRAMP and FIPS features to support companies that sell into
| [AC-10 Concurrent Session Control]((=fedramp.control_url=)AC-10) | Teleport administrators can define concurrent session limits using Teleport's RBAC. Supports both a maximum number of connections and maximum number of simultaneously connected users. |
| [AC-12 Session Termination]((=fedramp.control_url=)AC-12) | Teleport can be configured to terminate active sessions as soon as the user's certificate expires. Users can exit a Teleport interactive session at any time by typing exit or sending an interrupt signal to the process for remote execution of a program. Administrators can apply [locks](../../identity-governance/locking.mdx) to forcibly terminate active sessions based on a variety of criteria. |
| [AC-17 Remote Access]((=fedramp.control_url=)AC-17) | Teleport administrators create users with configurable roles that can be used to allow or deny access to system resources. |
| [AC-20 Use of External Information Systems]((=fedramp.control_url=)AC-20) | Teleport supports connecting multiple independent clusters using a feature called [Trusted Clusters](../deploy-a-cluster/trustedclusters.mdx). When allowing access from one cluster to another, roles are mapped according to a pre-defined relationship of the scope of access. |
| [AC-20 Use of External Information Systems]((=fedramp.control_url=)AC-20) | Teleport supports connecting multiple independent clusters using a feature called [Trusted Clusters](../management/trustedclusters.mdx). When allowing access from one cluster to another, roles are mapped according to a pre-defined relationship of the scope of access. |
### Audit and accountability
@@ -56,7 +56,7 @@ Each principle has many "Points of Focus" which will apply differently to differ
| --- | --- | --- |
| CC6.1 - Restricts Logical Access | Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative authorities, mobile devices, output, and offline system components is restricted through the use of access control software and rule sets. | Teleport Enterprise supports robust [Role-based Access Controls (RBAC)](../authentication/authentication.mdx) to: <ul> <li> Control which SSH nodes a user can or cannot access. </li> <li> Control cluster level configuration (session recording, configuration, etc.) </li> <li> Control which UNIX logins a user is allowed to use when logging into a server. </li></ul> |
| CC6.1 - Identifies and Authenticates Users | Persons, infrastructure, and software are identified and authenticated prior to accessing information assets, whether locally or remotely. | Provide role-based access controls (RBAC) using short-lived certificates and your existing identity management service. Connecting locally or remotely is just as easy. |
| CC6.1 - Considers Network Segmentation | Network segmentation permits unrelated portions of the entity&#39;s information system to be isolated from each other. | [Teleport enables beyond corp network segmentation](../deploy-a-cluster/trustedclusters.mdx) <br/><br/> [Connect to nodes behind Firewalls or create reverse tunnels to a proxy server](../../faq.mdx) |
| CC6.1 - Considers Network Segmentation | Network segmentation permits unrelated portions of the entity&#39;s information system to be isolated from each other. | [Teleport enables beyond corp network segmentation](../management/trustedclusters.mdx) <br/><br/> [Connect to nodes behind Firewalls or create reverse tunnels to a proxy server](../../faq.mdx) |
| CC6.1 - Manages Points of Access | Points of access by outside entities and the types of data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified, documented, and managed. | [Label Nodes to inventory and create rules](../rbac-get-started/labels.mdx) <br/><br/> [Create Labels from AWS Tags](../../enroll-resources/automatic-labels/ec2-tags.mdx) <br/><br/>Teleport maintains a live list of all nodes within a cluster. This node list can be queried by users (who see a subset they have access to) and administrators any time. |
| CC6.1 - Restricts Access to Information Assets | Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets. | [Teleport uses Certificates to grant access and create access control rules](../../core-concepts.mdx) |
| CC6.1 - Manages Identification and Authentication | Identification and authentication requirements are established, documented, and managed for individuals and systems accessing entity information, infrastructure, and software. | Teleport makes setting policies for SSH requirements easy since it works in the cloud and on premise with the same authentication security standards. |
@@ -73,7 +73,7 @@ Each principle has many "Points of Focus" which will apply differently to differ
| CC6.6 - Restricts Access | The types of activities that can occur through a communication channel (for example, FTP site, router port) are restricted. | Teleport makes it easy to restrict access to common ports like 21, 22 and instead have users [tunnel to the server](../../faq.mdx) using Teleport. [Teleport uses the following default ports.](../../reference/deployment/networking.mdx) |
| CC6.6 - Protects Identification and Authentication Credentials | Identification and authentication credentials are protected during transmission outside system boundaries. | [Yes, Teleport protects credentials outside your network allowing for Zero Trust network architecture](https://goteleport.com/blog/applying-principles-of-zero-trust-to-ssh/) |
| CC6.6 - Requires Additional Authentication or Credentials | Additional authentication information or credentials are required when accessing the system from outside its boundaries. | [Yes, Teleport can manage MFA with TOTP, WebAuthn or U2F Standards or connect to your Identity Provider using SAML, OAUTH or OIDC](../sso/sso.mdx) |
| CC6.6 - Implements Boundary Protection Systems | Boundary protection systems (for example, firewalls, demilitarized zones, and intrusion detection systems) are implemented to protect external access points from attempts and unauthorized access and are monitored to detect such attempts. | [Trusted clusters](../deploy-a-cluster/trustedclusters.mdx) |
| CC6.6 - Implements Boundary Protection Systems | Boundary protection systems (for example, firewalls, demilitarized zones, and intrusion detection systems) are implemented to protect external access points from attempts and unauthorized access and are monitored to detect such attempts. | [Trusted clusters](../management/trustedclusters.mdx) |
| CC6.7 - Uses Encryption Technologies or Secure Communication Channels to Protect Data | Encryption technologies or secured communication channels are used to protect transmission of data and other communications beyond connectivity access points. | [Teleport has strong encryption including a FedRAMP compliant FIPS mode](./fedramp.mdx#start-teleport-in-fips-mode) |
| CC7.2 - Implements Detection Policies, Procedures, and Tools | Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. | [Teleport creates detailed SSH Audit Logs with Metadata](../../reference/deployment/monitoring/audit.mdx) <br/><br/> [Use BPF Session Recording to catch malicious program execution](../../enroll-resources/server-access/guides/bpf-session-recording.mdx) |
| CC7.2 - Designs Detection Measures | Detection measures are designed to identify anomalies that could result from actual or attempted (1) compromise of physical barriers; (2) unauthorized actions of authorized personnel; (3) use of compromised identification and authentication credentials; (4) unauthorized access from outside the system boundaries; (5) compromise of authorized external parties; and (6) implementation or connection of unauthorized hardware and software. | [Use Enhanced Session Recording to catch malicious program execution, capture TCP connections and log programs accessing files on the system the should not be accessing.](../../enroll-resources/server-access/guides/bpf-session-recording.mdx) |
@@ -95,7 +95,7 @@ Each principle has many "Points of Focus" which will apply differently to differ
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Tests System Changes. | Teleport's infrastructure as code support and [gRPC API](../api/api.mdx) make it possible to set up staging environments and automated tests for changes in a Teleport configuration. |
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Approves System Changes. | [Access Requests](../../identity-governance/access-requests/access-requests.mdx) allow approvals to proposed permissions changes, and infrastructure as code support enables you to set up an approval system for configurations. |
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Deploys System Changes. | [RBAC protections](../../reference/access-controls/roles.mdx#rbac-for-dynamic-teleport-resources) for API resources allow you to restrict configuration changes to an authorized continuous deployment runner. |
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Identifies Changes in the Infrastructure, Data, Software, and Procedures Required to Remediate Incidents. | [Infrastructure as code](../infrastructure-as-code/infrastructure-as-code.mdx) support enables you to revert changes. It is also possible for you to [back up the Auth Service backend](../deploy-a-cluster/reliability/backup-restore.mdx) on self-hosted clusters.|
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Identifies Changes in the Infrastructure, Data, Software, and Procedures Required to Remediate Incidents. | [Infrastructure as code](../infrastructure-as-code/infrastructure-as-code.mdx) support enables you to revert changes. It is also possible for you to [back up the Auth Service backend](../management/backup-restore.mdx) on self-hosted clusters.|
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Creates Baseline Configuration of IT Technology. |[Infrastructure as code](../infrastructure-as-code/infrastructure-as-code.mdx) support enables you to set up a baseline configuration in a code repository. |
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Provides Changes Necessary in Emergency Situations. | Admins can use [Access Requests](../../identity-governance/access-requests/access-requests.mdx) to obtain temporarily elevated permissions in order to provide changes in emergency situations. |
| CC8.1 - Authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. | Manages Patch Changes. | [Infrastructure as code](../infrastructure-as-code/infrastructure-as-code.mdx) support enables regular patch changes to configurations. |
@@ -1,10 +0,0 @@
---
title: Reliability for Self-Hosted Clusters
sidebar_label: Reliability
description: The guides in this section show you Teleport capabilities for ensuring the reliability of self-hosted clusters.
---
The guides in this section show you Teleport capabilities for ensuring the
reliability of self-hosted clusters.
<DocCardList />
@@ -141,7 +141,7 @@ ERROR: ssh: rejected: administratively prohibited (unauthorized device)
<Admonition type="tip" title="Trusted Clusters">
It is possible to use [trusted
clusters](../deploy-a-cluster/trustedclusters.mdx) to limit the impact of
clusters](../management/trustedclusters.mdx) to limit the impact of
device mode `required`. A leaf cluster in mode `required` will enforce access to
all of its resources, without imposing the same restrictions to the root
cluster. Likewise, a root cluster will not enforce Device Trust on resources in
@@ -38,7 +38,7 @@ Teleport supports three ways to dynamically create resources from code:
For information about how to enroll a resource in your cluster, see
[Join Services to your Cluster](../../../installation/agents/agents.mdx).
- Read through the [Configure Trusted Clusters](../../deploy-a-cluster/trustedclusters.mdx)
- Read through the [Configure Trusted Clusters](../../management/trustedclusters.mdx)
guide to understand how trusted clusters works.
- The `tctl` admin tool and `tsh` client tool.
@@ -120,7 +120,7 @@ roles.
Helm Chart parameters are documented in the [`teleport-cluster` Helm chart reference](../../../reference/helm-reference/teleport-cluster.mdx).
See the [Helm Deployment guides](../../deploy-a-cluster/helm-deployments/helm-deployments.mdx) detailing specific setups like running Teleport on AWS or GCP.
See the [Helm Deployment guides](../../../installation/self-hosted/helm-deployments/helm-deployments.mdx) detailing specific setups like running Teleport on AWS or GCP.
## Troubleshooting
@@ -24,7 +24,7 @@ You must back up data that the Auth Service manages across its three backends:
- Audit event backend
- Session recording backend
See [Storage Backends](../../../reference/deployment/backends.mdx) for more information on
See [Storage Backends](../../reference/deployment/backends.mdx) for more information on
Teleport backends.
The following table summarizes the kinds of backend data the Auth Service
@@ -54,7 +54,7 @@ listed here, consult the documentation for your backend:
For the most part, you can use the same solution for both cluster state and
audit events, setting aside a separate table for each kind of backend. The
exception is etcd, which can only function as a cluster state backend. (See a
full explanation in [Storage Backends](../../../reference/deployment/backends.mdx#etcd).)
full explanation in [Storage Backends](../../reference/deployment/backends.mdx#etcd).)
| Backend | Recommended backup strategy |
| - | - |
@@ -77,7 +77,7 @@ full explanation in [Storage Backends](../../../reference/deployment/backends.md
## Versioning dynamic resources with infrastructure as code
Teleport uses [dynamic
resources](../../infrastructure-as-code/infrastructure-as-code.mdx) for roles,
resources](../infrastructure-as-code/infrastructure-as-code.mdx) for roles,
local users, authentication connectors, and other configurations, and stores
dynamic resource data on the cluster state backend. Backing up the cluster
state backend protects your cluster against the loss of dynamic resource data.
@@ -96,9 +96,9 @@ Teleport provides the following infrastructure as code tools for managing
dynamic resources:
- [Terraform
provider](../../infrastructure-as-code/terraform-provider/terraform-provider.mdx)
provider](../infrastructure-as-code/terraform-provider/terraform-provider.mdx)
- [Kubernetes
operator](../../infrastructure-as-code/teleport-operator/teleport-operator.mdx)
operator](../infrastructure-as-code/teleport-operator/teleport-operator.mdx)
## Cloning a backend
@@ -138,7 +138,7 @@ Kubernetes pod that usually runs the Teleport Auth Service, you can expect the
include information about the source and destination backends. Possible
values of `src` and `dst` are the same as the `teleport.storage` section in
the Teleport configuration file. See the [Storage
Backends](../../../reference/deployment/backends.mdx) reference for the configuration
Backends](../../reference/deployment/backends.mdx) reference for the configuration
fields to assign for each backend.
1. Run the following command on an Auth Service instance to execute the clone
@@ -162,7 +162,7 @@ Rollbacks can be performed without any backend corruption or data loss by levera
to upgrading a cluster from Teleport v18 to v19 the following clone configuration can
be used to make a full clone of the Teleport backend state to a different key range of
the same etcd cluster using the `prefix` field. See the etcd storage backend
[configuration reference](../../../reference/deployment/backends.mdx#etcd) for an explanation:
[configuration reference](../../reference/deployment/backends.mdx#etcd) for an explanation:
```yaml
src:
@@ -190,7 +190,7 @@ Log into the Teleport Agent server and run the following commands.
$ tctl create -f breakglass-bot.yaml
```
1. Create a [bound keypair](../../../reference/machine-workload-identity/bound-keypair/bound-keypair.mdx) to use as a join method for running instances of the bot:
1. Create a [bound keypair](../../reference/machine-workload-identity/bound-keypair/bound-keypair.mdx) to use as a join method for running instances of the bot:
Define the join method in a file named `breakglass-token.yaml`:
@@ -228,11 +228,11 @@ Log into the Teleport Agent server and run the following commands.
**This step is completed on the machine where you will store and make use of the certificates for break-glass access.**
This step will configure and start a [Teleport Machine ID bot](../../../machine-workload-identity/deployment/deployment.mdx) as a background
This step will configure and start a [Teleport Machine ID bot](../../machine-workload-identity/deployment/deployment.mdx) as a background
daemon (managed by `systemd`), which will continually generate and refresh a short-lived key and certificate for break-glass access (using the
`breakglass` user) and store it on the machine where it runs.
This guide will join the Teleport Machine ID bot to the cluster using a [bound keypair](../../../reference/machine-workload-identity/bound-keypair/concepts.mdx)
This guide will join the Teleport Machine ID bot to the cluster using a [bound keypair](../../reference/machine-workload-identity/bound-keypair/concepts.mdx)
which is a secure, optionally single-use join method based on public key cryptography, providing a strong guarantee of security and protection against
credential theft.
@@ -181,7 +181,7 @@ With an improperly scaled Proxy Service pool, the Proxy Service can become a
bottleneck for traffic to Teleport-protected resources. If Proxy Service
instances display heavy utilization of compute resources while the number of
connected infrastructure resources is high, you can consider scaling out your
Proxy Service pool and using [Proxy Peering](../../deploy-a-cluster/reliability/proxy-peering.mdx).
Proxy Service pool and using [Proxy Peering](../proxy-peering.mdx).
Use the following Grafana query to track the maximum number of reverse tunnels
by type over a given interval:
@@ -40,15 +40,15 @@ agents are configured to connect to a single Proxy Service instance. For high
availability a cluster administrator may configure agents to connect to 2 or
more Proxy Service instances.
![Teleport Proxy Peering](../../../../img/architecture/[email protected])
![Teleport Proxy Peering](../../../img/architecture/[email protected])
## Prerequisites
1. An existing self-hosted Teleport Enterprise cluster that is **not** using
[Trusted
Clusters](../trustedclusters.mdx). See
Clusters](trustedclusters.mdx). See
the documentation on [self-hosting
Teleport](../deploy-a-cluster.mdx) to get started.
Teleport](../../installation/self-hosted/self-hosted.mdx) to get started.
1. A network architecture that meets the following DNS requirements:
@@ -149,7 +149,7 @@ to learn how to:
To complete the steps in this guide, verify your environment meets the following requirements:
- [Proxy peering](reliability/proxy-peering.mdx) must be disabled. Proxy Peering and Trusted Clusters are not compatible.
- [Proxy peering](proxy-peering.mdx) must be disabled. Proxy Peering and Trusted Clusters are not compatible.
- Access to **two** Teleport cluster instances.
@@ -104,27 +104,6 @@ import mcpAndAiSvg from "@site/src/components/Icon/teleport-svg/mcp-and-ai.svg";
},
]
},
{
title: "Self-host Teleport",
description: "Run Teleport Enterprise in your own infrastructure, with guides covering high availability and multi-region clusters, securing key material with KMS or HSMs, and more.",
href: "./deploy-a-cluster/",
tags: [
{
name: "AWS KMS",
href: "./deploy-a-cluster/private-keys/aws-kms/",
icon: "aws",
},
{
name: "Google Cloud KMS",
href: "./deploy-a-cluster/private-keys/gcp-kms/",
icon: "googleCloud",
},
{
name: "Helm chart",
href: "./deploy-a-cluster/helm-deployments/",
},
]
},
{
title: "Infrastructure as Code",
description: "Manage Teleport's Dynamic Resources using infrastructure as code tools, including Terraform, Helm and the Teleport tctl client tool.",
@@ -750,7 +750,7 @@ podSecurityPolicy:
# and replaced since 1.23 by PodSecurityAdmission (PSA). If you are running on
# Kubernetes 1.23 or later, it is recommended to disable PSPs and use PSAs.
# The steps are documented in the
# [PSP removal guide](../../zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp.mdx).
# [PSP removal guide](../../installation/self-hosted/helm-deployments/migration-kubernetes-1-25-psp.mdx).
#
# This value will be removed in a future chart version.
enabled: true