diff --git a/docs/pages/management/operations/upgrading.mdx b/docs/pages/management/operations/upgrading.mdx index e16a294756663..b3b9ce47387dd 100644 --- a/docs/pages/management/operations/upgrading.mdx +++ b/docs/pages/management/operations/upgrading.mdx @@ -3,8 +3,7 @@ title: Upgrading a Teleport Cluster description: This guide shows you the correct order in which to upgrade Teleport components when rolling out a new Teleport release in your cluster. --- -In this guide, we will show you how to upgrade all of the components in your -Teleport cluster. +This guide demonstrates how to upgrade all of the components in your Teleport cluster. (!docs/pages/includes/cloud/call-to-action.mdx!) @@ -28,13 +27,14 @@ title="Auth Service and Proxy Service versions"> In Teleport Cloud, we manage the Auth and Proxy Services for you. You can determine the current version of these services by running the following -command, where `mytenant` is the name of your Teleport Cloud tenant: +command, where `mytenant` is the name of your Teleport Team or Teleport +Enterprise Cloud tenant: ```code $ curl -s https://mytenant.teleport.sh/webapi/ping | jq '.server_version' ``` -Read the following rules to ensure that your Teleport resource services (e.g., +Read the following rules to ensure that your Teleport resource services (for example, the SSH Service and Database Service) are compatible with the Teleport Auth and Proxy Services. You should check the version of the Auth and Proxy Services regularly to make sure that your Teleport resource services are compatible. @@ -47,28 +47,30 @@ regularly to make sure that your Teleport resource services are compatible. Back up before upgrading. We have more instructions in [Backing up Teleport](./backup-restore.mdx). -## Upgrade Sequence +## Upgrade sequence -When upgrading a single Teleport cluster: - Teleport requires upgrading the Teleport Cluster from one major version to another in sequence. -That means if you are currently on version 8.X you must upgrade to the latest version 9 before -going to version 10. To upgrade in sequence repeat upgrading the Teleport Cluster, confirming +If you are currently on version 11.x, you must upgrade to the latest version 12.x before +going to version 13.x. To upgrade in sequence, upgrade the Teleport cluster and confirm a healthy start before continuing to the next version. - -1. **Upgrade the Auth Service first to the next Major version**. The Auth Service keeps the cluster state - and, if there are data format changes introduced in the new version, will - perform necessary migrations. Confirm the start of the Auth Service and a healthy state. -2. Upgrade Proxy Service instances to the same version number. These are stateless and can be upgraded in - any sequence or at the same time. -3. Finally, upgrade your Teleport resource services in any sequence or at the - same time to the same version number. -4. If you are upgrading more then one version number then repeat Step 1 to 3 until you have reached your target - major version. +When upgrading a single Teleport cluster: + +- Upgrade the **Auth Service** to the next **major version first**. + The Auth Service keeps the cluster state. If there are data format + changes introduced in the new version, the Auth Service performs the necessary migrations. + After the upgrade, start the Auth Service and CONFIRM that it's in a healthy state before + continuing. +- Upgrade Proxy Service instances to the same version number as the Auth Service. + Proxy Service instances are stateless and can be upgraded in any sequence or at the same time. +- Upgrade your Teleport resource services to the same version number as the Auth Service. + You can upgrade resource agents in any sequence or at the same time. + +If you are upgrading more then one version number, repeat these steps until +you reach your target major version number. @@ -97,8 +100,9 @@ time. When upgrading multiple clusters: -1. First, upgrade the root cluster, i.e. the one that other clusters trust. -2. Upgrade the Trusted Clusters. +- Upgrade the root cluster—that is, the cluster that other clusters trust—first. +- Verify the upgrade was successful. +- Upgrade the Trusted Clusters. diff --git a/docs/pages/reference/audit.mdx b/docs/pages/reference/audit.mdx index 524f3808e5f99..cd298eac30267 100644 --- a/docs/pages/reference/audit.mdx +++ b/docs/pages/reference/audit.mdx @@ -9,18 +9,18 @@ There are two components of the audit log: -1. **Cluster Events:** Teleport logs events like successful user logins along +- **Cluster Events:** Teleport logs events like successful user logins along with metadata like remote IP address, time, and the session ID. -2. **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and +- **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and can be replayed later. By default, the recording is done by Teleport Nodes, but can be configured to be done by the proxy. -1. **Cluster Events:** Teleport logs events like successful user logins along +- **Cluster Events:** Teleport logs events like successful user logins along with metadata like remote IP address, time, and the session ID. -2. **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and +- **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and can be replayed later. Teleport Cloud manages the storage of session recording data. diff --git a/docs/pages/server-access/getting-started.mdx b/docs/pages/server-access/getting-started.mdx index 016138b0443ef..3e1b86617264a 100644 --- a/docs/pages/server-access/getting-started.mdx +++ b/docs/pages/server-access/getting-started.mdx @@ -9,8 +9,8 @@ issuing commands through a CLI or programmatically to an API. This guide introduces some of these common scenarios and how to interact with Teleport to accomplish them: -1. SSH into a cluster using Teleport. -2. Introspect the cluster using Teleport features. +- SSH into a cluster using Teleport. +- Introspect the cluster using Teleport features. This guide also demonstrates how to configure Teleport Nodes using the **bastion pattern** so that only a single Node can be accessed publicly. diff --git a/docs/pages/server-access/guides/restricted-session.mdx b/docs/pages/server-access/guides/restricted-session.mdx index dd5227b28364f..c48a394108572 100644 --- a/docs/pages/server-access/guides/restricted-session.mdx +++ b/docs/pages/server-access/guides/restricted-session.mdx @@ -39,14 +39,15 @@ Teleport supports network restrictions with more types coming in the future. - (!docs/pages/includes/tctl.mdx!) -## Network Restrictions +## Network restrictions Network restrictions work similarly to a firewall but with several differences: -1. Firewall rules apply to the entire machine whereas network restrictions are applied + +- Firewall rules apply to the entire machine whereas network restrictions are applied only to SSH sessions. -2. Whereas firewall typically blocks ingress (inbound) connections, network restrictions +- Whereas firewall typically blocks ingress (inbound) connections, network restrictions block egress (outbound) connections. -3. Firewall rules are typically static but Teleport provides an API for +- Firewall rules are typically static but Teleport provides an API for Restricted Sessions that allows the rules to be dynamically updated across the entire fleet. diff --git a/docs/pages/server-access/introduction.mdx b/docs/pages/server-access/introduction.mdx index a88b07a8738e6..9534190f95dc8 100644 --- a/docs/pages/server-access/introduction.mdx +++ b/docs/pages/server-access/introduction.mdx @@ -10,10 +10,10 @@ giving complete visibility over all sessions and events. Teleport server access is designed for the following kinds of scenarios: -1. When up to a vast number of clusters must be managed using the command-line (`tsh`) or programmatically (through the Teleport API) and you want to simplify your stack, security, and configuration complexity. -2. When security team members must track and audit every user session. -3. When Teleport users require a complete, dedicated, and secure SSH option (Teleport Node running in SSH mode) and more than a certificate authority (Teleport Auth) with proxy (Teleport Proxy). -4. When resource and network security must be maximized: SSH certificates over secret keys, Two-Factor Authentication (2FA), Single Sign-On (SSO), and short-lived certificates. +- When up to a vast number of clusters must be managed using the command-line (`tsh`) or programmatically (through the Teleport API) and you want to simplify your stack, security, and configuration complexity. +- When security team members must track and audit every user session. +- When Teleport users require a complete, dedicated, and secure SSH option (Teleport Node running in SSH mode) and more than a certificate authority (Teleport Auth) with proxy (Teleport Proxy). +- When resource and network security must be maximized: SSH certificates over secret keys, Two-Factor Authentication (2FA), Single Sign-On (SSO), and short-lived certificates. ## Getting started