gravitational · ptgott · Aug 24, 2023 · Aug 17, 2023 · Aug 18, 2023 · Aug 21, 2023
diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-discord.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-discord.mdx
@@ -323,9 +323,7 @@ should still check the Teleport audit log to ensure that the right users are
 reviewing the right requests.
 
 When auditing Access Request reviews, check for events with the type `Access
-Request Reviewed` in the Teleport Web UI <ScopedBlock scope={["oss",
-"enterprise"]}>and `access_request.review` if reviewing the audit log on the
-Auth Service host</ScopedBlock>.
+Request Reviewed` in the Teleport Web UI.
 
 </Admonition>
 

diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-mattermost.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-mattermost.mdx
@@ -29,20 +29,23 @@ Requests in the Proxy or Auth Service.
 
 ## Step 2/8. Install the Teleport Mattermost plugin
 
-<ScopedBlock scope={["enterprise", "oss"]}>
+<Tabs>
+<TabItem scope={["enterprise", "oss"]} label="Self-Hosted">
 
 We recommend installing Teleport plugins on the same host as the Teleport Proxy
 Service. This is an ideal location as plugins have a low memory footprint, and
 will require both public internet access and Teleport Auth Service access.
 
-</ScopedBlock>
+</TabItem>
 
-<ScopedBlock scope="cloud">
+<TabItem scope="cloud" label="Teleport Enterprise Cloud">
 
 Install the Teleport Mattermost plugin on a host that can access both your
 Teleport Proxy Service and your Mattermost deployment.
 
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 (!docs/pages/includes/plugins/install-access-request.mdx name="mattermost"!)
 
@@ -314,9 +317,7 @@ Requests, you should still check the Teleport audit log to ensure that the right
 users are reviewing the right requests.
 
 When auditing Access Request reviews, check for events with the type `Access
-Request Reviewed` in the Teleport Web UI <ScopedBlock scope={["oss",
-"enterprise"]}>and `access_request.review` if reviewing the audit log on the
-Auth Service host</ScopedBlock>.
+Request Reviewed` in the Teleport Web UI.
 
 </Admonition>
 

diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-msteams.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-msteams.mdx
@@ -509,9 +509,7 @@ should still check the Teleport audit log to ensure that the right users are
 reviewing the right requests.
 
 When auditing Access Request reviews, check for events with the type `Access
-Request Reviewed` in the Teleport Web UI <ScopedBlock scope={["oss",
-"enterprise"]}>and `access_request.review` if reviewing the audit log on the
-Auth Service host</ScopedBlock>.
+Request Reviewed` in the Teleport Web UI.
 
 </Admonition>
 

diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx
@@ -272,8 +272,9 @@ As with all Teleport users, the Teleport Auth Service authenticates the
 will need to request the credentials manually by *impersonating* the
 `access-plugin` role and user.
 
-<ScopedBlock scope={["oss", "enterprise"]}>If you are using `tctl` from the Auth
-Service host, you will already have impersonation privileges.</ScopedBlock>
+If you are running a self-hosted Teleport Enterprise cluster and are using
+`tctl` from the Auth Service host, you will already have impersonation
+privileges.
 
 To grant your user impersonation privileges for `access-plugin`, define a role
 called `access-plugin-impersonator` by pasting the following YAML document into
@@ -568,9 +569,7 @@ should still check the Teleport audit log to ensure that the right users are
 reviewing the right requests.
 
 When auditing Access Request reviews, check for events with the type `Access
-Request Reviewed` in the Teleport Web UI <ScopedBlock scope={[
-"enterprise"]}>and `access_request.review` if reviewing the audit log on the
-Auth Service host</ScopedBlock>.
+Request Reviewed` in the Teleport Web UI.
 
 </Admonition>
 

diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-slack.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-slack.mdx
@@ -365,9 +365,7 @@ should still check the Teleport audit log to ensure that the right users are
 reviewing the right requests.
 
 When auditing Access Request reviews, check for events with the type `Access
-Request Reviewed` in the Teleport Web UI <ScopedBlock scope={["oss",
-"enterprise"]}>and `access_request.review` if reviewing the audit log on the
-Auth Service host</ScopedBlock>.
+Request Reviewed` in the Teleport Web UI.
 
 </Admonition>
 

diff --git a/docs/pages/access-controls/access-requests/resource-requests.mdx b/docs/pages/access-controls/access-requests/resource-requests.mdx
@@ -13,16 +13,12 @@ under the hood.
 The Access Request API makes it easy to dynamically approve or deny these
 requests.
 
-<ScopedBlock scope={["oss"]}>
-
 Just-in-time Access Requests are a feature of Teleport Enterprise.
 Open-source Teleport users can get a preview of how Access Requests work by
 requesting a role via the Teleport CLI. Full Access Request functionality,
 including Resource Access Requests and an intuitive and searchable UI are
 available in Teleport Enterprise.
 
-</ScopedBlock>
-
 ## Prerequisites
 
 (!docs/pages/includes/commercial-prereqs-tabs.mdx!)

diff --git a/docs/pages/access-controls/getting-started.mdx b/docs/pages/access-controls/getting-started.mdx
@@ -56,7 +56,8 @@ will be able to act as a system administrator and auditor at the same time.
 Next, follow the instructions to set up an authentication connector that maps
 users within your SSO solution to Teleport roles.
 
-  <ScopedBlock scope={["oss"]}>
+<Tabs>
+  <TabItem label="Teleport Community Edition" scope={["oss"]}>
 
     Save the file below as `github.yaml` and update the fields. You will need to
     set up a
@@ -93,9 +94,9 @@ users within your SSO solution to Teleport roles.
     $ tctl create github.yaml
     ```
 
