Fix Vale warnings

CHANGELOG.md

@@ -1231,9 +1231,6 @@ The “teleport-cluster” Helm chart underwent significant refactoring in Telep
 deployments and the new “scratch” chart mode makes it easier to provide a custom
 Teleport config.
 
-“Custom” mode users should follow the [migration
-guide](docs/pages/admin-guides/deploy-a-cluster/helm-deployments/migration-v12.mdx).
-
 ### Dropped support for SHA1 in Teleport-protected servers
 
 Newer OpenSSH clients connecting to Teleport 12 clusters no longer need the
@@ -1256,10 +1253,7 @@ Teleport 12 before upgrading.
 
 #### Helm charts
 
-The teleport-cluster Helm chart underwent significant changes in Teleport 12. To
-upgrade from an older version of the Helm chart deployed in “custom” mode,
-follow
-the [migration guide](docs/pages/admin-guides/deploy-a-cluster/helm-deployments/migration-v12.mdx).
+The teleport-cluster Helm chart underwent significant changes in Teleport 12.
 
 Additionally, PSPs are removed from the chart when installing on Kubernetes 1.23
 and higher to account for the deprecation/removal of PSPs by Kubernetes.

docs/pages/admin-guides/access-controls/access-lists/access-lists.mdx

@@ -5,7 +5,7 @@ layout: tocless-doc
 ---
 
 Access Lists allow Teleport users to be granted long term access to resources
-managed within Teleport. With Access Lists, administrators and access list
+managed within Teleport. With Access Lists, administrators and Access List
 owners can regularly audit and control membership to specific roles and
 traits, which then tie easily back into Teleport's existing RBAC system.
 

docs/pages/admin-guides/access-controls/access-lists/guide.mdx

@@ -4,7 +4,7 @@ description: Learn how to use Access Lists to manage and audit long lived access
 ---
 
 This guide will help you:
-- Create an access list
+- Create an Access List
 - Assign a member to it
 - Verify permissions granted through the list membership
 
@@ -47,7 +47,7 @@ Try logging into the cluster with the test user to verify that no resources show
 
 ## Step 3/4. Create an Access List
 
-Next, we'll create a simple access list that will grant the `access` role to its members.
+Next, we'll create a simple Access List that will grant the `access` role to its members.
 Login as the administrative user mentioned in the prerequisites. Click on "Add New" in the left pane, and then "Create an Access List."
 
 ![Navigate to create new Access List](../../../../img/access-controls/access-lists/create-new-access-list.png)
@@ -64,10 +64,10 @@ not be able to manage the list, though they will still be reflected as an owner.
 
 ![Select an owner](../../../../img/access-controls/access-lists/select-owner.png)
 
-Under "Members" select `requester` as a required role, then add your test user to the access list. Similar to
+Under "Members" select `requester` as a required role, then add your test user to the Access List. Similar to
 the owner requirements, this will ensure that any member of the list must have the `requester` role in order to
 be granted the access described in this list. If the user loses this role later, they will not be granted the
-roles or traits described in the access list.
+roles or traits described in the Access List.
 
 ![Add a member](../../../../img/access-controls/access-lists/add-member.png)
 

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-request-plugins/ssh-approval-msteams.mdx

@@ -35,7 +35,7 @@ Once enrolled you can download the required `app.zip` file from the integrations
 - An Azure resource group in the same directory. This will host resources for
   the Microsoft Teams Access Request plugin. You should have enough
   permissions to create and edit Azure Bot Services in this resource group.
-- Someone with Global Admin rights on the Azure Active Directory that will grant
+- Someone with Global Admin rights on Microsoft Entra ID in order to grant
   permissions to the plugin.
 - Someone with the `Teams administrator` role that can approve installation
   requests for Microsoft Teams Apps.

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 the Teleport Auth Service.
 
 **Contractor role**
 
