[v6.1] Remaining edit pass (#6587)

* docs: improve enterprise rbac
* docs: correct links and editions
* docs: correct links and editions
* docs: correct editions
* docs: database access
* docs: database access
* docs: access controls
* docs: more edits
* docs: infra guides
* docs: enterprise guides
* docs: enterprise guides
* docs: correct session tables
* docs: cloud
* docs: reference
* docs: architecture
* docs: linting fixes
* docs: corrected
* docs: improved score for 6.1
* docs: improve scores
* docs: few more improvements

docs/config.json

@@ -123,7 +123,7 @@
           "title": "Quick Start Guide",
           "slug": "/enterprise/quickstart-enterprise/"
         },
-        { "title": "Single sign-on (SSO)", "slug": "/enterprise/sso/ssh-sso/" },
+        { "title": "Single Sign-On (SSO)", "slug": "/enterprise/sso/ssh-sso/" },
         { "title": "Access Workflows", "slug": "/enterprise/workflow/" },
         {
           "title": "FedRAMP for SSH & K8s",

docs/pages/access-controls/getting-started.mdx

@@ -5,11 +5,11 @@ description: Teleport Access Controls
 
 # Getting Started
 
-In Teleport, any local, SSO or robot user can be a member of one or several
-roles. Roles govern access to databases, SSH servers, kubernetes clusters and web apps.
+In Teleport, any local, SSO, or robot user can be a member of one or several
+roles. Roles govern access to databases, SSH servers, kubernetes clusters, and web apps.
 
 We will start with local users and preset roles, map SSO users to roles and wrap up
-with creating your own role.
+with creating your role.
 
 ## Prerequisites
 
@@ -30,9 +30,8 @@ CA pin   sha256:e63c7c44be468d37a5b0276b70e9d10b17f24f4be19d6b579810fc94eaa31783
 
 ## Step 1/3 Add local users with preset roles
 
-Teleport provides a couple of preset roles: `admin`, `editor`, `auditor` and `access`.
-Members of `editor` role can modify cluster configuration, members of `auditor`
-role can view audit logs, and `access` members can access cluster resources.
+Teleport provides a couple of preset roles: `admin`, `editor`, `auditor`, and `access`.
+Members of the `editor` role can modify cluster configuration, members who have the `auditor` role can view audit logs, and `access` members can access cluster resources.
 Members of `admin`, are full cluster administrators.
 
 Invite a local user Alice as cluster `editor`:
@@ -55,16 +54,16 @@ [email protected]    admin
 You can update user's roles using `tctl users update` command:
 
 ```bash
-# Once Alice relogins, she will be able to view audit logs
+# Once Alice logs in again, she will be able to view audit logs
 $ tctl users update alice --set-roles=editor,auditor
 ```
 
-Because Alice has two roles, permissions from those role create a union -
+Because Alice has two roles, permissions from those roles create a union -
 she will be able to act as a system administrator and auditor at the same time.
 
 ## Step 2/3 Map SSO users to roles
 
-We are going to setup Github connector for OSS and Okta for Enterprises version.
+We're going to set up a Github connector for the Open Source Edition and Okta for Enterprise versions.
 
 <Tabs>
   <TabItem label="Open Source">
@@ -100,7 +99,7 @@ We are going to setup Github connector for OSS and Okta for Enterprises version.
     Follow [SAML Okta Guide](../enterprise/sso/ssh-okta.mdx#configure-okta) to create a SAML app.
     Check out [OIDC guides](../enterprise/sso/oidc.mdx#identity-providers) for OpenID Connect apps.
     Save the file below as `okta.yaml` and update the `acs` field.
-    Any member in Okta group `okta-admin` will assume a builtin role `admin`.
+    Any member in Okta group `okta-admin` will assume a built-in role `admin`.
 
     ```yaml
     kind: saml
@@ -166,7 +165,7 @@ $ tctl create -f /tmp/interns.yaml
 $ tctl get roles --format text
 ```
 
-## Next Steps
+## Next steps
 
 - [Mapping SSO and local users traits with role templates](./guides/role-templates.mdx)
 - [Create certs for CI/CD using impersonation](./guides/impersonation.mdx)

docs/pages/access-controls/guides/dual-authz.mdx

@@ -3,12 +3,12 @@ title: Dual Authorization
 description: Dual Authorization for SSH and Kubernetes
 ---
 
-# Dual Authorization
+# Dual authorization
 
-You can set up Teleport to require require the approval of multiple team members to perform some critical actions.
+You can set up Teleport to require the approval of multiple team members to perform some critical actions.
 Here are the most common scenarios:
 
-- Improve security of your system and prevent one successful phishing attack from compromizing your system.
+- Improve the security of your system and prevent one successful phishing attack from compromising your system.
 - Satisfy FedRamp AC-3 Dual authorization control that requires approval of two authorized individuals.
 
 Let's set up Teleport's access requests to require approval of
@@ -18,8 +18,7 @@ two team members for a privileged role `dbadmin`.
   type="warning"
   title="Version Warning"
 >
-  This guide requires a commercial edition of Teleport. The open source
-  edition of Teleport only supports [Github](../../admin-guide.mdx#github-oauth-20) as
+  This guide requires a commercial edition of Teleport. The Teleport Open Source Edition only supports [Github](../../admin-guide.mdx#github-oauth-20) as
   an SSO provider.
 </Admonition>
 
@@ -170,9 +169,9 @@ output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/tele
 severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
 ```
 
-## Dual Authorization
+## Dual authorization
 
-Alice and Ivan are reviewers - they can approve requests for assuming role `dbadmin`.
+Alice and Ivan are reviewers - they can approve requests since they have the role `dbadmin`.
 Bob is a devops and can assume `dbadmin` role if two members of the `reviewer` role
 approved the request.
 
@@ -212,16 +211,16 @@ spec:
       'type': 'db'
 ```
 
-Example below creates local users Alice, Ivan and Bob.
-Bob does not have a role `dbadmin` assigned to him, but can create an access request for it.
+The example below creates local users Alice, Ivan, and Bob.
+Bob does not have a role `dbadmin` assigned to him but can create an access request for it.
 
 ```bash
 $ tctl users add [email protected] --roles=devops
 $ tctl users add [email protected] --roles=reviewer
 $ tctl users add [email protected] --roles=reviewer
 ```
 
-## Access Requests Flow
+## Access requests flow
 
 Bob can create an access request for the `dbadmin` role in the Web UI or CLI:
 

docs/pages/access-controls/guides/impersonation.mdx

@@ -5,8 +5,8 @@ description: How to issue short-lived certs on behalf of Teleport users using im
 
 # Impersonation
 
-Sometimes users need to create short-lived certificates for non-interactive users, for example CI/CD systems.
-Your programs interacting with Teleport may need to create their own authentication as well.
+Sometimes users need to create short-lived certificates for non-interactive users, for example, CI/CD systems.
+Your programs interacting with Teleport may need to create their authentication as well.
 Teleport's impersonation allows users and robots to create short-lived certs for other users and roles.
 
 Let's explore how interactive user Alice can create credentials for a non-interactive
@@ -48,7 +48,7 @@ spec:
     # issued to the users with this role.
     max_session_ttl: 240h
 
-  # allow section declares a list of resource/verb combinations that are
+  # The allow section declares a list of resource/verb combinations that are
   # allowed for the users of this role. by default nothing is allowed.
   allow:
     logins: ['jenkins']
@@ -90,15 +90,15 @@ spec:
     # issued to the users with this role.
     max_session_ttl: 10h
 
-  # allow section declares a list of resource/verb combinations that are
+  # The allow section declares a list of resource/verb combinations that are
   # allowed for the users of this role. by default nothing is allowed.
   allow:
     impersonate:
       users: ['jenkins']
       roles: ['jenkins']
 
-  # the deny section uses the identical format as the 'allow' section.
-  # the deny rules always override allow rules.
+  # The deny section uses the identical format as the 'allow' section.
+  # The deny rules always override allow rules.
   deny:
     node_labels:
       '*': '*'
@@ -122,9 +122,9 @@ $ tctl auth sign --user=jenkins --format=openssh --out=jenkins --ttl=240h
 Here is an example of how Alice can use the keys:
 
 ```bash
-# start a fresh SSH agent for this session
+# Start a fresh SSH agent for this session
 $ eval $(ssh-agent)
-# adds cert to the agent
+# Adds cert to the agent
 $ ssh-add jenkins
 # ssh into the node as jenkins
 $ ssh -J [email protected]:3023 -p 3022 [email protected]
@@ -155,7 +155,7 @@ to use this permission. Teleport prevents impersonating users recursively.
 pointing to a different Teleport leaf cluster.
 Teleport allows impersonated users to renew their certificates with the reduced scope of the certificate.
 
-## Step 3/3 Dynamic Impersonation
+## Step 3/3 dynamic impersonation
 
 Sometimes you don't know in advance what roles will be created by the system.
 
@@ -180,8 +180,8 @@ spec:
       roles: ['*']
       where: 'equals(impersonate_role.metadata.labels["group"], "security") && equals(impersonate_user.metadata.labels["group"], "security")'
 
-  # the deny section uses the identical format as the 'allow' section.
-  # the deny rules always override allow rules.
+  # The deny section uses the identical format as the 'allow' section.
+  # The deny rules always override allow rules.
   deny:
     node_labels:
       '*': '*'
@@ -247,8 +247,8 @@ spec:
       roles: ['*']
       where: 'contains(user.spec.traits["group"], impersonate_role.metadata.labels["group"]) && contains(user.spec.traits["group"], impersonate_user.metadata.labels["group"])'
 
-  # the deny section uses the identical format as the 'allow' section.
-  # the deny rules always override allow rules.
+  # The deny section uses the identical format as the 'allow' section.
+  # The deny rules always override allow rules.
   deny:
     node_labels:
       '*': '*'
@@ -280,10 +280,10 @@ $ tctl auth sign --user=security-scanner --format=openssh --out=security-scanner
 Here is a summary of variables and functions we used in this guide:
 
 <table>
-<th>
-  <td>Variable or Function</td>
-  <td>Description</td>
-</th>
+<tr>
+  <th>Variable or Function</th>
+  <th>Description</th>
+</tr>
 <tr>
   <td>`user.spec.traits`</td>
   <td>Access traits of local or SSO user.</td>

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

@@ -10,8 +10,7 @@ Teleport supports U2F authentication on every SSH and Kubernetes "connection"
 that protects users against compromises of their on-disk Teleport certificates.
 
 <Admonition type="note">
-  Per-session U2F checks don't apply to regular Teleport logins (`tsh login` or
-  logging into the Web UI). We encourage you to enable login MFA in your SSO
+  Per-session U2F checks don't apply to regular Teleport logins (`tsh login` or logging into the Web UI). We encourage you to enable login MFA in your SSO
   provider and/or for all [local Teleport
   users](../../admin-guide.mdx#local-connector).
 </Admonition>
@@ -36,7 +35,7 @@ to contain:
 ```yaml
 auth_service:
   authentication:
-    # require per-session MFA cluster-wide
+    # Require per-session MFA cluster-wide
     require_session_mfa: yes
 ```
 
@@ -51,7 +50,7 @@ metadata:
   name: example-role-with-mfa
 spec:
   options:
-    # require per-session MFA for this role
+    # Require per-session MFA for this role
     require_session_mfa: true
   allow:
     ...
@@ -64,7 +63,7 @@ clusters matching that role's `allow` section.
 
 #### Roles example
 
-Let's walk though an example of setting up per-session MFA checks for roles.
+Let's walk through an example of setting up per-session MFA checks for roles.
 
 Jerry is an engineer with access to the company infrastructure. The
 infrastructure is split into development and production environments. Security
@@ -93,7 +92,7 @@ version: v3
 metadata:
   name: access-prod
   options:
-    # require per-session MFA for production access
+    # Require per-session MFA for production access
     require_session_mfa: true
 spec:
   allow:
@@ -106,7 +105,7 @@ spec:
 
 Olga then assigns both roles to all engineers, including Jerry.
 
-When Jerry logs into node `dev1.example.com` (with label `env: dev`), nothing
+When Jerry logs into node `dev1.example.com` (with the label `env: dev`), nothing
 special happens:
 
 ```sh
@@ -115,7 +114,7 @@ jerry@localhost $ tsh ssh dev1.example.com
 [email protected] >
 ```
 
-But when Jerry logs into node `prod3.example.com` (with label `env: prod`), he
+But when Jerry logs into node `prod3.example.com` (with the label `env: prod`), he
 gets prompted for an MFA check:
 
 ```sh
@@ -137,7 +136,6 @@ Current limitations for this feature are:
   does not).
 - Only `kubectl` supports per-session U2F authentication for Kubernetes.
 - Database and Application access clients don't support per-session U2F
-  authentication yet, although cluster and role configuration applies to them.
-  If you enable per-session U2F checks cluster-wide, you will not be able to
-  use Database or Application access. We're working on integrating per-session
+  authentication yet, although cluster and role configuration apply to them.
+  If you enable per-session U2F checks cluster-wide, you will not be able to use Database or Application access. We're working on integrating per-session
   U2F checks for these clients.

docs/pages/access-controls/guides/role-templates.mdx

@@ -7,13 +7,13 @@ description: Mapping SSO and Local Users Traits to Roles with Template
 
 As organizations grow, infrastructure teams have to figure out
 how to define access control policies that don't require manual configuration
-every time people join, leave and form new teams.
+every time people join, leave, and form new teams.
 
 Here are some common examples of such policies:
 
 - Grant every single sign-on user an SSH login generated from their email.
 - Assign each team member to their team's Kubernetes group.
-- Limit dev team to read-only replica of a database.
+- Limit the dev team to a read-only replica of a database.
 
 Let's explore how Teleport's role templates provide a way to describe these and other policies.
 
@@ -39,8 +39,8 @@ CA pin   sha256:e63c7c44be468d37a5b0276b70e9d10b17f24f4be19d6b579810fc94eaa31783
 Imagine you have two users, Alice and Bob. We would like to set the following
 access policies:
 
-- Alice to login as SSH user `admin` and Kubernetes group `edit`
-- Bob to login as `ubuntu` and Kubernetes group `view`
+- Alice to log in as SSH user `admin` and Kubernetes group `edit`
+- Bob to log in as `ubuntu` and Kubernetes group `view`
 
 We can create two roles, one for each user in file `roles.yaml`:
 
@@ -206,13 +206,13 @@ metadata:
 spec:
   # Client ID of Github OAuth app
   client_id: client-id
-  # client secret of Github OAuth app
+  # Client secret of Github OAuth app
   client_secret: secret-data-here
-  # connector display name that will be shown on web UI login screen
+  # Connector display name that will be shown on web UI login screen
   display: Github
-  # callback URL that will be called after successful authentication
+  # Callback URL that will be called after successful authentication
   redirect_url: https://teleport.example.com/v1/webapi/github/callback
-  # mapping of org/team memberships onto allowed logins and roles
+  # Mapping of org/team memberships onto allowed logins and roles
   teams_to_logins:
     - organization: octocats # Github organization name
       team: cyber # Github team name within that organization
@@ -247,7 +247,7 @@ $ tsh login --proxy=teleport.example.com:443 --auth=github
 ## Interpolation rules
 
 Administrators can configure what attributes identity providers return
-during single-sign on and present to Teleport. Let's review a couple of scenarios
+during Single-Sign-On and present to Teleport. Let's review a couple of scenarios
 and see how Teleport interpolates the variables.
 
 Let's go back to the the list of attributes for Alice's user entry:
@@ -301,7 +301,7 @@ metadata:
   name: interpolation
 spec:
   allow:
-    # The variable external.logins is not sent by provider and it renders empty,
+    # The variable external.logins is not sent by the provider and it renders empty,
     # leaving only hard-coded admin value
     logins: ['admin']