-  </ScopedBlock>
+  </TabItem>
 
-  <ScopedBlock scope={["enterprise", "cloud"]}>
+  <TabItem label="Commercial Editions"  scope={["enterprise", "cloud"]}>
 
   Create a SAML or OIDC application that Teleport can integrate with, then
   create an authentication connector that maps users within your application to
@@ -152,7 +153,8 @@ users within your SSO solution to Teleport roles.
   </TabItem>
   </Tabs>
 
-  </ScopedBlock>
+  </TabItem>
+</Tabs>
 
 ## Step 3/3. Create a custom role
 
@@ -215,3 +217,4 @@ $ tctl get roles --format text
 
 - [Mapping SSO and local users traits with role templates](./guides/role-templates.mdx)
 - [Create certs for CI/CD using impersonation](./guides/impersonation.mdx)
+
diff --git a/docs/pages/access-controls/guides/dual-authz.mdx b/docs/pages/access-controls/guides/dual-authz.mdx
@@ -208,13 +208,10 @@ Bob can also assume granted Access Request roles using Web UI:
 
 ![Teleport Assume](../../../img/access-controls/dual-authz/teleport-7-bob-assume.png)
 
-{/* TODO: This H2 will show up in the table of contents when this section is invisible.
-We need a way to hide invisible H2s from the TOC. */}
-<ScopedBlock scope={["enterprise"]}>
 
 ## Troubleshooting
 
-### Cert errors in self-hosted deployments
+### Certificate errors in self-hosted deployments
 
 You may be getting certificate errors if Teleport's Auth Service is missing an address in the server certificate:
 
@@ -232,5 +229,3 @@ To fix the problem, update the Auth Service with a public address, and restart T
 auth_service:
   public_addr: ['localhost:3025', 'example.com:3025']
 ```
-
-</ScopedBlock>
diff --git a/docs/pages/access-controls/guides/hardware-key-support.mdx b/docs/pages/access-controls/guides/hardware-key-support.mdx
@@ -129,8 +129,6 @@ role or to that cluster must use their hardware key for all Teleport requests.
 Affected users will be prompted to connect and touch their YubiKey to sign in. 
 The first time users sign in with their hardware key they might be required to immediately sign in again.
 
-<ScopedBlock scope={["oss","enterprise"]}>
-
 ```code
 $ tsh login --user=dev --proxy=proxy.example.com:3080
 # Enter password for Teleport user dev:
@@ -142,28 +140,8 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
 #   Logged in as:       dev
 #   Cluster:            example.com
 #   ...
-
 ```
 
-</ScopedBlock>
-
-<ScopedBlock scope={["cloud"]}>
-
-```code
-$ tsh login --user=dev --proxy=proxy.example.com:3080
-# Enter password for Teleport user dev:
-# Unmet private key policy "hardware_key_touch".
-# Relogging in with hardware-backed private key.
-# Enter password for Teleport user dev:
-# Tap your YubiKey
-# > Profile URL:        https://example.com
-#   Logged in as:       dev
-#   Cluster:            example.com
-#   ...
-```
-
-</ScopedBlock>
-
 Affected users with existing sessions that aren't backed by a hardware key are prompted to sign in again
 on their next request. For example:
 
@@ -258,4 +236,4 @@ Detected security key tap
   Logged in as:       dev
   Cluster:            root.example.com
   ...
-```
+```
diff --git a/docs/pages/access-controls/guides/impersonation.mdx b/docs/pages/access-controls/guides/impersonation.mdx
@@ -118,22 +118,25 @@ $ tctl users add alice  --roles=impersonator,access
 
 Alice can log in using `tsh` and issue a cert for `jenkins`:
 
-<ScopedBlock scope={["oss", "enterprise"]}>
+<Tabs>
+<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 
 ```code
 $ tsh login --proxy=proxy.example.com --user=alice --auth=local
 $ tctl auth sign --user=jenkins --format=openssh --out=jenkins --ttl=240h
 ```
 
-</ScopedBlock>
-<ScopedBlock scope={["cloud"]}>
+</TabItem>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 
 ```code
 $ tsh login --proxy=mytenant.teleport.sh --user=alice --auth=local
 $ tctl auth sign --user=jenkins --format=openssh --out=jenkins --ttl=240h
 ```
 
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 Here is an example of how Alice can use the keys:
 
@@ -310,7 +313,8 @@ scanner.
 
 Alice will need to log in again to receive the newly updated traits:
 
-<ScopedBlock scope={["oss", "enterprise"]}>
+<Tabs>
+<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 
 ```code
 # Once Alice logs in again, she will receive a new certificate with updated roles.
