diff --git a/content/en/docs/admin/authorization/rbac.md b/content/en/docs/admin/authorization/rbac.md
index 1954a188d3..485ab5fab5 100644
--- a/content/en/docs/admin/authorization/rbac.md
+++ b/content/en/docs/admin/authorization/rbac.md
@@ -748,81 +748,87 @@ In order from most secure to least secure, the approaches are:
 
 1. Grant a role to an application-specific service account (best practice)
 
-   This requires the application to specify a `serviceAccountName` in its pod spec,
-   and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
+    This requires the application to specify a `serviceAccountName` in its pod spec,
+    and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
 
-   For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
-   
-   ```shell
-   kubectl create rolebinding my-sa-view \
-     --clusterrole=view \
-     --serviceaccount=my-namespace:my-sa \
-     --namespace=my-namespace
-   ```
+    For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
+
+    ```shell
+    kubectl create rolebinding my-sa-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:my-sa \
+      --namespace=my-namespace
+    ```
 
 2. Grant a role to the "default" service account in a namespace
 
-   If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+    If an application does not specify a `serviceAccountName`, it uses the "default" service account.
 
-   **NOTE:** Permissions given to the "default" service account are available to any pod in the namespace that does not specify a `serviceAccountName`.
+    {{< note >}}**NOTE:** Permissions given to the "default" service
+    account are available to any pod in the namespace that does not
+    specify a `serviceAccountName`.{{< /note >}}
 
-   For example, grant read-only permission within "my-namespace" to the "default" service account:
-   
-   ```shell
-   kubectl create rolebinding default-view \
-     --clusterrole=view \
-     --serviceaccount=my-namespace:default \
-     --namespace=my-namespace
-   ```
+    For example, grant read-only permission within "my-namespace" to the "default" service account:
 
-   Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
-   To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
-   
-   **NOTE:** Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
-   
-   ```shell
-   kubectl create clusterrolebinding add-on-cluster-admin \
-     --clusterrole=cluster-admin \
-     --serviceaccount=kube-system:default
-   ```
+    ```shell
+    kubectl create rolebinding default-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:default \
+      --namespace=my-namespace
+    ```
+
+    Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
+    To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
+
+    {{< note >}}**NOTE:** Enabling this means the "kube-system"
+    namespace contains secrets that grant super-user access to the
+    API.{{< /note >}}
+
+    ```shell
+    kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin \
+      --serviceaccount=kube-system:default
+    ```
 
 3. Grant a role to all service accounts in a namespace
 
-   If you want all applications in a namespace to have a role, no matter what service account they use,
-   you can grant a role to the service account group for that namespace.
+    If you want all applications in a namespace to have a role, no matter what service account they use,
+    you can grant a role to the service account group for that namespace.
 
-   For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
-   
-   ```shell
-   kubectl create rolebinding serviceaccounts-view \
-     --clusterrole=view \
-     --group=system:serviceaccounts:my-namespace \
-     --namespace=my-namespace
-   ```
+    For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
+
+    ```shell
+    kubectl create rolebinding serviceaccounts-view \
+      --clusterrole=view \
+      --group=system:serviceaccounts:my-namespace \
+      --namespace=my-namespace
+    ```
 
 4. Grant a limited role to all service accounts cluster-wide (discouraged)
 
-   If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
+    If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
 
-   For example, grant read-only permission across all namespaces to all service accounts in the cluster:
-   
-   ```shell
-   kubectl create clusterrolebinding serviceaccounts-view \
-     --clusterrole=view \
+    For example, grant read-only permission across all namespaces to all service accounts in the cluster:
+
+    ```shell
+    kubectl create clusterrolebinding serviceaccounts-view \
+      --clusterrole=view \
      --group=system:serviceaccounts
-   ```
+    ```
 
 5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)
 
-   If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
+    If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
 
-   **WARNING:** This allows any user with read access to secrets or the ability to create a pod to access super-user credentials.
+    {{< warning >}}**WARNING:** This allows any user with read access
+    to secrets or the ability to create a pod to access super-user
+    credentials.{{< /warning >}}
 
-   ```shell
-   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
-     --clusterrole=cluster-admin \
-     --group=system:serviceaccounts
-   ```
+    ```shell
+    kubectl create clusterrolebinding serviceaccounts-cluster-admin \
+      --clusterrole=cluster-admin \
+      --group=system:serviceaccounts
+    ```
 
 ## Upgrading from 1.5