@@ -91,7 +91,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
@@ -123,7 +123,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>`.
@@ -158,4 +158,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>
 
@@ -36,8 +36,8 @@ by the `device_trust_mode` authentication setting:
 (!docs/pages/includes/device-trust/prereqs.mdx!)
 
 This guide makes use of the preset `require-trusted-device` role, which does not
-enforce the use of a trusted device for [Apps](#app-access-support) or
-[Desktops](#desktop-access-support). Refer to their corresponding sections for
+enforce the use of a trusted device for [apps](#web-application-support) or
+[desktops](#desktop-support). Refer to their corresponding sections for
 instructions.
 
 ## Role-based trusted device enforcement
@@ -139,10 +139,10 @@ 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).
+The Teleport App Service may enforce Device Trust via [role-based
+enforcement](#role-based-trusted-device-enforcement).
 
 To access apps protected by Device Trust using the Web UI (Teleport v16 or
 later), make sure your device is [registered and enrolled](
@@ -191,7 +191,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/access-controls/guides/hardware-key-support.mdx

@@ -255,7 +255,7 @@ Make sure that the touch and PIN policy satisfy the hardware key requirement for
 
 ### `ERROR: private key policy not met`
 
-This error is returned by the Auth and Proxy services if a user does not meet the required private key policy.
+This error is returned by the Auth Service and Proxy Service if a user does not meet the required private key policy.
 Both `tsh` and Teleport Connect automatically catch these errors and require the user to sign in again with a valid hardware-based private key.
 
 ### `ERROR: authenticating with management key: auth challenge: smart card error 6982: security status not satisfied`

docs/pages/admin-guides/access-controls/guides/headless.mdx

@@ -26,7 +26,7 @@ For example:
 ## Prerequisites
 
 - A Teleport cluster with WebAuthn configured.
-  See the [Second Factor: WebAuthn](./webauthn.mdx) guide.
+  See the [Harden your Cluster Against IdP Compromises](./webauthn.mdx) guide.
 - WebAuthn hardware device, such as YubiKey.
 - Machines for Headless WebAuthn activities have [Linux](../../../installation.mdx), [macOS](../../../installation.mdx) or [Windows](../../../installation.mdx) `tsh` binary installed.
 - Machines used to approve Headless WebAuthn requests have a Web browser with [WebAuthn support](

docs/pages/admin-guides/access-controls/guides/locking.mdx

@@ -3,7 +3,7 @@ title: Session and Identity Locking
 description: How to lock compromised users or agents
 ---
 
-System administrators can disable a compromised user or Teleport agent—or
+System administrators can disable a compromised user or Teleport Agent—or
 prevent access during cluster maintenance—by placing a lock
 on a session, user or host identity.
 
@@ -19,7 +19,7 @@ A lock can target the following objects or attributes:
   ../device-trust/enforcing-device-trust.mdx#locking-a-device) by the device ID
 - an MFA device by the device's UUID
 - an OS/UNIX login
-- a Teleport agent by the agent's server UUID (effectively unregistering it from the
+- a Teleport Agent by the Agent's server UUID (effectively unregistering it from the
   cluster)
 - a Windows desktop by the desktop's name
 - an [Access Request](../access-requests/access-requests.mdx) by UUID

docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx

@@ -13,7 +13,7 @@ Examples of administrative actions include, but are not limited to:
 - Inviting new users
 - Updating cluster configuration resources
 - Modifying access management resources
-- Approving access requests
+- Approving Access Requests
 - Generating new join tokens
 - Impersonation
 - Creating new bots for Machine ID
@@ -41,15 +41,15 @@ their on-disk Teleport certificates.
 
 - (!docs/pages/includes/tctl.mdx!)
 - [WebAuthn configured](webauthn.mdx) on this cluster
-- Second factor hardware device, such as YubiKey or SoloKey
+- Multi-factor authentication hardware device, such as YubiKey or SoloKey
 - A Web browser with [WebAuthn support](
   https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/) (if using
   SSH or desktop sessions from the Teleport Web UI).
 
 ## Require MFA for administrative actions
 
 MFA for administrative actions is automatically enforced for clusters where
-WebAuthn is the only form of second factor allowed.
+WebAuthn is the only form of multi-factor authentication allowed.
 
 <Notice type="note">
   In a future major version, Teleport may enforce MFA for administrative actions

docs/pages/admin-guides/access-controls/guides/passwordless.mdx

@@ -11,16 +11,18 @@ usernameless authentication for Teleport.
 
 (!docs/pages/includes/edition-prereqs-tabs.mdx!)
 
-- Teleport must be configured for WebAuthn. See the [Second Factor:
-  WebAuthn](./webauthn.mdx) guide.
-- A hardware device with support for WebAuthn and resident keys.
-  As an alternative, you can use a Mac with biometrics / Touch ID or device that
+- Teleport must be configured for WebAuthn. See the [Harden your Cluster Against
+  IdP Compromises](./webauthn.mdx) guide.
+- A hardware device with support for WebAuthn and resident keys.  As an
+  alternative, you can use a Mac with biometrics / Touch ID or device that
   supports Windows Hello (Windows 10 19H1 or later).
-- A web browser with WebAuthn support. To see if your browser supports
-  WebAuthn, check the [WebAuthn
-  Compatibility](https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/) page.
-- A signed and notarized version of `tsh` is required for Touch ID. This means versions
-  installed from Homebrew or compiled from source will not work. [Download the macOS tsh installer](../../../installation.mdx#macos).
+- A web browser with WebAuthn support. To see if your browser supports WebAuthn,
+  check the [WebAuthn
+  Compatibility](https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/)
+  page.
+- A signed and notarized version of `tsh` is required for Touch ID. This means
+  versions installed from Homebrew or compiled from source will not work.
+  [Download the macOS tsh installer](../../../installation.mdx#macos).
 - (!docs/pages/includes/tctl.mdx!)
 
 A Teleport cluster capable of WebAuthn is automatically capable of passwordless.
@@ -46,8 +48,8 @@ If you are using a hardware device, a passwordless registration will occupy a
 resident key slot. Resident keys, also called discoverable credentials, are
 stored in persistent memory in the authenticator (i.e., the device that is used
 to authenticate). In contrast, MFA keys are encrypted by the authenticator and
-stored in the Teleport Auth Server. Regardless of your device type, passwordless
-registrations may also be used for regular MFA.
+stored in the Teleport Auth Service backend. Regardless of your device type,
+passwordless registrations may also be used for regular MFA.
 
 <Admonition type="tip" title="Important">
 If you plan on relying exclusively on passwordless, it's recommended to register

docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx

@@ -29,7 +29,7 @@ their on-disk Teleport certificates.
 
 - (!docs/pages/includes/tctl.mdx!)
 - [WebAuthn configured](webauthn.mdx) on this cluster
-- Second factor hardware device, such as YubiKey or SoloKey
+- Hardware device for multi-factor authentication, such as YubiKey or SoloKey
 - A Web browser with [WebAuthn support](
   https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/) (if using
   SSH or desktop sessions from the Teleport Web UI).

docs/pages/admin-guides/access-controls/idps/saml-gcp-workforce-identity-federation.mdx

@@ -79,7 +79,7 @@ resource ID for workforce pool and workforce pool provider, respectively.
 </Admonition>
 
 
-## Step 2/3 Add workforce pool To Teleport
+## Step 2/3. Add workforce pool To Teleport
 
 Proceed to the next step in the UI by clicking the **Next** button.
 
@@ -95,7 +95,7 @@ values or attribute mapping in GCP, you must also updated the respective SAML se
 </Admonition>
 
 
-## Step 3/3 Create GCP IAM policy
+## Step 3/3. Create GCP IAM policy
 
 Once a pool and pool provider is configured in the GCP, and its respective configuration is added
 to Teleport as a SAML service provider resource, users can sign in into the GCP web console, as
@@ -252,7 +252,7 @@ Save the spec as **pool_provider_name.yaml** file. And create the saml service p
 $ tctl create pool_provider_name.yaml
 ```
 
-## Step 3/3: Create GCP IAM policy
+## Step 3/3. Create GCP IAM policy
 
 This step is similar to Step 3 in the guided configuration flow.
 You will need to create a GCP IAM policy representing the workforce principal.