Updating notes in docu format

docs/en/security/hardening-guides/hardening-guides.md

@@ -39,9 +39,11 @@ These guides have been tested along with the Rancher v2.6 release. Each self-ass
 | ------------------ | --------------------- | --------------------- | ---------------- |
 | Kubernetes v1.18 up to v1.23 | CIS v1.6 | [Link]({{<baseurl>}}/rancher/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6) | [Link]({{<baseurl>}}/rancher/v2.6/en/security/hardening-guides/rke-1.6-hardening-2.6) |
 
-> **Notes**
->
-> - CIS v1.20 benchmark version for Kubernetes v1.19 and v1.20 is not yet released as a profile in Rancher's CIS Benchmark chart.
+:::note
+
+- CIS v1.20 benchmark version for Kubernetes v1.19 and v1.20 is not yet released as a profile in Rancher's CIS Benchmark chart.
+
+:::
 
 ### RKE2 Guides
 

docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md

@@ -31,7 +31,11 @@ Rancher and RKE install Kubernetes services via Docker containers. Configuration
 
 Where control audits differ from the original CIS benchmark, the audit commands specific to Rancher are provided for testing. When performing the tests, you will need access to the command line on the hosts of all RKE nodes. The commands also make use of the [kubectl](https://kubernetes.io/docs/tasks/tools/) (with a valid configuration file) and [jq](https://stedolan.github.io/jq/) tools, which are required in the testing and evaluation of test results.
 
-> NOTE: Only `automated` tests (previously called `scored`) are covered in this guide.
+:::note
+
+Only `automated` tests (previously called `scored`) are covered in this guide.
+
+:::
 
 ### Controls
 ## 1.1 Master Node Configuration Files

docs/en/security/hardening-guides/rke-1.6-hardening-2.6/rke-1.6-hardening-2.6.md

@@ -7,7 +7,11 @@ aliases:
 
 This document provides prescriptive guidance for hardening a production installation of a RKE cluster to be used with Rancher v2.6. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
 
-> This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
+:::note
+
+This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
+
+:::
 
 This hardening guide is intended to be used for RKE clusters and associated with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
 
@@ -115,7 +119,11 @@ Network Policies are namespace scoped. When a network policy is introduced to a
 
 Once a CNI provider is enabled on a cluster a default network policy can be applied. For reference purposes a **permissive** example is provided below. If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as “isolated”), you can create a policy that explicitly allows all traffic in that namespace. Save the following configuration as `default-allow-all.yaml`. Additional [documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/) about network policies can be found on the Kubernetes site.
 
-> This `NetworkPolicy` is just an example and is not recommended for production use.
+:::note
+
+This `NetworkPolicy` is just an example and is not recommended for production use.
+
+:::
 
 ```yaml
 ---
@@ -150,7 +158,11 @@ Execute this script to apply the `default-allow-all.yaml` configuration with the
 
 The reference `cluster.yml` is used by the RKE CLI that provides the configuration needed to achieve a hardened install of Rancher Kubernetes Engine (RKE). RKE install [documentation]({{<baseurl>}}/rke/latest/en/installation/) is provided with additional details about the configuration items. This reference `cluster.yml` does not include the required **nodes** directive which will vary depending on your environment. Documentation for node configuration in RKE can be found [here]({{<baseurl>}}/rke/latest/en/config-options/nodes/).
 
-> For a Kubernetes v1.18 cluster, the configuration `spec.volumes: 'ephemeral'` should be removed from the `PodSecurityPolicy`, since it's not supported in this Kubernetes release.
+:::note Important:
+
+For a Kubernetes v1.18 cluster, the configuration `spec.volumes: 'ephemeral'` should be removed from the `PodSecurityPolicy`, since it's not supported in this Kubernetes release.
+
+:::
 
 ```yaml
 # If you intend to deploy Kubernetes in an air-gapped environment,

docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md

