diff --git a/docs/pages/admin-guides/access-controls/access-monitoring.mdx b/docs/pages/admin-guides/access-controls/access-monitoring.mdx index 00cd0276cf9dc..3e7a972cf5140 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/opsgenie.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx index 0492e31ce28c1..3eaeff64d4b60 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 4dc9b33dd208b..6ea01b5406d61 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 7a663217f3cbf..7e23b5d41188d 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 a18e327bd5736..97aafd6f1dd5c 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 @@ -238,11 +238,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 7/8. 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/device-trust.mdx b/docs/pages/admin-guides/access-controls/device-trust/device-trust.mdx index a40575c2d0d94..c0e8a8f4bff59 100644 --- a/docs/pages/admin-guides/access-controls/device-trust/device-trust.mdx +++ b/docs/pages/admin-guides/access-controls/device-trust/device-trust.mdx @@ -5,7 +5,7 @@ layout: tocless-doc videoBanner: gBQyj_X1LVw --- - + Device Trust supports the following components: - User devices: macOS, Windows and Linux. 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 e95ca97431395..cf5b4bc5fe09a 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. Apps may enforce trusted devices using role-based enforcement. See the [App diff --git a/docs/pages/admin-guides/access-controls/device-trust/guide.mdx b/docs/pages/admin-guides/access-controls/device-trust/guide.mdx index 1284829c18ddd..ad67ccc8721be 100644 --- a/docs/pages/admin-guides/access-controls/device-trust/guide.mdx +++ b/docs/pages/admin-guides/access-controls/device-trust/guide.mdx @@ -4,7 +4,7 @@ description: Get started with Teleport Device Trust videoBanner: gBQyj_X1LVw --- - + Device Trust supports the following components: - User devices: macOS, Windows and Linux. 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 100bcf9e590f6..ebd45e95a4a8b 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 bda110868e958..230fe73bcf2f7 100644 --- a/docs/pages/admin-guides/access-controls/guides/headless.mdx +++ b/docs/pages/admin-guides/access-controls/guides/headless.mdx @@ -163,7 +163,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. @@ -173,7 +173,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 @@ -191,9 +191,9 @@ You will be prompted to tap your MFA key to complete the approval process. ![Headless WebAuthn Approval](../../../../img/headless/approval.png) - + This also requires a v13.3.1+ Teleport Auth Service. - + ## Troubleshooting 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 a3cab5e3e3b5b..36d6e2c90cf9b 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. - + 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 7a4e3b0fd56c8..e8c4da1b926de 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 @@ -15,12 +15,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/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 158d3cd4bf387..6812bb59e7d2a 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 @@ -36,11 +36,11 @@ to Teleport Enterprise customers. ``` - 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 Teleport 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 the Teleport Access Graph service 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/deploy-a-cluster/migrate-to-cloud.mdx b/docs/pages/admin-guides/deploy-a-cluster/migrate-to-cloud.mdx index 2f1ff314c8a82..f5c68baeff3f8 100644 --- a/docs/pages/admin-guides/deploy-a-cluster/migrate-to-cloud.mdx +++ b/docs/pages/admin-guides/deploy-a-cluster/migrate-to-cloud.mdx @@ -88,7 +88,7 @@ credentials. website](https://status.teleport.sh/) to stay current on any issues impacting the performance of your cloud-hosted cluster. - @@ -97,7 +97,7 @@ credentials. access. For your security, Teleport Support cannot assist with resetting passwords or recovering lost credentials. - + ## Step 2/4. Migrate Teleport resources 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 ffdbb78f2eacc..0b38a1eab42d8 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 @@ -241,13 +241,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/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 2c7d4d89d52e2..193771545d311 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 2a22c219cc523..bb3fe11fbd21d 100644 --- a/docs/pages/admin-guides/management/admin/troubleshooting.mdx +++ b/docs/pages/admin-guides/management/admin/troubleshooting.mdx @@ -47,13 +47,13 @@ Debug logs include the file and line number of the code that emitted the log, so you can investigate (or report) what a `teleport` process was doing before it ran into problems. - 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 @@ -92,11 +92,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 1c02f24edfd5d..bd3f70723a9c6 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 @@ -135,7 +135,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. @@ -155,7 +155,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. @@ -170,7 +170,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 @@ -194,7 +194,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. @@ -221,7 +221,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/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 31d857d523724..d1ce2b4d54cc8 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 36aedd0e0218c..8fc4906656a78 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/operations/ca-rotation.mdx b/docs/pages/admin-guides/management/operations/ca-rotation.mdx index 303dedcedcd80..2fcce0232e943 100644 --- a/docs/pages/admin-guides/management/operations/ca-rotation.mdx +++ b/docs/pages/admin-guides/management/operations/ca-rotation.mdx @@ -276,9 +276,9 @@ period so that it spends an equal amount of time in each phase before transitioning to the next phase. This means that using a shorter grace period will result in faster state transitions. - + Be careful when choosing a grace period when rotating host certificates. - + The grace period needs to be long enough for all nodes in a cluster to request a new certificate. If some nodes go offline during the rotation and come back only diff --git a/docs/pages/admin-guides/management/security/proxy-protocol.mdx b/docs/pages/admin-guides/management/security/proxy-protocol.mdx index 3dfe933fafed4..757642bf381a4 100644 --- a/docs/pages/admin-guides/management/security/proxy-protocol.mdx +++ b/docs/pages/admin-guides/management/security/proxy-protocol.mdx @@ -85,4 +85,4 @@ You can also have Teleport Proxies have different PROXY protocol settings, if yo example if you have dedicated Proxies for private and public networks. Running Teleport behind a L4 load balancer that doesn't send PROXY protocol headers will lead to all incoming connections seemingly -coming from the same IP address from Teleport's point of view, making the audit trail less useful and the IP pinning feature not helpful. \ No newline at end of file +coming from the same IP address from Teleport's point of view, making the audit trail less useful and the IP pinning feature not helpful. 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 e6753c73df5ec..d160496f2b189 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 da9b9e7feff9b..9e4c2d283982e 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 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 4609e07be3c6d..58fb8bb93a49e 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 @@ -173,10 +173,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/ai-assist.mdx b/docs/pages/ai-assist.mdx index b7eb60bc754ed..5bf2e055f4bad 100644 --- a/docs/pages/ai-assist.mdx +++ b/docs/pages/ai-assist.mdx @@ -58,10 +58,10 @@ chmod 400 /etc/teleport/openai_key chown teleport:teleport /etc/teleport/openai_key ``` - + Remember, your API keys carry many privileges, so be sure to keep them secure! Do not share your secret API keys in publicly accessible areas. - + ## Step 2/3. Enable Assist diff --git a/docs/pages/connect-your-client/gui-clients.mdx b/docs/pages/connect-your-client/gui-clients.mdx index 500058c814509..b3559603c03a1 100644 --- a/docs/pages/connect-your-client/gui-clients.mdx +++ b/docs/pages/connect-your-client/gui-clients.mdx @@ -532,12 +532,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 bd93e237713ea..6de17a39f0bce 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/deploy-agents-terraform.mdx b/docs/pages/enroll-resources/agents/deploy-agents-terraform.mdx index e2cd4ce83a9ba..8ad4c4b1acf7e 100644 --- a/docs/pages/enroll-resources/agents/deploy-agents-terraform.mdx +++ b/docs/pages/enroll-resources/agents/deploy-agents-terraform.mdx @@ -70,12 +70,12 @@ a demo cluster using: directory so the Terraform provider can access it. Name the file `terraform-identity`. - + If you don't have an identity file available, make sure you have followed the [prerequisites for this guide](#prerequisites). - + 1. Fetch the Teleport code repository and copy the example Terraform configuration for this project into your current working directory. Copy @@ -223,11 +223,11 @@ Edit the `module "teleport"` block in `main.tf` as follows: 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/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 f94d14b26e537..f9b6c53030741 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 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: @@ -164,13 +164,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. - +
@@ -180,13 +180,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 @@ -216,12 +216,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/databases.mdx b/docs/pages/enroll-resources/auto-discovery/databases/databases.mdx index 551bbb0594130..a429267cc1795 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 04eda10ea0a1d..38b65ca7b12c8 100644 --- a/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx +++ b/docs/pages/enroll-resources/auto-discovery/kubernetes/aws.mdx @@ -69,12 +69,12 @@ Update `Resource` entries to match your AWS account's EKS resources, which have ## 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 @@ -228,11 +228,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. - + @@ -296,11 +296,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 b4928be579ffe..9135b4dc59cf4 100644 --- a/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx +++ b/docs/pages/enroll-resources/auto-discovery/kubernetes/google-cloud.mdx @@ -205,13 +205,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 2f24fa39bd08b..286293de746a1 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 2ac82e8ac0685..7b82f0a19b298 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 15a3d9ece0f22..56ecb2ed42af3 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 42c1fae5c67c2..2a67e9d1234ab 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 f987c4de96e33..3aeac09b49a02 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, @@ -429,13 +429,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 fdc3bb612fe1f..3cf2008a612b8 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 f2e1b91c7b32c..f4f149863b851 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 bf101104d1170..763f0321a010f 100644 --- a/docs/pages/enroll-resources/machine-id/troubleshooting.mdx +++ b/docs/pages/enroll-resources/machine-id/troubleshooting.mdx @@ -271,7 +271,7 @@ $ nano db-role.yaml $ tctl create -f db-role.yaml ``` - + 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`. @@ -279,7 +279,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/includes/application-access/azure-teleport-role.mdx b/docs/pages/includes/application-access/azure-teleport-role.mdx index dd57dfd0c8cf8..59fdd75a1ecb8 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/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 56ad39b702e47..bc21ca997de5e 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 @@ -578,9 +578,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 cd65931308807..5e401a41a1af2 100644 --- a/docs/pages/installation.mdx +++ b/docs/pages/installation.mdx @@ -786,13 +786,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/reference/architecture/authentication.mdx b/docs/pages/reference/architecture/authentication.mdx index 67787df9179a3..17c9e0d435ed5 100644 --- a/docs/pages/reference/architecture/authentication.mdx +++ b/docs/pages/reference/architecture/authentication.mdx @@ -35,14 +35,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 @@ -103,11 +103,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 @@ -154,10 +154,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 a432b7c8d108b..9fd7cf511e4d0 100644 --- a/docs/pages/reference/architecture/authorization.mdx +++ b/docs/pages/reference/architecture/authorization.mdx @@ -35,12 +35,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 @@ -230,10 +230,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* @@ -323,9 +323,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 @@ -357,12 +357,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 c86865390765e..f39ef6b5dea70 100644 --- a/docs/pages/reference/architecture/proxy.mdx +++ b/docs/pages/reference/architecture/proxy.mdx @@ -19,11 +19,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 @@ -63,10 +63,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 57f9b8c719cf9..4e8ee4e58deae 100644 --- a/docs/pages/reference/architecture/trustedclusters.mdx +++ b/docs/pages/reference/architecture/trustedclusters.mdx @@ -20,11 +20,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 9dfc904f86f1a..97892e44632d0 100644 --- a/docs/pages/reference/backends.mdx +++ b/docs/pages/reference/backends.mdx @@ -837,7 +837,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 @@ -845,7 +845,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 b9d61dac9c92f..58b5505feb401 100644 --- a/docs/pages/reference/cli/teleport.mdx +++ b/docs/pages/reference/cli/teleport.mdx @@ -33,9 +33,9 @@ The primary commands for the `teleport` CLI are as follows: | `teleport status` | Prints the status of the current active Teleport SSH session. | | `teleport version` | Prints the current release version of the Teleport binary installed on your system. | - + For more information on subcommands when working with the `teleport` cli, use the `--help` option or `teleport --help`. - + ## teleport start @@ -83,13 +83,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 d0ba638148800..7a04b4c3b4595 100644 --- a/docs/pages/reference/cli/tsh.mdx +++ b/docs/pages/reference/cli/tsh.mdx @@ -624,13 +624,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 3e8406d010f2f..5d644b13d8553 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 @@ -102,10 +102,10 @@ These settings apply to any `teleport` instance: 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!) @@ -115,10 +115,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 bd76d4c62112c..74436ccb9b51e 100644 --- a/docs/pages/reference/helm-reference/teleport-cluster.mdx +++ b/docs/pages/reference/helm-reference/teleport-cluster.mdx @@ -1509,9 +1509,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 ff4857a65ed6b..b944ed41fec9a 100644 --- a/docs/pages/reference/join-methods.mdx +++ b/docs/pages/reference/join-methods.mdx @@ -283,13 +283,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 cac72c635739a..2df09c3615a6f 100644 --- a/docs/pages/reference/resources.mdx +++ b/docs/pages/reference/resources.mdx @@ -310,3 +310,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 5962057fc99fc..9963e67d68fb9 100644 --- a/examples/chart/teleport-kube-agent/values.yaml +++ b/examples/chart/teleport-kube-agent/values.yaml @@ -503,9 +503,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