Fix Vale warnings

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

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.
 
 <Admonition title="Auditing Access Requests">

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.
 

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 <id>`.
@@ -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
+- Request access to [specific resources](./resource-requests.mdx) with Teleport Enterprise

docs/pages/admin-guides/access-controls/access-requests/role-requests.mdx

@@ -75,15 +75,15 @@ spec:
 <Admonition type="warning" title="Requires Teleport Enterprise">
 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.
 </Admonition>
 
 ## Requesting Access
 
 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 <request-id>
 ```
 
-## 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.
 

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.

docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx

@@ -5,12 +5,12 @@ videoBanner: gBQyj_X1LVw
 ---
 
 <Admonition type="notice" title="Supported Resources">
-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.
 
 </Admonition>
 
@@ -138,7 +138,7 @@ cluster. Likewise, a root cluster will not enforce Device Trust on resources in
 leaf clusters.
 </Admonition>
 
-## 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).

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
 <Admonition type="tip">
   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.
 </Admonition>
 

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:
 

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.
+client and protocol outside of the Teleport cluster auditing system to access additional systems.