@@ -319,8 +323,8 @@ $ tsh login --proxy=teleport.example.com --user=alice --auth=local
 $ tctl auth sign --user=security-scanner --format=openssh --out=security-scanner --ttl=10h
 ```
 
-</ScopedBlock>
-<ScopedBlock scope={["cloud"]}>
+</TabItem>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 
 ```code
 # Once Alice logs in again, she will receive a new certificate with updated roles.
@@ -329,7 +333,9 @@ $ tsh login --proxy=mytenant.teleport.sh --user=alice --auth=local
 $ tctl auth sign --user=security-scanner --format=openssh --out=security-scanner --ttl=10h
 ```
 
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 ### Filter fields
 
@@ -343,3 +349,4 @@ Here is an explanation of the fields used in the `where` conditions within this
 
 Check out our [predicate language](../../reference/predicate-language.mdx#scoping-allowdeny-rules-in-role-resources) 
 guide for a more in depth explanation of the language.
+
diff --git a/docs/pages/access-controls/guides/locking.mdx b/docs/pages/access-controls/guides/locking.mdx
@@ -199,7 +199,8 @@ the last known locks. This decision strategy is encoded as one of the two modes:
   guaranteed to be up to date
 - `best_effort` mode keeps relying on the most recent locks
 
-<ScopedBlock scope={["oss", "enterprise"]}>
+<Tabs>
+<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 
 The cluster-wide mode defaults to `best_effort`. You can set up the default
 locking mode via API or CLI using a `cluster_auth_preference` resource or static
@@ -240,8 +241,8 @@ configuration file:
   </TabItem>
 </Tabs>
 
-</ScopedBlock>
-<ScopedBlock scope={["cloud"]}>
+</TabItem>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 
 The cluster-wide mode defaults to `best_effort`. You can set up the default
 locking mode via API or CLI using a `cluster_auth_preference` resource:
@@ -265,7 +266,9 @@ $ tctl create -f cap.yaml
 # cluster auth preference has been updated
 ```
 
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 It is also possible to configure the locking mode for a particular role:
 
@@ -285,3 +288,4 @@ there is no user involved, the mode is taken from the cluster-wide setting.
 With multiple potentially conflicting locking modes (the cluster-wide default
 and the individual per-role settings) a single occurrence of `strict` suffices
 for the local lock view to become evaluated strictly.
+
diff --git a/docs/pages/access-controls/guides/passwordless.mdx b/docs/pages/access-controls/guides/passwordless.mdx
@@ -102,7 +102,8 @@ passwordless registration.
 To enable passwordless by default, add `connector_name: passwordless` to your
 cluster configuration:
 
-<ScopedBlock scope={["oss", "enterprise"]}>
+<Tabs>
+<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 <Tabs>
   <TabItem label="Static Config">
     Auth Server `teleport.yaml` file:
@@ -142,9 +143,9 @@ cluster configuration:
     ```
   </TabItem>
 </Tabs>
-</ScopedBlock>
+</TabItem>
 
-<ScopedBlock scope={["cloud"]}>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 Create a `cap.yaml` file or get the existing configuration using
 `tctl get cluster_auth_preference`:
 
@@ -167,7 +168,9 @@ Update the configuration:
 $ tctl create -f cap.yaml
 # cluster auth preference has been updated
 ```
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 ## Troubleshooting
 
@@ -241,7 +244,8 @@ $ tsh webauthnwin diag
 If you want to forbid passwordless access to your cluster, add `passwordless:
 false` to your configuration:
 
-<ScopedBlock scope={["oss", "enterprise"]}>
+<Tabs>
+<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 <Tabs>
   <TabItem label="Static Config">
     Auth Server `teleport.yaml` file:
@@ -282,9 +286,9 @@ false` to your configuration:
     ```
   </TabItem>
 </Tabs>
-</ScopedBlock>
+</TabItem>
 
-<ScopedBlock scope={["cloud"]}>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 Create a `cap.yaml` file or get the existing configuration using
 `tctl get cluster_auth_preference`:
 
@@ -307,4 +311,7 @@ Update the configuration:
 $ tctl create -f cap.yaml
 # cluster auth preference has been updated
 ```
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
+