From 260cec41ee7d236d1f131d734e8b2ba8016f6c42 Mon Sep 17 00:00:00 2001 From: Paul Gottschling Date: Tue, 7 May 2024 10:46:23 -0400 Subject: [PATCH] Edit the Enterprise migration guide **Edit the guide for structure and style:** - Use title case in the title. - Wrap lines at 80 chars. - Begin H2s with "Step n/d" - Move the Conclusion text to the intro. How-to guides do not include conclusions in our docs, and this information is valuable at the start of the guide. - Use numbered steps for instructions. - Use relative file paths for links. - Minor style edits. **Remove the "Verify connectivity" step:** This repeats instructions from the step to deploy a cloud-hosted cluster. **Add a note on migrating plugins and Machine ID Bots:** the guide only includes instructions for migrating agents in the section on migrating services. This change suggests linking to docs on migrating plugins and Bots. **Edit the navigation:** - Add a link to the navigation sidebar. - Edit the "Choose a Teleport Edition" intro page to (a) imply that cloud-hosted is the recommended solution and (b) link to the migration guide. --- docs/config.json | 4 + docs/pages/choose-an-edition/introduction.mdx | 47 ++- .../choose-an-edition/migrate-to-cloud.mdx | 324 ++++++++++++++++++ docs/pages/migrating.mdx | 193 ----------- 4 files changed, 356 insertions(+), 212 deletions(-) create mode 100644 docs/pages/choose-an-edition/migrate-to-cloud.mdx delete mode 100644 docs/pages/migrating.mdx diff --git a/docs/config.json b/docs/config.json index fc95a04fc94b9..f37f0e1e16e46 100644 --- a/docs/config.json +++ b/docs/config.json @@ -87,6 +87,10 @@ "title": "Introduction", "slug": "/choose-an-edition/introduction/" }, + { + "title": "Migrate to Cloud-Hosted Enterprise", + "slug": "/choose-an-edition/migrate-to-cloud/" + }, { "title": "Teleport Enterprise Cloud", "slug": "/choose-an-edition/teleport-cloud/introduction/", diff --git a/docs/pages/choose-an-edition/introduction.mdx b/docs/pages/choose-an-edition/introduction.mdx index bdabd0483472d..f5ed279e9229b 100644 --- a/docs/pages/choose-an-edition/introduction.mdx +++ b/docs/pages/choose-an-edition/introduction.mdx @@ -1,36 +1,45 @@ --- title: "How to Choose a Teleport Edition" -description: "Read this guide to determine whether to deploy Teleport Enterprise, Teleport Cloud, or Teleport Community Edition." +description: "Determine whether to use the cloud-hosted Teleport Enterprise, host your own Teleport Enterprise deployment, or try Teleport Community Edition for personal use." --- -Teleport supports three editions. In this guide, we will help you determine -which edition is most appropriate for your use case. +The fully-featured edition of Teleport is called **Teleport Enterprise**. -## Editions +For most users, we recommend [signing up](https://goteleport.com/signup) for a +cloud-hosted Teleport Enterprise account. Our team at Teleport manages the +Teleport Auth Service and Proxy Service, giving you a running Teleport cluster +where you can configure RBAC, set up Single Sign-On connectors, and register +resources by deploying additional Teleport services. -### Teleport Enterprise Cloud +[Read more about Teleport Enterprise +(cloud-hosted)](./teleport-cloud/introduction.mdx). -Our team at Teleport manages the Auth and Proxy Services, giving you a running -Teleport cluster where you can configure RBAC, set up Single Sign-On connectors, -and register resources by deploying additional Teleport services. +## Self-hosting Teleport Enterprise -[Read more about Teleport Enterprise Cloud](./teleport-cloud/introduction.mdx). +For organizations with specific security needs, it is also possible to run a +self-hosted Teleport Enterprise cluster. Self-hosting Teleport Enterprise allows +you to set up advanced features like Hardware Security Modules and FedRAMP +compliance. -### Teleport Enterprise +[Read more about self-hosting Teleport +Enterprise](./teleport-enterprise/introduction.mdx). -A self-hosted Teleport deployment for security-conscious organizations. -Supports advanced features like Hardware Security Modules and FedRAMP -compliance. +## Migrating Teleport Enterprise clusters to the cloud -[Read more about Teleport Enterprise](./teleport-enterprise/introduction.mdx). +We recommend using the cloud-hosted edition of Teleport Enterprise for most +organizations, as it removes the overhead of maintaining, scaling, and securing +a deployment of the Auth Service and Proxy Service. To migrate from a +self-hosted Teleport Enterprise deployment to a cloud-hosted deployment, follow +the [migration guide](./migrate-to-cloud.mdx). -### Teleport Community Edition +## Teleport Community Edition -We provide a free, open source distribution of Teleport that enables you to get -secure access to databases, Windows desktops, Kubernetes clusters, and more. +For hobby and personal use, we provide a free, open source distribution of +Teleport that enables you to get secure access to databases, Windows desktops, +Kubernetes clusters, and more. -[Try out Teleport on a Linux server](../index.mdx). If you would like to -take a look at the source, visit the [Teleport GitHub +[Try out Teleport on a Linux server](../index.mdx). If you would like to take a +look at the source, visit the [Teleport GitHub repository](https://github.com/gravitational/teleport). ## Comparing editions diff --git a/docs/pages/choose-an-edition/migrate-to-cloud.mdx b/docs/pages/choose-an-edition/migrate-to-cloud.mdx new file mode 100644 index 0000000000000..9397da8d641e4 --- /dev/null +++ b/docs/pages/choose-an-edition/migrate-to-cloud.mdx @@ -0,0 +1,324 @@ +--- +title: Migrating from Teleport Enterprise (Self-Hosted) to Teleport Enterprise (Cloud-Hosted) +description: How to migrate from Teleport Enterprise (self-hosted) to Teleport Enterprise (cloud-hosted). +h1: Migrate to Cloud-Hosted Teleport Enterprise +--- + +Migrating from a Teleport Enterprise (self-hosted) deployment to Teleport +Enterprise (cloud-hosted) offers scalability, reliability, and ease of +management. By following the steps outlined in this guide, you can transition +your Teleport Enterprise (self-hosted) deployment to Teleport Enterprise +(cloud-hosted) successfully while ensuring minimal disruption to your +operations. + +## How it works + +While in a cloud-hosted Enterprise Teleport account, Teleport manages the Auth +Service and Proxy Service for you, you need to migrate dynamic resources and +Teleport services yourself. + +To migrate a self-hosted Teleport Enterprise cluster to a cloud-hosted Teleport +Enterprise cluster: + +1. Set up a separate cloud-hosted Teleport account. +1. Retrieve dynamic Teleport resources from the Auth Service backend on the + self-hosted cluster and apply them against the Auth Service backed on the + cloud-hosted cluster. +1. Reconfigure Teleport agents and plugins to connect to the cloud-hosted + Teleport cluster. +1. Verify that the migration has succeeded. + +## Prerequisites + +- An existing Teleport Enterprise (self-hosted) cluster. +- The `tsh` and `tctl` client tools. This guide assumes that you are using + `tctl` to manage dynamic resources, but it is also possible to use [Teleport + Terraform provider](./management/dynamic-resources/terraform-provider.mdx) and + [Kubernetes + operator](./management/dynamic-resources/teleport-operator-standalone.mdx), in + addition to custom scripts that use the [Teleport API](./api/introduction.mdx) + to manage the Teleport Auth Service backend. + +## Step 1/4. Deploy your Teleport Enterprise (cloud-hosted) cluster + +1. Determine the `teleport.sh` subdomain you would like to use for your new + Teleport Enterprise (cloud-hosted) account. + +1. If your existing Teleport Enterprise (self-hosted) license dashboard is + already using your desired subdomain, you can contact Teleport Support to + free up the domain for re-use. + + [Reach out](https://goteleport.com/signup/enterprise/) to your Account + Management team to set up your Teleport Enterprise (cloud-hosted) tenant. + +1. Ensure you are running Teleport Enterprise agents with versions that are + lower than the Teleport Enterprise (cloud-hosted) tenant version. To check + the versions of your Teleport Enterprise agents, you can use the `tctl` + command to list the inventory of connected agents and their version: + + ```code + $ tctl inventory ls --older-than= + ``` + +Validate connectivity to both the newly deployed Teleport Enterprise +(cloud-hosted) cluster and your existing Teleport Enterprise (self-hosted) +cluster. You should be able to connect to both Teleport clusters and execute +`tctl` commands using your current credentials. + +1. Log in to the self-hosted Teleport Enterprise cluster: + + ```code + $ tsh login --proxy= --user= + $ tctl status + ``` + +1. Log in to the cloud-hosted Teleport Enterprise cluster: + + ```code + $ tsh login --proxy= --user= + $ tctl status + ``` + +1. Subscribe to the [Teleport Enterprise status + website](https://status.teleport.sh/) to stay current on any issues impacting + Teleport Enterprise (cloud-hosted) performance. + + + + Ensure that the recovery codes displayed when you first set up your Teleport Enterprise (cloud-hosted) tenant are saved securely, so as not to lose access. For your security, Teleport Support cannot assist with resetting passwords or recovering lost credentials. + + + +## Step 2/4. Migrate Teleport resources + +After ensuring that both your self-hosted and cloud-hosted Teleport Enterprise +clusters are up and running, you can migrate dynamic Teleport resources from one +cluster to the next. + +Dynamic Teleport resources such as roles and local users are stored on the +Teleport Auth Service backend. Since your self-hosted Teleport Enterprise +cluster uses a separate Auth Service backend from your cloud-hosted cluster, you +must retrieve the resources on the first backend, then re-apply them against the +second backend. + +Review the [dynamic resources](https://goteleport.com/docs/reference/resources/) +list to see if any other resources need to be migrated. Some common dynamic +resources includes: + +- `windows_desktop` +- `apps` +- `dbs` +- `login_rule` + + + + Trusted clusters are not supported on Teleport Enterprise (cloud-hosted). You + will not be able to migrate trusted cluster resources. + + + +If you are using infrastructure-as-code tools to +To achieve this: +- Log in to your existing Teleport Enterprise (self-hosted) Cluster and export a collection of the above-mentioned dynamic resource configuration using the `tctl` administrative tool. An example is shown below: + +```code +$ tsh login --proxy=teleport.example.com --user=admin@example.com +$ tctl get roles > roles.yaml +$ tctl get users > users.yaml +``` + +- Once you have the resource configuration file from the above, proceed to log in to your Teleport Enterprise (cloud-hosted) tenant with an admin user and create the resources from the exported files: + +```code +$ tsh login --proxy=example.teleport.sh --user=admin@example.com +$ tctl create -f roles.yaml +$ tctl create -f user.yaml +``` + +For your SSO auth connector, most SSO integrations only work for a single configured endpoint. It is recommended to create a separate SSO connector in your Identity Provider specifically for the Teleport Enterprise (cloud-hosted) endpoint, and configure a new Auth Connector in the Teleport Enterprise (cloud-hosted) tenant. + +## Step 3/4. Migrate Teleport services and plugins + +To migrate services such as Teleport agents, Machine ID Bots, and plugins, start +by cataloging the various services you're managing with Teleport. The following +resources should be considered for migration: + + - Teleport agents + - Machine ID Bots + - Access Request plugins + - The Teleport Event Handler + +Before migrating services, make sure you are logged in to your new cloud-hosted +Teleport Enterprise account. + +You can migrate Teleport services all at once or gradually, depending on your +business requirements. If running Teleport at scale, you'll generally want to +use a configuration management tool to automate and streamline the process of +carrying out the actions involved in migrating agent configurations. + +### Migrate Teleport agents + +To migrate Teleport agents: + +1. For each agent and Machine ID bot, obtain a valid join token. We recommend + using a [delegated join + method](https://goteleport.com/docs/reference/join-methods/#delegated-join-methods). + +1. If using ephemeral tokens, ensure you specify the appropriate token type to + match the Teleport services. Token types can include `node`, `app`, `kube`, + `db`, `windowsdesktop` and others depending on the service you wish to join + to your Teleport Cluster. + +1. In the following example, a new token is created with the TTL of fifteen + minutes: + + ```code + $ tctl tokens add --type node,app,db --ttl 15m + ``` + + In this command, we assigned the token the `node`, `app` and `db` type, + indicating that it will allow an agent to join which is running the Teleport + `ssh_service`, `db_service` and `app_service`. + + Copy the token so you can use it later in this guide. + +1. Stop Teleport services on the agent (if applicable). + +1. Update the `proxy_server` or `auth_servers` field in the agent configuration + file to point to the address of your Teleport Enterprise (cloud-hosted) + cluster. By default, on Linux servers, the configuration is located in the + `/etc/teleport.yaml` directory. + + ```yaml + version: v3 + teleport: + proxy_server: example.teleport.sh:443 + ``` + +1. Update the `auth_token` or `join_params.token_name` field with the newly + generated token. + + ```yaml + teleport: + join_params: + method: token + token_name: new-token-goes-here + ``` + +1. On Linux servers, delete the local agent cache to force the agent to rejoin + the new Teleport Enterprise (cloud-hosted) Cluster. By default, the data is + located in the `/var/lib/teleport` directory: + + ```code + rm -rf /var/lib/teleport + ``` + +1. On Linux servers, restartthe Teleport process on each agent or, if you are + using the `teleport-kube-agent` Helm chart, recycle the Kubernetes pod to + apply the new configuration. This will cause the agents to re-register with + the cloud-hosted Teleport Enterprise cluster and obtain new certificates + signed by the new cluster's certificate authority. + +### Migrate Machine ID bots + +In general, you can migrate a Machine ID bot using the following steps: + +1. Obtain a new join token. +1. In the `tbot` configuration file, edit the `proxy_server` configuration field + to point to the new Teleport cluster address and port `443`. +1. Restart `tbot`. + +To learn how to restart and configure a Machine ID bot in your infrastructure, +read the [full documentation](./machine-id/deployment.mdx) on deploying a +Machine ID Bot. + +### Access Request plugins and the Event Handler + +In general, you can migrate Teleport plugins using the following steps: + +1. If you are using Machine ID to produce credentials for the plugin, + reconfigure the Machine ID Bot to connect to the new Teleport cluster and + restart the Bot. + + Otherwise, connect to the new Teleport cluster with `tctl` and produce an + identity file manually, then make it available to the plugin. + +1. Reconfigure the plugin by editing the `teleport.address` field of the plugin + configuration file to point to the address of the new Teleport cluster, with + port `443`. + +1. Restart the plugin. + +For specific plugins running in your infrastructure, read the full documentation +on: +- [Access Request plugins](./access-controls/access-request-plugins.mdx) +- The [Teleport Event Handler](./management/export-audit-events.mdx) + +## Step 4/4. Verify end user access and performance + +Once you have migrated dynamic resources and reconfigured services to connect to +your new Teleport cluster, ensure that the setup is complete. + +1. Validate that all expected resources are present in the Teleport cluster and + verify their status and connectivity to ensure they are properly registered + and available for connections. You can either check via the Web UI, or use + `tctl` to get a list of all resources and verify their registration and + status. + + For example, to list all nodes registered with the Teleport Cluster, you can run the command below: + + ```code + $ tctl nodes ls + ``` + + Similarly, to list all other registered resources, you can run the commands below: + + + List all registered Kubernetes clusters: + + ```code + $ tctl kube ls + ``` + + List all registered databases: + + ```code + $ tctl db ls + ``` + + List all registered applications: + + ```code + $ tctl apps ls + ``` + + List all registered Windows desktops: + + ```code + $ tctl get windows_desktop + ``` + +1. Ensure that end users have the expected SSO access to your infrastructure. + +1. Establish break-glass access procedures to ensure access to infrastructure in + case your cloud-hosted Teleport Enterprise cluster becomes unavailabile. + + For example, you can run OpenSSH with a limited key following our best + practices on [How to SSH + properly](https://goteleport.com/blog/how-to-ssh-properly/). + + We recommend configuring systemd to start OpenSSH for 5 minutes at boot, then + shut it down. The master keys should be stored in a secure vault. To break the + glass, obtain the master key, reboot the server, and connect using an OpenSSH + client within 5 minutes. + +## Further reading + +For more information on using cloud-hosted Teleport Enterprise, refer to our +documentation on [signing up for a cloud-hosted Teleport Enterprise +account](./teleport-cloud/introduction.mdx). diff --git a/docs/pages/migrating.mdx b/docs/pages/migrating.mdx deleted file mode 100644 index b9d5aa6d47823..0000000000000 --- a/docs/pages/migrating.mdx +++ /dev/null @@ -1,193 +0,0 @@ ---- -title: Migrating from Teleport Enterprise (self-hosted) to Teleport Enterprise (cloud-hosted) -description: How to migrate from Teleport Enterprise (self-hosted) to Teleport Enterprise (cloud-hosted). -h1: Migrate to Teleport Enterprise (cloud-hosted) ---- - -This guide outlines the steps required to migrate your Teleport deployment from a Teleport Enterprise (self-hosted) Cluster to Teleport Enterprise (cloud-hosted). -The migration process involves transferring configurations, migrating Teleport agents, and ensuring a successful transition with good performance on Teleport Enterprise (cloud-hosted). - - -## Prerequisites - -- An existing Teleport Enterprise (self-hosted) Cluster - - -## Next Steps - -### Deploy your Teleport Enterprise (cloud-hosted) Cluster - -- Determine the `teleport.sh` subdomain you would like to use for your new Teleport Enterprise (cloud-hosted) tenant. - - If your existing Teleport Enterprise (self-hosted) license dashboard is already using your desired subdomain, you can contact Teleport Support to free up the domain for re-use. - -- Reach out to your Account Management team to setup your Teleport Enterprise (cloud-hosted) tenant, [Contact Us](https://goteleport.com/signup/enterprise/). For more information, you may refer to our documentation on [signing up for a Teleport Enterprise account](https://goteleport.com/docs/choose-an-edition/teleport-cloud/introduction/) - -- Ensure you are running Teleport enterprise agents with versions which are lower than the Teleport Enterprise (cloud-hosted) tenant version. - - To check the versions of your Teleport Enterprise agents, you can use the `tctl` command to list the inventory of connected agents and their version. - -```code -tctl inventory ls --older-than= -``` - -- Validate connectivity to both the newly deployed Teleport Enterprise (cloud-hosted) Cluster and your existing Teleport Enterprise (self-hosted) Cluster. You should be able to connect to both Teleport Clusters and execute `tctl` commands using your current credentials. To verify connectivity, follow these steps: - - Sign in to your Teleport Cluster using `tsh login`. - - Verify connectivity by running `tctl status` - - - - - - Ensure that the recovery codes displayed when you first set up your Teleport Enterprise (cloud-hosted) tenant are saved securely, so as not to lose access. For your security, Teleport Support cannot assist with resetting passwords or recovering lost credentials. - - - - -- Subscribe to the [Teleport Enterprise status website](https://status.teleport.sh/) to stay current on any issues impacting Teleport Enterprise (cloud-hosted) performance. - -### Validate connectivity - -To check that you can connect to your Teleport Enterprise (cloud-hosted) tenant, using the `tsh` command-line tool sign in with `tsh login`, then verify that you can run `tctl` commands using your current credentials. -For example: - -```code -$ tsh login --proxy=example.teleport.sh --user=admin@example.com -$ tsh status && tctl status -``` - -If you can connect to the Cluster and run the `tctl status` command, you can use your current credentials to run subsequent `tctl` commands from your workstation. - - -### Migrate Teleport Configurations. - -Migrating to Teleport Enterprise (cloud-hosted) involves transferring essential resource configurations from your Teleport Enterprise (self-hosted) Cluster to Teleport Enterprise (cloud-hosted). Teleport uses YAML configuration for these resources, hence, it is required to grab a backup of the dynamic resource configurations from the existing Teleport Enterprise (self-hosted) Cluster and restore the resource on Teleport Enterprise (cloud-hosted). These resources include: - -- Roles -- Local users -- SSO authentication connectors - -Review the [dynamic resources](https://goteleport.com/docs/reference/resources/) list to see if any other resources need to be migrated. Some common dynamic resources includes: -- `windows_desktop` -- `apps` -- `dbs` -- `login_rule` - - - - - - Trusted Clusters are not supported on Teleport Enterprise (cloud-hosted). You will not be able to migrate trusted Cluster resources. - - - - -To achieve this: -- Log in to your existing Teleport Enterprise (self-hosted) Cluster and export a collection of the above-mentioned dynamic resource configuration using the `tctl` administrative tool. An example is shown below: - -```code -$ tsh login --proxy=teleport.example.com --user=admin@example.com -$ tctl get roles > roles.yaml -$ tctl get users > users.yaml -``` - -- Once you have the resource configuration file from the above, proceed to log in to your Teleport Enterprise (cloud-hosted) tenant with an admin user and create the resources from the exported files: - -```code -$ tsh login --proxy=example.teleport.sh --user=admin@example.com -$ tctl create -f roles.yaml -$ tctl create -f user.yaml -``` - -For your SSO auth connector, most SSO integrations only work for a single configured endpoint. It is recommended to create a separate SSO connector in your Identity Provider specifically for the Teleport Enterprise (cloud-hosted) endpoint, and configure a new Auth Connector in the Teleport Enterprise (cloud-hosted) tenant. - - -### Migrate Teleport Agents - -To ensure a successful migration process across your infrastructure, start by cataloging the various services you're managing with Teleport. The following resources should be considered for migration: - - - Teleport Agents (SSH, Kubernetes, Databases, Applications, Desktops) - - Machine ID Bots - - Access Request Plugins - -The following procedure is required to successfully migrate your Teleport agents: - -- Log in to your Teleport Enterpise (cloud-hosted) tenant, You'll need to authenticate to access your resources and management interfaces. - -- Obtain a valid join token: We recommend using a [Delegated Join Method](https://goteleport.com/docs/reference/join-methods/#delegated-join-methods) - -If using ephemeral tokens, ensure you specify the appropriate token type to match the Teleport services. Token types can include `node`, `app`, `kube`, `db`, `windowsdesktop` and others depending on the service you wish to join to your Teleport Cluster. - -In the following example, a new token is created with the TTL of fifteen minutes: - -```code -$ tctl tokens add --type node,app,db --ttl 15m -``` - -In this command, we assigned the token the `node`, `app` and `db` type, indicating that it will allow an agent to join which is running the Teleport `ssh_service`, `db_service` and `app_service`. - -Copy the token so you can use it later in this guide. - -- Stop the Teleport service on the agent (if applicable) - -- Update the `proxy_server` or `auth_servers` field in the agent configuration file to point to the address of your Teleport Enterprise (cloud-hosted) Cluster. By default, the configuration is located in the `/etc/teleport.yaml` directory. - -```yaml -version: v3 -teleport: - proxy_server: example.teleport.sh:443 -``` - -- Update the `auth_token` or `join_params.token_name` field with the newly generated token. - -```yaml -teleport: - join_params: - method: token - token_name: new-token-goes-here -``` - -- Delete the local agent cache to force the agent to rejoin the new Teleport Enterprise (cloud-hosted) Cluster. By default, the data is located in the `/var/lib/teleport` directory: - -```code -rm -rf /var/lib/teleport -``` - -- Start the Teleport process on each agent or recycle the pod to apply the new configuration. This will cause the agents to re-register with the Teleport Enterprise (cloud-hosted) Cluster and obtain new certificates signed by the Teleport Enterprise (cloud-hosted) Cluster's certificate authority. - -As new services come online, they start sending heartbeat requests every few seconds to the Auth Service. This allows users to explore Cluster membership. - -Note: ​​Migration of agents can be done all at once or gradually, depending on your business requirements. If running Teleport at scale, you'll generally want to leverage the use of a configuration management tool to automate and streamline the process of carrying out the actions involved in migrating agent configurations. - -### Verify end User Access and performance - -Once the migration is complete, validate that the resources are present in the Teleport Cluster and verify their status and connectivity to ensure they are properly registered and available for connections. You can either check via the Web UI, or use `tctl` to get a list of all resources and verify their registration and status. - -To list all other registered resources, you can run the commands below: - -| **Resource Type** | **Command** | -|--------------------------|---------------------------| -| Nodes | `tctl nodes ls` | -| Kubernetes Clusters | `tctl kube ls` | -| Databases | `tctl db ls` | -| Applications | `tctl apps ls` | -| Windows Desktops | `tctl get windows_desktop`| - - -These `tctl` commands will show you the resources registered within your Teleport Cluster, and you can verify their availability for connections. - -- Ensure that end users have the expected SSO access to your infrastructure and workflow. - -Additionally, establish break glass access procedures to ensure access to infrastructure in case of Teleport Enterprise (cloud-hosted) unavailability. -An example break-glass option for infrastructure admins for temporary access in case of an outage: - -- Run OpenSSH with a limited key following our best practices on [How to SSH properly](https://goteleport.com/blog/how-to-ssh-properly/). - - We recommend configuring systemd to start OpenSSH for 5 minutes at boot, then shut it down. The master keys should be stored in a secure vault. To break the glass, obtain the master key, reboot the server, and connect using an OpenSSH client within 5 minutes. - -### Conclusion - -Migrating from a Teleport Enterprise (self-hosted) deployment to Teleport Enterprise (cloud-hosted) offers scalability, reliability, and ease of management. By following the steps outlined in this guide, you can transition your Teleport Enterprise (self-hosted) deployment to Teleport Enterprise (cloud-hosted) successfully while ensuring minimal disruption to your operations.