[v6.1] edit pass - app + kub access (#6568)

* docs: couple more tics

* docs: few more tics

* docs: improve kub and app access

CHANGELOG.md

@@ -1939,7 +1939,7 @@ This release focus was to increase Teleport user experience in the following are
 
 #### Bug Fixes
 
-* Proper handling of `ENV_SUPATH` from login.defs [#1004](https://github.com/gravitational/teleport/pull/1004)
+* Proper handling of `ENV_SUPATH` from `login.defs` [#1004](https://github.com/gravitational/teleport/pull/1004)
 * Reverse tunnels would periodically lose connectivity. [#1156](https://github.com/gravitational/teleport/issues/1156)
 * `tsh` now stores user identities in a format compatible with OpenSSH. [1171](https://github.com/gravitational/teleport/issues/1171).
 
@@ -2120,7 +2120,7 @@ v1.3.1 is a maintenance release which fixes a few issues found in 1.3
 ### Bugfixes
 
 * Teleport session recorder can skip characters.
-* U2F was enabled by default in "demo mode" if teleport.yaml file was missing.
+* U2F was enabled by default in "demo mode" if `teleport.yaml` file was missing.
 
 ### Improvements
 
@@ -2133,7 +2133,7 @@ This release includes several major new features and it's recommended for produc
 ### Features
 
 * Support for hardware U2F keys for 2nd factor authentication.
-* CLI client profiles: `tsh` can now remember its --proxy setting.
+* CLI client profiles: `tsh` can now remember its `--proxy` setting.
 * tctl auth sign command to allow administrators to generate user session keys
 * Web UI is now served directly from the executable. There is no more need for web
   assets in `/usr/local/share/teleport`
@@ -2160,7 +2160,7 @@ This is a maintenance release meant to be a drop-in upgrade of previous versions
 ### Changes
 
 * User experience improvements: nicer error messages
-* Better compatibility with ssh command: -t flag can be used to force allocation of TTY
+* Better compatibility with ssh command: `-t` flag can be used to force allocation of TTY
 
 ## 1.0.5
 

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

@@ -5,10 +5,10 @@ description: Getting started with Teleport Application Access
 
 # Getting Started
 
-Let's connect to Grafana using Teleport Application Access in 3 steps:
+Let's connect to Grafana using Teleport Application Access in three steps:
 
 - Launch Grafana in a Docker container.
-- Install Teleport and configure it it to proxy Grafana.
+- Install Teleport and configure it to proxy Grafana.
 - Access Grafana through Teleport.
 
 ## Follow along with our video guide
@@ -29,13 +29,13 @@ Let's connect to Grafana using Teleport Application Access in 3 steps:
   use that instead.
 - We will assume your Teleport cluster is accessible at `teleport.example.com`
   and `*.teleport.example.com`. Configured DNS records are required to
-  automatically fetch a Let's Encrypt certificate.
+  automatically fetch a [Let's Encrypt](https://letsencrypt.org) certificate.
 
 ## Step 1/3. Start Grafana
 
 We've picked Grafana for this tutorial since it's very easy to run with zero
 configuration required. If you have another web application you'd like to
-expose, skip over to Step 2.
+expose, skip over to **Step 2**.
 
 Grafana can be launched in a [Docker container](https://grafana.com/docs/grafana/latest/installation/docker/)
 with a single command:

docs/pages/application-access/introduction.mdx

@@ -47,19 +47,26 @@ Get started with Application Access in a 10 minute [guide](./getting-started.mdx
 
 ## Example Legacy Apps
 
-A device such as a load balancer might come with a control panel, but it
-doesn't have any authentication and can only be access via a privileged network.
-These applications are supported and can extend access beyond your network.
+A load balancer might display network telemetry through 
+a control panel but might lack the ability to authenticate with 
+and be accessed by resources outside your private newtork.
 
-Other example legacy apps:
+Teleport let's team members access these resources securely, even outside a private network:
+
+- Team members can access private resources securely using certificates and SSH tunnels.
+- No sharing of resource secrets, passwords, or credentials.
+- All interactions with any connected resource can be monitored, logged, and tracked.
+- Now, private resources can securely communicate with other resources that aren't on the network.
+
+Other common legacy app scenarios:
 
 - An internal admin tool.
 - Control panel for networking devices.
 
 ## Example Modern Apps
 
-Teleport Application Access supports web applications such as internal web
-tools and infrastructure software like:
+Teleport Application Access also supports modern web applications such as internal web
+tools and infrastructure software:
 
 - Kubernetes Dashboard.
 - Grafana.

docs/pages/faq.mdx

@@ -42,7 +42,7 @@ in file configuration). As defined in [Adding a node located behind NAT - Telepo
 
 ### Can nodes use a single port for reverse tunnels?
 
-Yes, Teleport supports tunnel multiplexing on a single port.  Set the `tunnel_listen_addr` to use the same port as the `web_listen_addr` address setting in the `proxy_service` configuration. Teleport will automatically use multiplexing with that configuration.
+Yes, Teleport supports tunnel multiplexing on a single port. Set the `tunnel_listen_addr` to use the same port as the `web_listen_addr` address setting in the `proxy_service` configuration. Teleport will automatically use multiplexing with that configuration.
 
 ### What are Teleport's scalability and hardware recommendations?
 

docs/pages/index.mdx

@@ -17,7 +17,7 @@ With Teleport you can:
 
 - Teleport replaces legacy keys and shared secrets with short-lived X.509 and SSH certificates
   for services and users.
-- It proxies and inspects SSH, Kubernetes, Web and Database protocols.
+- It proxies and inspects SSH, Kubernetes, Web, and Database protocols.
   For example for SSH, it controls the session from the start
   and captures a session recording and in-kernel system calls using BPF.
 - It removes a need for VPN and can connect multiple regions and organizations

docs/pages/kubernetes-access/controls.mdx

@@ -200,7 +200,7 @@ $ tctl users add joe --roles="admins"
 
 ## Kubernetes Labels
 
-Label each cluster with key value pairs describing the cluster:
+Label each cluster with key-value pairs describing the cluster:
 
 <Tabs>
   <TabItem label="Helm">

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

@@ -8,7 +8,7 @@ description: Getting started with Teleport Kubernetes Access
 Let's deploy Teleport in a Kubernetes with SSO and Audit logs:
 
 - Install Teleport in a Kubernetes cluster.
-- Set up Single Sign On
+- Set up Single Sign On (SSO).
 - Capture and play back Kubernetes commands.
 
 ## Follow along with our video guide
@@ -158,7 +158,7 @@ for web apps using [application access](../application-access/introduction.mdx).
 </Tabs>
 
 The first request to Teleport's API will take a bit longer because it gets
-a cert from [Letsencrypt](https://letsencrypt.org).
+a cert from [Let's Encrypt](https://letsencrypt.org).
 Teleport will respond back with a discovery info:
 
 ```bash

docs/pages/kubernetes-access/guides/federation.mdx

@@ -18,12 +18,12 @@ login](../../cli-docs.mdx#tsh-login).
 
 For example, consider the following setup:
 
-- There are three Teleport/Kubernetes clusters: "main", "east" and "west". These
+- There are three Teleport/Kubernetes clusters: `main`, `east`, and `west`. These
   are the names set in `cluster_name` setting in their configuration files.
-- The clusters "east" and "west" are trusted clusters for "main".
-- Users always authenticate against "main" but use their certificates to access
+- The clusters `east` and `west` are trusted clusters for `main`.
+- Users always authenticate against `main` but use their certificates to access
   SSH nodes and Kubernetes API in all three clusters.
-- The DNS name of the main proxy server is "main.example.com"
+- The DNS name of the main proxy server is `main.example.com`.
 
 In this scenario, users usually login using this command:
 

docs/pages/kubernetes-access/guides/migration.mdx

@@ -11,9 +11,9 @@ described below.
 
 The main changes in 5.0 are:
 
-- new `kubernetes_service` configuration section in `teleport.yaml`, decoupled
+- New `kubernetes_service` configuration section in `teleport.yaml`, decoupled
   from `proxy_service`
-- support for multiple Kubernetes clusters per Teleport cluster (replaces the
+- Support for multiple Kubernetes clusters per Teleport cluster (replaces the
   need to use [Trusted Clusters](../../admin-guide.mdx#trusted-clusters) to achieve this)
 - RBAC support for Kubernetes clusters
 

docs/pages/kubernetes-access/introduction.mdx

@@ -5,14 +5,14 @@ description: Teleport Kubernetes Access introduction, demo and resources
 
 Teleport provides a unified access for Kubernetes clusters.
 
-- Users can receive short-lived certificates using Single Sign-On and switch between clusters without relogins.
-- Admins can use roles to implement policies "developers must not access production" and enforce
+- Users can receive short-lived certificates using Single Sign-On (SSO) and switch between clusters without relogins.
+- Admins can use *roles* to implement policies like the best practice that *developers must not access production* and enforce
   dual authorization using [access workflows](../enterprise/workflow/index.mdx) for privileged operations.
 - Organizations can achieve compliance by capturing `kubectl` events and session recordings for `kubectl`.
 
 ## SSO and Audit for Kubernetes Clusters
 
-Set up single sign on, capture audit events and sessions with Teleport running in a Kubernetes cluster.
+Set up SSO, capture audit events and sessions with Teleport running in a Kubernetes cluster.
 
 <video
   muted

docs/pages/user-manual.mdx

@@ -487,13 +487,13 @@ db-1          xxxxxxxxx     10.0.20.31:3022    kernel:4.4
 db-2          xxxxxxxxx     10.0.20.41:3022    kernel:4.2
 ```
 
-Similarly, if you want to SSH into `db-1` inside the "production" cluster:
+Similarly, if you want to SSH into `db-1` inside the `production` cluster:
 
 ```bash
 $ tsh --proxy=work ssh --cluster=production db-1
 ```
 
-This is possible even if nodes in the "production" cluster are located behind a
+This is possible even if nodes in the `production` cluster are located behind a
 firewall without open ports. This works because the `production` cluster
 establishes a reverse SSH tunnel back into `work` proxy, and this tunnel is used
 to establish inbound SSH connections.