Mention Teleport Cloud in some of our guides (#10526)

Backports #9989

* Mention Teleport Cloud in some of our guides

- Mention Teleport Cloud in the  Desktop Access guide
  prerequisites
- Minor style tweak to the K8s Agent guide
- Add a Cloud compatibility note to the Kubernetes cluster
  guide
- Make Cloud compatibility more explicit in the multiple-clusters
  guide
- Clarify the EC2 tag guide's relationship to Cloud (also add some
  general clarity tweaks)

* Respond to PR feedback

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

@@ -19,12 +19,22 @@ Desktop Access and log into a Windows desktop from that domain.
 
 This guide requires you to have:
 
-- An Active Directory domain, configured for LDAPS (Teleport requires an encrypted LDAP connection)
+- An Active Directory domain, configured for LDAPS (Teleport requires an
+  encrypted LDAP connection)
+
 - Access to a Domain Controller
-- An existing Teleport cluster and user, version 8.0 or newer
-  - See [Teleport Getting Started](../getting-started.mdx) if you're new to Teleport
-- A Linux server to run the Teleport Desktop Access service on
-  - You can reuse an existing server running any other Teleport instance
+
+- An existing Teleport cluster with one of the following versions:
+
+  **Open Source or Enterprise:** version 8.0 or newer
+
+  **Teleport Cloud:** version 9.0 or newer
+
+  See [Teleport Getting Started](../getting-started.mdx) if you're new to Teleport.
+
+- A Linux server to run the Teleport Desktop Access service on. 
+
+  You can reuse an existing server running any other Teleport instance.
 
 ## Step 1/6. Create a restrictive service account
 
@@ -99,8 +109,10 @@ dsacls "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuratio
   domain).
 </Admonition>
 
-The Teleport service account is only needed to authenticate over LDAP, meaning that it needn't be able to login to Windows machines like an ordinary user.
-Restrict it from doing so by creating a new Group Policy Object (GPO) linked to your entire domain, and then deny it interactive login.
+The Teleport service account is only needed to authenticate over LDAP, meaning
+that it needn't be able to log in to Windows machines like an ordinary user.
+Restrict it from doing so by creating a new Group Policy Object (GPO) linked to
+your entire domain, and then deny it interactive login.
 
 ### Create a GPO
 

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

@@ -1,10 +1,10 @@
 ---
-title: Connect Kubernetes Cluster to Teleport
-description: Connecting Kubernetes cluster to Teleport
+title: Connect a Kubernetes Cluster to Teleport
+description: Connecting a Kubernetes cluster to Teleport
 ---
 
 <Admonition type="notice" title="Editions">
-This guide works for Open Source and Enterprise, self-hosted or cloud-hosted editions of Teleport.
+You can use this guide with Teleport Open Source, Teleport Enterprise, and Teleport Cloud.
 </Admonition>
 
 ## Prerequisites

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

@@ -11,6 +11,14 @@ Let's deploy Teleport in a Kubernetes with SSO and Audit logs:
 - Set up Single Sign-On (SSO).
 - Capture and playback Kubernetes commands.
 
+<Details title="Teleport Cloud customers" scopeOnly={true} scope={["cloud"]}>
+This guide shows you how to deploy the Teleport Auth Service and Proxy Service on a Kubernetes cluster. These services are fully managed in Teleport Cloud.
+
+Instead, Teleport Cloud users should consult the following guide, which shows you how to connect a Teleport Kubernetes Service node to an existing Teleport cluster.
+
+[Connect a Kubernetes Cluster to Teleport](./agent.mdx)
+</Details>
+
 ## Follow along with our video guide
 
 <iframe

docs/pages/kubernetes-access/guides/multiple-clusters.mdx

@@ -3,11 +3,13 @@ title: Kubernetes Access Multiple Clusters
 description: Connecting a Kubernetes cluster to Teleport.
 ---
 
