Replace Notices with Docusaurus syntax

See gravitational/docs-website#94 Relevant commands are included below to make reproducing this work easier. 1. Replace all `Notice` tags with `Admonition` tags. 2. Add `type="info"` if an Admonition is missing a type. To find instances: ``` find docs/pages -name "*.mdx" -exec awk ' BEGIN{a=0} a==0 && /<Admonition/{ a = 1 } a==1 && /type/{t = 1} a==1 && />/{ a = 0; if(t == 0) print FILENAME ":" FNR }' {} \; ``` 3. Replace `type="notice"` with `type="note"`. To find instances: ``` find docs/pages -name "*.mdx" -exec awk ' BEGIN{a=0} a==0 && /<Admonition/{ a = 1 } a==1 && /type="notice"/{t = 1} a==1 && />/{ a = 0; if(t == 1) print FILENAME ":" FNR }' {} \; ```
gravitational · Feb 28, 2025 · 2c01f52 · 2c01f52
1 parent 0212ee6
commit 2c01f52
Show file tree

Hide file tree

Showing 95 changed files with 300 additions and 300 deletions.
diff --git a/docs/pages/admin-guides/access-controls/access-monitoring.mdx b/docs/pages/admin-guides/access-controls/access-monitoring.mdx
@@ -15,7 +15,7 @@ or database sessions without MFA) and provides users with recommendations on sug
 
 Users are able to write their own custom access monitoring queries by querying the audit log.
 
-<Admonition type="notice">
+<Admonition type="note">
   Access Monitoring is not currently supported with External Audit Storage
   in Teleport Enterprise (Cloud). This functionality will be
   enabled in a future Teleport release.

diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx
@@ -199,7 +199,7 @@ approve or deny the request:
 
 ![Review access request](../../../../img/enterprise/plugins/datadog/review-access-request.png)
 
-<Admonition title="Auditing Access Requests">
+<Admonition type="info" title="Auditing Access Requests">
 
 When the Datadog plugin sends a notification, anyone who receives the
 notification can follow the enclosed link to an Access Request URL. While users

diff --git a/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx b/docs/pages/admin-guides/access-controls/access-request-plugins/opsgenie.mdx
@@ -130,7 +130,7 @@ or in the schedules specified by `teleport.dev/notify-services` annotation in th
 
 (!docs/pages/includes/plugins/resolve-request.mdx!)
 
-<Admonition title="Auditing Access Requests">
+<Admonition type="info" title="Auditing Access Requests">
 
 When the Opsgenie plugin sends a notification, anyone who receives the
 notification can follow the enclosed link to an Access Request URL. While users

