diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/servicenow.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/servicenow.mdx index 2d5921f0cf289..fde2569c4dfb3 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/servicenow.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/servicenow.mdx @@ -34,7 +34,7 @@ The Teleport ServiceNow plugin works by receiving Access Request events from the Teleport Auth Service and, based on these events, interacting with the ServiceNow API. -Before making the access request ensure the user making the request has +Before making the Access Request ensure the user making the request has the `requester` role. For the plugin to know which ServiceNow rotations to check for the diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-discord.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-discord.mdx index 1ca3df2e0856b..f91873cbb2301 100644 --- a/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-discord.mdx +++ b/docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-discord.mdx @@ -326,7 +326,7 @@ Web UI and either approve or deny the request. (!docs/pages/includes/plugins/resolve-request.mdx!) -Once the request is resolved, the Discord bot will update the access request +Once the request is resolved, the Discord bot will update the Access Request message with ✅ or ❌, depending on whether the request was approved or denied. 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 dd10deccc0066..74e3d25add023 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 @@ -3,9 +3,9 @@ title: Run the Mattermost Access Request plugin description: How to set up Teleport's Mattermost plugin for privilege elevation approvals. --- -This guide explains how to integrate Teleport access requests with Mattermost, an open +This guide explains how to integrate Teleport Access Requests with Mattermost, an open source messaging platform. The Teleport Mattermost plugin notifies individuals of -access requests. Users can then approve and deny access requests by following the +Access Requests. Users can then approve and deny Access Requests by following the message link, making it easier to implement security best practices without compromising productivity. diff --git a/docs/pages/admin-guides/access-controls/access-requests/oss-role-requests.mdx b/docs/pages/admin-guides/access-controls/access-requests/oss-role-requests.mdx index cd364ddc76544..b82cc5e9aae39 100644 --- a/docs/pages/admin-guides/access-controls/access-requests/oss-role-requests.mdx +++ b/docs/pages/admin-guides/access-controls/access-requests/oss-role-requests.mdx @@ -20,7 +20,7 @@ users can request access to. In this example, we will define two roles: There is no role for request approvers, because request approval rules can only be configured for Teleport Enterprise. In Teleport Community Edition, approvals must -be performed by running `tctl` on the Auth Server. +be performed by running `tctl` on an Auth Service instance. **Contractor role** @@ -89,7 +89,7 @@ $ tsh request create \ By default, this command will block until the request is approved. To submit the request without waiting for approval, add the `--nowait` flag. -Alternatively, `tsh` can automatically create an access request during the login +Alternatively, `tsh` can automatically create an Access Request during the login process. To activate this behavior, specify the `--request-roles` flag: ```code @@ -121,7 +121,7 @@ $ tsh request ls ## Reviewing requests In Teleport Community Edition, Access Requests must be reviewed by a cluster administrator -with the ability to run `tctl` on the Auth Server. +with the ability to run `tctl` on the Auth Service. Administrators can list requests with `tctl requests ls`, and view the details of a particular request with `tctl requests get `. @@ -156,4 +156,4 @@ $ tctl request approve \ - Learn more about [Access Requests](access-requests.mdx) - See what additional features are available for [role requests](./role-requests.mdx) in Teleport Enterprise -- Request access to [specific resources](./resource-requests.mdx) with Teleport Enterprise \ No newline at end of file +- Request access to [specific resources](./resource-requests.mdx) with Teleport Enterprise diff --git a/docs/pages/admin-guides/access-controls/access-requests/role-requests.mdx b/docs/pages/admin-guides/access-controls/access-requests/role-requests.mdx index e1782f1ea8492..8244c400d9a57 100644 --- a/docs/pages/admin-guides/access-controls/access-requests/role-requests.mdx +++ b/docs/pages/admin-guides/access-controls/access-requests/role-requests.mdx @@ -75,7 +75,7 @@ spec: Roles containing a `review_requests` rule can only be used in Teleport Enterprise. In Teleport Community Edition, Access Requests must be approved by an admin -running `tctl` on the Auth Server. +running `tctl` on the Auth Service. ## Requesting Access @@ -83,7 +83,7 @@ running `tctl` on the Auth Server. While Teleport Enterprise supports the same CLI-based workflows for requesting access to roles, most users will prefer to request access via the web UI. -To request access to one or more roles, navigate to the access requests page. +To request access to one or more roles, navigate to the Access Requests page. You can find this page by selecting **Resources** on the side bar, expanding the *Access Requests* menu, and selecting **New Request**. @@ -126,7 +126,7 @@ with the `tsh` command line: $ tsh request review --approve ``` -## Using an approved access request +## Using an approved Access Request Once a request has been approved, the requestor can elevate their access for both command-line workflows and web UI workflows. @@ -140,10 +140,10 @@ $ tsh login --request-id=bc8ca931-fec9-4b15-9a6f-20c13c5641a9 In the web UI, the requestor can open their request on the **Review Requests** page and click **ASSUME ROLES** to gain access to additional roles. Note: -role-based access requests are additive. The user will have access to their +role-based Access Requests are additive. The user will have access to their standard role set in addition to the roles granted by the request. -A banner will appear at the top of the page while the approved access request is +A banner will appear at the top of the page while the approved Access Request is active. When elevated access is no longer necessary, click **Switch Back** to revert to the original set of roles. 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 30ccd62349073..dafb8c7683e16 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 @@ -69,7 +69,7 @@ the better the ongoing guarantees that the device itself is trustworthy. ## Device Trust enforcement -Enforcing Device Trust means configuring Teleport with device trust mode, i.e. applying +Enforcing Device Trust means configuring Teleport with Device Trust mode, i.e. applying `device_trust_mode: required` rule, which tells Teleport Auth Service to only allow access with a trusted and an authenticated device, in addition to establishing the user's identity and enforcing the necessary roles. 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 9ac5c819060c2..8af52c34b6786 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 @@ -5,12 +5,12 @@ videoBanner: gBQyj_X1LVw --- -Device trust fully supports SSH, Database and Kubernetes resources using +Device Trust fully supports SSH, database and Kubernetes resources using cluster-wide or role-based enforcement. -Apps and Desktops may enforce trusted devices using role-based enforcement. See the [App -Access support](#app-access-support) and the [Desktop Access support](#desktop-access-support) -sections for further details. +Apps and Desktops may enforce trusted devices using role-based enforcement. See +the [web application support ](#web-application-support) and [desktop +support](#desktop-support) sections for further details. @@ -138,7 +138,7 @@ cluster. Likewise, a root cluster will not enforce Device Trust on resources in leaf clusters. -## App Access support +## Web application support The Teleport App Service may enforce Device Trust via [role-based enforcement]( #role-based-trusted-device-enforcement). @@ -190,7 +190,7 @@ version: v2 Now the alice user can only access `env:production` apps using a trusted device. -## Desktop Access support +## Desktop support The Teleport Desktop Service may enforce Device Trust via [role-based enforcement]( #role-based-trusted-device-enforcement). diff --git a/docs/pages/admin-guides/infrastructure-as-code/managing-resources/agentless-ssh-servers.mdx b/docs/pages/admin-guides/infrastructure-as-code/managing-resources/agentless-ssh-servers.mdx index b64234da193f4..4a5dd53e3a484 100644 --- a/docs/pages/admin-guides/infrastructure-as-code/managing-resources/agentless-ssh-servers.mdx +++ b/docs/pages/admin-guides/infrastructure-as-code/managing-resources/agentless-ssh-servers.mdx @@ -54,8 +54,8 @@ A functional Teleport Terraform provider by following [the Terraform provider gu If you want to add a private SSH server (e.g. behind a NAT, in a private network, protected by a firewall blocking inbound traffic, ...) you can - [install a Teleport agent](../../../enroll-resources/server-access/getting-started.mdx). The - Teleport agent opens a tunnel to the Teleport Proxy Service, allowing any user + [install a Teleport Agent](../../../enroll-resources/server-access/getting-started.mdx). The + Teleport Agent opens a tunnel to the Teleport Proxy Service, allowing any user to connect to it by going through the Proxy Service. diff --git a/docs/pages/admin-guides/infrastructure-as-code/terraform-provider/dedicated-server.mdx b/docs/pages/admin-guides/infrastructure-as-code/terraform-provider/dedicated-server.mdx index 121ed798ad5b9..36abccdac622d 100644 --- a/docs/pages/admin-guides/infrastructure-as-code/terraform-provider/dedicated-server.mdx +++ b/docs/pages/admin-guides/infrastructure-as-code/terraform-provider/dedicated-server.mdx @@ -87,7 +87,7 @@ Terraform plan later. You should now see an `identity` file under `/opt/machine-id`. This contains the private key and signed certificates needed by the Terraform provider to -authenticate with the Teleport Auth Server. +authenticate with the Teleport Auth Service. ## Step 4/4. Run Terraform @@ -137,9 +137,9 @@ resource "teleport_role" "terraform-test" { } ``` -Replace `teleport.example.com:443` with the address of your Teleport Proxy or -Auth Server. If you modified the destination directory from `/opt/machine-id`, -then this should also be replaced. +Replace `teleport.example.com:443` with the address of your Teleport Proxy +Service or Auth Service. If you modified the destination directory from +`/opt/machine-id`, then this should also be replaced. Now, execute Terraform to test the configuration: diff --git a/docs/pages/admin-guides/management/security/restrict-privileges.mdx b/docs/pages/admin-guides/management/security/restrict-privileges.mdx index 2aa37cea8fd94..006306224cce1 100644 --- a/docs/pages/admin-guides/management/security/restrict-privileges.mdx +++ b/docs/pages/admin-guides/management/security/restrict-privileges.mdx @@ -45,7 +45,7 @@ To prevent elevated privileges from resulting in security incidents, you should following guidelines: - Create new, non-root, users and use test instances for experimenting with Teleport. -- Run all Teleport agent services except the SSH Service as a non-root user. +- Run all Teleport Agent services except the SSH Service as a non-root user. The SSH Service requires root access, so you should limit access to the SSH Service. The Teleport Proxy Service must also have root permission—or the `CAP_NET_BIND_SERVICE` capability—to allow Teleport listen on any port number less than 1024, including port 443. @@ -67,4 +67,4 @@ secured so the data can't be tampered with. For more information about managing Teleport doesn't provide network restrictions. For example, you need to consider if port forwarding should be allowed, and if it is, which roles allow it and what resources can be accessed. You want to prevent a condition where a user establishes network access through Teleport, then uses another -client and protocol outside of the Teleport cluster auditing system to access additional systems. \ No newline at end of file +client and protocol outside of the Teleport cluster auditing system to access additional systems.