@@ -29,7 +29,11 @@ RKE2 launches control plane components as static pods, managed by the kubelet, a
 
 Where control audits differ from the original CIS benchmark, the audit commands specific to Rancher are provided for testing. When performing the tests, you will need access to the command line on the hosts of all RKE2 nodes. The commands also make use of the [kubectl](https://kubernetes.io/docs/tasks/tools/) (with a valid configuration file) and [jq](https://stedolan.github.io/jq/) tools, which are required in the testing and evaluation of test results.
 
-> NOTE: Only `automated` tests (previously called `scored`) are covered in this guide.
+:::note
+
+Only `automated` tests (previously called `scored`) are covered in this guide.
+
+:::
 
 ### Controls
 

docs/en/security/hardening-guides/rke2-1.6-hardening-2.6/rke2-1.6-hardening-2.6.md

@@ -5,7 +5,11 @@ weight: 100
 
 This document provides prescriptive guidance for hardening a production installation of a RKE2 cluster to be provisioned with Rancher v2.6.5. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
 
-> This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
+:::note
+
+This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
+
+:::
 
 This hardening guide is intended to be used for RKE2 clusters and associated with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
 
@@ -40,7 +44,11 @@ To help ensure these above requirements are met, RKE2 can be started with the `p
 1. Checks that host-level requirements have been met. If they haven't, RKE2 will exit with a fatal error describing the unmet requirements.
 2. Configures runtime pod security policies and network policies that allow the cluster to pass associated controls.
 
-> The profile's flag only valid values are `cis-1.5` or `cis-1.6`. It accepts a string value to allow for other profiles in the future.
+:::note
+
+The profile's flag only valid values are `cis-1.5` or `cis-1.6`. It accepts a string value to allow for other profiles in the future.
+
+:::
 
 The following section outlines the specific actions that are taken when the `profile` flag is set to `cis-1.6`.
 
@@ -54,7 +62,11 @@ This is a kubelet flag that will cause the kubelet to exit if the required kerne
 
 When the `profile` flag is set, RKE2 will set the flag to `true`.
 
-> `protect-kernel-defaults` is exposed as a configuration flag for RKE2. If you have set `profile` to "cis-1.x" and `protect-kernel-defaults` to `false` explicitly, RKE2 will exit with an error.
+:::caution
+
+`protect-kernel-defaults` is exposed as a configuration flag for RKE2. If you have set `profile` to "cis-1.x" and `protect-kernel-defaults` to `false` explicitly, RKE2 will exit with an error.
+
+:::
 
 RKE2 will also check the same kernel parameters that the kubelet does and exit with an error following the same rules as the kubelet. This is done as a convenience to help the operator more quickly and easily identify what kernel parameters are violating the kubelet defaults.
 
@@ -122,8 +134,11 @@ When ran with a valid "cis-1.x" profile, RKE2 will put `NetworkPolicies` in plac
 
 The `NetworkPolicy` used will only allow pods within the same namespace to talk to each other. The notable exception to this is that it allows DNS requests to be resolved.
 
-> Operators must manage network policies as normal for additional namespaces that are created.
+:::note
 
+Operators must manage network policies as normal for additional namespaces that are created.
+
+:::
 #### Configure `default` service account
 
 **Set `automountServiceAccountToken` to `false` for `default` service accounts**

docs/en/security/selinux/selinux.md

@@ -39,7 +39,11 @@ For more information about installing RKE2 on SELinux-enabled hosts, see the [RK
 
 # Installing the rancher-selinux RPM
 
-> **Requirements:** The rancher-selinux RPM was tested with CentOS 7 and 8.
+:::note Requirement:
+
+The rancher-selinux RPM was tested with CentOS 7 and 8.
+
+:::
 
 ### 1. Set up the yum repo
 
@@ -80,7 +84,11 @@ yum -y install rancher-selinux
 
 # Configuring the Logging Application to Work with SELinux
 
-> **Requirements:** Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
+:::note Requirement:
+
+Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
+
+:::
 
 Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM.