[v7.0] docs: port of edit pass 5/9

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

@@ -16,6 +16,8 @@ with creating your own role.
 - Installed [Teleport](../getting-started.mdx) or [Teleport Cloud](../cloud/introduction.mdx) >= (=teleport.version=)
 - [Tctl admin tool](https://goteleport.com/teleport/download) >= (=teleport.version=)
 
+(!docs/pages/includes/permission-warning.mdx!)
+
 Verify that your Teleport client is connected:
 
 ```bash

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

@@ -1,6 +1,6 @@
 ---
 title: Per-session MFA
-description: Require U2F checks for user SSH and Kubernetes sessions
+description: Require U2F checks for user SSH and Kubernetes sessions.
 ---
 
 # Per-session MFA

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

@@ -1,6 +1,6 @@
 ---
 title: Teleport Role Templates
-description: Mapping SSO and Local Users Traits to Roles with Template
+description: Mapping SSO and Local Users Traits to Roles with Template.
 ---
 
 # Role Templates

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

@@ -1,9 +1,9 @@
 ---
 title: Second Factor - U2F
-description: Configuring U2F support in Teleport clusters
+description: Configuring U2F support in Teleport clusters.
 ---
 
-# U2F
+#  U2F ( Hardware Tokens) 
 
 Teleport supports [FIDO U2F](https://www.yubico.com/about/background/fido/)
 hardware keys as a second authentication factor. U2F can be used for logging

docs/pages/access-controls/introduction.mdx

@@ -17,7 +17,7 @@ Role-Based Access Control (RBAC) is almost always used in conjunction with Singl
 
 It also works with users stored in Teleport's internal database.
 
-## Getting Started
+## Getting started
 
 Configure Access Controls in a 5 minute [Getting Started](./getting-started.mdx)
 guide.

docs/pages/architecture/authentication.mdx

@@ -1,5 +1,5 @@
 ---
-title: Teleport Authentication Service, SSH and Kubernetes certificates
+title: Teleport Authentication Service, SSH, and Kubernetes certificates
 description: This chapter explains the concept of a Teleport Auth Service and Certificate Authority (CA) to issue SSH and Kubernetes certificates.
 h1: Teleport Authentication Service
 ---
@@ -22,9 +22,7 @@ certificate issued by the Teleport Auth Certificate Authority.
 
 **Authorization** is proving access to something: "Bob has a purple hat, but
 also a debit card and the correct PIN code. Bob can access a bank account with
-the number 814000001344. Can Bob get $20 out of the ATM?" The ATM's
-Authentication system would validate Bob's PIN Code, while the Authorization
-system would use a stored mapping from Bob to account #814000001344 to decide
+the number 814000001344. Can Bob get $20 out of the ATM?" The ATM's Authentication system would validate Bob's PIN Code, while the Authorization system would use a stored mapping from Bob to account #814000001344 to decide
 whether Bob could withdraw cash. Authorization defines and determines
 permissions that users have within a system, such as access to cash within a
 banking system, or data in a filesystem. Before users are granted access to
@@ -33,42 +31,36 @@ database.
 
 ![Authentication and Authorization](../../img/authn_authz.svg)
 
-## SSH Certificates
+## SSH certificates
 
 One can think of an SSH certificate as a "permit" issued and time-stamped by a
-trusted authority. In this case the authority is the Auth Server's Certificate
+trusted authority. In this case, the authority is the Auth Server's Certificate
 Authority. A certificate contains four important pieces of data:
 
 1. List of principals (identities) this certificate belongs to.
 2. Signature of the certificate authority who issued it.
 3. The expiration date, also known as "time-to-live" or simply TTL.
-4. Additional data, such as the node role, stored as a certificate extension.
+4. Additional data, such as the node role, is stored as a certificate extension.
 
 ## Authentication in Teleport
 
 Teleport uses SSH certificates to authenticate nodes and users within a cluster.
 
-There are two CAs operating inside the Auth Server because nodes and users each
-need their own certificates. {/* TODO: Why? */}
+Two CAs are used inside the Auth Server because nodes and users each need their own certificates. {/* TODO: Why? */}
 
 - The **Node CA** issues certificates which identify a node (i.e. host, server,
-  computer). These certificates are used to add new nodes to a cluster and
-  identify connections coming from the node.
-- The **User CA** issues certificates which identify a User. These certificates
-  are used to authenticate users when they try to connect to a cluster node.
+  computer). These certificates are used to add new nodes to a cluster and identify connections coming from the node.
+- The **User CA** issues certificates which identify a User. These certificates are used to authenticate users when they try to connect to a cluster node.
 
-### Issuing Node Certificates
+### Issuing Node certificates
 
 Node Certificates identify a node within a cluster and establish the permissions
 of the node to access other Teleport services. The presence of a signed
 certificate on a node makes it a cluster member.
 
 ![Node Joins Cluster](../../img/node_join.svg)
 
-1. To join a cluster for the first time, a node must present a "join token" to
-   the auth server. The token can be static (configured via config file) or a
-   dynamic, single-use token generated by [`tctl nodes
-   add`](../cli-docs.mdx#tctl-nodes-add).
+1. To join a cluster for the first time, a node must present a "join token" to the auth server. The token can be static (configured via config file) or a dynamic, single-use token generated by [`tctl nodes add`](../cli-docs.mdx#tctl-nodes-add).
 
 <Admonition
   type="tip"
@@ -79,12 +71,9 @@ certificate on a node makes it a cluster member.
   [`tctl nodes add --ttl`](../cli-docs.mdx#tctl-nodes-add) flag.
 </Admonition>
 
-2. When a new node joins the cluster, the auth server generates a new
-   public/private keypair for the node and signs its certificate. This node
-   certificate contains the node's role(s) (`proxy`, `auth` or `node`) as a
-   certificate extension (opaque signed string).
+2. When a new node joins the cluster, the auth server generates a new public/private keypair for the node and signs its certificate. This node certificate contains the node's role(s) (`proxy`, `auth` or `node`) as a certificate extension (opaque signed string).
 
-### Using Node Certificates
+### Using Node certificates
 
 ![Node Authorization](../../img/node_cluster_auth.svg)
 
@@ -96,29 +85,23 @@ connection using a certificate with only the `node` role won't be able to add
 and delete users. This client connection would only be authorized to get auth
 servers registered in the cluster.
 
-### Issuing User Certificates
+### Issuing user certificates
 
 ![Client obtains new certificate](../../img/cert_invalid.svg)
 
 The Auth Server uses its User CA to issue user certificates. User certificates
 are stored on a user's machine in the `~/.tsh/keys/example.com` directory or also
 by the system's SSH agent if it is running.
 
-1. To get permission to join a cluster for the first time a user must provide
-   their username, password, and 2nd-factor token. Users can log in with [`tsh
-   login`](../cli-docs.mdx#tsh-login) or via the Web UI. The Auth Server checks
-   the username and password against its identity storage and checks the 2nd factor token.
-2. If the correct credentials were offered, the Auth Server will generate a
-   signed certificate and return it to the client. For users, certificates are
-   stored in `~/.tsh` by default. If the client uses the Web UI the signed certificate
-   is associated with a secure websocket session.
+1. To get permission to join a cluster for the first time a user must provide their username, password, and 2nd-factor token. Users can log in with [`tsh login`](../cli-docs.mdx#tsh-login) or via the Web UI. The Auth server checks the username and password against its identity storage and checks the 2nd-factor token.
+2. If the correct credentials were offered, the Auth Server will generate a signed certificate and return it to the client. For users, certificates are stored in `~/.tsh` by default. If the client uses the Web UI the signed certificate is associated with a secure WebSocket session.
 
 In addition to a user's identity, user certificates also contain user roles and
 SSH options, like "permit-agent-forwarding" {/* TODO: link to config/set options here */}.
 This additional data is stored as a certificate extension and is protected by
 the CA signature.
 
-### Using User Certificates
+### Using user certificates
 
 ![Client offers valid certificate](../../img/user_auth.svg)
 
@@ -129,11 +112,9 @@ certificate is still valid, the Auth Server validates the certificate's
 signature. The client is then granted access to the cluster. From here, the
 [Proxy Server](proxy.mdx) establishes a connection between client and node.
 
-## Certificate Rotation
+## Certificate rotation
 
-By default, all user certificates have an expiration date, also known as time to
-live (TTL). This TTL can be configured by a Teleport administrator. However, the node
-certificates issued by an Auth Server are valid indefinitely by default.
+By default, all user certificates have an expiration date, also known as the *time to live *(TTL). This TTL can be configured by a Teleport administrator. However, the node certificates issued by an Auth Server are valid indefinitely by default.
 
 Teleport supports certificate rotation, i.e. the process of invalidating all
 previously-issued certificates for nodes *and* users regardless of their TTL.
@@ -142,13 +123,9 @@ rotate`](../cli-docs.mdx#tctl-auth-rotate). When this command is invoked by a Te
 administrator on one of a cluster's Auth Servers, the following happens:
 
 1. A new certificate authority (CA) key is generated.
-2. The old CA will be considered valid *alongside* the new CA for some period of
-   time. This period of time is called a *grace period*. {/* TODO: Link to
-   config/defaults. */}
-3. During the grace period, all previously issued certificates will be
-   considered valid, assuming their TTL isn't expired.
-4. After the grace period is over, the certificates issued by the old CA are no
-   longer accepted.
+2. The old CA will be considered valid *alongside* the new CA for a while. This period is called a *grace period*. {/* TODO: Link to config/defaults. */}
+3. During the grace period, all previously issued certificates will be considered valid, assuming their TTL isn't expired.
+4. After the grace period is over, the certificates issued by the old CA are no longer accepted.
 
 This process is repeated twice, once for the node CA and once for the user CA.
 
@@ -161,10 +138,9 @@ learn how to do certificate rotation in practice.
   /* TODO: Can we say more about this, abstract of routes provided */
 }
 
