gravitational · ptgott · Aug 24, 2023 · Aug 17, 2023 · Aug 18, 2023 · Aug 21, 2023
diff --git a/docs/pages/access-controls/access-request-plugins/opsgenie.mdx b/docs/pages/access-controls/access-request-plugins/opsgenie.mdx
@@ -122,8 +122,6 @@ 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-discord.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-discord.mdx
@@ -351,9 +351,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>
 
 <Tabs>
 <TabItem label="Download">
@@ -339,9 +342,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
@@ -399,9 +399,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
@@ -288,8 +288,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
@@ -598,9 +599,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
@@ -405,9 +405,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
@@ -33,57 +33,66 @@ Teleport Enterprise contains two additional preset roles: `reviewer` and `reques
 - The `requester` role authorizes users to request resources.
 </Details>
 
-<ScopedBlock scope={["oss"]}>
+<Tabs>
+<TabItem scope={["oss"]} label="Teleport Community Edition">
 Invite the local user Alice as cluster `editor`:
 
 ```code
 $ tctl users add alice --roles=editor
 ```
-</ScopedBlock>
-<ScopedBlock scope={["enterprise", "cloud"]}>
+</TabItem>
+<TabItem scope={["enterprise", "cloud"]} label="Commercial">
 Invite the local user Alice as cluster `editor` and `reviewer`:
 
 ```code
 $ tctl users add alice --roles=editor,reviewer
 ```
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 Once Alice signs up, she will be able to edit cluster configuration. You can list
 users and their roles using `tctl users ls`.
 
-<ScopedBlock scope={"oss"}>
+<Tabs>
+<TabItem scope={"oss"} label="Teleport Community Edition">
 ```code
 $ tctl users ls
 
 # User                 Roles
 # -------------------- --------------
 # alice                editor
 ```
-</ScopedBlock>
-<ScopedBlock scope={["enterprise", "cloud"]}>
+</TabItem>
+<TabItem scope={["enterprise", "cloud"]} label="Commercial">
 ```code
 $ tctl users ls
 
 # User                 Roles
 # -------------------- --------------
 # alice                editor, reviewer
 ```
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 You can update the user's roles using the `tctl users update` command:
 
-<ScopedBlock scope={"oss"}>
+<Tabs>
+<TabItem scope={"oss"} label="Teleport Community Edition">
 ```code
 # Once Alice logs back in, she will be able to view audit logs
 $ tctl users update alice --set-roles=editor,auditor
 ```
-</ScopedBlock>
-<ScopedBlock scope={["enterprise", "cloud"]}>
+</TabItem>
+<TabItem scope={["enterprise", "cloud"]} label="Commercial">
 ```code
 # Once Alice logs back in, she will be able to view audit logs
 $ tctl users update alice --set-roles=editor,reviewer,auditor
 ```
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 Because Alice has two or more roles, permissions from those roles create a union. She
 will be able to act as a system administrator and auditor at the same time.
@@ -93,7 +102,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
@@ -130,9 +140,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
@@ -189,7 +199,8 @@ users within your SSO solution to Teleport roles.
   </TabItem>
   </Tabs>
 
-  </ScopedBlock>
+  </TabItem>
+</Tabs>
 
 ## Step 3/3. Create a custom role
 
@@ -252,3 +263,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
@@ -127,7 +127,8 @@ 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"]}>
+<Tabs>
+<TabItem scope={["oss"]} label="Teleport Community Edition">
 
 ```code
 $ tsh login --user=dev --proxy=proxy.example.com:3080
@@ -143,9 +144,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
 
 ```
 
-</ScopedBlock>
+</TabItem>
 
-<ScopedBlock scope={["enterprise"]}>
+<TabItem scope={["enterprise"]} label="Teleport Enterprise">
 
 ```code
 $ tsh login --user=dev --proxy=proxy.example.com:3080
@@ -160,9 +161,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
 #   ...
 ```
 
-</ScopedBlock>
+</TabItem>
 
-<ScopedBlock scope={["cloud"]}>
+<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
 
 ```code
 $ tsh login --user=dev --proxy=proxy.example.com:3080
@@ -177,7 +178,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
 #   ...
 ```
 
-</ScopedBlock>
+</TabItem>
+
+</Tabs>
 
 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:

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.
+