+This guide will show you how to use Teleport as an access plane for multiple Kubernetes clusters.
+
 ## Prerequisites
 
 - [Kubernetes](https://kubernetes.io) >= v(=kubernetes.major_version=).(=kubernetes.minor_version=).0
 - [Helm](https://helm.sh) >= (=helm.version=)
-- Installed and running Teleport Cluster
+- Installed and running Teleport cluster (Open Source, Enterprise, or Teleport Cloud)
 
 (!docs/pages/includes/helm.mdx!)
 
@@ -17,11 +19,12 @@ Teleport can act as an access plane for multiple Kubernetes clusters.
 We have set up the Teleport cluster `tele.example.com` in [SSO and Kubernetes](../getting-started.mdx).
 
 Let's start a lightweight agent in another Kubernetes cluster `cookie` and connect it to `tele.example.com`.
-We would need a join token from `tele.example.com`:
+
+We will need a join token from `tele.example.com`:
 
 ```code
 # A trick to save the pod ID in tele.example.com
-$ POD=$(kubectl get po -l app=teleport-cluster -o jsonpath='{.items[0].metadata.name}')
+$ POD=$(kubectl get pod -l app=teleport-cluster -o jsonpath='{.items[0].metadata.name}')
 # Create a join token for the cluster cookie to authenticate
 $ TOKEN=$(kubectl exec -ti "${POD?}" -- tctl nodes add --roles=kube --ttl=10000h --format=json | jq -r '.[0]')
 $ echo $TOKEN
@@ -33,8 +36,9 @@ Switch `kubectl` to the Kubernetes cluster `cookie` and run:
 # Add teleport chart repository
 $ helm repo add teleport https://charts.releases.teleport.dev
 
-# Install Kubernetes agent. It dials back to the Teleport cluster tele.example.com.
+# Deploy a Kubernetes agent. It dials back to the Teleport cluster tele.example.com.
 $ CLUSTER='cookie'
+# For Cloud users this will be similar to mytenant.teleport.sh
 $ PROXY='tele.example.com:443'
 $ helm install teleport-agent teleport/teleport-kube-agent --set kubeClusterName=${CLUSTER?} \
   --set proxyAddr=${PROXY?} --set authToken=${TOKEN?} --create-namespace --namespace=teleport-agent

docs/pages/setup/guides/ec2-tags.mdx

@@ -8,14 +8,14 @@ This section will explain how to setup Teleport node labels based on EC2 tags.
 
 ## Prerequisites
 
-- Teleport v(=teleport.version=) Open Source or Enterprise.
-- AWS instance running Teleport
+- Teleport v(=teleport.version=) Open Source, Enterprise, or Cloud
+- An AWS EC2 instance running a Teleport node
 
 ## Step 1/3. Deploy the script
 
-You’ll need a script on your instance which can query the AWS API and get the values of tags for you.
+You’ll need a script on your instance that can query the AWS API and get the values of your instance's tags for you. The Teleport node will then use these values to execute RBAC rules.
 
-Here’s one you can use:
+Here’s one script you can use:
 
 ```bash
 #!/bin/bash
@@ -47,13 +47,14 @@ $ chmod +x /usr/local/bin/get-tag.sh
 
 <Admonition type="note">
 For the script to work, you’ll need `curl`, `python` and the `aws` command line tool installed.
-`aws` comes from the awscli Python package, so you can install it using `pip3 install awscli` or similar.
-If you don’t have `python`, `pip3` or curl installed, look for them in your OS’s package manager.
+`aws` comes from the `awscli` Python package, so you can install it using `pip3 install awscli` or similar.
+
+If you don’t have `python`, `pip3` or `curl` installed, look for them via your OS’s package manager.
 </Admonition>
 
-## Step 2/3. Setup IAM role
+## Step 2/3. Set up an IAM role
 
-Grant your EC2 instance an IAM role which will allow it to query tags values for EC2 instances.
+Grant your EC2 instance an IAM role that will allow it to query tag values for EC2 instances.
 
 Here’s an example policy which you can add to an IAM role:
 
@@ -71,29 +72,29 @@ Here’s an example policy which you can add to an IAM role:
 }
 ```
 
-Once this is done, query the value of the test tag on your EC2 instance by running `/usr/local/bin/get-tag.sh` test:
+Once this is done, query the value of the test tag on your EC2 instance by running the following command:
 
-```bash
-[ec2-user@ip-172-31-26-55 ~]# /usr/local/bin/get-tag.sh test
+```code
+$ /usr/local/bin/get-tag.sh test
 tagValue
 ```
 
-## Step 3/3. Modify config file
+## Step 3/3. Modify the Teleport node config file
 
-Modify your Teleport config file `/etc/teleport.yaml` to add commands to run on your node:
+Modify the Teleport config file on your node (`/etc/teleport.yaml`) as follows:
 
 ```yaml
 teleport:
   ssh_service:
-  enabled: yes
-  listen_addr: 0.0.0.0:3022
-  commands:
-    - name: aws_tag_test
-      command: ['/usr/local/bin/get-tag.sh', 'test']
-      period: 1h
+    enabled: yes
+    listen_addr: 0.0.0.0:3022
+    commands:
+      - name: aws_tag_test
+        command: ['/usr/local/bin/get-tag.sh', 'test']
+        period: 1h
 ```
 
-This config will add a label with the key `aws_tag_test` to your instance - its value will be set to whatever the test tag is set to and it will be updated once every hour.
+This config will add a label with the key `aws_tag_test` to your instance. Its value will be set to whatever the `test` tag is set to and it will be updated once every hour.
 
 Restart Teleport on the node and you should see the new label appear:
 
@@ -124,6 +125,6 @@ spec:
     port_forwarding: true
 ```
 
-When assigned to Teleport users, this role will only allow them to log into Teleport nodes which have the `aws_tag_test` label with the value of tagValue, effectively gating access to infrastructure based on the value of the EC2 test tag.
+When assigned to Teleport users, this role will only allow them to log in to Teleport nodes which have the `aws_tag_test` label with the value of tagValue, effectively gating access to infrastructure based on the value of the EC2 test tag.
 
 By adding multiple commands to a Teleport node set to the values of different tags and then adding Teleport roles which reference them, you can build quite complex RBAC systems based off your EC2 tagging structure.