-Clients can also connect to the auth API through the Teleport proxy to use a
-limited subset of the API to discover the member nodes of the cluster.
+Clients can also connect to the auth API through the Teleport proxy to use a limited subset of the API to discover the member nodes of the cluster.
 
-## Auth State
+## Auth state
 
 The Auth service maintains state using a database of users, credentials,
 certificates, and audit logs. The default storage location is
@@ -173,45 +149,35 @@ destination](../admin-guide.mdx#high-availability).
 
 There are three types of data stored by the auth server:
 
-- **Cluster State** The auth server stores its own keys in a cluster state
-  storage. All of cluster dynamic configuration is stored there as well,
-  including:
+- - **Cluster State** The auth server stores its own keys in a cluster state storage. All of cluster dynamic configuration is stored there as well, including:
   - Node membership information and online/offline status for each node.
   - List of active sessions.
   - List of locally stored users
   - RBAC configuration (roles and permissions).
   - Other dynamic configuration.
-- **Audit Log** When users log into a Teleport cluster, execute remote commands
-  and logout, that activity is recorded in the audit log. See Audit Log for more
-  details. More on this in the [Audit Log section below](#audit-log).
-- **Recorded Sessions** When Teleport users launch remote shells via `tsh ssh`
-  command, their interactive sessions are recorded and stored by the auth
-  server. Each recorded session is a file which is saved in /var/lib/teleport by
-  default, but can also be saved in external storage, like an AWS S3 bucket.
+- **Audit Log** When users log into a Teleport cluster, execute remote commands, and log out, that activity is recorded in the audit log. See Audit Log for more details. More on this in the [Audit Log section below](#audit-log).
+- **Recorded Sessions** When Teleport users launch remote shells via `tsh ssh` command, their interactive sessions are recorded and stored by the auth server. Each recorded session is a file that is saved in /var/lib/teleport by default but can also be saved in external storage, like an AWS S3 bucket.
 
-## Audit Log
+## Audit log
 
 The Teleport auth server keeps the audit log of SSH-related events that take
 place on any node within a Teleport cluster. Each node in a cluster emits audit
 events and submits them to the auth server. The events recorded include:
 
-- successful user logins
-- node IP addresses
-- session time
-- session IDs
+- Successful user logins
+- Node IP addresses, Application, Database and Kubernetes FQDN
+- Session time
+- Session IDs
 
 <Admonition
   type="warning"
   title="Compatibility Warning"
 >
-  Because all SSH events like `exec` or `session_start` are by default
-  reported by the Teleport node service, they will not be logged if you are
-  using OpenSSH `sshd` daemon on your nodes. [Recording proxy mode](proxy.mdx#recording-proxy-mode)
-  can be used to log audit events when using OpenSSH on your nodes.
+  Because all SSH events like `exec` or `session_start` are by default reported by the Teleport node service, they will not be logged if you are using OpenSSH `sshd` daemon on your nodes. [Recording proxy mode](proxy.mdx#recording-proxy-mode)
 </Admonition>
 
 Only an SSH server can report what's happening to the Teleport auth server.
-The audit log is a JSON file which is by default stored on the auth server's
+The audit log is a JSON file that is by default stored on the auth server's
 filesystem under `/var/lib/teleport/log`. The format of the file is documented
 in the [Admin Manual](../admin-guide.mdx#audit-log).
 
@@ -228,7 +194,7 @@ storage.
   same audit log. [Learn how to deploy Teleport in HA Mode.](../admin-guide.mdx#high-availability)
 </Admonition>
 
-## Storage Back-Ends
+## Storage back-ends
 
 Different types of cluster data can be configured with different storage
 back-ends as shown in the table below:
@@ -243,13 +209,7 @@ back-ends as shown in the table below:
   type="tip"
   title="Note"
 >
-  The reason Teleport designers split the audit log events and the recorded
-  sessions into different back-ends is because of the nature of the data. A
-  recorded session is a compressed binary stream (blob) while the event is a
-  well-defined JSON structure. `dir` works well enough for both in small
-  deployments, but large clusters require specialized data stores: S3 is
-  perfect for uploading session blobs, while DynamoDB or `etcd` are better
-  suited to store the cluster state.
+  The reason Teleport designers split the audit log events and the recorded sessions into different back-ends is because of the nature of the data. A recorded session is a compressed binary stream (blob) while the event is a well-defined JSON structure. `dir` works well enough for both in small deployments, but large clusters require specialized data stores: S3 is perfect for uploading session blobs, while DynamoDB or `etcd` are better suited to store the cluster state.
 </Admonition>
 
 The combination of DynamoDB + S3 is especially popular among AWS users because
@@ -264,7 +224,7 @@ it allows them to run Teleport clusters completely devoid of local state.
   configuration](../admin-guide.mdx#high-availability) in the Admin Guide.
 </Admonition>
 
-## More Concepts
+## More concepts
 
 - [Architecture Overview](overview.mdx)
 - [Teleport Users](users.mdx)