diff --git a/docs/pages/admin-guides/access-controls/access-monitoring.mdx b/docs/pages/admin-guides/access-controls/access-monitoring.mdx index 25797cf3e89d3..5e05dd3936c8d 100644 --- a/docs/pages/admin-guides/access-controls/access-monitoring.mdx +++ b/docs/pages/admin-guides/access-controls/access-monitoring.mdx @@ -15,7 +15,7 @@ or database sessions without MFA) and provides users with recommendations on sug Users are able to write their own custom access monitoring queries by querying the audit log. - + Access Monitoring is not currently supported with External Audit Storage in Teleport Enterprise (Cloud). This functionality will be enabled in a future Teleport release. diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx index 419937a61cc83..94a79d370779e 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx @@ -199,7 +199,7 @@ approve or deny the request: ![Review access request](../../../../img/enterprise/plugins/datadog/review-access-request.png) - + When the Datadog plugin sends a notification, anyone who receives the notification can follow the enclosed link to an Access Request URL. While users diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx index 01e97b95c59f1..b770b15e7fd98 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx @@ -131,7 +131,7 @@ or in the schedules specified by `teleport.dev/notify-services` annotation in th (!docs/pages/includes/plugins/resolve-request.mdx!) - + When the Opsgenie plugin sends a notification, anyone who receives the notification can follow the enclosed link to an Access Request URL. While users diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx index 800a8a587c2e7..732d9f939f49b 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx @@ -153,13 +153,13 @@ the URL scheme and port. (If you're using a local SMTP server for testing, use If you are running the email plugin on a Linux host, fill in `username` and `password`. - + You can also save your password to a separate file and assign `password_file` to the file's path. The plugin reads the file and uses the file's content as the password. - + If you are deploying the email plugin on Kubernetes: diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx index eb913d51cf278..fd24bba828a4a 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx @@ -127,13 +127,13 @@ following: ![Jira board setup](../../../../img/enterprise/plugins/jira/board-setup.png) - + If your project board does not contain these (and only these) columns, each with a status of the same name, the Jira Access Request plugin will behave in unexpected ways. Remove all other columns and statuses. - + Click **Back to board** to review your changes. @@ -409,12 +409,12 @@ Request Reviewed` in the Teleport Web UI. ## Step 7/7. Set up systemd - + This step is only applicable if you are running the Teleport Jira plugin on a Linux machine. - + In production, we recommend starting the Teleport plugin daemon via an init system like systemd. Here's the recommended Teleport plugin service unit file diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx index afd669fffcb95..698655c30b548 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx @@ -320,7 +320,7 @@ the Teleport Web UI and either approve or deny the request. (!docs/pages/includes/plugins/resolve-request.mdx!) - + When the Mattermost plugin posts an Access Request notification to a channel, anyone with access to the channel can view the notification and follow the link. diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx index 46f4a7c8fd599..33380d6afcc9c 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx @@ -364,7 +364,7 @@ Once the request is resolved, the Slack bot will add an emoji reaction of ✅ or ❌ to the Slack message for the Access Request, depending on whether the request was approved or denied. - + When the Slack plugin posts an Access Request notification to a channel, anyone with access to the channel can view the notification and follow the link. While diff --git a/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx b/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx index 6ea7c20194ee9..83b1005e97f72 100644 --- a/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx +++ b/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx @@ -38,13 +38,13 @@ For the rest of the guide we will assume that the `requester` role has been granted to a user named `alice` and the `reviewer` role has been granted to a user named `bob`. - + Consider defining custom roles to limit the scope of a requester or reviewer's permissions. Read the [Access Request Configuration](./access-request-configuration.mdx) guide for available options. - + ## Step 2/6. Search for resources @@ -193,11 +193,11 @@ $ tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab Successfully submitted review. Request state: APPROVED ``` - + Check out our [Access Request Integrations](#integrating-with-an-external-tool) to notify the right people about new Access Requests. - + ## Step 5/6. Access the requested resource diff --git a/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx b/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx index 0fcc79c6750e8..cfee9e9165052 100644 --- a/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx +++ b/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx @@ -7,12 +7,12 @@ h1: SOC 2 Compliance for SSH, Kubernetes, Databases, Desktops, and Web Apps Teleport is designed to meet SOC 2 requirements for the purposes of accessing infrastructure, change management, and system operations. This document outlines a high level overview of how Teleport can be used to help your company to become SOC 2 compliant. - + SOC 2 compliance features are only available for Teleport Enterprise and Teleport Enterprise Cloud. - + ## Achieving SOC 2 Compliance with Teleport SOC 2 or Service Organization Controls were developed by the American Institute of CPAs (AICPA). They are based on five trust services criteria: security, availability, processing integrity, confidentiality, and privacy. diff --git a/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx b/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx index 2e08a45c97b6c..02504e8e21659 100644 --- a/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx +++ b/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx @@ -4,7 +4,7 @@ description: Learn how to enforce trusted devices with Teleport videoBanner: gBQyj_X1LVw --- - + Device trust fully supports SSH, Database and Kubernetes resources using cluster-wide or role-based enforcement. diff --git a/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx b/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx index 2fbada2f0815e..0d3286909bf6c 100644 --- a/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx +++ b/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx @@ -31,7 +31,7 @@ and behavior. ## Step 1/4. Create Jamf API credentials - + Teleport versions v16.0.0 or lower don't support Jamf API credentials. Follow the instructions under [Using Jamf user and password authentication]( #optional-using-jamf-user-and-password-authentication) instead. @@ -330,7 +330,7 @@ ssh_service: ## Optional: Using Jamf user and password authentication - + Teleport versions v16.1.0 and higher support [Jamf API credentials]( #step-14-create-jamf-api-credentials). Prefer using API credentials instead of username and password authentication. diff --git a/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx b/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx index 579c6f62bad81..c7917908ace6c 100644 --- a/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx +++ b/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx @@ -16,11 +16,11 @@ the approval of two team members for a privileged role `dbadmin`. The steps below describe how to use Teleport with Mattermost. You can also [integrate with many other providers](../access-requests/access-requests.mdx). - + Dual Authorization requires Teleport Enterprise. - + ## Prerequisites diff --git a/docs/pages/admin-guides/access-controls/guides/headless.mdx b/docs/pages/admin-guides/access-controls/guides/headless.mdx index f66c9a7f56913..e90de04213c56 100644 --- a/docs/pages/admin-guides/access-controls/guides/headless.mdx +++ b/docs/pages/admin-guides/access-controls/guides/headless.mdx @@ -155,7 +155,7 @@ $ tsh ssh --headless --proxy=proxy.example.com --user=alice alice@server01 alice@server01 $ ``` - + The Teleport user, `--user` parameter, is the Teleport user requesting Headless WebAuthn activity. If no `--user` parameter or environment variables set the OS user in the machine terminal is used. @@ -165,7 +165,7 @@ alice@server01 $ an access denied message. The user could receive an access denied message after being approved for their Headless WebAuthn activity since the same access rights are granted or denied as if running from your local terminal. - + ## Optional: Teleport Connect diff --git a/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx b/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx index 809a3b193ba8d..dd9b6e30338d8 100644 --- a/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx +++ b/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx @@ -21,7 +21,7 @@ Examples of administrative actions include, but are not limited to: This is an advanced security feature that protects users against compromises of their on-disk Teleport certificates. - + When MFA for administrative actions is enabled, user certificates produced with `tctl auth sign` will no longer be suitable for automation due to the additional MFA checks. @@ -33,7 +33,7 @@ their on-disk Teleport certificates. Certificates produced with `tctl auth sign` directly on an Auth Service instance using the super-admin role are not subject to MFA checks to support legacy self-hosted setups. - + ## Prerequisites @@ -51,10 +51,10 @@ their on-disk Teleport certificates. MFA for administrative actions is automatically enforced for clusters where WebAuthn is the only form of second factor allowed. - + In a future major version, Teleport may enforce MFA for administrative actions for a wider range of cluster configurations. - + Edit the `cluster_auth_preference` resource: diff --git a/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx b/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx index c2fa8ed63f9ef..dbdfe5e2cd3bb 100644 --- a/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx +++ b/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx @@ -16,12 +16,12 @@ when starting new: This is an advanced security feature that protects users against compromises of their on-disk Teleport certificates. - + In addition to per-session MFA, enable login MFA in your SSO provider and/or for all [local Teleport users](../../../reference/access-controls/authentication.mdx) to improve security. - + ## Prerequisites diff --git a/docs/pages/admin-guides/access-controls/guides/webauthn.mdx b/docs/pages/admin-guides/access-controls/guides/webauthn.mdx index 4f2bf559475d8..de485598e870b 100644 --- a/docs/pages/admin-guides/access-controls/guides/webauthn.mdx +++ b/docs/pages/admin-guides/access-controls/guides/webauthn.mdx @@ -172,12 +172,12 @@ when starting new: - Application sessions - Desktop sessions - + In addition to per-session MFA, enable login MFA in your SSO provider and/or for all [local Teleport users](../../../reference/access-controls/authentication.mdx) to improve security. - + To enforce MFA checks for all roles, edit your cluster authentication configuration: @@ -417,7 +417,7 @@ layer by re-verifying user identity immediately before any admin action, mitigat By adopting these advanced security measures, you can create a robust defense against IdP compromises and significantly reduce your organization's attack surface. In the following sections, we'll dive deeper into each of these recommendations, providing step-by-step guidance on implementation and best practices. - + When MFA for administrative actions is enabled, user certificates produced with `tctl auth sign` will no longer be suitable for automation due to the additional MFA checks. @@ -427,7 +427,7 @@ In the following sections, we'll dive deeper into each of these recommendations, Certificates produced with `tctl auth sign` directly on an Auth Service instance using the super-admin role are not subject to MFA checks to support legacy self-hosted setups. - + ### Prerequisites @@ -439,10 +439,10 @@ In the following sections, we'll dive deeper into each of these recommendations, MFA for administrative actions is automatically enforced for clusters where WebAuthn is the only form of multi-factor allowed. - + In a future major version, Teleport may enforce MFA for administrative actions for a wider range of cluster configurations. - + Examples of administrative actions include, but are not limited to: diff --git a/docs/pages/admin-guides/access-controls/sso/github-sso.mdx b/docs/pages/admin-guides/access-controls/sso/github-sso.mdx index 9e34f0bbb94c5..19938dc086248 100644 --- a/docs/pages/admin-guides/access-controls/sso/github-sso.mdx +++ b/docs/pages/admin-guides/access-controls/sso/github-sso.mdx @@ -26,7 +26,7 @@ reading data from the OAuth 2.0 access token. In particular, the Auth Service: permissions. - Assigns the user's Teleport username to their GitHub username. - + GitHub usernames are not formatted as email addresses. As a result, any Teleport plugin that expects to send email to a user based on their Teleport username @@ -34,7 +34,7 @@ will not work as expected. For example, the [PagerDuty Access Request plugin](../access-request-plugins/ssh-approval-pagerduty.mdx) has this limitation. - + ## Prerequisites diff --git a/docs/pages/admin-guides/api/access-plugin.mdx b/docs/pages/admin-guides/api/access-plugin.mdx index 80943073a7bb8..75046165b3668 100644 --- a/docs/pages/admin-guides/api/access-plugin.mdx +++ b/docs/pages/admin-guides/api/access-plugin.mdx @@ -20,12 +20,12 @@ spreadsheet, with links to allow or deny each request. ![The result of the plugin](../../../img/api/google-sheets.png) - + The plugin we will build in this guide is intended as a learning tool. **Do not connect it to your production Teleport cluster.** Use a demo cluster instead. - + ## Prerequisites @@ -428,14 +428,14 @@ In your spreadsheet, click "View Access Request" next to your new request. Sign into the Teleport Web UI as your original user. When you submit your review, e.g., deny the request, the new status will appear within the spreadsheet. - + Access Request plugins must not enable reviewing Access Requests via the plugin, and must always refer a reviewer to the Teleport Web UI to complete the review. Otherwise, an unauthorized party could spoof traffic to the plugin and escalate privileges. - + ## Next steps diff --git a/docs/pages/admin-guides/api/automatically-register-agents.mdx b/docs/pages/admin-guides/api/automatically-register-agents.mdx index 5cad251d7a1d6..f7ab66d507ec4 100644 --- a/docs/pages/admin-guides/api/automatically-register-agents.mdx +++ b/docs/pages/admin-guides/api/automatically-register-agents.mdx @@ -29,12 +29,12 @@ Automatic registration consists of the following steps: infrastructure, use the Teleport API to deregister the resource and, if necessary, remove the Teleport service proxying the resource. - + The program we build in this guide is intended as a learning tool. **Do not connect it to your production Teleport cluster.** Use a demo cluster instead. - + ## Prerequisites @@ -704,13 +704,13 @@ To deregister the Application Service instance manually, we call the `pruneAppServiceInstance` function to get the namespace, host ID, and name of the Application Service instance to delete. - + While Teleport namespaces are deprecated, they still appear occasionally in the Teleport API client library. The only namespace that Teleport supports is called `default`. - + Next, this function stops and removes the Application Service container associated with the `types.AppServer` we want to prune. The hostname of an diff --git a/docs/pages/admin-guides/api/rbac.mdx b/docs/pages/admin-guides/api/rbac.mdx index 83b9ae16edc0b..b0e30ea292ec0 100644 --- a/docs/pages/admin-guides/api/rbac.mdx +++ b/docs/pages/admin-guides/api/rbac.mdx @@ -20,12 +20,12 @@ This is especially useful for: In this guide, we will build a small demo application to show you how to generate Teleport roles using Teleport's API client library. - + The program we will build in this guide is intended as a learning tool. **Do not connect it to your production Teleport cluster.** Use a demo cluster instead. - + ## Prerequisites diff --git a/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx b/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx index 6f44b0dad7525..9cce5ad8baebb 100644 --- a/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx +++ b/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx @@ -29,11 +29,11 @@ This guide will help you set up the service and enable Access Graph in your Tele ``` - The node running the Access Graph service must be reachable from Teleport Auth Service and Proxy Service. - + The deployment with Docker is suitable for testing and development purposes. For production deployments, consider using the Access Graph Helm chart to deploy this service on Kubernetes. Refer to [Helm chart for Access Graph](self-hosted-helm.mdx) for instructions. - + ## Step 1/3. Set up Access Graph diff --git a/docs/pages/admin-guides/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx b/docs/pages/admin-guides/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx index 431d441c9973e..c14226b1a59b8 100644 --- a/docs/pages/admin-guides/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx +++ b/docs/pages/admin-guides/deploy-a-cluster/helm-deployments/kubernetes-cluster.mdx @@ -55,13 +55,13 @@ cluster to Teleport. cluster in order to follow this guide, the following example configuration sets up the EBS CSI driver add-on. - + The example configuration below assumes that you are familiar with how `eksctl` works, are not using your EKS cluster in production, and understand that you are proceeding at your own risk. - + Update the cluster name, version, node group size, and region as required: @@ -96,7 +96,7 @@ cluster to Teleport. (!docs/pages/includes/kubernetes-access/helm-k8s.mdx!) - + It is worth noting that this guide shows you how to set up Kubernetes access with the broadest set of permissions. This is suitable for a personal demo @@ -104,7 +104,7 @@ cluster, but if you would like to set up Kubernetes RBAC for production usage, we recommend getting familiar with the [Teleport Kubernetes RBAC guide](../../../enroll-resources/kubernetes-access/controls.mdx) before you begin. - + ## Step 1/2. Install Teleport diff --git a/docs/pages/admin-guides/deploy-a-cluster/high-availability.mdx b/docs/pages/admin-guides/deploy-a-cluster/high-availability.mdx index 49a16ac166666..2b93e0280ad51 100644 --- a/docs/pages/admin-guides/deploy-a-cluster/high-availability.mdx +++ b/docs/pages/admin-guides/deploy-a-cluster/high-availability.mdx @@ -163,7 +163,7 @@ When you configure the Teleport Auth Service to access a table or collection, the Auth Service checks that the table or collection exists on startup. If it does not, the Auth Service attempts to create it. - + Make sure you configure your cloud provider's RBAC solution (e.g., AWS or Google Cloud IAM) so that your Auth Service instances have permissions to read from and @@ -192,7 +192,7 @@ S3-compatible service to use for managing session recordings. The Auth Service will check that the bucket exists on startup. If it does not, the Auth Service attempts to create it. - + In your cloud provider's RBAC solution, your Auth Service instances need permissions to get buckets as well as to create, get, list, and update objects. @@ -273,7 +273,7 @@ application with Teleport: |A|*.teleport.example.com|The IP address of your load balancer| |CNAME|*.teleport.example.com|The domain name of your load balancer| - + If you are using Let's Encrypt to provide TLS credentials to your Teleport instances, the TLS credential system we mentioned earlier needs permissions to @@ -292,13 +292,13 @@ compute resources, for example, using Kubernetes Deployments or AWS Auto Scaling groups. This requires running the `teleport` binary on each Kubernetes pod or virtual machine in your group. - + If you plan to run Teleport on Kubernetes, the `teleport-cluster` Helm chart deploys the Auth Service and Proxy Service pools for you. To see how to use this Helm chart, read our [Helm Deployments](helm-deployments/helm-deployments.mdx) documentation. - + You should deploy your Teleport instances across multiple zones (if using a cloud provider) or data centers (if using an on-premise solution) to ensure diff --git a/docs/pages/admin-guides/infrastructure-as-code/infrastructure-as-code.mdx b/docs/pages/admin-guides/infrastructure-as-code/infrastructure-as-code.mdx index f1b8d92aee5b1..6cfbe4048e643 100644 --- a/docs/pages/admin-guides/infrastructure-as-code/infrastructure-as-code.mdx +++ b/docs/pages/admin-guides/infrastructure-as-code/infrastructure-as-code.mdx @@ -242,13 +242,13 @@ If you remove a dynamic configuration resource, the Auth Service will restore its configuration fields to the default values and add the `teleport.dev/origin=defaults` label. - + Cloud-hosted Teleport deployments use configuration files, but these are not available for operators to modify. Users of Teleport Enterprise Cloud may see configuration resources with the `teleport.dev/origin=config-file` label. - + ## Further reading diff --git a/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/enroll-resources.mdx b/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/enroll-resources.mdx index 5a2f34e326db2..8bb743de0a830 100644 --- a/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/enroll-resources.mdx +++ b/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/enroll-resources.mdx @@ -254,11 +254,11 @@ Edit the `agent_installation_dev` and `agent_installation_prod` blocks in 1. Assign `proxy_service_address` to the host and HTTPS port of your Teleport Proxy Service, e.g., `mytenant.teleport.sh:443`. - + Make sure to include the port. - + 1. Make sure `teleport_edition` matches your Teleport edition. Assign this to `oss`, `cloud`, or `enterprise`. The default is `oss`. diff --git a/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/rbac.mdx b/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/rbac.mdx index 865192382bc8a..bbf88135f03c2 100644 --- a/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/rbac.mdx +++ b/docs/pages/admin-guides/infrastructure-as-code/terraform-starter/rbac.mdx @@ -438,14 +438,14 @@ configuration. The bot will exist for one hour and will be granted the default role in your authentication connector. Your user should have the `dev_access` role. - + If you receive errors logging in using your authentication connector, log in as a local user with permissions to view the Teleport audit log. These is available in the preset `auditor` role. Check for error messages in events related with the "SSO Login" type. - + 1. Request access to the `prod_access` role through the Web UI. Visit the "Access Requests" tab and click "New Request". diff --git a/docs/pages/admin-guides/management/admin/daemon.mdx b/docs/pages/admin-guides/management/admin/daemon.mdx index a6a8837c8388c..43376ce940c04 100644 --- a/docs/pages/admin-guides/management/admin/daemon.mdx +++ b/docs/pages/admin-guides/management/admin/daemon.mdx @@ -19,7 +19,7 @@ $ readlink /sbin/init /lib/systemd/systemd ``` - @@ -27,7 +27,7 @@ $ readlink /sbin/init Teleport stores data in `/var/lib/teleport`. Make sure that regular/non-admin users do not have access to this folder on the Auth Service host. - + ## Step 1/3. Install and configure Teleport diff --git a/docs/pages/admin-guides/management/admin/self-signed-certs.mdx b/docs/pages/admin-guides/management/admin/self-signed-certs.mdx index 0bdf021076e7d..bf49ee59af0f8 100644 --- a/docs/pages/admin-guides/management/admin/self-signed-certs.mdx +++ b/docs/pages/admin-guides/management/admin/self-signed-certs.mdx @@ -17,7 +17,7 @@ you will likely see a page warning you that the website is not trusted. Additionally, self-signed certificates can prevent `teleport`, `tsh`, and `tctl` from connecting to the Proxy Service. - + **DO NOT USE SELF-SIGNED CERTIFICATES IN PRODUCTION** Configuring your cluster to trust self-signed certificates @@ -26,7 +26,7 @@ to the Proxy Service. way to verify the authenticity of the certificates. It is therefore important to properly configure certificates when using Teleport in a production environment. - + ## Prerequisites diff --git a/docs/pages/admin-guides/management/admin/troubleshooting.mdx b/docs/pages/admin-guides/management/admin/troubleshooting.mdx index 2f4db10fd9ccc..3876618b611cb 100644 --- a/docs/pages/admin-guides/management/admin/troubleshooting.mdx +++ b/docs/pages/admin-guides/management/admin/troubleshooting.mdx @@ -82,13 +82,13 @@ DEBU [NODE:PROX] Pool is closing agent. leaseID:2 target:tele.example.com:11106 DEBU [NODE:PROX] Pool is closing agent. leaseID:3 target:tele.example.com:11106 reversetunnel/agentpool.go:238 ``` - It is not recommended to run Teleport in production with verbose logging as it generates a substantial amount of data. - + ## Step 2/3. Generate a debug dump @@ -127,11 +127,11 @@ runtime/pprof.writeGoroutineStacks(0x3c2ffc0, 0xc0001a8010, 0xc001011a38, 0x4bcf ... ``` - + You can print a goroutine dump without enabling verbose logging. - + ## Step 3/3. Ask for help diff --git a/docs/pages/admin-guides/management/admin/uninstall-teleport.mdx b/docs/pages/admin-guides/management/admin/uninstall-teleport.mdx index a566c3ea4d8e8..a8deafa8e88ae 100644 --- a/docs/pages/admin-guides/management/admin/uninstall-teleport.mdx +++ b/docs/pages/admin-guides/management/admin/uninstall-teleport.mdx @@ -96,7 +96,7 @@ Follow the instructions for your Linux distribution: $ sudo rm -f /etc/apt/sources.list.d/teleport.list ``` - + If the commands above do not work, you may have installed Teleport using a standalone DEB package. Remove it with: ```code @@ -123,7 +123,7 @@ Follow the instructions for your Linux distribution: $ sudo rm -f /etc/yum.repos.d/teleport.repo ``` - + If the commands above do not work, you may have installed Teleport using a standalone RPM package. Remove it with: ```code @@ -151,7 +151,7 @@ Follow the instructions for your Linux distribution: - + These are the default paths to the Teleport binaries. If you have changed these from the defaults on your system, substitute those paths here. You can use `dirname $(which teleport)` to look this up automatically. @@ -171,7 +171,7 @@ Follow the instructions for your Linux distribution: ### macOS - + These are the default paths to the Teleport binaries. If you have changed these from the defaults on your system, substitute those paths here. You can use `dirname $(which teleport)` to look this up automatically. @@ -186,7 +186,7 @@ Follow the instructions for your Linux distribution: $ sudo rm -f /usr/local/bin/fdpass-teleport ``` - + If you installed the macOS `tsh` client-only package and/or Teleport Connect for macOS, you can optionally remove those too: ```code @@ -211,7 +211,7 @@ Follow the instructions for your Linux distribution: - + These are the default paths to the Teleport config files and data directory. If you have changed these from the defaults on your system, substitute those paths here. @@ -238,7 +238,7 @@ Follow the instructions for your Linux distribution: ``` - + These are the default paths to the Teleport config files and data directory. If you have changed these from the defaults on your system, substitute those paths here. diff --git a/docs/pages/admin-guides/management/diagnostics/diagnostics.mdx b/docs/pages/admin-guides/management/diagnostics/diagnostics.mdx index 598c9465a29db..a94b1edf5cda6 100644 --- a/docs/pages/admin-guides/management/diagnostics/diagnostics.mdx +++ b/docs/pages/admin-guides/management/diagnostics/diagnostics.mdx @@ -75,11 +75,11 @@ metrics that Teleport tracks. It is compatible with [Prometheus](https://prometh The following metrics are available: - + Teleport Enterprise (cloud-hosted) does not expose monitoring endpoints for the Auth Service and Proxy Service. - + (!docs/pages/includes/metrics.mdx!) diff --git a/docs/pages/admin-guides/management/external-audit-storage.mdx b/docs/pages/admin-guides/management/external-audit-storage.mdx index 587bb7ffebe56..41d581732f3eb 100644 --- a/docs/pages/admin-guides/management/external-audit-storage.mdx +++ b/docs/pages/admin-guides/management/external-audit-storage.mdx @@ -21,7 +21,7 @@ External Audit Storage is based on Teleport's available on Teleport Enterprise Cloud clusters running Teleport v14.2.1 or above. - + On Teleport Enterprise (Cloud), External Audit Storage is not currently supported for users who have Access Monitoring enabled. This functionality will be enabled in a future Teleport release. diff --git a/docs/pages/admin-guides/management/guides/ec2-tags.mdx b/docs/pages/admin-guides/management/guides/ec2-tags.mdx index 93338221fd7b6..ef3d67c581452 100644 --- a/docs/pages/admin-guides/management/guides/ec2-tags.mdx +++ b/docs/pages/admin-guides/management/guides/ec2-tags.mdx @@ -19,10 +19,10 @@ Node Name Address Labels fakehost.example.com 127.0.0.1:3022 env=example,hostname=ip-172-31-53-70,aws/Name=atburke-dev,aws/TagKey=TagValue,aws/TeleportHostname=fakehost.example.com ``` - + For services that manage multiple resources (such as the Database Service), each resource will receive the same labels from EC2. - + ## Prerequisites diff --git a/docs/pages/admin-guides/management/guides/gcp-tags.mdx b/docs/pages/admin-guides/management/guides/gcp-tags.mdx index 031f8679b5bef..ef99f8a4d0a6b 100644 --- a/docs/pages/admin-guides/management/guides/gcp-tags.mdx +++ b/docs/pages/admin-guides/management/guides/gcp-tags.mdx @@ -27,10 +27,10 @@ Node Name Address Labels fakehost.example.com 127.0.0.1:3022 gcp/label/testing=yes,gcp/tag/environment=staging,gcp/TeleportHostname=fakehost.example.com ``` - + For services that manage multiple resources (such as the Database Service), each resource will receive the same tags and labels from GCP. - + ## Prerequisites diff --git a/docs/pages/admin-guides/management/security/proxy-protocol.mdx b/docs/pages/admin-guides/management/security/proxy-protocol.mdx index 3a53dff6876cb..9bc8a82d44b9c 100644 --- a/docs/pages/admin-guides/management/security/proxy-protocol.mdx +++ b/docs/pages/admin-guides/management/security/proxy-protocol.mdx @@ -12,13 +12,13 @@ reliable client IP information is important from a security standpoint, because features like audit logging and IP pinning depend on it. If the PROXY protocol is not configured correctly, these features will be compromised. - + Users of Teleport Enterprise (Cloud) do not need to manage PROXY protocol setting. Teleport-managed Auth Service and Proxy Service deployments run behind an L4 load balancer with the PROXY protocol configured. - + ## How it works @@ -125,10 +125,10 @@ IP pinning will not work if `proxy_protocol` setting wasn't explicitly set in the config. Connections that are marked with `0` as the source port will be rejected during IP pinning checks. - + The default unspecified value mode is not suitable for production. It is only suitable for test environments. - + diff --git a/docs/pages/admin-guides/migrate-plans.mdx b/docs/pages/admin-guides/migrate-plans.mdx index 9007fafccb536..78844563107d9 100644 --- a/docs/pages/admin-guides/migrate-plans.mdx +++ b/docs/pages/admin-guides/migrate-plans.mdx @@ -115,7 +115,7 @@ Teleport clusters and execute `tctl` commands using your current credentials. website](https://status.teleport.sh/) to stay current on any issues impacting the performance of your new cluster. - @@ -125,7 +125,7 @@ Teleport clusters and execute `tctl` commands using your current credentials. security, Teleport Support cannot assist with resetting passwords or recovering lost credentials. - + ## Step 2/4. Migrate Teleport resources @@ -171,13 +171,13 @@ To achieve this: $ tctl create -f user.yaml ``` - + We recommend managing dynamic resources with the Teleport Terraform provider or Kubernetes operator. In this case, you can configure these tools to manage dynamic resources on your new Teleport cluster. - + 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 diff --git a/docs/pages/admin-guides/teleport-policy/crown-jewels.mdx b/docs/pages/admin-guides/teleport-policy/crown-jewels.mdx index cfb4d101bef3c..f2ad8e9682067 100644 --- a/docs/pages/admin-guides/teleport-policy/crown-jewels.mdx +++ b/docs/pages/admin-guides/teleport-policy/crown-jewels.mdx @@ -12,14 +12,14 @@ Crown Jewels, and how to see permission changes for these resources. ## Prerequisites - + For an improved experience, we recommend using Crown Jewels in conjunction with Teleport local users or integrating with [Okta](../../enroll-resources/application-access/okta/okta.mdx) or [Microsoft Entra ID](./integrations/entra-id.mdx). This setup helps minimize the number of access path change entries generated when highly privileged ephemeral users log in via Teleport Auth Connectors. - + - A running Teleport Enterprise cluster v16.2.0 or later. - For self-hosted clusters, an updated `license.pem` with Teleport Policy enabled. diff --git a/docs/pages/admin-guides/teleport-policy/integrations/aws-sync.mdx b/docs/pages/admin-guides/teleport-policy/integrations/aws-sync.mdx index 421a732a44384..f9ffdc2333300 100644 --- a/docs/pages/admin-guides/teleport-policy/integrations/aws-sync.mdx +++ b/docs/pages/admin-guides/teleport-policy/integrations/aws-sync.mdx @@ -70,12 +70,12 @@ how to set up Access Graph. ## Step 1/2. Configure Discovery Service (Self-hosted only) - + If you have a managed Teleport Enterprise cluster, you can disregard this step, as managed Teleport Enterprise already operates a properly configured Discovery Service within your cluster. - + To activate the Teleport Discovery Service, add the provided snippet to your Auth Service configuration. diff --git a/docs/pages/admin-guides/teleport-policy/integrations/entra-id.mdx b/docs/pages/admin-guides/teleport-policy/integrations/entra-id.mdx index dd6d30a6c1243..0e30adee4a026 100644 --- a/docs/pages/admin-guides/teleport-policy/integrations/entra-id.mdx +++ b/docs/pages/admin-guides/teleport-policy/integrations/entra-id.mdx @@ -8,12 +8,12 @@ and offers insights into relationships in your Entra ID directory. Additionally, when Entra ID is used as an SSO identity provider, Teleport Policy visualizes SSO grants across your services. - + SSO grant analysis is currently only supported in situations where Entra ID acts as the identity provider, and AWS accounts are set up as relying parties using AWS IAM role federation. Support for additional relying parties will be added in the future. - + ## How it works @@ -55,9 +55,9 @@ configuration and user requirements. ### Automatic setup with Teleport as an OIDC Provider for Entra ID - + This method is recommended and is required if you are a Teleport Enterprise (Cloud) customer. - + This method is suitable for Teleport clusters that are publicly accessible and lack Azure credentials on Auth Service nodes or pods. @@ -252,10 +252,10 @@ Be sure to follow each step in the `tctl plugins install entraid` guide closely This step configures the Azure Identity on your Auth Service machine with the required Entra ID permissions. - + Follow this step only if you want to use system-available credentials to authenticate Teleport with Entra ID. If you intend to use Teleport as an OIDC provider for Entra ID, you can skip this step. - + - `Application.Read.All` @@ -513,9 +513,9 @@ For clusters running in multiplex mode, this address will be the same as your pr If you chose to use Teleport as the OIDC provider for Entra ID in the previous step, remove the `--use-system-credentials` flag from the command below. - + Currently, when using manual mode, it is not possible to operate without the `--no-access-graph` flag. - + ```code # enable Access Graph integration if your license supports Teleport Policy. diff --git a/docs/pages/admin-guides/teleport-policy/integrations/gitlab.mdx b/docs/pages/admin-guides/teleport-policy/integrations/gitlab.mdx index 3a25ef7ad225f..2920cef00318c 100644 --- a/docs/pages/admin-guides/teleport-policy/integrations/gitlab.mdx +++ b/docs/pages/admin-guides/teleport-policy/integrations/gitlab.mdx @@ -67,7 +67,7 @@ Create a new token with the `read_api` scope and copy the generated token. For m The importer will use this token to fetch the necessary resources from your GitLab instance. - + The GitLab importer will only fetch resources that the token has access to. Ensure that the user associated with the token has the necessary permissions to access/view the resources you want to import. @@ -78,7 +78,7 @@ The importer will use this token to fetch the necessary resources from your GitL If you're using a self-hosted GitLab instance, the importer will fetch all resources that the token has access to, including all users who are part of the instance. - + The token will be used in the next step to configure the GitLab Sync integration. diff --git a/docs/pages/admin-guides/teleport-policy/integrations/ssh-keys-scan.mdx b/docs/pages/admin-guides/teleport-policy/integrations/ssh-keys-scan.mdx index c9c212a1798e0..8655794c474c1 100644 --- a/docs/pages/admin-guides/teleport-policy/integrations/ssh-keys-scan.mdx +++ b/docs/pages/admin-guides/teleport-policy/integrations/ssh-keys-scan.mdx @@ -62,10 +62,10 @@ Teleport cluster with metadata such as: public key is extracted from the private key, `public_key_file` if the private key is encrypted and the public key is available in a separate file, or `protected` if the public key fingerprint is not available. - + `tsh` never sends the private key itself to the Teleport cluster, ensuring that the private key remains secure on the device. It also never sends the private key path or any other sensitive information. - + ## Prerequisites @@ -195,10 +195,10 @@ given that the command may consume system resources during the scan. ![Example of a recurring Jamf Pro](../../../../img/access-graph/jamf-pro.png) - + `tsh` must be installed on the devices to run the scan. If the `tsh` binary is not installed, consider distributing it to the devices using the same policy or a separate policy. - + Once the policy is created, the devices will start scanning for SSH private keys and sending the fingerprints to the Teleport Cluster. The keys will be imported and displayed in the Access Graph. diff --git a/docs/pages/connect-your-client/gui-clients.mdx b/docs/pages/connect-your-client/gui-clients.mdx index 53939c9a14827..e086cfa7e0074 100644 --- a/docs/pages/connect-your-client/gui-clients.mdx +++ b/docs/pages/connect-your-client/gui-clients.mdx @@ -508,12 +508,12 @@ The Oracle integration works only in the authenticated proxy mode. Start a local tsh proxy db --tunnel --port 1521 --db-user= --db-name= oracle ``` - + This command uses the local port 1521, but you can choose any port, or let `tsh` pick a local port at random if you omit the `--port` flag. You should specify a port to avoid the need to reconfigure your GUI client again later. - + In "Connections" click the "+" button for a new database connection: diff --git a/docs/pages/connect-your-client/tsh.mdx b/docs/pages/connect-your-client/tsh.mdx index 01932d5d50cf4..170350c98d91c 100644 --- a/docs/pages/connect-your-client/tsh.mdx +++ b/docs/pages/connect-your-client/tsh.mdx @@ -686,9 +686,9 @@ $ tsh join Refer them to the [Moderated Sessions guide](../admin-guides/access-controls/guides/joining-sessions.mdx) for more information on configuring join permissions. - + Joining sessions is not supported in recording proxy mode (where `session_recording` is set to `proxy`). - + ## Connecting to SSH clusters behind firewalls @@ -699,9 +699,9 @@ tunnels from behind-firewall environments into a Teleport Proxy Service you have To learn more about setting up a trust relationship between clusters behind firewalls, see [Configure Trusted Clusters](../admin-guides/management/admin/trustedclusters.mdx). - + Trusted clusters are only available for self-hosted Teleport clusters. - + Assuming the Teleport Proxy Server called `work` is configured with a few trusted clusters, you can use the `tsh clusters` command to see a list of all the trusted clusters on the server: @@ -752,13 +752,13 @@ $ tsh ssh -X node01 X11 forwarding provides the server with secure access to your local X Server so that it can communicate directly with your local display and I/O devices. - + The `-Y` flag can be used to start Trusted X11 forwarding. This is needed in order to enable more "unsafe" features, such as running clipboard or screenshot utilities like `xclip`. However, it provides the server with unmitigated access to your local X Server and puts your local machine at risk of X11 attacks, so it should only be used with extreme caution. - + In order to use X11 forwarding, you'll need to enable it on the Teleport Node. You'll also need to ensure that your user has the `permit_x11_forwarding` role option: diff --git a/docs/pages/enroll-resources/agents/join-services-to-your-cluster/join-token.mdx b/docs/pages/enroll-resources/agents/join-services-to-your-cluster/join-token.mdx index dbe51d8c553bb..f343d7be1136c 100644 --- a/docs/pages/enroll-resources/agents/join-services-to-your-cluster/join-token.mdx +++ b/docs/pages/enroll-resources/agents/join-services-to-your-cluster/join-token.mdx @@ -38,12 +38,12 @@ relationship with the Teleport cluster. - + If you are using a Docker container, note that this guide assumes that your Linux host has `curl` and `sudo` installed. - + (!docs/pages/includes/tctl.mdx!) @@ -127,10 +127,10 @@ Token Type Labels Expiry Time (UTC)
- + Use short-lived tokens instead of long-lived static tokens. Static tokens are easier to steal, guess, and leak. - + Static tokens are defined ahead of time by an administrator and stored in the Auth Service's config file: @@ -165,13 +165,13 @@ $ sudo teleport configure \ -o file ``` - + For SSH Service instances, you can also run `teleport node configure` instead of `teleport configure`. This way, you can exclude the `--roles=node` flag from the command. - +
@@ -181,13 +181,13 @@ possibility in Teleport Enterprise Cloud.) Depending on the design of your infrastructure, you may need to connect your new Teleport process directly to the Auth Service. - + Only connect Teleport processes directly to the Auth Service if no other join methods are suitable, as we recommend exposing the Auth Service to as few sources of ingress traffic as possible. - + The Teleport process joining the cluster must also establish trust with the Auth Service in order to prevent an attacker from hijacking the address of your Auth @@ -217,12 +217,12 @@ CA pin (=presets.ca_pin=) Copy the CA pin and assign it to the value of . - + The CA pin becomes invalid if a Teleport administrator performs the CA rotation by executing [`tctl auth rotate`](../../../reference/cli/tctl.mdx#tctl-auth-rotate). - + ### Configure your Teleport process with the join token and CA pin diff --git a/docs/pages/enroll-resources/agents/join-services-to-your-cluster/kubernetes.mdx b/docs/pages/enroll-resources/agents/join-services-to-your-cluster/kubernetes.mdx index 38d70223dbd13..29ca761c924bd 100644 --- a/docs/pages/enroll-resources/agents/join-services-to-your-cluster/kubernetes.mdx +++ b/docs/pages/enroll-resources/agents/join-services-to-your-cluster/kubernetes.mdx @@ -13,12 +13,12 @@ Kubernetes issues signed proof to each pod describing which Kubernetes ServiceAccount they can assume. When using the Kubernetes join method, Teleport uses this Kubernetes proof to become part of the cluster. - + The Kubernetes join method is not available in Teleport Enterprise Cloud as it requires the joining service to run in the same Kubernetes cluster as the Auth Service. - + The Kubernetes join method is available in self-hosted versions of Teleport. It supports joining any Teleport service running in the same Kubernetes cluster diff --git a/docs/pages/enroll-resources/application-access/cloud-apis/google-cloud.mdx b/docs/pages/enroll-resources/application-access/cloud-apis/google-cloud.mdx index a48c6d1a8ac04..52d059c0a8c94 100644 --- a/docs/pages/enroll-resources/application-access/cloud-apis/google-cloud.mdx +++ b/docs/pages/enroll-resources/application-access/cloud-apis/google-cloud.mdx @@ -32,13 +32,13 @@ prevent unauthorized access to your organization's Google Cloud service accounts page](https://cloud.google.com/sdk/docs/install-sdk) to install and authenticate to `gcloud`. - + While this guide focuses on `gcloud`, once you set up Google Cloud API access with Teleport, you can also manage access to `gsutil` and other Google Cloud CLI tools using the Teleport Application Service. - + - Either a Google Compute Engine VM where you will run the Teleport Application Service *or* permissions to create VMs in your Google Cloud project. If you @@ -106,14 +106,14 @@ permissions to impersonate target service accounts. #### Create a service account and enable it to view resources - + If you are enabling access to an existing service account, you can skip to the [next section](#enable-teleport-google-cloud-cli-to-impersonate-target-service-accounts ). - + Create a target service account: @@ -139,12 +139,12 @@ Enable the `teleport-google-cloud-cli` service account to impersonate `teleport-google-cloud-cli` account to the predefined "Service Account Token Creator Role" for the `teleport-vm-viewer` service account: - + To enable Google Cloud CLI access for pre-existing service accounts, you must run this command for each service account. - + ```code $ gcloud iam service-accounts add-iam-policy-binding \ @@ -209,13 +209,13 @@ $ gcloud compute instances set-service-account \ --scopes=cloud-platform ``` - + You must use the `scopes` flag in the `gcloud compute instances set-service-account` command. Otherwise, your Google Cloud VM will fail to obtain the required authorization to access Google Cloud. - + Once you have attached the service account, restart your VM: @@ -295,7 +295,7 @@ service accounts: |**Dynamic**|A Teleport role includes a template variable that grants a user access to all Google Cloud service accounts assigned directly to them.|Local users, OIDC, SAML| |**Static**|A Teleport role explicitly specifies the Google Cloud service accounts a user is allowed to assume.|Local users, OIDC, SAML, GitHub| - + We recommend using the dynamic approach, since it scales more easily as you add service accounts to your Google Cloud account. If you have configured an open @@ -303,7 +303,7 @@ source Teleport cluster to authenticate users via GitHub SSO, you must use the static approach, as OAuth-based GitHub applications do not support custom claims. - + @@ -585,13 +585,13 @@ Use the following credentials and HTTPS proxy setting to connect to the proxy: export HTTPS_PROXY=http://127.0.0.1:50614 ``` - + `tsh proxy gcloud` runs the local proxy in the foreground, so don't interrupt the process or exit the terminal where you ran the command until you're ready to close the local proxy. - + Copy the `export` commands and paste them into a second terminal. In that terminal, you can now run your Google Cloud CLI application of choice. For @@ -616,13 +616,13 @@ ERROR: (gcloud.iam.service-accounts.create) User [myuser] does not have permissi reason: IAM_PERMISSION_DENIED ``` - + When you run a `gcloud` or `gsutil` command via `tsh gcloud` or `tsh gsutil`, `tsh` starts the local proxy in the background and uses it to execute the command. - + ## Next steps diff --git a/docs/pages/enroll-resources/auto-discovery/databases/aws.mdx b/docs/pages/enroll-resources/auto-discovery/databases/aws.mdx index 0d1c98a6973c6..fd69bf14cf5a6 100644 --- a/docs/pages/enroll-resources/auto-discovery/databases/aws.mdx +++ b/docs/pages/enroll-resources/auto-discovery/databases/aws.mdx @@ -112,7 +112,7 @@ discover AWS databases. Once it discovers databases, the Discovery Service will register them as `db` resources in your Teleport cluster. - + A Teleport `db` resource represents the specification of a database that a Teleport Database Service can then use to provide access to the database. When a Database Service instance matches the `db` resource via label selectors, it will @@ -120,7 +120,7 @@ begin to heartbeat the database by regularly creating short-lived `db_server` resources in your Teleport cluster. Tools like `tsh db ls` and `tctl db ls` will only display `db_server` resources, i.e. databases that a Database Service instance is providing access to. - + ## Step 5/8. List registered databases @@ -252,13 +252,13 @@ In this case, it will match auto-discovered AWS databases in the from any AWS account (`"*"` is a wildcard and it can be used as a label key and/or value). You can make it match more specific databases by adjusting the label selectors. - + The AWS tags attached to AWS databases are imported as Teleport `db` labels in addition to some other identifying metadata. Refer to [Database Labels Reference](../../../reference/agent-services/database-access-reference/labels.mdx) for more information about available database labels. - + ### Generate a join token @@ -283,7 +283,7 @@ $ tctl db ls teleport.dev/origin=cloud,teleport.dev/cloud=AWS,region= + This guide shows you how to set-up AWS database auto-discovery with a Discovery Service and Database Service, but does not cover database user provisioning. @@ -293,7 +293,7 @@ be required to connect to the discovered databases via Teleport. Refer to the appropriate guide in [Enroll AWS Databases](../../database-access/enroll-aws-databases/enroll-aws-databases.mdx) for information about database user provisioning and configuration. - + ## Next - Learn about [Dynamic Registration](../../database-access/guides/dynamic-registration.mdx) by the diff --git a/docs/pages/enroll-resources/auto-discovery/databases/databases.mdx b/docs/pages/enroll-resources/auto-discovery/databases/databases.mdx index 9163f3dc1b814..5614410cf99f4 100644 --- a/docs/pages/enroll-resources/auto-discovery/databases/databases.mdx +++ b/docs/pages/enroll-resources/auto-discovery/databases/databases.mdx @@ -44,7 +44,7 @@ information such as: - Cloud account information, e.g. AWS Account ID / Azure Subscription ID - *Endpoint Info*: Connection endpoint the database can be reached at - + You can override a discovered database's name by using a special tag attached to the database in your cloud provider: - ***key***: `TeleportDatabaseName` @@ -54,7 +54,7 @@ The Discovery Service will check if the database metadata includes the tag and use its value as the resource name in Teleport. The name override will be used verbatim, i.e. additional metadata will not be appended to it. - + The Teleport Discovery Service only needs access to APIs that it can poll for databases - it does not need network connectivity or permissions to connect to diff --git a/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx b/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx index 2bb47fb196889..8d6c7e4677b2d 100644 --- a/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx +++ b/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx @@ -50,12 +50,12 @@ running the Teleport Discovery Service: ## Step 2/3. Configure EKS cluster authorization - + If you are running Teleport Discovery v15.3.8 or later and the IAM role used by the Discovery Service has the necessary permissions to create and update Access Entries, you can skip this section. The service can self-bootstrap the required permissions automatically. - + When the Kubernetes Service uses an IAM role that is different from the one that creates the clusters, you need to configure the mapping between the Teleport IAM @@ -202,11 +202,11 @@ to forward requests to the cluster. - + Granting the `system:masters` group to the IAM role associated with the Teleport service means granting administrator-level permissions on the Kubernetes cluster. To follow least privilege principle we do not recommend using this method in production. - + If your cluster contains an `aws-auth` config map, you can use this to associate the Teleport IAM role with the `system:masters` RBAC group. Edit the @@ -261,11 +261,11 @@ to forward requests to the cluster. - + If you provision your EKS clusters using tools such as `terraform`, `eksctl` or `Cloudformation`, you can use them to automatically configure the `aws-auth` `Configmap` or access entry and create the `ClusterRole` and `ClusterRoleBinding` resources during cluster provisioning. - + ## Step 3/3. Configure Teleport to discover EKS clusters diff --git a/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx b/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx index 43a9eaa3d8161..8c7d0891eba20 100644 --- a/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx +++ b/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx @@ -207,13 +207,13 @@ $ gcloud compute instances set-service-account ${VM2_NAME?} \
- + You must use the `scopes` flag in the `gcloud compute instances set-service-account` command. Otherwise, your Google Cloud VM will fail to obtain the required authorization to access the GKE API. - + Once you have attached the service account, restart your VM: diff --git a/docs/pages/enroll-resources/auto-discovery/kubernetes/kubernetes.mdx b/docs/pages/enroll-resources/auto-discovery/kubernetes/kubernetes.mdx index f1d43d48870c2..f4f404efe7117 100644 --- a/docs/pages/enroll-resources/auto-discovery/kubernetes/kubernetes.mdx +++ b/docs/pages/enroll-resources/auto-discovery/kubernetes/kubernetes.mdx @@ -35,7 +35,7 @@ cloud provider such as: - Cluster location. - Identification of which cloud account the cluster belongs to — AWS Account ID / Azure Subscription ID. - + You can import the cluster under a different name into Teleport's registry. To achieve this, you must attach the following tag to the resources — EKS, AKS, GKE — in your cloud provider: - ***key***: `TeleportKubernetesName` @@ -47,7 +47,7 @@ as the resource name in Teleport. You should use this feature whenever there are clusters in different regions/cloud providers with the same name to prevent them from colliding in Teleport. - + In addition to detecting new Kubernetes clusters, the Discovery Service also removes — from Teleport's registry — the Kubernetes clusters that have been deleted or whose tags diff --git a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/mysql-cloudsql.mdx b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/mysql-cloudsql.mdx index 0d371ef6a2015..ee6302d62f2a8 100644 --- a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/mysql-cloudsql.mdx +++ b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/mysql-cloudsql.mdx @@ -59,12 +59,12 @@ The pre-defined "Cloud SQL Viewer" role has this permission, but also has other permissions that are not needed. Define and bind a custom role to the service account to follow the principal of least privilege. - + Support for legacy one-time password authentication will be deprecated. If you are following this guide and have already set up Teleport prior to the introduction of support for IAM database user authentication, then you should configure your database users to use IAM auth as described in this guide. - + ## Step 2/9. Create a service account for a database user @@ -94,12 +94,12 @@ default 3306 as the default Cloud SQL MySQL listener does not trust generated ephemeral certificates. For this reason, you should make sure to allow port 3307 when using "require trusted client certificates". - + The "require trusted client certificates" SSL mode only forces the client (Teleport) to provide a trusted client certificate. Teleport will always connect to the database over encrypted TLS regardless of the instance's SSL mode setting. - + ### Create a database user @@ -175,12 +175,12 @@ $ tsh db ls - You will only be able to see databases that your Teleport role has access to. See our [RBAC](../rbac.mdx) guide for more details. - + When connecting to the database, use either the database user name or the service account's Email ID. Both the user name and the service account's Email diff --git a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/postgres-cloudsql.mdx b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/postgres-cloudsql.mdx index 1b827b69c1b1e..356c0daaa663f 100644 --- a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/postgres-cloudsql.mdx +++ b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/postgres-cloudsql.mdx @@ -131,12 +131,12 @@ $ tsh db ls - You will only be able to see databases that your Teleport role has access to. See our [RBAC](../rbac.mdx) guide for more details. - + When connecting to the database, use the name of the database's service account that you added as an IAM database user diff --git a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/spanner.mdx b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/spanner.mdx index a1b17ad29fbb3..81d222a0c52a3 100644 --- a/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/spanner.mdx +++ b/docs/pages/enroll-resources/database-access/enroll-google-cloud-databases/spanner.mdx @@ -73,13 +73,13 @@ account as a principal and assign it the "Cloud Spanner Database User" role: Click "Save". - + [Cloud Spanner Database User](https://cloud.google.com/spanner/docs/iam#spanner.databaseUser) is a pre-defined role. You can use a different pre-defined role or create and customize your own role permissions with [custom IAM roles](https://cloud.google.com/spanner/docs/iam#custom-roles). - + ### Grant access to the service account @@ -177,12 +177,12 @@ spanner-example GCP Cloud Spanner [*] env=dev - You will only be able to see databases that your Teleport role has access to. See our [RBAC](../rbac.mdx) guide for more details. - + When connecting to the database, use the name of the service account that you created for a database user diff --git a/docs/pages/enroll-resources/database-access/enroll-self-hosted-databases/vitess.mdx b/docs/pages/enroll-resources/database-access/enroll-self-hosted-databases/vitess.mdx index 835a07ccc3e28..57d732b50843c 100644 --- a/docs/pages/enroll-resources/database-access/enroll-self-hosted-databases/vitess.mdx +++ b/docs/pages/enroll-resources/database-access/enroll-self-hosted-databases/vitess.mdx @@ -19,10 +19,10 @@ description: How to configure Teleport database access for Vitess (MySQL protoco - + Accessing Vitess using the gRPC protocol is not currently supported by Teleport. - + ## Prerequisites diff --git a/docs/pages/enroll-resources/database-access/rbac.mdx b/docs/pages/enroll-resources/database-access/rbac.mdx index 38a63801be474..19f84558b6856 100644 --- a/docs/pages/enroll-resources/database-access/rbac.mdx +++ b/docs/pages/enroll-resources/database-access/rbac.mdx @@ -30,12 +30,12 @@ For a more general description of Teleport roles and examples see [RBAC](../../admin-guides/access-controls/access-controls.mdx), as this section focuses on configuring RBAC for database access. - + Database Access Controls for database objects only supports PostgreSQL databases. - + ## Role configuration diff --git a/docs/pages/enroll-resources/desktop-access/directory-sharing.mdx b/docs/pages/enroll-resources/desktop-access/directory-sharing.mdx index c64fa889b4e90..af9b50aae8a38 100644 --- a/docs/pages/enroll-resources/desktop-access/directory-sharing.mdx +++ b/docs/pages/enroll-resources/desktop-access/directory-sharing.mdx @@ -105,12 +105,12 @@ the shared directory. You can also copy a file from one subdirectory within the shared directory and paste it into another—the local side will reflect the changes. - + Directory Sharing does not support moving files between subdirectories within the shared directory on the remote side. - + ### Editing on the local side diff --git a/docs/pages/enroll-resources/kubernetes-access/controls.mdx b/docs/pages/enroll-resources/kubernetes-access/controls.mdx index 5332e036201e2..b55ff1ddf5667 100644 --- a/docs/pages/enroll-resources/kubernetes-access/controls.mdx +++ b/docs/pages/enroll-resources/kubernetes-access/controls.mdx @@ -335,14 +335,14 @@ Below is a Kubernetes `ClusterRole` that grants the minimum set of permissions to enable impersonation, and a `ClusterRoleBinding` that grants these permissions to a service account. - + There is usually no need to define these resources manually. The [manual methods](register-clusters/register-clusters.mdx) and [automatic methods](../auto-discovery/kubernetes/kubernetes.mdx) for registering Kubernetes clusters with Teleport include steps for setting up the Kubernetes RBAC resources that Teleport needs to allow access to clusters. - + ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -555,14 +555,14 @@ value begins with `^` and ends in `$`, the Kubernetes Service will treat it as a regular expression using Go's `re2` syntax (see the `re2` [README](https://github.com/google/re2/wiki/Syntax)). - + For a user to access a pod named in a role's `kubernetes_resources` field, the user must be assigned a Teleport role that contains at least one value within `kubernetes_groups` or `kubernetes_users`. Teleport does not alter Kubernetes roles to allow or deny access. Read the next section for an explanation of how the Kubernetes Service evaluates Teleport roles in order to allow or deny access to pods in a cluster. - + ## How the Kubernetes Service evaluates Teleport roles diff --git a/docs/pages/enroll-resources/kubernetes-access/register-clusters/dynamic-registration.mdx b/docs/pages/enroll-resources/kubernetes-access/register-clusters/dynamic-registration.mdx index a89948e63ad70..567a5bc65179b 100644 --- a/docs/pages/enroll-resources/kubernetes-access/register-clusters/dynamic-registration.mdx +++ b/docs/pages/enroll-resources/kubernetes-access/register-clusters/dynamic-registration.mdx @@ -21,12 +21,12 @@ registration, then create, list, update, and delete Kubernetes clusters via - A Linux host where you will install the Teleport Kubernetes Service. - + Our `teleport-kube-agent` Helm chart does not support dynamic Kubernetes cluster registration. - + - A Kubernetes cluster to join to your Teleport cluster. You must have permissions to create namespaces, secrets, service accounts, cluster roles, @@ -422,13 +422,13 @@ $ tsh kube ls mycluster env=test teleport.dev/origin=dynamic * ``` - + If the updated `kube_cluster` resource's labels no longer match the ones a Teleport Kubernetes Service instance is configured to watch, the instance will unregister and stop proxying the Kubernetes cluster. - + ### Delete Kubernetes cluster resources diff --git a/docs/pages/enroll-resources/kubernetes-access/troubleshooting.mdx b/docs/pages/enroll-resources/kubernetes-access/troubleshooting.mdx index 0c90c6379a795..38d9e832db6a6 100644 --- a/docs/pages/enroll-resources/kubernetes-access/troubleshooting.mdx +++ b/docs/pages/enroll-resources/kubernetes-access/troubleshooting.mdx @@ -93,10 +93,10 @@ Or the following: GKE Autopilot denies requests that impersonate "system:masters" group ``` - + This issue only affects GKE Autopilot clusters. If you're using a standard GKE cluster, this issue doesn't apply to you. - + ### Explanation diff --git a/docs/pages/enroll-resources/machine-id/access-guides/ssh.mdx b/docs/pages/enroll-resources/machine-id/access-guides/ssh.mdx index 39a0aaaa043c0..5c845a6ed7385 100644 --- a/docs/pages/enroll-resources/machine-id/access-guides/ssh.mdx +++ b/docs/pages/enroll-resources/machine-id/access-guides/ssh.mdx @@ -143,11 +143,11 @@ $ ssh -F /opt/machine-id/ssh_config root@my-host.example.teleport.sh hostname my-host ``` - + The `ssh_config` for OpenSSH requires that `tsh` is installed. This is necessary as `tsh` is used to make the OpenSSH client compatible with Teleport's port multiplexing. - + ### Connecting using other tools diff --git a/docs/pages/enroll-resources/machine-id/deployment/linux.mdx b/docs/pages/enroll-resources/machine-id/deployment/linux.mdx index 8df4622ed3c67..a01de4a4521cf 100644 --- a/docs/pages/enroll-resources/machine-id/deployment/linux.mdx +++ b/docs/pages/enroll-resources/machine-id/deployment/linux.mdx @@ -73,12 +73,12 @@ Replace: - `(=presets.tokens.first=)` with the token that was returned by `tctl bots add` in the previous step. - + The first time that `tbot` runs, this token will be exchanged for a certificate that the bot uses for authentication. At this point, the token is invalidated. This means you may remove the token from the configuration file after the first run has completed, but there is no tangible security benefit to doing so. - + ### Prepare the storage directory diff --git a/docs/pages/enroll-resources/machine-id/troubleshooting.mdx b/docs/pages/enroll-resources/machine-id/troubleshooting.mdx index 05c37fc759fa0..ecb34fed28c23 100644 --- a/docs/pages/enroll-resources/machine-id/troubleshooting.mdx +++ b/docs/pages/enroll-resources/machine-id/troubleshooting.mdx @@ -274,7 +274,7 @@ $ tctl edit role/machine-id-db Edit the role, then save and close the file to apply your changes. - + By default, outputs (like `/opt/machine-id`) are granted all roles provided to the bot via `tctl bots add --roles=...`, but it's possible to grant only a subset of these roles using the `roles: ...` parameter in `tbot.yaml`. @@ -282,7 +282,7 @@ subset of these roles using the `roles: ...` parameter in `tbot.yaml`. If permissions are unexpectedly missing, ensure `tbot.yaml` requests your database role, either by relying on default behavior or adding the role to the `roles: ...` list. - + Once fixed, restart or reload the `tbot` clients for the updated role to take effect. diff --git a/docs/pages/enroll-resources/server-access/guides/bpf-session-recording.mdx b/docs/pages/enroll-resources/server-access/guides/bpf-session-recording.mdx index 44c681c9778d4..1e6340d84a5f9 100644 --- a/docs/pages/enroll-resources/server-access/guides/bpf-session-recording.mdx +++ b/docs/pages/enroll-resources/server-access/guides/bpf-session-recording.mdx @@ -71,12 +71,12 @@ library preloading, and environment variables may not be captured in session rec See below for more details on the required versions for your Linux kernel and distribution. - + Our Standard Session Recording works with older Linux kernels. View [Teleport Session Recording](../../../reference/architecture/session-recording.mdx) for more details. - + ### Linux distributions and supported kernels diff --git a/docs/pages/enroll-resources/server-access/guides/recording-proxy-mode.mdx b/docs/pages/enroll-resources/server-access/guides/recording-proxy-mode.mdx index d193511300806..858c0ff67e3f9 100644 --- a/docs/pages/enroll-resources/server-access/guides/recording-proxy-mode.mdx +++ b/docs/pages/enroll-resources/server-access/guides/recording-proxy-mode.mdx @@ -15,14 +15,14 @@ when gradually transitioning large server fleets to Teleport. ![Teleport OpenSSH Recording Proxy](../../../../img/server-access/openssh-proxy.svg) - + Teleport Cloud only supports session recording at the Node level. If you are interested in setting up session recording, read our [Server Access Getting Started Guide](../getting-started.mdx) so you can start replacing your OpenSSH servers with Teleport Nodes. - + We consider Recording Proxy Mode to be less secure than recording at the Node level for two reasons: diff --git a/docs/pages/enroll-resources/workload-identity/aws-oidc-federation.mdx b/docs/pages/enroll-resources/workload-identity/aws-oidc-federation.mdx index d02f0f3c4274a..899132c3eb3e4 100644 --- a/docs/pages/enroll-resources/workload-identity/aws-oidc-federation.mdx +++ b/docs/pages/enroll-resources/workload-identity/aws-oidc-federation.mdx @@ -59,10 +59,10 @@ This guide covers configuring OIDC federation. For Roles Anywhere, see information, see the [deployment guides](../machine-id/deployment/deployment.mdx). - + Issuing JWT SVIDs with Teleport Workload Identity requires at least Teleport version 16.4.3. - + ### Deciding on a SPIFFE ID structure diff --git a/docs/pages/enroll-resources/workload-identity/azure-federated-credentials.mdx b/docs/pages/enroll-resources/workload-identity/azure-federated-credentials.mdx index 93fbb0d39c25d..5774e3f43f4c6 100644 --- a/docs/pages/enroll-resources/workload-identity/azure-federated-credentials.mdx +++ b/docs/pages/enroll-resources/workload-identity/azure-federated-credentials.mdx @@ -44,10 +44,10 @@ protect Azure APIs in a few ways: - An Azure resource group and subscription you wish to grant the workload access to. - + Issuing JWT SVIDs with Teleport Workload Identity requires at least Teleport version 16.4.3. - + ### Deciding on a SPIFFE ID structure diff --git a/docs/pages/enroll-resources/workload-identity/gcp-workload-identity-federation-jwt.mdx b/docs/pages/enroll-resources/workload-identity/gcp-workload-identity-federation-jwt.mdx index 60531fffdcd15..52ebb9b18893e 100644 --- a/docs/pages/enroll-resources/workload-identity/gcp-workload-identity-federation-jwt.mdx +++ b/docs/pages/enroll-resources/workload-identity/gcp-workload-identity-federation-jwt.mdx @@ -40,10 +40,10 @@ GCP APIs in a few ways: workloads which need to access Teleport Workload Identity will run. For more information, see the [deployment guides](../machine-id/deployment/deployment.mdx). - + Issuing JWT SVIDs with Teleport Workload Identity requires at minimum version 16.4.3. - + ### Deciding on a SPIFFE ID structure diff --git a/docs/pages/includes/application-access/azure-teleport-role.mdx b/docs/pages/includes/application-access/azure-teleport-role.mdx index e380656b77615..082df77a45eea 100644 --- a/docs/pages/includes/application-access/azure-teleport-role.mdx +++ b/docs/pages/includes/application-access/azure-teleport-role.mdx @@ -11,14 +11,14 @@ identities. |**Dynamic**|A Teleport role includes a template variable that grants a user access to all Azure identities assigned directly to them.|Local users, OIDC, SAML| |**Static**|A Teleport role explicitly specifies the Azure identities a user is allowed to assume.|Local users, OIDC, SAML, GitHub| - + We recommend using the dynamic approach, since it scales well as you add Azure identities to your account. If you have configured a Teleport Community Edition cluster to authenticate users using GitHub SSO, you must use the static approach, as OAuth-based GitHub applications do not support custom claims. - + diff --git a/docs/pages/includes/application-access/azure-tsh.mdx b/docs/pages/includes/application-access/azure-tsh.mdx index fecc6b3d9150c..faaef2c4dd7ea 100644 --- a/docs/pages/includes/application-access/azure-tsh.mdx +++ b/docs/pages/includes/application-access/azure-tsh.mdx @@ -69,13 +69,13 @@ for example, run the following command: $ tsh az vm list ``` - + If you're not seeing the expected VMs at this point, double-check that your Azure managed identity is assigned the "Reader" role at the scope of your resource group. - + ### Use Azure CLI applications without `tsh` @@ -93,11 +93,11 @@ To start the local proxy, run the following `tsh` command: $ tsh proxy azure ``` - + The command `tsh proxy az` is an alias for `tsh proxy azure`. - + The command will print the address of the local proxy server along with `export` commands for assigning environment variables. Azure CLI applications read these @@ -105,13 +105,13 @@ variables in order to request an authentication token for Azure's APIs: (!docs/pages/includes/application-access/azure-tsh-proxy-azure-sample.mdx!) - + `tsh proxy azure` runs the local proxy in the foreground, so don't interrupt the process or exit the terminal where you ran the command until you're ready to close the local proxy. - + Copy the `export` commands and paste them into a second terminal. In that terminal, you can now run your Azure CLI application of choice. For example, you @@ -126,9 +126,9 @@ identity you created earlier, and that identity is authorized to view resources in your resource group, the `az vm list` command will only list VMs in that resource group. - + When you run an `az` command via `tsh az`, `tsh` starts the local proxy in the background and uses it to execute the command. - + diff --git a/docs/pages/includes/cloud/call-to-action.mdx b/docs/pages/includes/cloud/call-to-action.mdx index a0f242dc1ef4b..25dd4cd1bf3cc 100644 --- a/docs/pages/includes/cloud/call-to-action.mdx +++ b/docs/pages/includes/cloud/call-to-action.mdx @@ -1,4 +1,4 @@ - @@ -8,4 +8,4 @@ secure access to your infrastructure right away. Get started with a [free trial](https://goteleport.com/signup?t_source=docs) of Teleport Enterprise Cloud. - + diff --git a/docs/pages/includes/database-access/gui-clients/spanner-local-proxy.mdx b/docs/pages/includes/database-access/gui-clients/spanner-local-proxy.mdx index c4ae900e8c0d5..eb59a0e504ca6 100644 --- a/docs/pages/includes/database-access/gui-clients/spanner-local-proxy.mdx +++ b/docs/pages/includes/database-access/gui-clients/spanner-local-proxy.mdx @@ -12,10 +12,10 @@ The name of the service account should be everything before the "@" of the service account email address, e.g. the name for `llama@example-project-123456.iam.gserviceaccount.com` is just "llama". - + This command uses the local port 1443, but you can choose any port, or let `tsh` pick a local port at random if you omit the `--port` flag. You should specify a port to avoid the need to reconfigure your GUI client again later. - + diff --git a/docs/pages/includes/database-access/reference/aws-iam/redis/auto-password-access-policy.mdx b/docs/pages/includes/database-access/reference/aws-iam/redis/auto-password-access-policy.mdx index 65708f9b582d4..96b94f4b58129 100644 --- a/docs/pages/includes/database-access/reference/aws-iam/redis/auto-password-access-policy.mdx +++ b/docs/pages/includes/database-access/reference/aws-iam/redis/auto-password-access-policy.mdx @@ -1,11 +1,11 @@ {{ dbType="ElastiCache" permissionType="elasticache" updateUserPermission="ModifyUser" listTagsPermission="ListTagsForResource" }} - + The recommended way to configure Teleport access to {{ dbType }} is to use IAM auth, which is supported for Redis engine version 7.0 and up. Using managed users with passwords stored in AWS Secrets Manager is a legacy method for configuring Teleport access to {{ dbType }}. - + If any {{ dbType }} users are tagged to be managed by Teleport, below are the IAM permissions required for managing the {{ dbType }} users: diff --git a/docs/pages/includes/device-trust/support-notice.mdx b/docs/pages/includes/device-trust/support-notice.mdx index 182a081877c87..b76633e2fb183 100644 --- a/docs/pages/includes/device-trust/support-notice.mdx +++ b/docs/pages/includes/device-trust/support-notice.mdx @@ -1,4 +1,4 @@ - + Device Trust supports all platforms and clients, including `tsh`, Teleport Connect and the Web UI (requires Teleport Connect to be installed). diff --git a/docs/pages/includes/discovery/database-service-troubleshooting.mdx b/docs/pages/includes/discovery/database-service-troubleshooting.mdx index 31ed6a52a5663..768288ef4f772 100644 --- a/docs/pages/includes/discovery/database-service-troubleshooting.mdx +++ b/docs/pages/includes/discovery/database-service-troubleshooting.mdx @@ -37,11 +37,11 @@ spec: #### Errors when connecting to a database - + This section assumes you have already provisioned a database user and configured Teleport RBAC for that database user by following a specific guide in [Enroll AWS Databases](../../enroll-resources/database-access/enroll-aws-databases/enroll-aws-databases.mdx). - + If there are connection errors when you try to connect to a database, then first check if there are multiple `db_server` heartbeat resources for the target diff --git a/docs/pages/includes/discovery/discovery-group.mdx b/docs/pages/includes/discovery/discovery-group.mdx index ce3b48854da9b..026640c91a7ec 100644 --- a/docs/pages/includes/discovery/discovery-group.mdx +++ b/docs/pages/includes/discovery/discovery-group.mdx @@ -1,4 +1,4 @@ - + Discovery Service exposes a configuration parameter - `discovery_service.discovery_group` - that allows you to group discovered resources into different sets. This parameter is used to prevent Discovery Agents watching different sets of cloud resources @@ -18,4 +18,4 @@ the following configuration. from Production account. - 2 Discovery Services configured with `discovery_group: "staging"` polling data from Staging account. - + diff --git a/docs/pages/includes/helm-reference/zz_generated.teleport-kube-agent.mdx b/docs/pages/includes/helm-reference/zz_generated.teleport-kube-agent.mdx index 45e31399cbda9..de5b7ade1d8f7 100644 --- a/docs/pages/includes/helm-reference/zz_generated.teleport-kube-agent.mdx +++ b/docs/pages/includes/helm-reference/zz_generated.teleport-kube-agent.mdx @@ -660,9 +660,9 @@ You must create a secret containing the CA certs in the same namespace as Telepo $ kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem ``` - + The key containing the root CA in the secret must be `ca.pem`. - + ## `updater` diff --git a/docs/pages/installation.mdx b/docs/pages/installation.mdx index dc9c725248a55..8521a1bc30bfc 100644 --- a/docs/pages/installation.mdx +++ b/docs/pages/installation.mdx @@ -856,13 +856,13 @@ You can download one of the following .pkg installers for macOS: # /usr/local/bin/teleport ``` - + We do not recommend using Homebrew to install Teleport. The Teleport package in Homebrew is not maintained by Teleport and we can't guarantee its reliability or security. - + diff --git a/docs/pages/ips.mdx b/docs/pages/ips.mdx index 25d055b778b45..7dd01537e990f 100644 --- a/docs/pages/ips.mdx +++ b/docs/pages/ips.mdx @@ -32,9 +32,9 @@ This list may be used to allowlist outbound network connections from Teleport Ag Allowlisting these IPs is not a required or recommended configuration for Teleport Agents, but it may be useful in environments that require restrictions to outbound network connections. For example, this list may be used to configure firewalls that sit in front of Teleport Agents, when those firewalls block access to the public internet by default. - + Note that IP addresses may be added or removed from the above list over time. - + When this list is modified, we will provide at least two weeks notice by: 1. Updating the Changelog below. @@ -42,9 +42,9 @@ When this list is modified, we will provide at least two weeks notice by: 1. Providing a [Status Page](https://status.teleport.sh/) update. 1. Reaching out directly to Enterprise customers that have requested advanced notice. - + If you are Teleport Enterprise customer and plan to employ this allowlist, please let us know by opening a support ticket. - + Additionally, to receive Teleport agent updates, nodes must be able to reach the following domains via HTTPS during the update. diff --git a/docs/pages/reference/architecture/authentication.mdx b/docs/pages/reference/architecture/authentication.mdx index 313cdbf9cfe14..1abee0d4680cf 100644 --- a/docs/pages/reference/architecture/authentication.mdx +++ b/docs/pages/reference/architecture/authentication.mdx @@ -34,14 +34,14 @@ untrusted certificate authority. if the certificate has been signed with a valid certificate authority, and does not need to copy user credentials over to every service. - + Teleport issues certificates that are good from a few hours to minutes before they auto-expire without any action. The shorter the duration for these certificates, the better. Ideally, certs should be issued only for the duration of a session. In practice, several hours or the duration of the workday are OK too. The expiry date in certificates can not be forged without invalidating the certificates, so any system can validate the certificate. - + ### X.509 certificates @@ -102,11 +102,11 @@ X.509 certificates issued by Teleport and used for Kubernetes, Databases, Web Ap Teleport issues certificates that are good from a few hours to minutes before they auto-expire without any action. Instead of distributing revocation lists, Teleport relies on time to do the job for us. - + In some cases, certificate expiration is not fast enough, and all sessions have to be terminated immediately, for example during active security incident. For those cases, Teleport Proxy can terminate live connections using [session and identity locking](../../admin-guides/access-controls/guides/locking.mdx). - + ### Short-lived Certs For Users @@ -153,10 +153,10 @@ using a new certificate authority. Take a look at the [Certificate Rotation Guide](../../admin-guides/management/operations/ca-rotation.mdx) to learn how to do certificate rotation in practice. - + To quickly lock out the node, proxy or auth service that may be compromised without rotating the entire cluster certificates, use node [session and identity locking](../../admin-guides/access-controls/guides/locking.mdx). - + ## More concepts diff --git a/docs/pages/reference/architecture/authorization.mdx b/docs/pages/reference/architecture/authorization.mdx index 6fd5e012a9b63..52f5ce54f1203 100644 --- a/docs/pages/reference/architecture/authorization.mdx +++ b/docs/pages/reference/architecture/authorization.mdx @@ -33,12 +33,12 @@ with Teleport: ![Role mapping](../../../img/architecture/role-mapping@1.5x.svg) - + Every time SSO user logs in, Teleport creates a temporary user account record that automatically expires with SSO session and logs audit log entries. Teleport creates this record to avoid name collisions with local users. - + #### External users from other clusters @@ -228,10 +228,10 @@ spec: kubernetes_groups: ['{{external.groups}}'] ``` - + Any role that uses variable interpolation is treated as a role template. You can add interpolation to any role spec. - + **Variable interpolation rules* @@ -321,9 +321,9 @@ spec: where: contains(session.participants, user.metadata.name) ``` - + You can use `where` fields in all resource rules. Check out [the full role reference](../access-controls/roles.mdx) contains full role spec for details. - + ### Role options @@ -355,12 +355,12 @@ options, Teleport will choose `strict` option. ### Just in Time Access Requests - + The full version of Just In Time Access Requests is available only in Teleport Enterprise (including Enterprise Cloud). - + Roles allow requesting elevated privileges - other roles or individual resources. diff --git a/docs/pages/reference/architecture/proxy.mdx b/docs/pages/reference/architecture/proxy.mdx index 8436ea15133f8..edfb17dc62989 100644 --- a/docs/pages/reference/architecture/proxy.mdx +++ b/docs/pages/reference/architecture/proxy.mdx @@ -21,11 +21,11 @@ provides the following key features: ![Proxy service](../../../img/architecture/proxy.png) - + To create a minimal Teleport cluster, you have run two services: Teleport Auth Service and Teleport Proxy Service. For your home lab, you can run both services as a one binary and process. - + ## Web UI @@ -65,10 +65,10 @@ In the example below, Alice connects to kubernetes cluster behind firewall via t ![Teleport Proxy Tunnel](../../../img/architecture/proxy-tunnel@1.2x.png) - + All modes above are turned on by default in Proxies. No special configuration is necessary, unless you want to turn some of those modes off. - + ## More concepts diff --git a/docs/pages/reference/architecture/trustedclusters.mdx b/docs/pages/reference/architecture/trustedclusters.mdx index ee6cd43b4dbe2..3aee77e05129b 100644 --- a/docs/pages/reference/architecture/trustedclusters.mdx +++ b/docs/pages/reference/architecture/trustedclusters.mdx @@ -18,11 +18,11 @@ Uses for Trusted Clusters include: - Device manufacturers remotely maintaining computing appliances deployed on premises. - Large cloud software vendors managing multiple data centers. - + Individual nodes and proxies can create reverse tunnels to proxy services without creating a new cluster. You don't need to set up a trusted cluster just to connect a couple of servers, Kubernetes clusters or databases behind a firewall. - + ## Multi-Data-center Clusters diff --git a/docs/pages/reference/backends.mdx b/docs/pages/reference/backends.mdx index 9022bca0af1a9..3e246b94facba 100644 --- a/docs/pages/reference/backends.mdx +++ b/docs/pages/reference/backends.mdx @@ -855,7 +855,7 @@ To configure Teleport to use DynamoDB: - Make sure that all Teleport resource services have the `auth_servers` configuration setting populated with the addresses of your cluster's Auth Service instances. - + AWS can throttle DynamoDB if more than two processes are reading from the same stream's shard simultaneously, so you must not deploy more than two Auth Service @@ -863,7 +863,7 @@ instances that read from a DynamoDB backend. For details on DynamoDB Streams, read the [AWS documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html). - + ```yaml teleport: diff --git a/docs/pages/reference/cli/teleport.mdx b/docs/pages/reference/cli/teleport.mdx index 8e97e813deb40..baa8f87808d6e 100644 --- a/docs/pages/reference/cli/teleport.mdx +++ b/docs/pages/reference/cli/teleport.mdx @@ -36,9 +36,9 @@ The primary commands for the `teleport` CLI are as follows: | `teleport debug get-log-level` | Fetches instance current log level. | | `teleport debug debug profile` | Export the application profiles (pprof format). | - + For more information on subcommands when working with the `teleport` cli, use the `--help` option or `teleport --help`. - + ## teleport start @@ -86,13 +86,13 @@ The `--roles` flag when used with `teleport --start` instructs Teleport on which | [App](../../enroll-resources/application-access/introduction.mdx) | `app` | Provides access to applications. | | [Database](../agent-services/database-access-reference/database-access-reference.mdx) | `db` | Provides access to databases. | - + Teleport Cloud manages Teleport instances with the `auth` and `proxy` roles. Use the remaining roles to manage access to specific resources and other Teleport clusters. - + ### Examples diff --git a/docs/pages/reference/cli/tsh.mdx b/docs/pages/reference/cli/tsh.mdx index dac5863a853f6..37dfcfb59ffdd 100644 --- a/docs/pages/reference/cli/tsh.mdx +++ b/docs/pages/reference/cli/tsh.mdx @@ -632,13 +632,13 @@ commands for environment variables required to connect: (!docs/pages/includes/application-access/azure-tsh-proxy-azure-sample.mdx!) - + `tsh proxy azure` runs the local proxy in the foreground, so don't interrupt the process or exit the terminal where you ran the command until you're ready to close the local proxy. - + Copy the `export` commands and paste them into a second terminal. diff --git a/docs/pages/reference/config.mdx b/docs/pages/reference/config.mdx index 5f6f83b21cc14..577d02d2b2281 100644 --- a/docs/pages/reference/config.mdx +++ b/docs/pages/reference/config.mdx @@ -14,11 +14,11 @@ By default, Teleport reads its configuration from `/etc/teleport.yaml`. ## Before using this reference - + Do not use this example configuration in production. - + You must edit your configuration file to meet the needs of your environment. Using a copy of the reference configuration will have unintended effects. To @@ -33,12 +33,12 @@ There are also `configure` commands available for the SSH Service and Database Service. See our documentation on `teleport node configure` and `teleport db configure` in the [Teleport CLI Reference](cli/teleport.mdx). - + You should back up your configuration file before making changes. This will enable you to roll back to the previous configuration if you need to. - + ## Enabling Teleport services @@ -112,10 +112,10 @@ Further reading: These settings apply to the Teleport Proxy Service: - + Teleport Enterprise Cloud manages the Proxy Service for you, so you do not need to specify these configuration settings. - + ```yaml (!docs/pages/includes/config-reference/proxy-service.yaml!) @@ -125,10 +125,10 @@ to specify these configuration settings. These settings apply to the Teleport Auth Service: - + Teleport Enterprise Cloud manages the Auth Service for you, so you do not need to specify these configuration settings. - + ```yaml (!docs/pages/includes/config-reference/auth-service.yaml!) diff --git a/docs/pages/reference/helm-reference/teleport-cluster.mdx b/docs/pages/reference/helm-reference/teleport-cluster.mdx index e852ca2cff451..945e9296cda72 100644 --- a/docs/pages/reference/helm-reference/teleport-cluster.mdx +++ b/docs/pages/reference/helm-reference/teleport-cluster.mdx @@ -1519,9 +1519,9 @@ You should create the secret in the same namespace as Teleport using a command l kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem ``` - + The filename used for the root CA in the secret must be `ca.pem`. - + `values.yaml` example: diff --git a/docs/pages/reference/join-methods.mdx b/docs/pages/reference/join-methods.mdx index 75e0323337473..dbf67657eef38 100644 --- a/docs/pages/reference/join-methods.mdx +++ b/docs/pages/reference/join-methods.mdx @@ -284,13 +284,13 @@ IAM credentials with `ec2:DescribeInstances` permissions are required on your Teleport Auth Service. No IAM credentials are required on the Teleport processes joining the cluster. - + The EC2 join method is not available in Teleport Enterprise Cloud and Teleport Team. Teleport Enterprise Cloud and Team customers can use the [IAM join method](#aws-iam-role-iam) or [ephemeral secret tokens](#ephemeral-tokens). - + (!docs/pages/includes/provision-token/ec2-spec.mdx!) diff --git a/docs/pages/reference/monitoring/audit.mdx b/docs/pages/reference/monitoring/audit.mdx index bbc6295d0f6d6..775f1c5d9746b 100644 --- a/docs/pages/reference/monitoring/audit.mdx +++ b/docs/pages/reference/monitoring/audit.mdx @@ -27,13 +27,13 @@ There are two components of the audit log: - + You can use [Enhanced Session Recording with BPF](../../enroll-resources/server-access/guides/bpf-session-recording.mdx) to get even more comprehensive audit logs with advanced security. - + ## Events @@ -124,14 +124,14 @@ format: Below are some possible types of audit events. - + This list is not comprehensive. We recommend exporting audit events to a platform that automatically parses event payloads so you can group and filter them by their `event` key and discover trends. To set up audit event exporting, read [Exporting Teleport Audit Events](../../admin-guides/management/export-audit-events/export-audit-events.mdx). - + | Event Type | Description | | - | - | @@ -207,10 +207,10 @@ $ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931 --format=json ### Modes - + Available only for SSH sessions and when Teleport is configured with `auth_service.session_recording: node`. - + Modes define how Teleport deals with recording failures, such as a full disk error. They are configured per-service at the role level, where the strictest diff --git a/docs/pages/reference/monitoring/metrics.mdx b/docs/pages/reference/monitoring/metrics.mdx index 58d034a0c91f5..e0587f820621b 100644 --- a/docs/pages/reference/monitoring/metrics.mdx +++ b/docs/pages/reference/monitoring/metrics.mdx @@ -3,11 +3,11 @@ title: Teleport Metrics description: Comprehensive list of all metrics exposed by Teleport. --- - + Teleport Cloud does not expose monitoring endpoints for the Auth Service and Proxy Service. - + Teleport metrics are intended for performance monitoring. If you'd like to monitor Teleport usage, consider utilizing our Event Handler plugin to push Audit Events into your diff --git a/docs/pages/reference/resources.mdx b/docs/pages/reference/resources.mdx index 83fad09230033..4ee51603b6bcc 100644 --- a/docs/pages/reference/resources.mdx +++ b/docs/pages/reference/resources.mdx @@ -335,3 +335,4 @@ Find out more on the [Machine ID configuration reference](machine-id/configuration.mdx). (!docs/pages/includes/machine-id/bot-spec.mdx!) + diff --git a/examples/chart/teleport-kube-agent/values.yaml b/examples/chart/teleport-kube-agent/values.yaml index 56c014ef7776b..81c131c7a79d2 100644 --- a/examples/chart/teleport-kube-agent/values.yaml +++ b/examples/chart/teleport-kube-agent/values.yaml @@ -559,9 +559,9 @@ tls: # $ kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem # ``` # - # + # # The key containing the root CA in the secret must be `ca.pem`. - # + # existingCASecretName: "" # updater -- controls whether the Kube Agent Updater should be deployed alongside