diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-jira.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-jira.mdx index ef7152a018ae3..cabc76c523524 100644 --- a/docs/pages/access-controls/access-request-plugins/ssh-approval-jira.mdx +++ b/docs/pages/access-controls/access-request-plugins/ssh-approval-jira.mdx @@ -37,9 +37,9 @@ You'll need the project Jira key to configure the plugin. Create a new board for tasks in the permission management project. The board has to have at least these three columns: -1. Pending -2. Approved -3. Denied +- Pending +- Approved +- Denied Teleport's Jira plugin will create a new issue for each new permission request in the first available column on the board. When you drag the request task to the Approved column in Jira, the request will be approved. If you drag the request task to the Denied column in Jira, the request will be denied. @@ -158,10 +158,10 @@ plugin to Teleport. The `[jira]` section requires a few things: -1. Your Jira Cloud or Jira Server URL. For Jira Cloud, it looks something like `yourcompany.atlassian.net`. -2. Your username on Jira, i.e. [ben@goteleport.com](mailto:ben@goteleport.com) -3. Your Jira API token that you've created above. -4. A Jira Project key, available in Project settings. +- Your Jira Cloud or Jira Server URL. For Jira Cloud, it looks something like `yourcompany.atlassian.net`. +- Your username on Jira, i.e. [ben@goteleport.com](mailto:ben@goteleport.com) +- Your Jira API token that you've created above. +- A Jira Project key, available in Project settings. The `[http]` setting block describes how the plugin's HTTP server works. The HTTP server is responsible for listening for updates from Jira, and processing updates, like when someone drags a task from Inbox to Approved column. diff --git a/docs/pages/access-controls/access-requests/oss-role-requests.mdx b/docs/pages/access-controls/access-requests/oss-role-requests.mdx index bea21f395a5fc..91476769428de 100644 --- a/docs/pages/access-controls/access-requests/oss-role-requests.mdx +++ b/docs/pages/access-controls/access-requests/oss-role-requests.mdx @@ -11,19 +11,19 @@ requesting a role via the Teleport CLI. Full Access Request functionality, including Resource Access Requests and an intuitive and searchable UI are available in Teleport Enterprise. -## RBAC Setup +## RBAC security setup Teleport's role-based access control (RBAC) allows you to configure what roles users can request access to. In this example, we will define two roles: -1. `contractor`: users with this role can request elevated access to the `dba` role -2. `dba`: this role grants access to databases +- `contractor`: users with this role can request elevated access to the `dba` role +- `dba`: this role grants access to databases There is no role for request approvers, because request approval rules can only be configured for Teleport Enterprise. In Open Source Teleport, approvals must be performed by running `tctl` on the Auth Server. -**Contractor Role** +**Contractor role** Users with this role can request access to the `dba` role. @@ -51,7 +51,7 @@ $ tctl users update --set-roles \ $(tctl get users/alice --format=json | jq -r '.[].spec.roles | join(",")'),contractor alice ``` -**DBA Role** +**DBA role** This role grants access to databases. diff --git a/docs/pages/access-controls/access-requests/role-requests.mdx b/docs/pages/access-controls/access-requests/role-requests.mdx index 1ec0bfbcb1598..036c6eef2b806 100644 --- a/docs/pages/access-controls/access-requests/role-requests.mdx +++ b/docs/pages/access-controls/access-requests/role-requests.mdx @@ -18,9 +18,9 @@ via ChatOps or anywhere else via our flexible Authorization Workflow API. In this example, we will define three roles: -1. `contractor`: users with this role can request elevated access to the `dba` role -2. `dba`: this role grants access to databases -3. `approver`: users with this role can approve requests for access to the `dba` role +- `contractor`: users with this role can request elevated access to the `dba` role +- `dba`: this role grants access to databases +- `approver`: users with this role can approve requests for access to the `dba` role **Contractor Role** diff --git a/docs/pages/access-controls/device-trust/jamf-integration.mdx b/docs/pages/access-controls/device-trust/jamf-integration.mdx index 352300b20eb51..c4a54d7642615 100644 --- a/docs/pages/access-controls/device-trust/jamf-integration.mdx +++ b/docs/pages/access-controls/device-trust/jamf-integration.mdx @@ -32,7 +32,7 @@ Create a readonly Jamf user for inventory sync. 1. Access `https://yourtenant.jamfcloud.com/accounts.html`, replacing `yourtenant` with your Jamf Pro account. -2. Create a new Standard Account with the following settings: +1. Create a new Standard Account with the following settings: - Username: teleport (change as desired) - Access Level: Full Access diff --git a/docs/pages/access-controls/guides/moderated-sessions.mdx b/docs/pages/access-controls/guides/moderated-sessions.mdx index 15ec098fe55a7..1b579fa86c74e 100644 --- a/docs/pages/access-controls/guides/moderated-sessions.mdx +++ b/docs/pages/access-controls/guides/moderated-sessions.mdx @@ -249,8 +249,8 @@ this policy requires. The `on_leave` string option in require policies is used to define what happens when a moderator leaves a session, causing a policy to no longer be satisfied. There are two possible actions to take in this scenario: -1. Terminate the session and disconnect all participants, corresponding to the `"terminate"` value. -2. Pause the session and stop any input/output streaming until the policy is satisfied again, corresponding to the `"pause"` value. +- Terminate the session and disconnect all participants, corresponding to the `"terminate"` value. +- Pause the session and stop any input/output streaming until the policy is satisfied again, corresponding to the `"pause"` value. By default, Teleport treats an empty string in this field as the same as `terminate`. That is, the session is terminated instantly and all participants are disconnected. diff --git a/docs/pages/access-controls/login-rules/reference.mdx b/docs/pages/access-controls/login-rules/reference.mdx index 3803bd5bbde80..f52ad1f19656a 100644 --- a/docs/pages/access-controls/login-rules/reference.mdx +++ b/docs/pages/access-controls/login-rules/reference.mdx @@ -17,8 +17,7 @@ To learn how to add the first login rule to your cluster, checkout out the ## `traits_map` vs `traits_expression` -Every login rule spec must contain either the `traits_map` field or a -`traits_expression` field. +Every login rule spec must contain either the `traits_map` field or a `traits_expression` field. They both serve the same purpose of transforming user traits. The logic difference lies only in the syntax you prefer for your use case, since you can write @@ -29,8 +28,8 @@ every `traits_map` as an equivalent `traits_expression`. while keeping the rest unchanged. The `traits_map` behavior can be useful if you want to keep only a handful of necessary traits while filtering out all others. -If lower priority Login Rules set traits those must be also included with higher priority `traits_map` -to remain populated. For example this configuration will keep the `groups` trait unmodified. +If lower priority Login Rules set traits, those traits must be also included with higher priority `traits_map` +to remain populated. For example, the following configuration keeps the `groups` trait unmodified. ```yaml traits_map: @@ -40,15 +39,16 @@ to remain populated. For example this configuration will keep the `groups` trait ### `traits_map` -Here is an example Login Rule using a `traits_map` which implements the +Here is an example Login Rule that uses a `traits_map` to implement the following rules: -1. Every user with the `groups: devs` trait should receive an extra trait + +- Every user with the `groups: devs` trait should receive an extra trait `access: [staging]`. -2. Every user with the `groups: admins` trait should receive an extra trait +- Every user with the `groups: admins` trait should receive an extra trait `access: [staging, prod]`. -3. Every user should receive a `logins` trait with the value of their incoming +- Every user should receive a `logins` trait with the value of their incoming `username` trait converted to lowercase. -4. All traits other than `groups`, `logins`, and `access` should be filtered +- All traits other than `groups`, `logins`, and `access` should be filtered out. ```yaml diff --git a/docs/pages/access-controls/sso/azuread.mdx b/docs/pages/access-controls/sso/azuread.mdx index 85f4e2c815429..c87b4a25c0bde 100644 --- a/docs/pages/access-controls/sso/azuread.mdx +++ b/docs/pages/access-controls/sso/azuread.mdx @@ -38,17 +38,17 @@ Before you get started, you’ll need: ![Select Enterprise Applications From Manage](../../../img/azuread/azuread-1-home.png) -2. Select **New application** +1. Select **New application** ![Select New Applications From Manage](../../../img/azuread/azuread-2-newapp.png) -3. Select **Create your own application**, enter the application name (for example, +1. Select **Create your own application**, enter the application name (for example, Teleport), and select **Integrate any other application you don't find in the gallery (Non-gallery)**. ![Select Non-gallery application](../../../img/azuread/azuread-3-createnongalleryapp.png) -4. Select **Properties** under **Manage** and set **Assignment required?** to **No** +1. Select **Properties** under **Manage** and set **Assignment required?** to **No** ![Turn off user assignment](../../../img/azuread/azuread-4-turnoffuserassign.png) @@ -60,11 +60,11 @@ Before you get started, you’ll need: ![Select SAML](../../../img/azuread/azuread-5-selectsaml.png) -2. Edit the **Basic SAML Configuration** +1. Edit the **Basic SAML Configuration** ![Edit Basic SAML Configuration](../../../img/azuread/azuread-6-editbasicsaml.png) -3. Enter the URL for your Teleport cluster or Teleport tenant in the **Entity ID** and **Reply URL** fields. For example: +1. Enter the URL for your Teleport cluster or Teleport tenant in the **Entity ID** and **Reply URL** fields. For example: name="mytenant.teleport.sh:443" /> to the host and HTTPS port of your Teleport Proxy Service (or Teleport Team/Enterprise Cloud tenant): @@ -76,7 +76,7 @@ Before you get started, you’ll need: Click **Save** before proceeding to the next step. -4. In **SAML Certificates** section, copy the **App Federation +1. In **SAML Certificates** section, copy the **App Federation Metadata URL** link and save it for use in our Teleport connector configuration: ![Download Federation Metadata XML](../../../img/azuread/azuread-9-fedmeatadataxml.png) @@ -85,16 +85,16 @@ Before you get started, you’ll need: 1. Click on **Unique User Identifier (Name ID)** under **Required claim**. -2. Change the "name identifier format" to **Default**. Make sure the source +1. Change the "name identifier format" to **Default**. Make sure the source attribute is `user.userprincipalname`. ![Confirm Name Identifier](../../../img/azuread/azuread-8a-nameidentifier.png) -3. Add a group claim to make user security groups available to the connector: +1. Add a group claim to make user security groups available to the connector: ![Put in Security group claim](../../../img/azuread/azuread-8b-groupclaim.png) -4. Add a claim that transforms the format of the Azure AD username to lower case, in order to pass it to +1. Add a claim that transforms the format of the Azure AD username to lower case, in order to pass it to Teleport. Set the Source to "Transformation". In the new panel: - Set the Transformation value to "Extract()" diff --git a/docs/pages/access-controls/sso/gitlab.mdx b/docs/pages/access-controls/sso/gitlab.mdx index f92a35ea23823..74f8485bfe813 100644 --- a/docs/pages/access-controls/sso/gitlab.mdx +++ b/docs/pages/access-controls/sso/gitlab.mdx @@ -41,12 +41,12 @@ to each of these groups. ![Create App](../../../img/sso/gitlab/gitlab-oidc-0.png) -2. Collect the `Application ID` and `Secret` in the Application. These will be +1. Collect the `Application ID` and `Secret` in the Application. These will be used in the Teleport OIDC auth connector: ![Collection Information](../../../img/sso/gitlab/gitlab-oidc-1.png) -3. Confirm the GitLab issuer address. +1. Confirm the GitLab issuer address. For GitLab.com, the issuer address is `https://gitlab.com`. This allows Teleport to access the Open-ID configuration at diff --git a/docs/pages/agents/introduction.mdx b/docs/pages/agents/introduction.mdx index e32a0156a6c2b..a72a8013dac1a 100644 --- a/docs/pages/agents/introduction.mdx +++ b/docs/pages/agents/introduction.mdx @@ -77,9 +77,9 @@ Services to your Cluster](./join-services-to-your-cluster.mdx) guides. There are two ways to enroll infrastructure resources with Teleport agents: -1. **Static**: Edit an agent's configuration file to configure a specific +- **Static**: Edit an agent's configuration file to configure a specific infrastructure resource to proxy. -2. **Dynamic**: Apply a [configuration +- **Dynamic**: Apply a [configuration resource](../management/dynamic-resources.mdx) that configures a resource to proxy. diff --git a/docs/pages/agents/join-services-to-your-cluster/aws-ec2.mdx b/docs/pages/agents/join-services-to-your-cluster/aws-ec2.mdx index 056393b9e7d1e..631e2384e2f4c 100644 --- a/docs/pages/agents/join-services-to-your-cluster/aws-ec2.mdx +++ b/docs/pages/agents/join-services-to-your-cluster/aws-ec2.mdx @@ -58,7 +58,7 @@ The Teleport Auth Service needs permission to call `ec2:DescribeInstances` in or that the EC2 instances attempting to join your cluster are legitimate and currently running. -### Step 1.1. Create the IAM policy +### Create the IAM policy Create the following AWS IAM policy named `teleport-DescribeInstances-policy` in your account: @@ -76,7 +76,7 @@ your account: } ``` -### Step 1.2. Attach the IAM policy +### Attach the IAM policy If your Teleport Auth Service is running on an EC2 instance and already has an attached "IAM role for Amazon EC2", add the above @@ -194,16 +194,16 @@ have permissions to assume an IAM role in each of those accounts and call In each AWS account where your EC2 instances will be running: -1. Create the `teleport-DescribeInstances-policy` from [Step 1.1](#step-11-create-the-iam-policy). +1. Create the `teleport-DescribeInstances-policy` from [Step 1.1](#create-the-iam-policy). -2. Create an IAM role `teleport-DescribeInstances-role` that can be assumed from +1. Create an IAM role `teleport-DescribeInstances-role` that can be assumed from the account where your Teleport Auth Service is running. Go to the AWS IAM Console, select Create Role, and for "Select type of trusted entity", select "Another AWS account" and enter the AWS Account ID of the account where your Teleport Auth Service is running. - Attach the `teleport-DescribeInstances-policy` to the role. +1. Attach the `teleport-DescribeInstances-policy` to the role. In the AWS account where your Teleport Auth Service is running: @@ -228,8 +228,8 @@ In the AWS account where your Teleport Auth Service is running: } ``` -2. Attach this `teleport-AssumeRole-policy` to the IAM role your Teleport Auth - Service has credentials for, see [Step 1.2](#step-12-attach-the-iam-policy). +1. Attach this `teleport-AssumeRole-policy` to the IAM role your Teleport Auth + Service has credentials for, see [Step 1.2](#attach-the-iam-policy). When creating the AWS joining token, include an allow rule for each foreign account and specify the AWS ARN for the foreign diff --git a/docs/pages/ai-assist.mdx b/docs/pages/ai-assist.mdx index 1651343f3532f..69a15eb1bc43f 100644 --- a/docs/pages/ai-assist.mdx +++ b/docs/pages/ai-assist.mdx @@ -58,16 +58,16 @@ Follow these steps to generate your OpenAI API key: 1. Sign in to your OpenAI account or [sign up](https://platform.openai.com/signup) if you don't have one. -2. Navigate to the [API section](https://platform.openai.com/account/api-keys) +1. Navigate to the [API section](https://platform.openai.com/account/api-keys) in your OpenAI dashboard. -3. Click on "Create new secret key". -4. Give your key a descriptive name. -5. Click "Create secret key". -6. Your new API key will be displayed. Make sure to copy it and save it in a +1. Click on "Create new secret key". +1. Give your key a descriptive name. +1. Click "Create secret key". +1. Your new API key will be displayed. Make sure to copy it and save it in a file on the system where the Teleport Proxy Service is running, e.g., `/etc/teleport/openai_key`. If you have multiple instances of Teleport Proxy, you must copy the file to all of them. -7. Set read-only permissions and change the file owner to the user that the +1. Set read-only permissions and change the file owner to the user that the Teleport Proxy Service uses by running the following commands: ```bash @@ -86,29 +86,30 @@ To enable Teleport Assist, you need to provide your OpenAI API key. On each Proxy and Auth Service host, perform the following actions: 1. Open your Teleport configuration file. This is typically located at `/etc/teleport.yaml`. -2. Add your OpenAI API key to the `assist` section: -If the host is running the Auth Service, add the following section: +1. Add your OpenAI API key to the `assist` section: - ```yaml -auth_service: - assist: - openai: - api_token_path: /etc/teleport/openai_key -``` - -If the host is running the Proxy Service, add the following section: + If the host is running the Auth Service, add the following section: + + ```yaml + auth_service: + assist: + openai: + api_token_path: /etc/teleport/openai_key + ``` -```yaml -proxy_service: - assist: - openai: - api_token_path: /etc/teleport/openai_key -``` + If the host is running the Proxy Service, add the following section: + + ```yaml + proxy_service: + assist: + openai: + api_token_path: /etc/teleport/openai_key + ``` -3. Save the changes and close the file. -4. Restart Teleport for the changes to take effect. +1. Save the changes and close the file. +1. Restart Teleport for the changes to take effect. Make sure that your Teleport user has the `assistant` permission. By default, users with built-in `access` and `editor` roles have this permission. You can also @@ -137,10 +138,10 @@ spec: Now that you have Teleport Assist enabled, you can start using it. 1. Open Teleport's Web UI in your browser (e.g., https://teleport.example.com). -2. Log in to the Web UI using your Teleport credentials. -3. Click on the "Assist" button in the top left dropdown menu. +1. Log in to the Web UI using your Teleport credentials. +1. Click on the "Assist" button in the top left dropdown menu. ![Teleport Assist Menu](../img/assist/main-screen.png) -4. Click "New Conversation" to start a new conversation with Teleport Assist. +1. Click "New Conversation" to start a new conversation with Teleport Assist. ![Teleport Assist New Chat](../img/assist/assist-screen.png) Remember, Teleport Assist is powered by OpenAI, so the more specific your query, diff --git a/docs/pages/api/getting-started.mdx b/docs/pages/api/getting-started.mdx index 019cdf861240d..762bb9545e014 100644 --- a/docs/pages/api/getting-started.mdx +++ b/docs/pages/api/getting-started.mdx @@ -8,9 +8,9 @@ to a Teleport Auth Service. Here are the steps we'll walkthrough: -1. Create an API user using a simple role-based authentication method. -2. Generate credentials for that user. -3. Create and connect a Go client to interact with Teleport's API. +- Create an API user using a simple role-based authentication method. +- Generate credentials for that user. +- Create and connect a Go client to interact with Teleport's API. ## Prerequisites diff --git a/docs/pages/architecture/authentication.mdx b/docs/pages/architecture/authentication.mdx index e229f47e07f2d..19803a83c0115 100644 --- a/docs/pages/architecture/authentication.mdx +++ b/docs/pages/architecture/authentication.mdx @@ -77,10 +77,10 @@ to the public key with a certificate authority's signature. OpenSSH certificate contain metadata used to authenticate users and hosts: -1. List of principals (identities) this certificate belongs to. -2. Signature of the certificate authority who issued it. -3. The expiration date, also known as "time-to-live" or simply TTL. -4. Additional data, such as the node role, is stored as a certificate extension. +- List of principals (identities) this certificate belongs to. +- Signature of the certificate authority who issued it. +- The expiration date, also known as "time-to-live" or simply TTL. +- Additional data, such as the node role, is stored as a certificate extension. ### Making Time Work For You diff --git a/docs/pages/architecture/nodes.mdx b/docs/pages/architecture/nodes.mdx index 428321f4c901d..eb5b23a0dfaca 100644 --- a/docs/pages/architecture/nodes.mdx +++ b/docs/pages/architecture/nodes.mdx @@ -130,12 +130,12 @@ helpful when gradually transitioning large server fleets to Teleport. We consider the "recording proxy mode" to be less secure for two reasons: -1. It grants additional privileges to the Teleport proxy. In the default mode, +- It grants additional privileges to the Teleport proxy. In the default mode, the proxy stores no secrets and cannot "see" the decrypted data. This makes a proxy less critical to the security of the overall cluster. But if an attacker gains physical access to a proxy Node running in the "recording" mode, they will be able to see the decrypted traffic and client keys stored in the proxy's process memory. -2. Recording proxy mode requires SSH Agent Forwarding. Agent Forwarding is required because without it, a proxy will not be able to establish the 2nd connection to the destination Node. +- Recording proxy mode requires SSH Agent Forwarding. Agent Forwarding is required because without it, a proxy will not be able to establish the 2nd connection to the destination Node. However, there are advantages of proxy-based session recording too. When sessions are recorded at the Nodes, a root user can add iptables rules to diff --git a/docs/pages/choose-an-edition/teleport-enterprise/gcp-kms.mdx b/docs/pages/choose-an-edition/teleport-enterprise/gcp-kms.mdx index 2e883312f228f..eebcc410cfcda 100644 --- a/docs/pages/choose-an-edition/teleport-enterprise/gcp-kms.mdx +++ b/docs/pages/choose-an-edition/teleport-enterprise/gcp-kms.mdx @@ -260,8 +260,8 @@ migration can be performed in three steps: 1. Configure all Auth Servers `ca_key_params` to use your desired KMS keyring, as described in [Step 4](#step-45-configure-your-auth-server-to-use-kms-keys). -2. Restart all Auth Servers. -3. Perform a full [CA rotation](../../management/operations/ca-rotation.mdx). +1. Restart all Auth Servers. +1. Perform a full [CA rotation](../../management/operations/ca-rotation.mdx). To avoid any downtime while migrating your cluster, do the following procedure instead: @@ -273,12 +273,12 @@ instead: your existing backend and new KMS key ring, one option would be to run it locally on an existing Auth Server host (make sure to give it its own `teleport.yaml` and unique `data_dir`). -2. Perform a full [CA rotation](../../management/operations/ca-rotation.mdx). +1. Perform a full [CA rotation](../../management/operations/ca-rotation.mdx). The temporary Auth Server will generate new KMS keys and include their names in the backend CA state. -3. Stop/remove/delete the temporary Auth Server as it is no longer necessary. -4. Configure all other existing Auth Servers with identical `ca_key_params` and +1. Stop/remove/delete the temporary Auth Server as it is no longer necessary. +1. Configure all other existing Auth Servers with identical `ca_key_params` and reload/restart them, one by one. They will now use the KMS keys generated by the temporary Auth Server. -5. Perform one more full CA rotation to evict all now-unused software keys from the +1. Perform one more full CA rotation to evict all now-unused software keys from the CA backend state so that hosts will no longer trust them. diff --git a/docs/pages/choose-an-edition/teleport-enterprise/hsm.mdx b/docs/pages/choose-an-edition/teleport-enterprise/hsm.mdx index 9010e62f6cb34..63f6465b7ddf2 100644 --- a/docs/pages/choose-an-edition/teleport-enterprise/hsm.mdx +++ b/docs/pages/choose-an-edition/teleport-enterprise/hsm.mdx @@ -39,9 +39,9 @@ to use. 1. Create a CloudHSM cluster in the VPC where you will run your Teleport Auth Server. https://docs.aws.amazon.com/cloudhsm/latest/userguide/create-cluster.html -2. Wait for the newly created cluster to enter the "Uninitialized" state. +1. Wait for the newly created cluster to enter the "Uninitialized" state. -3. Add an HSM to the new cluster, using the AWS Console or the AWS CLI: +1. Add an HSM to the new cluster, using the AWS Console or the AWS CLI: ```code $ aws cloudhsmv2 create-hsm --cluster-id --availability-zone @@ -56,10 +56,10 @@ to use. } ``` -4. Optionally verify the identity and authenticity of your new HSM +1. Optionally verify the identity and authenticity of your new HSM https://docs.aws.amazon.com/cloudhsm/latest/userguide/verify-hsm-identity.html -5. To initialize the cluster, you must download and sign a certificate signing +1. To initialize the cluster, you must download and sign a certificate signing request (CSR) that is generated by the cluster's first HSM. Download the CSR from the AWS Console or via the AWS CLI: @@ -70,7 +70,7 @@ to use. > ClusterCsr.csr ``` -6. Choose an appropriate RSA 2048 or RSA 4096 key and self-signed certificate to +1. Choose an appropriate RSA 2048 or RSA 4096 key and self-signed certificate to sign the HSM CSR. For a production cluster, AWS recommends a secured offsite and offline HSM. For a demonstration or test cluster, you can create a key and self-signed @@ -81,7 +81,7 @@ to use. $ openssl req -new -x509 -days 3652 -key customerCA.key -out customerCA.crt ``` -7. Sign the cluster CSR using the key and self-signed cert from the previous +1. Sign the cluster CSR using the key and self-signed cert from the previous step. A demonstration `openssl` command to sign the CSR is: @@ -93,7 +93,7 @@ to use. -out CustomerHsmCertificate.crt ``` -8. Initialize the CloudHSM cluster by uploading the signed cert to the AWS +1. Initialize the CloudHSM cluster by uploading the signed cert to the AWS Console or with the following AWS CLI command: ```code @@ -106,82 +106,83 @@ to use. } ``` -9. A security group with the same name as your CloudHSM cluster will have been +1. A security group with the same name as your CloudHSM cluster will have been automatically created when you created the cluster. Attach this security group to the EC2 instance where you will run your Teleport Auth Server to allow traffic between the Auth Server and your HSM. -10. On the Auth Server EC2 instance, install the CloudHSM CLI for the CloudHSM +1. On the Auth Server EC2 instance, install the CloudHSM CLI for the CloudHSM Client SDK 5. https://docs.aws.amazon.com/cloudhsm/latest/userguide/gs_cloudhsm_cli-install.html - Bootstrap the CLI by configuring the IP address of the new HSM: - - ```code - $ sudo /opt/cloudhsm/bin/configure-cli -a - ``` + Bootstrap the CLI by configuring the IP address of the new HSM: + + ```code + $ sudo /opt/cloudhsm/bin/configure-cli -a + ``` -11. Copy the self-signed certificate from step 6 (`customerCA.crt`) to the EC2 +1. Copy the self-signed certificate from step 6 (`customerCA.crt`) to the EC2 instance, save it at `/opt/cloudhsm/etc/customerCA.crt`. -12. Activate the CloudHSM cluster with the CloudHSM CLI by creating an admin user +1. Activate the CloudHSM cluster with the CloudHSM CLI by creating an admin user with a new password: - ```text - $ sudo /opt/cloudhsm/bin/cloudhsm-cli interactive - aws-cloudhsm > cluster activate - Enter password: - Confirm password: - { - "error_code": 0, - "data": "Cluster activation successful" - } - ``` - -13. Login to the CloudHSM CLI as the new admin user and create a Crypto User to + ```text + $ sudo /opt/cloudhsm/bin/cloudhsm-cli interactive + aws-cloudhsm > cluster activate + Enter password: + Confirm password: + { + "error_code": 0, + "data": "Cluster activation successful" + } + ``` + +1. Login to the CloudHSM CLI as the new admin user and create a Crypto User to be used by Teleport. Remember this new password because Teleport will use it later to authenticate to the PKCS#11 library. - ```text - aws-cloudhsm > login --username admin --role admin - Enter password: - { - "error_code": 0, - "data": { - "username": "admin", - "role": "admin" - } - } - aws-cloudhsm > user create --username teleport --role crypto-user - Enter password: - Confirm password: - { - "error_code": 0, - "data": { - "username": "teleport", - "role": "crypto-user" - } - } - aws-cloudhsm > quit - ``` - -14. Install the PKCS#11 library for the Client SDK 5 on the same Auth Server EC2 instance - https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library-install.html + ```text + aws-cloudhsm > login --username admin --role admin + Enter password: + { + "error_code": 0, + "data": { + "username": "admin", + "role": "admin" + } + } + aws-cloudhsm > user create --username teleport --role crypto-user + Enter password: + Confirm password: + { + "error_code": 0, + "data": { + "username": "teleport", + "role": "crypto-user" + } + } + aws-cloudhsm > quit + ``` - Bootstrap the PKCS#11 library by configuring the HSM IP address. - If you only have one HSM in the cluster, you must include the - `--disable-key-availability-check` flag. +1. Install the PKCS#11 library for the Client SDK 5 on the same Auth Server EC2 instance + https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library-install.html - ```code - $ sudo /opt/cloudhsm/bin/configure-pkcs11 --disable-key-availability-check -a + Bootstrap the PKCS#11 library by configuring the HSM IP address. + If you only have one HSM in the cluster, you must include the + `--disable-key-availability-check` flag. + ```code + $ sudo /opt/cloudhsm/bin/configure-pkcs11 --disable-key-availability-check -a + ``` + 1. Install the YubiHSM2 [SDK](https://developers.yubico.com/YubiHSM2/Releases/). -2. Start `yubihsm-connector` with debug logging enabled. This is a background +1. Start `yubihsm-connector` with debug logging enabled. This is a background process that you will need to keep running to facilitate connections to your YubiHSM2. @@ -190,7 +191,7 @@ to use. DEBU[0000] preflight complete cert= config= key= pid=73502 seccomp=false serial= syslog=false timeout=0s version=3.0.3 DEBU[0000] takeoff TLS=false listen="localhost:12345" pid=73502 ``` -3. Use `yubihsm-shell` to create a new authentication key to be used by +1. Use `yubihsm-shell` to create a new authentication key to be used by Teleport with the necessary capabilities. YubiHSM2 comes with a factory default authentication key at slot 1 with password @@ -224,7 +225,7 @@ to use. This will need to be included in your Teleport configuration file in a later step. -4. Create a `yubihsm_pkcs11.conf` file to configure the address and port that +1. Create a `yubihsm_pkcs11.conf` file to configure the address and port that `yubihsm-connector` is listening on and enable debug logging: ```text @@ -233,7 +234,7 @@ to use. debug ``` -5. Set the environment variable `YUBIHSM_PKCS11_CONF` to the path of your +1. Set the environment variable `YUBIHSM_PKCS11_CONF` to the path of your configuration file. This will be read by the PKCS#11 module and needs to be set in the Teleport auth server's environment. diff --git a/docs/pages/connect-your-client/introduction.mdx b/docs/pages/connect-your-client/introduction.mdx index a0640106c4be4..778cce44695d6 100644 --- a/docs/pages/connect-your-client/introduction.mdx +++ b/docs/pages/connect-your-client/introduction.mdx @@ -20,6 +20,7 @@ your Teleport cluster: + ```code $ tsh login --proxy= --user= Enter password for Teleport user alice: @@ -112,17 +113,17 @@ server and database access within a single window. ![A new instance of Teleport Connect](../../img/teleport-connect-init.png) -2. Provide the address of your Teleport Cluster (e.g. +1. Provide the address of your Teleport Cluster (e.g. `https://teleport.example.com` `https://mytennant.teleport.sh` ) and click **NEXT**. -3. Teleport Connect will ask you for your username, password, and MFA. If -Teleport is integrated with an external Identity Provider (**IdP**), it may -instead prompt you to authenticate in a browser window with that service. +1. Teleport Connect will ask you for your username, password, and MFA. + + If Teleport is integrated with an external Identity Provider (**IdP**), you might be + prompted to authenticate with that service in a browser window. -4. Once authenticated, you can browse and connect to all the resources your -user is permitted to access: +1. Browse and connect to all the resources your user is permitted to access: ![An example of Teleport Connect, populated with instances](../../img/use-teleport/connect-ui-overview.png) @@ -328,18 +329,18 @@ list those that are accessible to your user under `https://teleport.example.com` `https://mytennant.teleport.sh` ). - 1. From the menu on the right, select **Desktops**. -2. Next to the desktop you want to access, click **CONNECT**. Select +1. Next to the desktop you want to access, click **CONNECT**. Select or type in a username available to your Teleport user. -3. Teleport will open a new browser tab or window and begin the RDP session. +1. Teleport will open a new browser tab or window and begin the RDP session. Note that you may need to wait a moment for Teleport to log you in as the specified user. ## Next steps diff --git a/docs/pages/connect-your-client/teleport-connect.mdx b/docs/pages/connect-your-client/teleport-connect.mdx index dc52d7af4281a..e7125aa97a2f4 100644 --- a/docs/pages/connect-your-client/teleport-connect.mdx +++ b/docs/pages/connect-your-client/teleport-connect.mdx @@ -68,9 +68,10 @@ which cluster the current tab is bound to, and the **Share Feedback** button in 1. Open a tab with cluster resources by clicking on the plus symbol at the right end of the tab bar. You can also press `Ctrl/Cmd + T` to achieve the same result. -2. Look for the SSH server you want to connect to and click the Connect button to the right. -3. Select or enter the SSH user you wish to log in as and press `Enter`. -4. A new tab will open with a shell session on the chosen server. +1. Look for the SSH server you want to connect to and click the Connect button to the right. +1. Select or enter the SSH user you wish to log in as and press `Enter`. + +A new tab will open with a shell session on the chosen server. Alternatively, you can look for the server in the search bar and press `Enter` to connect to it. @@ -92,12 +93,13 @@ reflected in both the tab title and the status bar. 1. Open a tab with cluster resources by clicking on the plus symbol at the right end of the tab bar. You can also press `Ctrl/Cmd + T` to achieve the same result. -2. Select the Kubes section. -3. Look for the cluster you wish to connect to and click the Connect button to the right. -4. A new local terminal tab will open which is preconfigured with the `$KUBECONFIG` environment variable - pointing to a configuration for the specified cluster. Any tools that you have installed that respect - the `$KUBECONFIG` environment variable (`kubectl`, `helm`, etc.) will work without additional configuration. - To identify the path to this config for use in other tools, run `echo $KUBECONFIG`. +1. Select the Kubes section. +1. Look for the cluster you wish to connect to and click the Connect button to the right. + +A new local terminal tab will open which is preconfigured with the `$KUBECONFIG` environment variable +pointing to a configuration for the specified cluster. Any tools that you have installed that respect +the `$KUBECONFIG` environment variable (`kubectl`, `helm`, etc.) will work without additional configuration. +To identify the path to this config for use in other tools, run `echo $KUBECONFIG`. Alternatively, you can look for the cluster in the search bar and press `Enter` to connect to it. @@ -105,10 +107,11 @@ Alternatively, you can look for the cluster in the search bar and press `Enter` 1. Open a tab with cluster resources by clicking on the plus symbol at the end of the tab bar. You can also press `Ctrl/Cmd + T` to achieve the same result. -2. Select the Databases section. -3. Look for the database server you wish to connect to and click the Connect button to the right. -4. Select or enter the database user you wish to use and press `Enter`. -5. A new tab will open with a new connection established between your device and the database server. +1. Select the Databases section. +1. Look for the database server you wish to connect to and click the Connect button to the right. +1. Select or enter the database user you wish to use and press `Enter`. + +A new tab will open with a new connection established between your device and the database server. Alternatively, you can look for the database in the search bar and press `Enter` to connect to it. @@ -133,10 +136,9 @@ Teleport Connect allows you to log in to multiple clusters at the same time. Aft your first cluster, open the profile selector at the top right and click the *+Add another cluster* button. You can switch between active profiles in multiple ways: -- Click at the profile selector button at the top right. -- Open the profile selector with a shortcut (`Ctrl/Cmd + I`). -- Using the connection list at the top left to select a connection will automatically switch you to - the right profile. +1. Click at the profile selector button at the top right. +1. Open the profile selector with a shortcut (`Ctrl/Cmd + I`). +1. Select a connection from the connection list at the top to automatically switch to the right profile. At the moment Teleport Connect supports only one user per cluster. To log in as a different user, log out of the cluster first. diff --git a/docs/pages/connect-your-client/tsh.mdx b/docs/pages/connect-your-client/tsh.mdx index 35930231bf776..3855562363756 100644 --- a/docs/pages/connect-your-client/tsh.mdx +++ b/docs/pages/connect-your-client/tsh.mdx @@ -529,9 +529,9 @@ $ tsh ssh -L 5000:google.com:80 --local node curl http://localhost:5000 This command: -1. Connects to `node`. -2. Binds the local port `5000` to port `80` on `google.com`. -3. Executes `curl` command locally, which results in `curl` hitting `google.com:80` via `node`. +- Connects to `node`. +- Binds the local port `5000` to port `80` on `google.com`. +- Executes `curl` command locally, which results in `curl` hitting `google.com:80` via `node`. ### SSH jump host @@ -561,9 +561,9 @@ Known limitations: `tsh` supports multiple methods to resolve remote Node names. -1. **Traditional**: by IP address or via DNS. -2. **Nodename setting**: the `teleport` daemon supports the` nodename` flag, which allows Teleport administrators to assign alternative Node names. -3. **Labels**: you can address a Node by `name=value` pair. +- **Traditional**: by IP address or via DNS. +- **Nodename setting**: the `teleport` daemon supports the` nodename` flag, which allows Teleport administrators to assign alternative Node names. +- **Labels**: you can address a Node by `name=value` pair. If we have two Node, one with `os:linux` label and one Node with `os:osx`, we can log in to the OSX Node with: diff --git a/docs/pages/contributing/documentation/style-guide.mdx b/docs/pages/contributing/documentation/style-guide.mdx index e7c1fdb5767fc..389046770adbe 100644 --- a/docs/pages/contributing/documentation/style-guide.mdx +++ b/docs/pages/contributing/documentation/style-guide.mdx @@ -91,9 +91,9 @@ architectural decisions, configuration, and usage scenarios. Specific kinds of architecture guides include: -1. **Networking**: Readers are interested in learning about specific ports, components, and protocols that are or can be used. -2. **Security**: Lists security protocols and primitives. SecOps will look for an attack vector tree diagram. -3. **Deployment**: Should include a deployment diagram which in turn explains components and how they interact with databases and each other. +- **Networking**: Readers are interested in learning about specific ports, components, and protocols that are or can be used. +- **Security**: Lists security protocols and primitives. SecOps will look for an attack vector tree diagram. +- **Deployment**: Should include a deployment diagram which in turn explains components and how they interact with databases and each other. ### Conceptual guides diff --git a/docs/pages/database-access/architecture.mdx b/docs/pages/database-access/architecture.mdx index 4f7682b38e6bb..a701cbffdf12d 100644 --- a/docs/pages/database-access/architecture.mdx +++ b/docs/pages/database-access/architecture.mdx @@ -56,18 +56,18 @@ connect to a database. 1. A user logs into the cluster with `tsh login` command and retrieves a client certificate. See [Issuing User Certificates](../architecture/authentication.mdx) for more details on how it works. -2. The user picks the database they want to connect to from the list of available +1. The user picks the database they want to connect to from the list of available databases shown in `tsh db ls` command. -3. The user connects to the database with the `tsh db connect` command, which +1. The user connects to the database with the `tsh db connect` command, which first retrieves a short-lived X.509 certificate and then launches the standard database client (e.g. `psql`) with this client certificate to authenticate with the Teleport Proxy service. -4. The Proxy authenticates the connection and dispatches it to the appropriate +1. The Proxy authenticates the connection and dispatches it to the appropriate Database Service based on the routing information encoded in the client certificate, over the reverse tunnel. -5. The Database Service authenticates the connection, performs an authorization +1. The Database Service authenticates the connection, performs an authorization check, and then establishes the connection to the database. -6. The Database Service begins proxying traffic between the user's database +1. The Database Service begins proxying traffic between the user's database client and the database. Additionally, it interprets the database wire protocol messages and submits events to the Teleport audit log. diff --git a/docs/pages/database-access/getting-started.mdx b/docs/pages/database-access/getting-started.mdx index 38d5caf3f1e2c..73e4e38fc1189 100644 --- a/docs/pages/database-access/getting-started.mdx +++ b/docs/pages/database-access/getting-started.mdx @@ -3,14 +3,14 @@ title: Database Access Getting Started Guide description: Getting started with Teleport database access and AWS Aurora PostgreSQL. --- -In this getting started guide we will use Teleport to connect to a PostgreSQL +This guide demonstrates how to use Teleport to connect to a PostgreSQL AWS Aurora database. -Here's an overview of what we will do: +In this guide, you will: 1. Configure an AWS Aurora database with IAM authentication. -2. Join the Aurora database to your Teleport cluster. -3. Connect to the Aurora database via the Teleport Database Service. +1. Join the Aurora database to your Teleport cluster. +1. Connect to the Aurora database via the Teleport Database Service. ![Teleport Database Access RDS Self-Hosted](../../img/database-access/guides/rds_selfhosted.png) diff --git a/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx b/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx index bed4b2d66abf9..24ed5fba24923 100644 --- a/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx +++ b/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx @@ -3,11 +3,11 @@ title: Database Access with Self-Hosted CockroachDB description: How to configure Teleport database access with self-hosted CockroachDB. --- -This guide will help you to: +In this guide, you will: -1. Install Teleport and connect it to a CockroachDB cluster. -2. Configure mutual TLS authentication between Teleport and your CockroachDB cluster. -3. Connect to your CockroachDB cluster via Teleport. +- Install Teleport and connect it to a CockroachDB cluster. +- Configure mutual TLS authentication between Teleport and your CockroachDB cluster. +- Connect to your CockroachDB cluster via Teleport. ![Teleport Database Access CockroachDB Self-Hosted](../../../img/database-access/guides/cockroachdb_selfhosted.png) diff --git a/docs/pages/database-access/guides/mongodb-atlas.mdx b/docs/pages/database-access/guides/mongodb-atlas.mdx index 0b89493180fed..d49ab08121a20 100644 --- a/docs/pages/database-access/guides/mongodb-atlas.mdx +++ b/docs/pages/database-access/guides/mongodb-atlas.mdx @@ -4,11 +4,11 @@ description: How to configure Teleport database access with MongoDB Atlas. videoBanner: mu_ZKTjnFJ8 --- -In this guide you will: +In this guide, you will: -1. Configure Teleport for accessing your MongoDB Atlas cluster. -2. Configure MongoDB Atlas authentication. -3. Connect to your Atlas cluster via Teleport. +- Configure Teleport for accessing your MongoDB Atlas cluster. +- Configure MongoDB Atlas authentication. +- Connect to your Atlas cluster through Teleport. ![Teleport Database Access MongoDB Self-Hosted](../../../img/database-access/guides/mongodbatlas_selfhosted.png) diff --git a/docs/pages/database-access/guides/mongodb-self-hosted.mdx b/docs/pages/database-access/guides/mongodb-self-hosted.mdx index bf0db20f8134a..5f5b591ac15c7 100644 --- a/docs/pages/database-access/guides/mongodb-self-hosted.mdx +++ b/docs/pages/database-access/guides/mongodb-self-hosted.mdx @@ -4,11 +4,11 @@ description: How to configure Teleport database access with self-hosted MongoDB. videoBanner: 6lgVObxoLkc --- -In this guide you will: +In this guide, you will: -1. Install and configure Teleport for database access. -2. Configure mutual TLS authentication between Teleport and your MongoDB cluster. -3. Connect to your MongoDB instance via Teleport. +- Install and configure Teleport for database access. +- Configure mutual TLS authentication between Teleport and your MongoDB cluster. +- Connect to your MongoDB instance through Teleport. ![Teleport Database Access MongoDB Self-Hosted](../../../img/database-access/guides/mongodb_selfhosted.png) diff --git a/docs/pages/database-access/guides/redshift-serverless.mdx b/docs/pages/database-access/guides/redshift-serverless.mdx index 7be008f9cde7b..1cb2065ac9fa6 100644 --- a/docs/pages/database-access/guides/redshift-serverless.mdx +++ b/docs/pages/database-access/guides/redshift-serverless.mdx @@ -340,7 +340,7 @@ prior to logging in as this new IAM role to avoid or resolve user permission iss CREATE USER "IAMR:teleport-redshift-serverless-access" WITH PASSWORD DISABLE; ``` -2. Grant this user appropriate in-database permissions. For example: +1. Grant this user appropriate in-database permissions. For example: ```sql GRANT SELECT ON TABLE users TO "IAMR:teleport-redshift-serverless-access"; diff --git a/docs/pages/database-access/guides/sql-server-ad-pkinit.mdx b/docs/pages/database-access/guides/sql-server-ad-pkinit.mdx index bc7dedc40eaae..b9e60dcb6a28a 100644 --- a/docs/pages/database-access/guides/sql-server-ad-pkinit.mdx +++ b/docs/pages/database-access/guides/sql-server-ad-pkinit.mdx @@ -3,7 +3,7 @@ title: Microsoft SQL Server access with PKINIT authentication description: How to configure Microsoft SQL Server access with Active Directory PKINIT authentication. --- -This guide will help you to: +In this guide, you will: - Install and configure Teleport. - Set up access to SQL Server using Active Directory PKINIT authentication. @@ -116,13 +116,13 @@ You will need to repeat these steps if you rotate Teleport's database certificat $ tctl auth export --type=db-der > db-ca.cer ``` -2. Get the Teleport database CRL by running: +1. Get the Teleport database CRL by running: ```code $ tctl auth crl --type=db > db-ca.crl ``` -3. Transfer the `db-ca.cer` and `db-ca.crl` files to a Windows machine where you can manage your group policy. +1. Transfer the `db-ca.cer` and `db-ca.crl` files to a Windows machine where you can manage your group policy. ### Create a GPO and import the Teleport CA @@ -140,20 +140,20 @@ You will need to repeat these steps if you rotate Teleport's database certificat New-GPO -Name $GPOName | New-GPLink -Target $((Get-ADDomain).DistinguishedName) ``` -2. Open the `Group Policy Management` program, and on the left pane, +1. Open the `Group Policy Management` program, and on the left pane, navigate to `$FOREST > Domains > $DOMAIN > Group Policy Objects`. -3. Right click on the GPO you just made (`Teleport DB Access`), and select `Edit...`. +1. Right click on the GPO you just made (`Teleport DB Access`), and select `Edit...`. -4. In the group policy editor, select: +1. In the group policy editor, select: ```text Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies ``` -5. Right click on `Trusted Root Certification Authorities` and select `Import`. +1. Right click on `Trusted Root Certification Authorities` and select `Import`. -6. Click through the wizard, selecting your CA file (`db-ca.cer`). +1. Click through the wizard, selecting your CA file (`db-ca.cer`).
![Import Teleport CA](../../../img/desktop-access/ca.png) @@ -169,7 +169,7 @@ Teleport performs certificate-based authentication by emulating a smart card. Computer Configuration > Policies > Windows Settings > Security Settings > System Services ``` -2. Double click on `Smart Card`, select `Define this policy setting` and switch +1. Double click on `Smart Card`, select `Define this policy setting` and switch to `Automatic` then click `OK`.
@@ -298,6 +298,7 @@ db_service: ## Step 5/7. Start the Database Service + Start the Database Service: ```code diff --git a/docs/pages/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment.mdx b/docs/pages/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment.mdx index d5aaf7d1acafd..ebad45240109f 100644 --- a/docs/pages/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment.mdx +++ b/docs/pages/deploy-a-cluster/deployments/aws-gslb-proxy-peering-ha-deployment.mdx @@ -5,10 +5,10 @@ description: "Deploying a high-availability Teleport cluster using Proxy Peering This deployment architecture features two important design decisions: -1. AWS Route 53 latency-based routing is used for global server load balancing +- AWS Route 53 latency-based routing is used for global server load balancing ([GSLB](https://www.cloudflare.com/learning/cdn/glossary/global-server-load-balancing-gslb/)). This allows for efficient distribution of traffic across resources that are globally distributed. -2. Teleport's [Proxy Peering](../../architecture/proxy-peering.mdx) is used to reduce the total number of tunnel connections in the Teleport cluster. +- Teleport's [Proxy Peering](../../architecture/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 diff --git a/docs/pages/deploy-a-cluster/deployments/ibm.mdx b/docs/pages/deploy-a-cluster/deployments/ibm.mdx index 3c894a8b2b005..95a7fea22fb98 100644 --- a/docs/pages/deploy-a-cluster/deployments/ibm.mdx +++ b/docs/pages/deploy-a-cluster/deployments/ibm.mdx @@ -107,10 +107,10 @@ teleport: We recommend using [IBM Cloud Object Storage](https://www.ibm.com/cloud/object-storage) to store Teleport recorded sessions. -1. Create New Object Storage Resource. [IBM Catalog - Object Storage Quick Link](https://cloud.ibm.com/catalog/infrastructure/object-storage) -2. Create a new bucket. -3. Set up [HMAC Credentials](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-uhc-hmac-credentials-main) -4. Update audit sessions URI: `audit_sessions_uri: 's3://BUCKET-NAME/readonly/records?endpoint=s3.us-east.cloud-object-storage.appdomain.cloud®ion=ibm'` +- Create New Object Storage Resource. [IBM Catalog - Object Storage Quick Link](https://cloud.ibm.com/catalog/infrastructure/object-storage) +- Create a new bucket. +- Set up [HMAC Credentials](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-uhc-hmac-credentials-main) +- Update audit sessions URI: `audit_sessions_uri: 's3://BUCKET-NAME/readonly/records?endpoint=s3.us-east.cloud-object-storage.appdomain.cloud®ion=ibm'` When setting up `audit_sessions_uri` use `s3://` session prefix. diff --git a/docs/pages/desktop-access/active-directory-manual.mdx b/docs/pages/desktop-access/active-directory-manual.mdx index a1b8ffcdd648e..4d93bde5ffff4 100644 --- a/docs/pages/desktop-access/active-directory-manual.mdx +++ b/docs/pages/desktop-access/active-directory-manual.mdx @@ -1,16 +1,16 @@ --- title: Desktop Access with Active Directory (Manual) -description: Manually Connect Teleport to an Active Directory domain +description: Manually connect Teleport to an Active Directory domain. videoBanner: YvMqgcq0MTQ --- -In this guide we will connect an Active Directory domain to Teleport using the +This guide demonstrates how to connect an Active Directory domain to Teleport using the Desktop Service and log into a Windows desktop from that domain. Starting with Teleport 10.2.6, you can install Active Directory and configure -the Teleport Desktop Service through the web UI. See [Desktop Access with Active +the Teleport Desktop Service through the Teleport Web UI. See [Desktop Access with Active Directory](active-directory.mdx) for more information. Teleport Enterprise users can configure Windows Access for local users by @@ -35,14 +35,13 @@ This guide requires you to have: Microsoft's Azure Active Directory (Azure AD) offering does not support the -Kerberos authentication protocol, which is required for Teleport's -certificate-based authentication. +Kerberos authentication protocol, which is required for the certificate-based +authentication described in this section. At this time, Teleport does not support integration with Azure AD, however Teleport Enterprise customers can access Windows desktops (including those joined to Azure AD) using local accounts via the process described in [Getting Started with Desktop Access](./getting-started.mdx). - - Access to a Domain Controller @@ -149,7 +148,7 @@ your entire domain, and then deny it interactive login. $GPOName="Block teleport-svc Interactive Login" ``` -2. Create the new GPO by running (from the same prompt): +1. Create the new GPO by running (from the same prompt): ```powershell New-GPO -Name $GPOName | New-GPLink -Target $((Get-ADDomain).DistinguishedName) @@ -161,17 +160,20 @@ New-GPO -Name $GPOName | New-GPLink -Target $((Get-ADDomain).DistinguishedName) created (`$FOREST > Domains > $DOMAIN > Group Policy Objects > Block teleport-svc Interactive Login`), right-click on it and select `Edit...` from the context menu. -2. Select: -```text -Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment -``` +1. Select: -3. Double click `Deny log on locally` and in the popup, check `Define these policy settings`. -4. Then click `Add User or Group...`, `Browse ...`, enter the SAM account name + ```text + Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment + ``` + +1. Double click `Deny log on locally` and in the popup, check `Define these policy settings`. + +1. Then click `Add User or Group...`, `Browse ...`, enter the SAM account name of the user you created above (`svc-teleport`) and hit `Check Names` select your Group, and then hit `OK` on all the windows. -5. Repeat steps 3 and 4 for `Deny log on through Remote Desktop Services` (in + +1. Repeat steps 3 and 4 for `Deny log on through Remote Desktop Services` (in lieu of `Deny log on locally`).
@@ -239,20 +241,20 @@ and `Users` which is nested one level beneath the domain root. New-GPO -Name $GPOName | New-GPLink -Target $((Get-ADDomain).DistinguishedName) ``` -2. Again open the `Group Policy Management` program, and on the left pane, +1. Open the `Group Policy Management` program, and on the left pane, navigate to `$FOREST > Domains > $DOMAIN > Group Policy Objects`. -3. Right click on the GPO you just made (`Teleport Access Policy`), and select `Edit...`. +1. Right click on the GPO you just made (`Teleport Access Policy`), and select `Edit...`. -4. In the group policy editor, select: +1. In the group policy editor, select: ```text Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies ``` -5. Right click on `Trusted Root Certification Authorities` and select `Import`. +1. Right click on `Trusted Root Certification Authorities` and select `Import`. -6. Click through the wizard, selecting your CA file. +1. Click through the wizard, selecting your CA file.
![Import Teleport CA](../../img/desktop-access/ca.png) @@ -292,7 +294,7 @@ access. certutil –dspublish –f NTAuthCA ``` -2. Force the retrieval of the CA from LDAP. While this step is not required, it +1. Force the retrieval of the CA from LDAP. While this step is not required, it speeds up the process and allows you to proceed to the next steps without waiting for the certificate to propagate. @@ -310,7 +312,7 @@ Teleport performs certificate based authentication by emulating a smart card. Computer Configuration > Policies > Windows Settings > Security Settings > System Services ``` -2. Double click on `Smart Card`, select `Define this policy setting` and switch +1. Double click on `Smart Card`, select `Define this policy setting` and switch to `Automatic` then click `OK`.
@@ -325,21 +327,21 @@ Teleport performs certificate based authentication by emulating a smart card. Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections ``` -2. Right click on `Allow users to connect remotely by using Remote Desktop Services` and select `Edit`. Select `Enabled` and `OK`. +1. Right click on `Allow users to connect remotely by using Remote Desktop Services` and select `Edit`. Select `Enabled` and `OK`. -3. Select: +1. Select: ```text Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security ``` -4. Right click `Require user authentication for remote connections by using Network Level Authentication`, edit, select `Disable` and `OK`. +1. Right click `Require user authentication for remote connections by using Network Level Authentication`, edit, select `Disable` and `OK`.
![Disable Require](../../img/desktop-access/disable.png)
-5. Right click `Always prompt for password upon connection`, edit, select **`Disabled`** and . +1. Right click `Always prompt for password upon connection`, edit, select **`Disabled`** and . Teleport's smart card based authentication generates a random smart card PIN for each desktop session and provides the PIN to the desktop during the RDP connection establishment. Since the PIN is never provided to the Teleport user, this setting must be disabled in @@ -363,13 +365,13 @@ Set to `Disabled` and click `OK`. Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security (x2) ``` -2. Right click on `Inbound Rules` and select `New Rule...`. +1. Right click on `Inbound Rules` and select `New Rule...`. -3. Under `Predefined` select `Remote Desktop`. +1. Under `Predefined` select `Remote Desktop`. -4. Only select the rule for `User Mode (TCP-in)`. +1. Only select the rule for `User Mode (TCP-in)`. -5. On the next screen, select `Allow the connection` and finish. +1. On the next screen, select `Allow the connection` and finish.
![Open the Firewall](../../img/desktop-access/firewall.png) @@ -409,45 +411,35 @@ P-384 and uses SHA384 as the signature algorithm. Start > Control Panel > Administrative Tools > Certificate Authority ``` -2. Open your CA computer and right-click on `Certificate Templates`, then select - `Manage`. +1. Open your CA computer and right-click on `Certificate Templates`, then select `Manage`. -3. Find the `Computer` template on the list, right-click on it, then select - `Duplicate Template`. +1. Find the `Computer` template on the list, right-click on it, then select `Duplicate Template`. -4. In the `Compatibility` tab change `Certification Authority` to - `Windows Server 2012 R2` and click `OK`. +1. In the `Compatibility` tab change `Certification Authority` to `Windows Server 2012 R2` and click `OK`. -5. In the same tab change `Certificate recipient` to `Windows Server 2012 R2` - and click `OK`. +1. In the same tab change `Certificate recipient` to `Windows Server 2012 R2` and click `OK`. -6. Go to the `General` tab and change `Template display name` to - `RemoteDesktopAccess`. Make sure `Template name` is also - `RemoteDesktopAccess`. +1. Go to the `General` tab and change `Template display name` to `RemoteDesktopAccess`. + Make sure `Template name` is also `RemoteDesktopAccess`. -7. In the `Cryptography` tab change `Provider Category` to - `Key Storage Provider`, then `Algorithm name` to `ECDH_P384`. Also, change - `Request hash` to `SHA384`. +1. In the `Cryptography` tab change `Provider Category` to `Key Storage Provider`, + then `Algorithm name` to `ECDH_P384`. Also, change `Request hash` to `SHA384`. -8. Next, in the `Extensions` tab select `Application Polices` and click the - `Edit` button. +1. In the `Extensions` tab select `Application Polices` and click the `Edit` button. -9. Remove all entries from the list. +1. Remove all entries from the list. -10. Go to the `Security` tab, select `Domain Computers` and give the group - `Read` and `Enroll` permissions. Repeat this process for the - `Domain Controllers` group as well. +1. Go to the `Security` tab, select `Domain Computers` and give the group `Read` and `Enroll` permissions. -11. Finally, create a template by clicking `OK`. +1. Finally, create a template by clicking `OK`. -12. Go back to the Certificate Authority window and right-click on - `Certificate Templates`. Then: +1. Go back to the Certificate Authority window and right-click on `Certificate Templates`. Then: ```text New > Certificate Template to Issue ``` -Select `RemoteDesktopAccess` and click `OK`. +1. Select `RemoteDesktopAccess` and click `OK`. ### Update GPO to use a new certificate template @@ -504,12 +496,12 @@ skipping TLS verification in production environments. 1. Begin by navigating to `Start > Control Panel > Administrative Tools > CertificateAuthority` to open the CA Microsoft Management Console (MMC) GUI. -2. Right click on your CA computer and select `Properties`. -3. From `General` tab, click `View Certificate`. -4. Select the `Details` view and click `Copy to File`. -5. Click `Next` in the Certificate Export Wizard, and ensure that - `DER encoded binary X.509 (.CER)` is selected -6. Select a name and location for you certificate and click through the wizard. +1. Right click on your CA computer and select `Properties`. +1. From `General` tab, click `View Certificate`. +1. Select the `Details` view and click `Copy to File`. +1. Click `Next` in the Certificate Export Wizard, and ensure that `DER encoded binary X.509 (.CER)` + is selected +1. Select a name and location for you certificate and click through the wizard. Now transfer the exported file to the system where you're running Teleport. You can either add this certificate to your system's trusted repository or provide diff --git a/docs/pages/desktop-access/rbac.mdx b/docs/pages/desktop-access/rbac.mdx index a6bcd22b28ef4..571c66430eba5 100644 --- a/docs/pages/desktop-access/rbac.mdx +++ b/docs/pages/desktop-access/rbac.mdx @@ -61,9 +61,9 @@ use wildcards (`"*"`) to match all desktop labels. Windows desktops acquire labels in two ways: -1. Using the `host_labels` rules defined in the `windows_desktop_service` section +- Using the `host_labels` rules defined in the `windows_desktop_service` section of your Teleport configuration file. -2. Using LDAP (for desktops discovered via LDAP only) +- Using LDAP (for desktops discovered via LDAP only) ### Using `host_labels` diff --git a/docs/pages/machine-id/getting-started.mdx b/docs/pages/machine-id/getting-started.mdx index 471c4a3df2720..ac91477a1931e 100644 --- a/docs/pages/machine-id/getting-started.mdx +++ b/docs/pages/machine-id/getting-started.mdx @@ -8,11 +8,10 @@ certificates that enable a bot user to connect to a remote host. Here's an overview of what you will do: -1. Download and install `tbot` on the host that will run - Machine ID. -2. Create a bot user. -3. Start Machine ID. -4. Use certificates issued by Machine ID to connect to a remote machine. +- Download and install `tbot` on the host that will run Machine ID. +- Create a bot user. +- Start Machine ID. +- Use certificates issued by Machine ID to connect to a remote machine. ## Prerequisites diff --git a/docs/pages/machine-id/guides/databases.mdx b/docs/pages/machine-id/guides/databases.mdx index 52523f87fe915..38a8b406dde40 100644 --- a/docs/pages/machine-id/guides/databases.mdx +++ b/docs/pages/machine-id/guides/databases.mdx @@ -56,11 +56,12 @@ spec: ``` This role allows Machine ID bots to do two things: - 1. Access the database `example` on any database server (due to the `'*': '*'` + + - Access the database `example` on any database server (due to the `'*': '*'` label selector) as the user `alice`. You may restrict access to the bot using a more specific label selector; see the [Database Access RBAC guide](../../database-access/rbac.mdx) for more info. - 2. Discover information about databases in Teleport. + - Discover information about databases in Teleport. Write this to `role.yaml` and run the following to create the role in Teleport: diff --git a/docs/pages/machine-id/troubleshooting.mdx b/docs/pages/machine-id/troubleshooting.mdx index 16ce2adcfedde..3772d8ebdc02d 100644 --- a/docs/pages/machine-id/troubleshooting.mdx +++ b/docs/pages/machine-id/troubleshooting.mdx @@ -68,7 +68,7 @@ directories (usually `/opt/machine-id`) rather than the internal data directory Once you have addressed the underlying cause, follow these steps to reset a locked bot: 1. Remove the lock on the bot's user - 2. Reset the bot's generation counter by deleting and re-creating the bot + 1. Reset the bot's generation counter by deleting and re-creating the bot To remove the lock, first find and remove the lock targeting the bot user: @@ -185,9 +185,9 @@ However, the SSH command attempted to log in as `bob`. Ensure the bot identity is allowed to log in as the requested user by taking any of the following actions: - 1. Changing the SSH command to log in as an allowed user - 2. Modifying the `access` role to allow the `alice` principal - 3. Adding a role granting login via the `bob` principal + - Changing the SSH command to log in as an allowed user + - Modifying the `access` role to allow the `alice` principal + - Adding a role granting login via the `bob` principal Note that if roles are added or modified, the certificates will need to be renewed for the changes to take effect. The bot will renew certificates on its diff --git a/docs/pages/management/guides/ec2-tags.mdx b/docs/pages/management/guides/ec2-tags.mdx index 3a5da6a11e467..21cf098962536 100644 --- a/docs/pages/management/guides/ec2-tags.mdx +++ b/docs/pages/management/guides/ec2-tags.mdx @@ -45,17 +45,19 @@ for more details. ### AWS EC2 Console To launch a new instance with instance metadata tags enabled: + 1. Open `Advanced Options` at the bottom of the page. -2. Ensure that `Metadata accessible` is not disabled. -3. Enable `Allow tags in metadata`. +1. Ensure that `Metadata accessible` is not disabled. +1. Enable `Allow tags in metadata`.
![Advanced Options](../../../img/aws/launch-instance-advanced-options.png)
To modify an existing instance to enable instance metadata tags: + 1. From the instance summary, go to `Actions > Instance Settings > Allow tags in instance metadata`. -2. Enable `Allow`. +1. Enable `Allow`.
![Instance Settings](../../../img/aws/instance-settings.png) diff --git a/docs/pages/management/operations/tls-routing.mdx b/docs/pages/management/operations/tls-routing.mdx index 33b5a83909dec..64d1d33807ebc 100644 --- a/docs/pages/management/operations/tls-routing.mdx +++ b/docs/pages/management/operations/tls-routing.mdx @@ -145,11 +145,11 @@ To go back to the legacy separate listeners mode, perform the following steps: 1. Set `version: v1` in the proxy configuration and restart the proxy to make it create legacy listeners. -2. Set `proxy_listener_mode: separate` in auth service configuration to make +1. Set `proxy_listener_mode: separate` in auth service configuration to make clients connect to the legacy listeners. -3. Reconnect all clients (trusted clusters, reverse tunnel agents, `tsh`) as +1. Reconnect all clients (trusted clusters, reverse tunnel agents, `tsh`) as described above. -4. If using OpenSSH client, regenerate SSH config using `tsh config` command. +1. If using OpenSSH client, regenerate SSH config using `tsh config` command. ## Next steps diff --git a/docs/pages/server-access/getting-started.mdx b/docs/pages/server-access/getting-started.mdx index 816a91f8c6d2d..ec468af66a67d 100644 --- a/docs/pages/server-access/getting-started.mdx +++ b/docs/pages/server-access/getting-started.mdx @@ -44,7 +44,7 @@ pattern** so that only a single Node can be accessed publicly. We'll configure and launch our instance, then demonstrate how to use the `tsh` tool and Teleport in SSH mode. -2. On the host where you will run the Teleport SSH Service, follow the instructions +1. On the host where you will run the Teleport SSH Service, follow the instructions for your environment to install Teleport. (!docs/pages/includes/install-linux.mdx!) @@ -375,8 +375,8 @@ pattern: To recap, this guide described: -1. How to set up and add an SSH server to a cluster. -2. Connect to the cluster using `tsh` to manage and introspect resources. +- How to set up and add an SSH server to a cluster. +- Connect to the cluster using `tsh` to manage and introspect resources. Feel free to shut down, clean up, and delete your resources, or use them in further Getting Started exercises.