Add admonition type to shortcode (#9482)

* Change existing admon blocks

* Fix includes issue

content/en/docs/reference/access-authn-authz/rbac.md

@@ -807,7 +807,7 @@ In order from most secure to least secure, the approaches are:
 
     If an application does not specify a `serviceAccountName`, it uses the "default" service account.
 
-    {{< note >}}**Note:** Permissions given to the "default" service
+    {{< note >}}Permissions given to the "default" service
     account are available to any pod in the namespace that does not
     specify a `serviceAccountName`.{{< /note >}}
 
@@ -823,7 +823,7 @@ In order from most secure to least secure, the approaches are:
     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`
+    {{< note >}}Enabling this means the `kube-system`
     namespace contains secrets that grant super-user access to the
     API.{{< /note >}}
 
@@ -863,9 +863,11 @@ In order from most secure to least secure, the approaches are:
 
     If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
 
-    {{< warning >}}**Warning:** This allows any user with read access
+    {{< warning >}}
+    This allows any user with read access
     to secrets or the ability to create a pod to access super-user
-    credentials.{{< /warning >}}
+    credentials.
+    {{< /warning >}}
 
     ```shell
     kubectl create clusterrolebinding serviceaccounts-cluster-admin \
@@ -909,7 +911,7 @@ in the server logs, you can remove the ABAC authorizer.
 You can replicate a permissive policy using RBAC role bindings.
 
 {{< warning >}}
-**Warning:** The following policy allows **ALL** service accounts to act as cluster administrators.
+The following policy allows **ALL** service accounts to act as cluster administrators.
 Any application running in a container receives service account credentials automatically,
 and could perform any action against the API, including viewing secrets and modifying permissions.
 This is not a recommended policy.