diff --git a/...ages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx b/...ages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx
@@ -181,13 +181,13 @@ the URL scheme and port. (If you're using a local SMTP server for testing, use
 If you are running the email plugin on a Linux host, fill in `username` and
 `password`.
 
-<Notice type="tip">
+<Admonition type="tip">
 
 You can also save your password to a separate file and assign `password_file` to
 the file's path. The plugin reads the file and uses the file's content as the
 password.
 
-</Notice>
+</Admonition>
 
 If you are deploying the email plugin on Kubernetes:
 

diff --git a/...pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx b/...pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx
@@ -127,13 +127,13 @@ following:
 
 ![Jira board setup](../../../../img/enterprise/plugins/jira/board-setup.png)
 
-<Notice type="warning">
+<Admonition type="warning">
 
 If your project board does not contain these (and only these) columns, each with
 a status of the same name, the Jira Access Request plugin will behave in
 unexpected ways. Remove all other columns and statuses.
 
-</Notice>
+</Admonition>
 
 Click **Back to board** to review your changes.
 
@@ -409,12 +409,12 @@ Request Reviewed` in the Teleport Web UI.
 
 ## Step 7/7. Set up systemd
 
-<Notice type="tip">
+<Admonition type="tip">
 
 This step is only applicable if you are running the Teleport Jira plugin on a
 Linux machine.
 
-</Notice>
+</Admonition>
 
 In production, we recommend starting the Teleport plugin daemon via an init
 system like systemd. Here's the recommended Teleport plugin service unit file

diff --git a/...admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx b/...admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx
@@ -320,7 +320,7 @@ the Teleport Web UI and either approve or deny the request.
 
 (!docs/pages/includes/plugins/resolve-request.mdx!)
 
-<Admonition title="Auditing Access Requests">
+<Admonition type="info" title="Auditing Access Requests">
 
 When the Mattermost plugin posts an Access Request notification to a channel,
 anyone with access to the channel can view the notification and follow the link.

diff --git a/...ages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx b/...ages/admin-guides/access-controls/access-request-plugins/ssh-approval-slack.mdx
@@ -364,7 +364,7 @@ Once the request is resolved, the Slack bot will add an emoji reaction of ✅ or
 ❌ to the Slack message for the Access Request, depending on whether the request
 was approved or denied.
 
-<Admonition title="Auditing Access Requests">
+<Admonition type="info" title="Auditing Access Requests">
 
 When the Slack plugin posts an Access Request notification to a channel, anyone
 with access to the channel can view the notification and follow the link. While

diff --git a/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx b/docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx
@@ -39,13 +39,13 @@ user named `bob`.
 
 1. Repeat these steps to assign the `reviewer` role to a user named `bob`.
 
-<Notice type="tip">
+<Admonition type="tip">
 
 Consider defining custom roles to limit the scope of a requester or reviewer's
 permissions. Read the [Access Request
 Configuration](./access-request-configuration.mdx) guide for available options.
 
-</Notice>
+</Admonition>
 
 ## Step 2/6. Search for resources
 
@@ -194,11 +194,11 @@ $ tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab
 Successfully submitted review.  Request state: APPROVED
 ```
 
-<Notice type="tip">
+<Admonition type="tip">
 Check out our
 [Access Request Integrations](#integrating-with-an-external-tool)
 to notify the right people about new Access Requests.
-</Notice>
+</Admonition>
 
 ## Step 5/6. Access the requested resource
 

diff --git a/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx b/docs/pages/admin-guides/access-controls/compliance-frameworks/soc2.mdx
@@ -7,12 +7,12 @@ h1: SOC 2 Compliance for SSH, Kubernetes, Databases, Desktops, and Web Apps
 Teleport is designed to meet SOC 2 requirements for the purposes of accessing infrastructure, change management, and system operations. This document outlines a high
 level overview of how Teleport can be used to help your company to become SOC 2 compliant.
 
-<Notice type="warning">
+<Admonition type="warning">
 
   SOC 2 compliance features are only available for Teleport Enterprise and
   Teleport Enterprise Cloud.
 
-</Notice>
+</Admonition>
 
 ## Achieving SOC 2 Compliance with Teleport
 SOC 2 or Service Organization Controls were developed by the American Institute of CPAs (AICPA). They are based on five trust services criteria: security, availability, processing integrity, confidentiality, and privacy.

diff --git a/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx b/docs/pages/admin-guides/access-controls/device-trust/enforcing-device-trust.mdx
@@ -4,7 +4,7 @@ description: Learn how to enforce trusted devices with Teleport
 videoBanner: gBQyj_X1LVw
 ---
 
-<Admonition type="notice" title="Supported Resources">
+<Admonition type="note" title="Supported Resources">
 Device Trust fully supports SSH, database and Kubernetes resources using
 cluster-wide or role-based enforcement.
 

diff --git a/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx b/docs/pages/admin-guides/access-controls/device-trust/jamf-integration.mdx
@@ -31,7 +31,7 @@ and behavior.
 
 ## Step 1/4. Create Jamf API credentials
 
-<Admonition type="notice" title="v16.0.0 or lower">
+<Admonition type="note" title="v16.0.0 or lower">
   Teleport versions v16.0.0 or lower don't support Jamf API credentials. Follow
   the instructions under [Using Jamf user and password authentication](
   #optional-using-jamf-user-and-password-authentication) instead.
@@ -335,7 +335,7 @@ ssh_service:
 
 ## Optional: Using Jamf user and password authentication
 
-<Admonition type="notice" title="v16.1.0+">
+<Admonition type="note" title="v16.1.0+">
   Teleport versions v16.1.0 and higher support [Jamf API credentials](
   #step-14-create-jamf-api-credentials). Prefer using API credentials instead
   of username and password authentication.

diff --git a/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx b/docs/pages/admin-guides/access-controls/guides/dual-authz.mdx
@@ -16,11 +16,11 @@ the approval of two team members for a privileged role `elevated-access`.
 The steps below describe how to use Teleport with Mattermost. You can also
 [integrate with many other providers](../access-requests/access-requests.mdx).
 
-<Notice type="warning">
+<Admonition type="warning">
 
 Dual Authorization requires Teleport Enterprise.
 
-</Notice>
+</Admonition>
 
 ## Prerequisites
 

diff --git a/docs/pages/admin-guides/access-controls/guides/headless.mdx b/docs/pages/admin-guides/access-controls/guides/headless.mdx
@@ -155,7 +155,7 @@ $ tsh ssh --headless --proxy=proxy.example.com --user=alice alice@server01
 alice@server01 $
 ```
 
-<Notice type="note">
+<Admonition type="note">
   The Teleport user, `--user` parameter, is the Teleport user requesting Headless WebAuthn activity.
   If no `--user` parameter or environment variables set the OS user in the machine terminal is used.
 
@@ -165,7 +165,7 @@ alice@server01 $
   an access denied message. The user could receive an access denied message after being approved
   for their Headless WebAuthn activity since the same access rights are granted or denied as if running from
   your local terminal.
-</Notice>
+</Admonition>
 
 ## Optional: Teleport Connect
 

diff --git a/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx b/docs/pages/admin-guides/access-controls/guides/mfa-for-admin-actions.mdx
@@ -21,7 +21,7 @@ Examples of administrative actions include, but are not limited to:
 This is an advanced security feature that protects users against compromises of
 their on-disk Teleport certificates.
 
-<Notice type="warning">
+<Admonition type="warning">
   When MFA for administrative actions is enabled, user certificates produced
   with `tctl auth sign` will no longer be suitable for automation due to the
   additional MFA checks.
@@ -33,7 +33,7 @@ their on-disk Teleport certificates.
   Certificates produced with `tctl auth sign` directly on an Auth Service
   instance using the super-admin role are not subject to MFA checks to support
   legacy self-hosted setups.
-</Notice>
+</Admonition>
 
 ## Prerequisites
 
@@ -51,10 +51,10 @@ their on-disk Teleport certificates.
 MFA for administrative actions is automatically enforced for clusters where
 WebAuthn is the only form of multi-factor authentication allowed.
 
-<Notice type="note">
+<Admonition type="note">
   In a future major version, Teleport may enforce MFA for administrative actions
   for a wider range of cluster configurations.
-</Notice>
+</Admonition>
 
 Edit the `cluster_auth_preference` resource:
 

diff --git a/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx b/docs/pages/admin-guides/access-controls/guides/per-session-mfa.mdx
@@ -16,12 +16,12 @@ when starting new:
 This is an advanced security feature that protects users against compromises of
 their on-disk Teleport certificates.
 
-<Notice type="note">
+<Admonition type="note">
   In addition to per-session MFA, enable login MFA in your SSO provider and/or
   for all [local Teleport
   users](../../../reference/access-controls/authentication.mdx)
   to improve security.
-</Notice>
+</Admonition>
 
 ## Prerequisites
 

diff --git a/docs/pages/admin-guides/access-controls/guides/webauthn.mdx b/docs/pages/admin-guides/access-controls/guides/webauthn.mdx
@@ -172,12 +172,12 @@ when starting new:
 - Application sessions
 - Desktop sessions
 
-<Notice type="note">
+<Admonition type="note">
   In addition to per-session MFA, enable login MFA in your SSO provider and/or
   for all [local Teleport
   users](../../../reference/access-controls/authentication.mdx)
   to improve security.
-</Notice>
+</Admonition>
 
 To enforce MFA checks for all roles, edit your cluster authentication
 configuration:
@@ -413,7 +413,7 @@ layer by re-verifying user identity immediately before any admin action, mitigat
 By adopting these advanced security measures, you can create a robust defense against IdP compromises and significantly reduce your organization's attack surface.
 In the following sections, we'll dive deeper into each of these recommendations, providing step-by-step guidance on implementation and best practices.
 
-<Notice type="warning">
+<Admonition type="warning">
   When MFA for administrative actions is enabled, user certificates produced
   with `tctl auth sign` will no longer be suitable for automation due to the
   additional MFA checks.
@@ -423,7 +423,7 @@ In the following sections, we'll dive deeper into each of these recommendations,
 
   Certificates produced with `tctl auth sign` directly on an Auth Service instance using the super-admin
   role are not subject to MFA checks to support legacy self-hosted setups.
-</Notice>
+</Admonition>
 
 ### Prerequisites
 
@@ -435,10 +435,10 @@ In the following sections, we'll dive deeper into each of these recommendations,
 
 MFA for administrative actions is automatically enforced for clusters where WebAuthn is the only form of multi-factor allowed.
 
-<Notice type="note">
+<Admonition type="note">
   In a future major version, Teleport may enforce MFA for administrative actions
   for a wider range of cluster configurations.
-</Notice>
+</Admonition>
 
 Examples of administrative actions include, but are not limited to:
 

diff --git a/docs/pages/admin-guides/access-controls/sso/github-sso.mdx b/docs/pages/admin-guides/access-controls/sso/github-sso.mdx
@@ -26,15 +26,15 @@ reading data from the OAuth 2.0 access token. In particular, the Auth Service:
   permissions. 
 - Assigns the user's Teleport username to their GitHub username.
 
-<Notice type="warning">
+<Admonition type="warning">
 
 GitHub usernames are not formatted as email addresses. As a result, any Teleport
 plugin that expects to send email to a user based on their Teleport username
 will not work as expected. For example, the [PagerDuty Access Request
 plugin](../access-request-plugins/ssh-approval-pagerduty.mdx) has this
 limitation.
 
-</Notice>
+</Admonition>
 
 ## Prerequisites
 

diff --git a/docs/pages/admin-guides/api/access-plugin.mdx b/docs/pages/admin-guides/api/access-plugin.mdx
@@ -20,12 +20,12 @@ spreadsheet, with links to allow or deny each request.
 
 ![The result of the plugin](../../../img/api/google-sheets.png)
 
-<Notice type="danger">
+<Admonition type="danger">
 
 The plugin we will build in this guide is intended as a learning tool. **Do not
 connect it to your production Teleport cluster.**  Use a demo cluster instead.
 
-</Notice>
+</Admonition>
 
 ## Prerequisites
 
@@ -428,14 +428,14 @@ In your spreadsheet, click "View Access Request" next to your new request. Sign
 into the Teleport Web UI as your original user. When you submit your review,
 e.g., deny the request, the new status will appear within the spreadsheet.
 
-<Notice type="danger">
+<Admonition type="danger">
 
 Access Request plugins must not enable reviewing Access Requests via the plugin,
 and must always refer a reviewer to the Teleport Web UI to complete the review.
 Otherwise, an unauthorized party could spoof traffic to the plugin and escalate
 privileges. 
 
-</Notice>
+</Admonition>
 
 ## Next steps
 

diff --git a/docs/pages/admin-guides/api/automatically-register-agents.mdx b/docs/pages/admin-guides/api/automatically-register-agents.mdx
@@ -29,12 +29,12 @@ Automatic registration consists of the following steps:
   infrastructure, use the Teleport API to deregister the resource and, if
   necessary, remove the Teleport service proxying the resource.
 
-<Notice type="danger">
+<Admonition type="danger">
 
 The program we build in this guide is intended as a learning tool. **Do not
 connect it to your production Teleport cluster.**  Use a demo cluster instead.
 
-</Notice>
+</Admonition>
 
 ## Prerequisites
 
@@ -706,13 +706,13 @@ To deregister the Application Service instance manually, we call the
 `pruneAppServiceInstance` function to get the namespace, host ID, and name of
 the Application Service instance to delete.
 
-<Notice type="tip">
+<Admonition type="tip">
 
 While Teleport namespaces are deprecated, they still appear occasionally in the
 Teleport API client library. The only namespace that Teleport supports is called
 `default`.
 
-</Notice>
+</Admonition>
 
 Next, this function stops and removes the Application Service container
 associated with the `types.AppServer` we want to prune. The hostname of an

diff --git a/docs/pages/admin-guides/api/rbac.mdx b/docs/pages/admin-guides/api/rbac.mdx
@@ -20,12 +20,12 @@ This is especially useful for:
 In this guide, we will build a small demo application to show you how to
 generate Teleport roles using Teleport's API client library.
 
-<Notice type="danger">
+<Admonition type="danger">
 
 The program we will build in this guide is intended as a learning tool. **Do not
 connect it to your production Teleport cluster.**  Use a demo cluster instead.
 
-</Notice>
+</Admonition>
 
 ## Prerequisites
 

diff --git a/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx b/docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx
@@ -29,11 +29,11 @@ This guide will help you set up the service and enable Access Graph in your Tele
     ```
 - The node running the Access Graph service must be reachable from Teleport Auth Service and Proxy Service.
 
-<Notice type="warning">
+<Admonition type="warning">
     The deployment with Docker is suitable for testing and development purposes. For production deployments,
     consider using the Access Graph Helm chart to deploy this service on Kubernetes.
     Refer to [Helm chart for Access Graph](self-hosted-helm.mdx) for instructions.
-</Notice>
+</Admonition>
 
 ## Step 1/3. Set up Access Graph