Merge pull request #481 from rancher/release/v2.7.2

Publishing v2.7.2 docs
2026-09-15 21:44:24 +00:00 · 2023-04-11 21:22:28 -07:00
parent 1b5278c3a9 5de5735017
commit 13d71a5142
83 changed files with 30623 additions and 56127 deletions
@@ -17,4 +17,6 @@

 npm-debug.log*
 yarn-debug.log*
-yarn-error.log*
+yarn-error.log*
+
+.idea/
@@ -0,0 +1,37 @@
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+- configuration:
+    apiVersion: pod-security.admission.config.k8s.io/v1
+    defaults:
+      audit: restricted
+      audit-version: latest
+      enforce: restricted
+      enforce-version: latest
+      warn: restricted
+      warn-version: latest
+    exemptions:
+      namespaces:
+      - ingress-nginx
+      - kube-system
+      - cattle-system
+      - cattle-epinio-system
+      - cattle-fleet-system
+      - longhorn-system
+      - cattle-neuvector-system
+      - cattle-monitoring-system
+      - rancher-alerting-drivers
+      - cis-operator-system
+      - cattle-csp-adapter-system
+      - cattle-externalip-system
+      - cattle-gatekeeper-system
+      - istio-system
+      - cattle-istio-system
+      - cattle-logging-system
+      - cattle-windows-gmsa-system
+      - cattle-sriov-system
+      - cattle-ui-plugin-system
+      - tigera-operator
+    kind: PodSecurityConfiguration
+  name: PodSecurity
+  path: ""
@@ -0,0 +1,62 @@
+---
+title: Upgrade a Hardened Custom/Imported Cluster to Kubernetes v1.25
+---
+
+Kubernetes v1.25 changes how clusters describe and implement security policies. From this version forward, [Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are no longer available. Kubernetes v1.25 replaces them with new security objects: [Pod Security Standards (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/), and [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/). 
+
+If you have custom or imported hardened clusters, you must make special preparations to ensure that the upgrade from an earlier version of Kubernetes to v1.25 or later goes smoothly.
+
+## Upgrading Imported Hardened Clusters to Kubernetes v1.25 or Later
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2" default>
+
+Perform the following on each node in the cluster: 
+1. Save [`rancher-psact.yaml`](./rancher-psact.yaml) in `/etc/rancher/rke2`.
+1. Edit the RKE2 configuration file:
+   1. Update the `profile` field to `cis-1.23`.
+   1. Specify the path for the configuration file that you just added: `pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`.
+  
+</TabItem>
+<TabItem value="K3s">
+
+Perform the following on each node in the cluster:
+
+Follow the official K3s instructions on [Upgrading Hardened Clusters from v1.24.x to v1.25.x](https://docs.k3s.io/known-issues#hardened-125), but use a [custom](./rancher-psact.yaml) Rancher PSA configuration template, instead of the configuration provided on the official K3s site.
+</TabItem>
+</Tabs>
+
+After you perform these steps, you can upgrade the cluster's Kubernetes version through the Rancher UI:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
+1. Select **Edit Config**.
+1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
+1. Click **Save**.
+
+## Upgrading Custom Hardened Clusters to Kubernetes v1.25 or Later
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2" default>
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
+1. Select **Edit Config**.
+1. Under **Basics > Security**, in the **CIS Profile** dropdown menu, select `cis-1.23`. 
+1. In the **Default Pod Security Admission** dropdown menu, select `rancher-restricted`.
+1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
+1. Click **Save**.
+
+</TabItem>
+<TabItem value="K3s">
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
+1. Select **Edit YAML**.
+1. Delete `PodSecurityPolicy` from `kube-apiserver-arg.enable-admission-plugins`
+1. Add this line to the `spec` field: `defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
+1. Update `kubernetesVersion` to your chosen version (v1.25 or later).
+1. Click **Save**.
+
+</TabItem>
+</Tabs>
@@ -74,13 +74,12 @@ When setting up the Rancher Helm template, there are several options in the Helm
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |

-### 3. Fetch the Cert-Manager chart 
+### 3. Fetch the Cert-Manager Chart

 Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.

 #### Option A: Default Self-Signed Certificate

-
 By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.

 :::note
@@ -109,15 +108,14 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
 :::

 ```plain
-helm fetch jetstack/cert-manager --version v1.7.1
+helm fetch jetstack/cert-manager --version v1.11.0
 ```

-
 ##### 3. Retrieve the Cert-Manager CRDs

 Download the required CRD file for cert-manager:
   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+   curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
   ```

 ### 4. Install Rancher
@@ -128,6 +126,12 @@ Copy the fetched charts to a system that has access to the Rancher server cluste

 Install cert-manager with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 <details id="install-cert-manager">
  <summary>Click to expand</summary>

@@ -139,7 +143,7 @@ If you are using self-signed certificates, install cert-manager:
    kubectl create namespace cert-manager
    ```

-2. Create the cert-manager CustomResourceDefinitions (CRDs). 
+2. Create the cert-manager CustomResourceDefinitions (CRDs).

    ```plain
    kubectl apply -f cert-manager/cert-manager-crd.yaml
@@ -148,7 +152,7 @@ If you are using self-signed certificates, install cert-manager:
 3. Install cert-manager.

    ```plain
-    helm install cert-manager ./cert-manager-v1.7.1.tgz \
+    helm install cert-manager ./cert-manager-v1.11.0.tgz \
        --namespace cert-manager \
        --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
        --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
@@ -56,13 +56,6 @@ Skip this step if you are using your own certificates, or if you are terminating

 In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well.

-
-:::note
-
-New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
-
-:::
-
 1.  Fetch the latest `cert-manager` Helm chart and parse the template for image details:

    :::note
@@ -74,7 +67,7 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
    ```plain
    helm repo add jetstack https://charts.jetstack.io
    helm repo update
-    helm fetch jetstack/cert-manager --version v1.7.1
+    helm fetch jetstack/cert-manager --version v1.11.0
    helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
    ```

@@ -253,7 +246,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
   ```plain
   helm repo add jetstack https://charts.jetstack.io
   helm repo update
-   helm fetch jetstack/cert-manager --version v0.12.0
+   helm fetch jetstack/cert-manager --version v1.11.0
   helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
   ```

@@ -30,21 +30,21 @@ kubectl create namespace cert-manager

 Install the CustomResourceDefinitions of cert-manager:

-:::note
-
-New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
-
-:::
-
 ```
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 helm upgrade --install cert-manager jetstack/cert-manager \
-  --namespace cert-manager --version v1.7.1 \
+  --namespace cert-manager --version v1.11.0 \
  --set http_proxy=http://${proxy_host} \
  --set https_proxy=http://${proxy_host} \
  --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
@@ -93,7 +93,7 @@ In order to upgrade cert-manager, follow these instructions:
    helm install \
      cert-manager jetstack/cert-manager \
      --namespace cert-manager \
-      --version v0.12.0
+      --version v1.11.0
    ```

 1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -125,7 +125,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).

    ```plain
-    helm fetch jetstack/cert-manager --version v0.12.0
+    helm fetch jetstack/cert-manager --version v1.11.0
    ```

 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
@@ -153,7 +153,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager (old and new)

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
    ```

@@ -92,12 +92,18 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work.

 Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed.

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

 kubectl create namespace cattle-system

-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 helm repo add jetstack https://charts.jetstack.io

@@ -106,13 +112,13 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0

 # Windows Powershell
 helm install cert-manager jetstack/cert-manager `
  --namespace cert-manager `
  --create-namespace `
-  --version v1.7.1
+  --version v1.11.0
 ```

 The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
@@ -8,4 +8,10 @@ title: Install Rancher CIS Benchmark
 1. Click **CIS Benchmark**
 1. Click **Install**.

-**Result:** The CIS scan application is deployed on the Kubernetes cluster.
+**Result:** The CIS scan application is deployed on the Kubernetes cluster.
+
+:::note
+
+CIS Benchmark 4.0.0 and above have PSPs disabled by default. To install CIS Benchmark on a hardened cluster, set `golbal.psp.enabled` to `true` in the values before installing the chart.
+
+:::
@@ -6,6 +6,8 @@ title: Configure Azure AD

 Microsoft Graph API is now the flow through which you will set up Azure AD. The below sections will assist [new users](#new-user-setup) in configuring Azure AD with a new instance as well as assist existing Azure app owners in [migrating to the new flow](#migrating-from-azure-ad-graph-api-to-microsoft-graph-api).

+The Microsoft Graph API flow in Rancher is constantly evolving. We recommend that you use the latest patched version of 2.7, as it is still in active development and will continue to receive new features and improvements.
+
 ### New User Setup

 If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
@@ -23,8 +25,7 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco

 :::tip

-Before you start, open two browser tabs: one for Rancher, one for the Azure portal. That will help in easily copying and pasting
-configuration values from the portal to Rancher.
+Before you start, open two browser tabs: one for Rancher, and one for the Azure portal. This will help with copying and pasting configuration values from the portal to Rancher.

 :::

@@ -76,13 +77,13 @@ From the Azure portal, create a client secret. Rancher will use this key to auth

     ![Open Rancher Registration](/img/open-rancher-app-reg.png)

-1. From the navigation pane on left, click **Certificates & secrets**.
+1. From the navigation pane, click **Certificates & secrets**.

 1. Click **New client secret**.
    ![Create new client secret](/img/new-client-secret.png)
 1. Enter a **Description** (something like `Rancher`).
-1. Select duration for the key from the options under **Expires**. This drop-down sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key after expiration.
-Note that users won't be able to log in to Rancher when it detects that the application secret has expired, so rotate the secret in Azure and update in Rancher before it expires.
+1. Select the duration from the options under **Expires**. This drop-down menu sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key more frequently.
+Note that users won't be able to log in to Rancher if it detects that the application secret has expired. To avoid this problem, rotate the secret in Azure and update it in Rancher before it expires.
 1. Click **Add** (you don't need to enter a value—it will automatically populate after you save).
 <a id="secret"></a>

@@ -94,11 +95,11 @@ Next, set API permissions for Rancher within Azure.

 :::caution

-Ensure that you set the permissions of type Application and NOT Delegated. Otherwise, you may not be able to login to Azure AD.
+Ensure that you set Application permissions, and *not* Delegated permissions. Otherwise, you won't be able to login to Azure AD.

 :::

-1. From the navigation pane on the left, select **API permissions**.
+1. From the navigation pane on, select **API permissions**.

 1. Click **Add a permission**.

@@ -106,13 +107,27 @@ Ensure that you set the permissions of type Application and NOT Delegated. Other

    ![Select API Permissions](/img/api-permissions.png)

-1. Return to **API permissions** in the left nav bar. From there, click **Grant admin consent**. Then click **Yes**. The app's permissions should look like the following:
+1. Return to **API permissions** in the nav bar. From there, click **Grant admin consent**. Then click **Yes**. The app's permissions should look like the following:

 ![Open Required Permissions](/img/select-req-permissions.png)

 :::note

-Rancher does not validate the permissions you grant to the app in Azure. We only support the use of the `Directory.Read.All` application permission.
+Rancher doesn't validate the permissions you grant to the app in Azure. You're free to try any permissions you want, as long as they allow Rancher to work with AD users and groups.
+
+Specifically, Rancher needs permissions that allow the following actions:
+- Get a user.
+- List all users.
+- List groups of which a given user is a member.
+- Get a group.
+- List all groups.
+
+Rancher performs these actions either to log in a user or to run a user/group search. Keep in mind that the permissions must be of type `Application`.
+
+Here are a few examples of permission combinations that satisfy Rancher's needs:
+- `Directory.Read.All`
+- `User.Read.All` and `GroupMember.Read.All`
+- `User.Read.All` and `Group.Read.All`

 :::

@@ -130,38 +145,42 @@ Rancher does not validate the permissions you grant to the app in Azure. We only

 1. Obtain your Rancher **Application (Client) ID**.

-    1. Use search to open **App registrations** (if not already there).
+    1. If you aren't already there, use search to open **App registrations**.

    1. In **Overview**, find the entry you created for Rancher.

    1. Copy the **Application (Client) ID** and paste it into Rancher as your **Application ID**.

-1. Your endpoint options will typically be either [Standard](#global) or [China](#china). With these options, you only enter the **Tenant ID**, **Application ID**, and **Application Secret**.
+1. In most cases, your endpoint options will either be [Standard](#global) or [China](#china). For either of these options, you only need to enter the **Tenant ID**, **Application ID**, and **Application Secret**.

 ![Standard Endpoint Options](/img/tenant-application-id-secret.png)

 **For Custom Endpoints:**

-**Warning:** Custom Endpoints are not tested or fully supported by Rancher.
+:::caution

-You will need to also manually enter the Graph, Token, and Auth Endpoints.
+Custom Endpoints are not tested or fully supported by Rancher.
+
+:::
+
+You'll also need to manually enter the Graph, Token, and Auth Endpoints.

 - From <b>App registrations</b>, click <b>Endpoints</b>:

 ![Click Endpoints](/img/endpoints.png)

- Note the following endpoints - these values will be your Rancher endpoint values. Make sure to use the v1 version of the endpoints.
+- The following endpoints will be your Rancher endpoint values. Make sure to use the v1 version of these endpoints:
  - **Microsoft Graph API endpoint** (Graph Endpoint)
  - **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
  - **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)

 #### 5. Configure Azure AD in Rancher

-From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
+To complete configuration, enter information about your AD instance in the Rancher UI.

 1. Log into Rancher.

-1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the top left corner, click **☰ > Users & Authentication**.

 1. In the left navigation menu, click **Auth Provider**.

@@ -169,14 +188,14 @@ From the Rancher UI, enter information about your AD instance hosted in Azure to

 1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).

-    :::caution 
-    
-    The Azure AD account will be granted administrator privileges, since its details will be mapped to the Rancher local principal account. Make sure that this level of privilege is appropriate before you continue. 
-    
+    :::caution
+
+    The Azure AD account will be granted administrator privileges, since its details will be mapped to the Rancher local principal account. Make sure that this level of privilege is appropriate before you continue.
+
    :::

    **For Standard or China Endpoints:**
-    
+
    The following table maps the values you copied in the Azure portal to the fields in Rancher:

    | Rancher Field      | Azure Value                           |
@@ -207,21 +226,19 @@ From the Rancher UI, enter information about your AD instance hosted in Azure to

 ### Migrating from Azure AD Graph API to Microsoft Graph API

-Since [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2020 
-and will be retired in June 2023, admins should update their Azure AD App to use the new 
-[Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) in Rancher. 
-This needs to be done well in advance of the endpoint being retired. 
-If Rancher is still configured to use the old Azure AD Graph API when it is retired, users may not be able to log into Rancher using Azure AD.
+Since the [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) is deprecated and slated to retire in June 2023, admins should update their Azure AD App to use the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) in Rancher.
+This needs to be done well in advance of the endpoint being retired.
+If Rancher is still configured to use the Azure AD Graph API when it is retired, users may not be able to log into Rancher using Azure AD.

 #### Updating Endpoints in the Rancher UI

 :::caution

-Admins should create a [backup](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) right before they commit to the endpoint migration described below.
+Admins should create a [Rancher backup](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) before they commit to the endpoint migration described below.

 :::

-1. Update the permissions of your Azure AD app registration as described [here](#3-set-required-permissions-for-rancher). This is critical.
+1. [Update](#3-set-required-permissions-for-rancher) the permissions of your Azure AD app registration. This is critical.

 1. Log into Rancher.

@@ -253,7 +270,12 @@ If you need to roll back your migration, please note the following:

 1. Azure app owners who want to rotate the Application Secret will need to also rotate it in Rancher as Rancher does not automatically update the Application Secret when it is changed in Azure. In Rancher, note that it is stored in a Kubernetes secret called `azureadconfig-applicationsecret` which is in the `cattle-global-data` namespace.

-1. **Caution:** If admins upgrade to Rancher v2.7.0+ with an existing Azure AD setup and choose to disable the auth provider, they won't be able to restore the previous setup and also will not be able to set up Azure AD using the old flow. Admins will then need to register again with the new auth flow. Rancher now uses the new Graph API and, therefore, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
+:::caution
+
+If you upgrade to Rancher v2.7.0+ with an existing Azure AD setup, and choose to disable the auth provider, you won't be able to restore the previous setup. You also won't be able to set up Azure AD anew using the old flow. You'll need to re-register with the new auth flow. Since Rancher now uses the Graph API, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
+
+:::
+

 #### Global:

@@ -292,12 +314,13 @@ Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2

 >**Important:**
 >
->- The [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2022 and will be retired at the end of 2022. We will update our docs to advise the community when it is retired. Rancher now uses the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) as the new flow to set up Azure AD as the external auth provider.
+>- The [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) is deprecated and will be retired by Microsoft at any time after June 30, 2023, without advance notice. We will update our docs to advise the community when it is retired. Rancher now uses the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) as the new flow to set up Azure AD as the external auth provider.
 >
 >
->- For new users, or existing users who wish to migrate, refer to the new flow instructions for <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>.
+>- If you're a new user, or wish to migrate, refer to the new flow instructions for <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>.
 >
 >
->- For existing users who do not wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, they will need to either:
+>- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
    - Use the built-in Rancher auth or
    - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](../../../../pages-for-subheaders/authentication-config.md) to learn how to configure other open authentication providers.
+
@@ -2,9 +2,13 @@
 title: Pod Security Policies
 ---

-_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges).
+:::caution
+Pod Security Policy is only available in Kubernetes until v1.24. [Pod Security Standards](pod-security-standards.md) are the built-in alternative.
+:::

-If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod <NAME> is forbidden: unable to validate...`.
+[Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are objects that control security-sensitive aspects of the pod specification (such as root privileges).
+
+If a pod doesn't meet the conditions specified in the PSP, Kubernetes won't allow it to start, and Rancher will display the following error message: `Pod <NAME> is forbidden: unable to validate...`.


 ## How PSPs Work
@@ -40,6 +44,12 @@ This policy is a relaxed version of the `restricted-noroot` policy, with almost

 This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.

+:::note important
+
+When disabling PSPs, default PSPs are **not** automatically deleted from your cluster. You must manually delete them if they're no longer needed.
+
+:::
+
 ## Creating PSPs

 Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.
@@ -0,0 +1,122 @@
+---
+title: Pod Security Standards (PSS) & Pod Security Admission (PSA)
+---
+
+[Pod Security Standards (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) and [Pod Security Admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) define security restrictions for a broad set of workloads.
+They became available and were turned on by default in Kubernetes v1.23, and replace [Pod Security Policies (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) in Kubernetes v1.25 and above.
+
+PSS define security levels for workloads. PSAs describe requirements for pod security contexts and related fields. PSAs reference PSS levels to define security restrictions.
+
+## Upgrade to Pod Security Standards (PSS)
+
+Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper), [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
+
+:::caution
+You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
+:::
+
+### Removing PodSecurityPolicies from Rancher-Maintained Apps & Marketplace Workloads {#remove-psp-rancher-workloads}
+
+Rancher v2.7.2 offers a new major version of Rancher-maintained Helm charts. v102.x.y allows you to remove PSPs that were installed with previous versions of the chart. This new version replaces non-standard PSPs switches with the standardized `global.cattle.psp.enabled` switch, which is turned off by default.
+
+You must perform the following steps _while still in Kubernetes v1.24_:
+1. Configure the PSA controller to suit your needs. You can use one of Rancher's built-in [PSA Configuration Templates](#psa-config-templates), or create a custom template and apply it to the clusters that you are migrating.
+
+1. Map your active PSPs to Pod Security Standards:
+    1. See which PSPs are still active in your cluster:
+       ```shell
+       kubectl get pods \
+         --all-namespaces \
+         --output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
+         | tr " " "\n" | sort -u
+       ```
+
+    1. Follow the Kubernetes guide on [Mapping PSPs to Pod Security Standards](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/) to apply PSSs to your workloads that were relying on PSPs. See [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission controller](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) for more details.
+
+1. To remove PSPs from Rancher charts, upgrade the charts to the latest v102.x.y version _before_ you upgrade to Kubernetes v1.25. Make sure that the **Enable PodSecurityPolicies** option is **disabled**. This will remove any PSPs that were installed with previous chart versions.
+
+:::info important
+If you want to upgrade your charts to v102.x.y, but don't plan on upgrading your clusters to Kubernetes v1.25 and moving away from PSPs, make sure that you select the option **Enable PodSecurityPolicies** for each chart that you are upgrading.
+:::
+
+### Cleaning Up Releases After a Kubernetes v1.25 Upgrade
+
+If you experience problems while removing PSPs from your charts, or have charts that don't contain a built-in mechanism for removing PSPs, your chart upgrades or deletions might fail with an error message such as the following:
+```console
+Error: UPGRADE FAILED: resource mapping not found for name: "<object-name>" namespace: "<object-namespace>" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
+ensure CRDs are installed first
+```
+
+This happens when Helm tries to query the cluster for objects that were stored in a previous release's data blob. To clean up these releases and avoid this error, use the `helm-mapkubeapis` Helm  plugin. To learn more about `helm-mapkubeapis`, how it works, and how it can be fine-tuned for your use case, see the [official Helm documentation](https://github.com/helm/helm-mapkubeapis#readme).
+
+Note that Helm plugin installation is local to the machine that you run the commands from. Therefore, make sure that you run both the installation and cleanup from the same machine.
+
+#### Install `helm-mapkubeapis`
+
+1. Open your terminal in the machine you intend to use `helm-mapkubeapis` from and install the plugin:
+    ```shell
+    helm plugin install https://github.com/helm/helm-mapkubeapis
+    ```
+    
+    You will see output similar to the following:
+    ```console
+    Downloading and installing helm-mapkubeapis v0.4.1 ...
+    https://github.com/helm/helm-mapkubeapis/releases/download/v0.4.1/helm-mapkubeapis_0.4.1_darwin_amd64.tar.gz
+    Installed plugin: mapkubeapis
+    ```
+   
+    :::info important
+    Ensure that the `helm-mapkubeapis` plugin is at least v0.4.1, as older versions _do not_ support removal of resources.
+    :::
+
+1. Verify that the plugin was correctly installed:
+    ```shell
+    helm mapkubeapis --help
+    ```
+    
+    You will see output similar to the following:
+    ```console
+    Map release deprecated or removed Kubernetes APIs in-place
+    
+    Usage:
+    mapkubeapis [flags] RELEASE
+    
+    Flags:
+    --dry-run               simulate a command
+    -h, --help              help for mapkubeapis
+    --kube-context string   name of the kubeconfig context to use
+    --kubeconfig string     path to the kubeconfig file
+    --mapfile string        path to the API mapping file
+    --namespace string      namespace scope of the release
+    ```
+
+#### Cleaning Up Broken Releases
+
+After you install the `helm-mapkubeapis` plugin, clean up the releases that became broken after the upgrade to Kubernetes v1.25.
+
+1. Open your preferred terminal and make sure it's connected to the cluster you wish to target by running `kubectl cluster-info`.
+
+1. List all the releases you have installed in your cluster by running `helm list --all-namespaces`.
+
+1. Perform a dry run for each release you would like to clean up by running `helm mapkubeapis --dry-run <release-name> --namespace <release-namespace>`. The result of this command will inform you what resources are going to be replaced or removed.
+
+1. Finally, after reviewing the changes, perform a full run with `helm mapkubeapis <release-name> --namespace <release-namespace>`.
+
+#### Upgrading Charts to a Version That Supports Kubernetes v1.25
+
+You can proceed with your upgrade once any releases that had lingering PSPs are cleaned up. For Rancher-maintained workloads, follow the steps outlined in the [Removing PodSecurityPolicies from Rancher-maintained Apps & Marketplace workloads](#remove-psp-rancher-workloads) section of this document.
+For workloads not maintained by Rancher, refer to the vendor documentation.
+
+:::caution
+Do not skip this step. Applications incompatible with Kubernetes v1.25 aren't guaranteed to work after a cleanup.
+:::
+
+## Pod Security Admission Configuration Templates {#psa-config-templates}
+
+Rancher offers PSA configuration templates. These are pre-defined security configurations that you can apply to a cluster. Rancher admins (or those with the right permissions) can [create, manage, and edit](./psa-config-templates.md) PSA templates.
+
+### Rancher on PSA-restricted Clusters
+
+Rancher system namespaces are also affected by the restrictive security policies described by PSA templates. You need to exempt Rancher's system namespaces after you assign the template, or else the cluster won't operate correctly. See [Pod Security Admission (PSA) Configuration Templates](./psa-config-templates.md#exempting-required-rancher-namespaces) for more details.
+
+For a complete file which has all the exemptions you need to run Rancher, please refer to this [sample Admission Configuration](../../../reference-guides/rancher-security/psa-restricted-exemptions.md).
@@ -0,0 +1,138 @@
+---
+title: Pod Security Admission (PSA) Configuration Templates
+---
+
+[Pod Security admission (PSA)](./pod-security-standards.md) configuration templates are a Rancher custom-defined resource (CRD), available in Rancher v2.7.2 and above. The templates provide pre-defined security configurations that you can apply to a cluster:
+
+- `rancher-privileged`: The most permissive configuration. It doesn't restrict the behavior of any pods. This allows for known privilege escalations. This policy has no exemptions.
+- `rancher-restricted`: A heavily restricted configuration that follows current best practices for hardening pods. You must make [namespace-level exemptions](./pod-security-standards.md#rancher-on-psa-restricted-clusters) for Rancher components.
+
+## Assign a Pod Security Admissions (PSA) Configuration Template
+
+You can assign a PSA template at the same time that you create a downstream cluster. You can also add a template by configuring an existing cluster.
+
+### Assign a Template During Cluster Creation
+<Tabs>
+<TabItem value="RKE2 and K3s">
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, click the **Create** button.
+1. Select a provider.
+1. On the **Cluster: Create** page, go to **Basics > Security**.
+1. In the **Default Pod Security Admission** dropdown menu, select the template you want to assign.
+1. Click **Create**.
+
+### Assign a Template to an Existing Cluster
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
+1. Select **Edit Config** .
+1. In the **Default Pod Security Admission** dropdown menu, select the template you want to assign.
+1. Click **Save**.
+
+### Hardening the Cluster
+
+If you select the **rancher-restricted** template but don't select a **CIS Profile**, you won't meet required CIS benchmarks. See the [RKE2 hardening guide](../../../pages-for-subheaders/rke2-hardening-guide.md) for more details.
+
+</TabItem>
+<TabItem value="RKE1">
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, click the **Create** button.
+1. Select a provider.
+1. On the **Add Cluster** page, under **Cluster Options**, click **Advanced Options**.
+1. In the **Pod Security Admission Configuration Template** dropdown menu, select the template you want to assign.
+1. Click **Create**.
+
+### Assign a Template to an Existing Cluster
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
+1. Select **Edit Config**.
+1. On the **Edit Cluster** page, go to **Cluster Options > Advanced Options**.
+1. In the **Pod Security Admission Configuration Template**, select the template you want to assign.
+1. Click **Save**.
+
+</TabItem>
+</Tabs>
+
+## Add or Edit a Pod Security Admissions (PSA) Configuration Template
+
+If you have administrator privileges, you can customize security restrictions and permissions by creating additional PSA templates, or by editing existing templates.
+
+:::caution
+If you edit an existing PSA template while it is still in use, changes will be applied to all clusters that have been assigned to that template.
+:::
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Click **Advanced** to open the dropdown menu.
+1. Select **Pod Security Admissions**.
+1. Find the template you want to modify, and click the **⋮**.
+1. Select **Edit Config** to edit the template.
+1. When you're done editing the configuration, click **Save**.
+
+### Allow Non-Admin Users to Manage PSA Templates
+
+If you want to allow other users to manage templates, you can bind that user to a role that grants all verbs (`"*"`) on `management.cattle.io/podsecurityadmissionconfigurationtemplates`.
+
+:::caution
+Any user that is bound to the above permission will be able to change the restriction levels on _all_ managed clusters which use a given PSA template, including ones that they have no permissions on.
+:::
+
+## Exempting Namespaces
+
+If you assign the `rancher-restricted` template to a cluster, by default the restrictions are applied across the entire cluster at the namespace level. To exempt certain namespaces from this highly restricted policy, do the following:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Click **Advanced** to open the dropdown menu.
+1. Select **Pod Security Admissions**.
+1. Find the template you want to modify, and click the **⋮**.
+1. Select **Edit Config**.
+1. Click the **Namespaces** checkbox under **Exemptions** to edit the **Namespaces** field.
+1. When you're done exempting namespaces, click **Save**.
+
+:::note
+You need to update the target cluster to make the new template take effect in that cluster. An update can be triggered by editing and saving the cluster without changing values.
+:::
+
+### Exempting Required Rancher Namespaces
+
+When you run Rancher on a Kubernetes cluster that enforces a restrictive security policy by default, you will need to [exempt the following namespaces](./psa-config-templates.md#exempting-namespaces), otherwise the policy might prevent Rancher system pods from properly running.
+
+- `calico-apiserver`
+- `calico-system`
+- `cattle-alerting`
+- `cattle-csp-adapter-system`
+- `cattle-epinio-system`
+- `cattle-externalip-system`
+- `cattle-fleet-local-system`
+- `cattle-fleet-system`
+- `cattle-gatekeeper-system`
+- `cattle-global-data`
+- `cattle-global-nt`
+- `cattle-impersonation-system`
+- `cattle-istio`
+- `cattle-istio-system`
+- `cattle-logging`
+- `cattle-logging-system`
+- `cattle-monitoring-system`
+- `cattle-neuvector-system`
+- `cattle-prometheus`
+- `cattle-sriov-system`
+- `cattle-system`
+- `cattle-ui-plugin-system`
+- `cattle-windows-gmsa-system`
+- `cert-manager`
+- `cis-operator-system`
+- `fleet-default`
+- `ingress-nginx`
+- `istio-system`
+- `kube-node-lease`
+- `kube-public`
+- `kube-system`
+- `longhorn-system`
+- `rancher-alerting-drivers`
+- `security-scan`
+- `tigera-operator`
+
+Rancher, some Rancher owned charts, and RKE2 and K3s distributions all use these namespaces. A subset of the listed namespaces are already exempt in the built-in Rancher `rancher-restricted` policy, for use in downstream clusters. For a complete template which has all the exemptions you need to run Rancher, please refer to this [sample Admission Configuration](../../../reference-guides/rancher-security/psa-restricted-exemptions.md).
@@ -1,8 +1,8 @@
 ---
-title: Fleet - GitOps at Scale
+title: Continuous Delivery with Fleet
 ---

-Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/multi-cluster-install/) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/multi-cluster-install/) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

@@ -108,3 +108,26 @@ If you need to reconfigure or disable then re-enable a provider that had been pr
 is logged in to Rancher as an external user, not the local admin.

 :::
+
+## Disabling An Auth Provider
+
+When you disable an auth provider, Rancher deletes all resources associated with it, such as:
+- Secrets.
+- Global role bindings.
+- Cluster role template bindings.
+- Project role template bindings.
+- External users associated with the provider, but who never logged in as local users to Rancher.
+
+As this operation may lead to a loss of many resources, you may want to add a safeguard on the provider. To ensure that this cleanup process doesn't run when the auth provider is disabled, add a special annotation to the corresponding auth config.
+
+For example, to add a safeguard to the Azure AD provider, annotate the `azuread` authconfig object:
+
+`kubectl annotate --overwrite authconfig azuread management.cattle.io/auth-provider-cleanup='user-locked'`
+
+Rancher won't perform cleanup until you set the annotation to `unlocked`.
+
+### Running Resource Cleanup Manually
+
+Rancher might retain resources from a previously disabled auth provider configuration in the local cluster, even after you configure another auth provider. For example, if you used Provider A, then disabled it and started using Provider B, when you upgrade to a new version of Rancher, you can manually trigger cleanup on resources configured by Provider A.
+
+To manually trigger cleanup for a disabled auth provider, add the `management.cattle.io/auth-provider-cleanup` annotation with the `unlocked` value to its auth config.
@@ -13,8 +13,7 @@ The Center for Internet Security is a 501(c\)(3) non-profit organization, formed

 CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.

-The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is
-<a href="https://learn.cisecurity.org/benchmarks" target="_blank">here.</a>
+[Sign up](https://learn.cisecurity.org/benchmarks) at the CIS website to view the official Benchmark documents.

 ## About the Generated Report

@@ -30,20 +29,20 @@ Some tests are designated as "Not Applicable." These tests will not be run on an

 The report contains the following information:

-| Column in Report | Description |
-|------------------|-------------|
-| `id`               | The ID number of the CIS Benchmark. |
-| `description`      | The description of the CIS Benchmark test. |
-| `remediation`      | What needs to be fixed in order to pass the test. |
-| `state`    | Indicates if the test passed, failed, was skipped, or was not applicable. |
-| `node_type`        | The node role, which affects which tests are run on the node. Master tests are run on controlplane nodes, etcd tests are run on etcd nodes, and node tests are run on the worker nodes. |
-| `audit` | This is the audit check that `kube-bench` runs for this test. |
-| `audit_config` | Any configuration applicable to the audit script. |
-| `test_info` | Test-related info as reported by `kube-bench`, if any. |
-| `commands` | Test-related commands as reported by `kube-bench`, if any. |
-| `config_commands` | Test-related configuration data as reported by `kube-bench`, if any. |
-| `actual_value` | The test's actual value, present if reported by `kube-bench`. |
-| `expected_result` | The test's expected result, present if reported by `kube-bench`. |
+| Column in Report  | Description                                                                                                                                                                             |
+|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `id`              | The ID number of the CIS Benchmark.                                                                                                                                                     |
+| `description`     | The description of the CIS Benchmark test.                                                                                                                                              |
+| `remediation`     | What needs to be fixed in order to pass the test.                                                                                                                                       |
+| `state`           | Indicates if the test passed, failed, was skipped, or was not applicable.                                                                                                               |
+| `node_type`       | The node role, which affects which tests are run on the node. Master tests are run on controlplane nodes, etcd tests are run on etcd nodes, and node tests are run on the worker nodes. |
+| `audit`           | This is the audit check that `kube-bench` runs for this test.                                                                                                                           |
+| `audit_config`    | Any configuration applicable to the audit script.                                                                                                                                       |
+| `test_info`       | Test-related info as reported by `kube-bench`, if any.                                                                                                                                  |
+| `commands`        | Test-related commands as reported by `kube-bench`, if any.                                                                                                                              |
+| `config_commands` | Test-related configuration data as reported by `kube-bench`, if any.                                                                                                                    |
+| `actual_value`    | The test's actual value, present if reported by `kube-bench`.                                                                                                                           |
+| `expected_result` | The test's expected result, present if reported by `kube-bench`.                                                                                                                        |

 Refer to [the table in the cluster hardening guide](./rancher-security.md) for information on which versions of Kubernetes, the Benchmark, Rancher, and our cluster hardening guide correspond to each other. Also refer to the hardening guide for configuration files of CIS-compliant clusters and information on remediating failed tests.

@@ -51,16 +50,27 @@ Refer to [the table in the cluster hardening guide](./rancher-security.md) for i

 The following profiles are available:

- Generic CIS 1.5
 - Generic CIS 1.6
- RKE permissive 1.5
- RKE hardened 1.5
+- Generic CIS 1.20
+- Generic CIS 1.23
 - RKE permissive 1.6
 - RKE hardened 1.6
- RKE2 permissive 1.5
- RKE2 hardened 1.5
+- RKE permissive 1.20
+- RKE hardened 1.20
+- RKE permissive 1.23
+- RKE hardened 1.23
 - RKE2 permissive 1.6
 - RKE2 hardened 1.6
+- RKE2 permissive 1.20
+- RKE2 hardened 1.20
+- RKE2 permissive 1.23
+- RKE2 hardened 1.23
+- K3s permissive 1.6
+- K3s hardened 1.6
+- K3s permissive 1.20
+- K3s hardened 1.20
+- K3s permissive 1.23
+- K3s hardened 1.23
 - AKS
 - EKS
 - GKE
@@ -105,4 +115,4 @@ For more information about configuring the custom resources for the scans, profi

 ## How-to Guides

-Please refer [here](../pages-for-subheaders/cis-scan-guides.md) for how-to guides on CIS scans.
+Please refer to the [CIS Scan Guides](../pages-for-subheaders/cis-scan-guides.md) to learn how to run CIS scans.
@@ -5,7 +5,7 @@ title: Deploying Applications across Clusters

 Rancher v2.5 introduced Fleet, a new way to deploy applications across clusters.

-Fleet is GitOps at scale. For more information, refer to the [Fleet section.](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)
+Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section.](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)

 ### Multi-cluster Apps

@@ -1,8 +1,8 @@
 ---
-title: Fleet - GitOps at Scale
+title: Continuous Delivery with Fleet
 ---

-Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/tut-deployment#single-cluster-examples) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/tut-deployment#multi-cluster-examples). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/multi-cluster-install/). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

@@ -44,6 +44,15 @@ Any major versions that are less than the ones mentioned in the table below are

 - On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.

+### Prerelease Versions
+
+Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
+
+To display prerelease versions:
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Preferences**.
+1. Under **Helm Charts**, select **Include Prerelease Versions**.

 ### Charts

@@ -148,3 +157,5 @@ If you have a legacy app installed and want to upgrade it:
 ### Limitations

 [Dashboard apps or Rancher feature charts](helm-charts-in-rancher.md) **cannot** be installed using the Rancher CLI.
+
+a
@@ -143,9 +143,15 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher

 These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm).

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 # If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 # Add the Jetstack Helm repository
 helm repo add jetstack https://charts.jetstack.io
@@ -157,7 +163,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -0,0 +1,728 @@
+---
+title: K3s Hardening Guide
+---
+
+This document provides prescriptive guidance for how to harden a K3s cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
+
+:::note
+This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
+:::
+
+This hardening guide is intended to be used for K3s clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+| Rancher Version | CIS Benchmark Version | Kubernetes Version           |
+|-----------------|-----------------------|------------------------------|
+| Rancher v2.7    | Benchmark v1.23       | Kubernetes v1.23 up to v1.25 |
+
+:::note
+At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters.
+:::
+
+For more details on how to evaluate a hardened K3s cluster against the official CIS benchmark, refer to the K3s self-assessment guides for specific Kubernetes and CIS benchmark versions.
+
+K3s passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
+
+1. K3s does not modify the host operating system. Any host-level modifications need to be done manually.
+2. Certain CIS policy controls for `NetworkPolicies` and `PodSecurityStandards` (`PodSecurityPolicies` on v1.24 and older) restrict cluster functionality.
+   You must opt into having K3s configure these policies. Add the appropriate options to your command-line flags or configuration file (enable admission plugins), and manually apply the appropriate policies.
+   See further for more details.
+
+The first section (1.1) of the CIS Benchmark primarily focuses on  pod manifest permissions and ownership. Since everything in the distribution is packaged in a single binary, this section does not apply to the core components of K3s.
+
+## Host-level Requirements
+
+### Ensure `protect-kernel-defaults` is set
+
+This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
+
+The `protect-kernel-defaults` flag can be set in the cluster configuration in Rancher.
+
+```yaml
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          protect-kernel-defaults: true
+```
+
+### Set kernel parameters
+
+The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
+
+```ini
+vm.panic_on_oom=0
+vm.overcommit_memory=1
+kernel.panic=10
+kernel.panic_on_oops=1
+```
+
+Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
+
+This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
+
+## Kubernetes Runtime Requirements
+
+The CIS Benchmark runtime requirements center around pod security (via PSP or PSA), network policies and API Server auditing logs.
+
+By default, K3s does not include any pod security or network policies. However, K3s ships with a controller that enforces any network policies you create. By default, K3s enables both the `PodSecurity` and `NodeRestriction` admission controllers, among others.
+
+### Pod Security
+
+<Tabs groupId="k3s-version">
+<TabItem value="v1.25 and Newer" default>
+
+K3s v1.25 and newer support [Pod Security admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) for controlling pod security.
+
+You can specify the PSA configuration by setting the `defaultPodSecurityAdmissionConfigurationTemplateName` field in the cluster configuration in Rancher:
+
+```yaml
+spec:
+  defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
+```
+
+The `rancher-restricted` template is provided by Rancher to enforce the highly-restrictive Kubernetes upstream [`Restricted`](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) profile with best practices for pod hardening.
+
+</TabItem>
+<TabItem value="v1.24 and Older">
+
+K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
+
+You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
+
+```yaml
+spec:
+  rkeConfig:
+    machineGlobalConfig:
+      kube-apiserver-arg:
+        - enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount
+```
+
+This maintains the `NodeRestriction` plugin and enables the `PodSecurityPolicy`.
+
+Once you enable PSPs, you can apply a policy to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
+
+:::note
+These are manual checks in the CIS Benchmark. The CIS scan flags the results as `warning`, because manual inspection is necessary by the cluster operator.
+:::
+
+Here is an example of a compliant PSP:
+
+```yaml
+---
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: restricted-psp
+spec:
+  privileged: false                # CIS - 5.2.1
+  allowPrivilegeEscalation: false  # CIS - 5.2.5
+  requiredDropCapabilities:        # CIS - 5.2.7/8/9
+    - ALL
+  volumes:
+    - 'configMap'
+    - 'emptyDir'
+    - 'projected'
+    - 'secret'
+    - 'downwardAPI'
+    - 'csi'
+    - 'persistentVolumeClaim'
+    - 'ephemeral'
+  hostNetwork: false               # CIS - 5.2.4
+  hostIPC: false                   # CIS - 5.2.3
+  hostPID: false                   # CIS - 5.2.2
+  runAsUser:
+    rule: 'MustRunAsNonRoot'       # CIS - 5.2.6
+  seLinux:
+    rule: 'RunAsAny'
+  supplementalGroups:
+    rule: 'MustRunAs'
+    ranges:
+      - min: 1
+        max: 65535
+  fsGroup:
+    rule: 'MustRunAs'
+    ranges:
+      - min: 1
+        max: 65535
+  readOnlyRootFilesystem: false
+```
+
+For the example PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" for system-level pods that require additional privileges, and an additional policy that allows the necessary sysctls for full functionality of ServiceLB.
+
+```yaml
+---
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: restricted-psp
+spec:
+  privileged: false
+  allowPrivilegeEscalation: false
+  requiredDropCapabilities:
+    - ALL
+  volumes:
+    - 'configMap'
+    - 'emptyDir'
+    - 'projected'
+    - 'secret'
+    - 'downwardAPI'
+    - 'csi'
+    - 'persistentVolumeClaim'
+    - 'ephemeral'
+  hostNetwork: false
+  hostIPC: false
+  hostPID: false
+  runAsUser:
+    rule: 'MustRunAsNonRoot'
+  seLinux:
+    rule: 'RunAsAny'
+  supplementalGroups:
+    rule: 'MustRunAs'
+    ranges:
+      - min: 1
+        max: 65535
+  fsGroup:
+    rule: 'MustRunAs'
+    ranges:
+      - min: 1
+        max: 65535
+  readOnlyRootFilesystem: false
+---
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: system-unrestricted-psp
+  annotations:
+    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
+spec:
+  allowPrivilegeEscalation: true
+  allowedCapabilities:
+  - '*'
+  fsGroup:
+    rule: RunAsAny
+  hostIPC: true
+  hostNetwork: true
+  hostPID: true
+  hostPorts:
+  - max: 65535
+    min: 0
+  privileged: true
+  runAsUser:
+    rule: RunAsAny
+  seLinux:
+    rule: RunAsAny
+  supplementalGroups:
+    rule: RunAsAny
+  volumes:
+  - '*'
+---
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: svclb-psp
+  annotations:
+    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
+spec:
+  allowPrivilegeEscalation: false
+  allowedCapabilities:
+  - NET_ADMIN
+  allowedUnsafeSysctls:
+  - net.ipv4.ip_forward
+  - net.ipv6.conf.all.forwarding
+  fsGroup:
+    rule: RunAsAny
+  hostPorts:
+  - max: 65535
+    min: 0
+  runAsUser:
+    rule: RunAsAny
+  seLinux:
+    rule: RunAsAny
+  supplementalGroups:
+    rule: RunAsAny
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:restricted-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  verbs:
+  - use
+  resourceNames:
+  - restricted-psp
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:system-unrestricted-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  resourceNames:
+  - system-unrestricted-psp
+  verbs:
+  - use
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:svclb-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  resourceNames:
+  - svclb-psp
+  verbs:
+  - use
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:svc-local-path-provisioner-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  resourceNames:
+  - system-unrestricted-psp
+  verbs:
+  - use
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:svc-coredns-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  resourceNames:
+  - system-unrestricted-psp
+  verbs:
+  - use
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: psp:svc-cis-operator-psp
+rules:
+- apiGroups:
+  - policy
+  resources:
+  - podsecuritypolicies
+  resourceNames:
+  - system-unrestricted-psp
+  verbs:
+  - use
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: default:restricted-psp
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:restricted-psp
+subjects:
+- kind: Group
+  name: system:authenticated
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: system-unrestricted-node-psp-rolebinding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:system-unrestricted-psp
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:nodes
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: system-unrestricted-svc-acct-psp-rolebinding
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:system-unrestricted-psp
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:serviceaccounts
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: svclb-psp-rolebinding
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:svclb-psp
+subjects:
+- kind: ServiceAccount
+  name: svclb
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: svc-local-path-provisioner-psp-rolebinding
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:svc-local-path-provisioner-psp
+subjects:
+- kind: ServiceAccount
+  name: local-path-provisioner-service-account
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: svc-coredns-psp-rolebinding
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:svc-coredns-psp
+subjects:
+- kind: ServiceAccount
+  name: coredns
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: svc-cis-operator-psp-rolebinding
+  namespace: cis-operator-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: psp:svc-cis-operator-psp
+subjects:
+- kind: ServiceAccount
+  name: cis-operator-serviceaccount
+```
+
+The policies presented above can be placed in a file named `policy.yaml` in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
+
+```shell
+sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
+```
+
+:::note
+The critical Kubernetes additions such as CNI, DNS, and Ingress are run as pods in the `kube-system` namespace. Therefore, this namespace has a less restrictive policy, so that these components can run properly.
+:::
+
+</TabItem>
+</Tabs>
+
+### Network Policies
+
+CIS requires that all namespaces apply a network policy that reasonably limits traffic into namespaces and pods.
+
+:::note
+This is a manual check in the CIS Benchmark. The CIS scan flags the result as a `warning`, because manual inspection is necessary by the cluster operator.
+:::
+
+The network policies can be placed in the `policy.yaml` file in `/var/lib/rancher/k3s/server/manifests` directory. If the directory was not created as part of the PSP (as described above), it must be created first.
+
+```shell
+sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
+```
+
+Here is an example of a compliant network policy:
+
+```yaml
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+  name: intra-namespace
+  namespace: kube-system
+spec:
+  podSelector: {}
+  ingress:
+    - from:
+      - namespaceSelector:
+          matchLabels:
+            name: kube-system
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+  name: intra-namespace
+  namespace: default
+spec:
+  podSelector: {}
+  ingress:
+    - from:
+      - namespaceSelector:
+          matchLabels:
+            name: default
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+  name: intra-namespace
+  namespace: kube-public
+spec:
+  podSelector: {}
+  ingress:
+    - from:
+      - namespaceSelector:
+          matchLabels:
+            name: kube-public
+```
+
+The active restrictions block DNS unless purposely allowed. Below is a network policy that allows DNS-related traffic:
+
+```yaml
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-network-dns-policy
+  namespace: <NAMESPACE>
+spec:
+  ingress:
+  - ports:
+    - port: 53
+      protocol: TCP
+    - port: 53
+      protocol: UDP
+  podSelector:
+    matchLabels:
+      k8s-app: kube-dns
+  policyTypes:
+  - Ingress
+```
+
+The metrics-server and Traefik ingress controller are blocked by default if network policies are not created to allow access.
+
+```yaml
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-metrics-server
+  namespace: kube-system
+spec:
+  podSelector:
+    matchLabels:
+      k8s-app: metrics-server
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-svclbtraefik-ingress
+  namespace: kube-system
+spec:
+  podSelector:
+    matchLabels:
+      svccontroller.k3s.cattle.io/svcname: traefik
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-traefik-v121-ingress
+  namespace: kube-system
+spec:
+  podSelector:
+    matchLabels:
+      app.kubernetes.io/name: traefik
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
+```
+
+:::note
+You must manage network policies as normal for any additional namespaces you create.
+:::
+
+### API Server audit configuration
+
+CIS requirements 1.2.22 to 1.2.25 are related to configuring audit logs for the API Server. K3s does not create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
+
+If you need a log directory, it must be created before you start K3s. We recommend a restrictive access permission to avoid leaking sensitive information.
+
+```bash
+sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
+```
+
+The following is a starter audit policy to log request metadata. This policy should be written to a file named `audit.yaml` in the `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
+
+```yaml
+---
+apiVersion: audit.k8s.io/v1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+Further configurations are also needed to pass CIS checks. These are not configured by default in K3s, because they vary based on your environment and needs:
+
+- Ensure that the `--audit-log-path` argument is set.
+- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
+- Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
+- Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
+
+Combined, to enable and configure audit logs, add the following lines to the K3s cluster configuration file in Rancher:
+
+```yaml
+spec:
+  rkeConfig:
+    machineGlobalConfig:
+      kube-apiserver-arg:
+        - audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml    # CIS 3.2.1
+        - audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log   # CIS 1.2.18
+        - audit-log-maxage=30                                         # CIS 1.2.19
+        - audit-log-maxbackup=10                                      # CIS 1.2.20
+        - audit-log-maxsize=100                                       # CIS 1.2.21
+```
+
+### Controller Manager Requirements
+
+CIS requirement 1.3.1 checks for garbage collection settings in the Controller Manager. Garbage collection is important to ensure sufficient resource availability and avoid degraded performance and availability. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
+
+This can be remediated by setting the following configuration in the K3s cluster file in Rancher. The value below is only an example. The appropriate threshold value is specific to each user's environment.
+
+```yaml
+spec:
+  rkeConfig:
+    machineGlobalConfig:
+      kube-controller-manager-arg:
+        - terminated-pod-gc-threshold=10                              # CIS 1.3.1
+```
+
+### Configure `default` Service Account
+
+Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
+
+For CIS requirement 5.1.5 the `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
+
+This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
+
+For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default)`, K3s does not automatically do this.
+
+Save the following configuration to a file called `account_update.yaml`.
+
+```yaml
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: default
+automountServiceAccountToken: false
+```
+
+Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
+
+```shell
+#!/bin/bash -e
+
+for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
+  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
+done
+```
+
+Run the script every time a new service account is added to your cluster.
+
+## Reference Hardened K3s Template Configuration
+
+The following reference template configuration is used in Rancher to create a hardened K3s custom cluster based on each CIS control in this guide. This reference does not include other required **cluster configuration** directives, which vary based on your environment.
+
+<Tabs groupId="k3s-version">
+<TabItem value="v1.25 and Newer" default>
+
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+metadata:
+  name: # Define cluster name
+spec:
+  defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
+  enableNetworkPolicy: true
+  kubernetesVersion: # Define K3s version
+  rkeConfig:
+    machineGlobalConfig:
+      kube-apiserver-arg:
+        - enable-admission-plugins=NodeRestriction,ServiceAccount     # CIS 1.2.15, 1.2.13
+        - audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml    # CIS 3.2.1
+        - audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log   # CIS 1.2.18
+        - audit-log-maxage=30                                         # CIS 1.2.19
+        - audit-log-maxbackup=10                                      # CIS 1.2.20
+        - audit-log-maxsize=100                                       # CIS 1.2.21
+        - request-timeout=300s                                        # CIS 1.2.22
+        - service-account-lookup=true                                 # CIS 1.2.24
+      kube-controller-manager-arg:
+        - terminated-pod-gc-threshold=10                              # CIS 1.3.1
+      secrets-encryption: true
+    machineSelectorConfig:
+      - config:
+          kubelet-arg:
+            - make-iptables-util-chains=true                          # CIS 4.2.7
+          protect-kernel-defaults: true                               # CIS 4.2.6
+```
+
+</TabItem>
+<TabItem value="v1.24 and Older">
+
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+metadata:
+  name: # Define cluster name
+spec:
+  enableNetworkPolicy: true
+  kubernetesVersion: # Define K3s version
+  rkeConfig:
+    machineGlobalConfig:
+      kube-apiserver-arg:
+        - enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount    # CIS 1.2.15, 5.2, 1.2.13
+        - audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml    # CIS 3.2.1
+        - audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log   # CIS 1.2.18
+        - audit-log-maxage=30                                         # CIS 1.2.19
+        - audit-log-maxbackup=10                                      # CIS 1.2.20
+        - audit-log-maxsize=100                                       # CIS 1.2.21
+        - request-timeout=300s                                        # CIS 1.2.22
+        - service-account-lookup=true                                 # CIS 1.2.24
+      kube-controller-manager-arg:
+        - terminated-pod-gc-threshold=10                              # CIS 1.3.1
+      secrets-encryption: true
+    machineSelectorConfig:
+      - config:
+          kubelet-arg:
+            - make-iptables-util-chains=true                          # CIS 4.2.7
+          protect-kernel-defaults: true                               # CIS 4.2.6
+```
+
+</TabItem>
+</Tabs>
+
+## Conclusion
+
+If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
@@ -0,0 +1,52 @@
+---
+title: Self-Assessment and Hardening Guides for Rancher
+---
+
+Rancher provides specific security hardening guides for each supported Rancher version's Kubernetes distributions.
+
+## Rancher Kubernetes Distributions
+
+Rancher uses the following Kubernetes distributions:
+
+- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine, is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
+- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
+- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
+
+To harden a Kubernetes cluster that's running a distribution other than those listed, refer to your Kubernetes provider docs.
+
+## Hardening Guides and Benchmark Versions
+
+Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guides was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
+
+### RKE Guides
+
+| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
+|--------------------|-----------------------|-----------------------|------------------|
+| Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke1-hardening-guide.md) |
+| Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke1-hardening-guide.md) |
+| Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke1-hardening-guide.md) |
+
+### RKE2 Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke2-hardening-guide.md) |
+| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke2-hardening-guide.md) |
+| Rancher provisioned RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke2-hardening-guide.md) |
+| Standalone RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
+
+### K3s Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](k3s-hardening-guide.md) |
+| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](k3s-hardening-guide.md) |
+| Rancher provisioned K3s cluster | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](k3s-hardening-guide.md) |
+| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
+
+## Rancher with SELinux
+
+[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a kernel module that adds extra access controls and security tools to Linux. Historically used by government agencies, SELinux is now industry-standard. SELinux is enabled by default on RHEL and CentOS.
+
+To use Rancher with SELinux, we recommend [installing](../reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md) the `rancher-selinux` RPM.
+
@@ -1,51 +0,0 @@
---
-title: Self-Assessment and Hardening Guides for Rancher v2.6
---
-
-Rancher provides specific security hardening guides for each supported Rancher's Kubernetes distributions.
-
-
-## Rancher Kubernetes Distributions
-
-Rancher uses the following Kubernetes distributions:
-
- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine, is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- [**K3s**](https://rancher.com/docs/k3s/latest/en/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory of upstream Kubernetes, all in a binary of less than 100 MB.
-
-To harden a Kubernetes cluster outside of Rancher's distributions, refer to your Kubernetes provider docs.
-
-## Hardening Guides and Benchmark Versions
-
-These guides have been tested along with the Rancher v2.6 release. Each self-assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added.
-
-### RKE Guides
-
-| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ------------------ | --------------------- | --------------------- | ---------------- |
-| Kubernetes v1.18 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md) |
-
-:::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
-
-| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
-| Rancher provisioned RKE2 cluster |  Kubernetes v1.21 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md) |
-| Standalone RKE2 | Kubernetes v1.21 up to v1.23 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16/) | [Link](https://docs.rke2.io/security/hardening_guide/) |
-
-### K3s Guides
-
-| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
-| Standalone K3s | Kubernetes v1.21 and v1.22 | CIS v1.6 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
-
-## Rancher with SELinux
-
-[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on RHEL and CentOS.
-
-To use Rancher with SELinux, we recommend installing the `rancher-selinux` RPM according to the instructions on [this page.](selinux-rpm.md#installing-the-rancher-selinux-rpm)
@@ -1,52 +0,0 @@
---
-title: Self-Assessment and Hardening Guides for Rancher v2.7
---
-
-Rancher provides specific security hardening guides for each supported Rancher's Kubernetes distributions.
-
-
-## Rancher Kubernetes Distributions
-
-Rancher uses the following Kubernetes distributions:
-
- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine, is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- [**K3s**](https://rancher.com/docs/k3s/latest/en/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory of upstream Kubernetes, all in a binary of less than 100 MB.
-
-To harden a Kubernetes cluster outside of Rancher's distributions, refer to your Kubernetes provider docs.
-
-## Hardening Guides and Benchmark Versions
-
-These guides have been tested along with the Rancher v2.7 release. Each self-assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added.
-
-### RKE Guides
-
-| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ------------------ | --------------------- | --------------------- | ---------------- |
-| Kubernetes v1.18 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md) |
-
-:::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
-
-| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
-| Rancher provisioned RKE2 cluster |  Kubernetes v1.21 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md) |
-| Standalone RKE2 | Kubernetes v1.21 up to v1.23 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16/) | [Link](https://docs.rke2.io/security/hardening_guide/) |
-
-### K3s Guides
-
-| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
-| Rancher provisioned K3s cluster | Kubernetes v1.21 up to v1.24 | CIS v1.20 and v1.23 | [CIS v1.20](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-benchmark.md) | [Link](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-hardening-guide-with-cis-benchmark.md) |
-| Standalone K3s | Kubernetes v1.21 and v1.22 | CIS v1.6 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
-
-## Rancher with SELinux
-
-[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on RHEL and CentOS.
-
-To use Rancher with SELinux, we recommend installing the `rancher-selinux` RPM according to the instructions on [this page.](selinux-rpm.md#installing-the-rancher-selinux-rpm)
@@ -0,0 +1,504 @@
+---
+title: RKE Hardening Guide
+---
+
+This document provides prescriptive guidance for how to harden an RKE cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
+
+:::note
+This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
+:::
+
+This hardening guide is intended to be used for RKE clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+| Rancher Version | CIS Benchmark Version | Kubernetes Version           |
+|-----------------|-----------------------|------------------------------|
+| Rancher v2.7    | Benchmark v1.23       | Kubernetes v1.23 up to v1.25 |
+
+:::note
+At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.3, 5.2.4, 5.2.5 and 5.2.6 might fail.
+:::
+
+For more details on how to evaluate a hardened RKE cluster against the official CIS benchmark, refer to the RKE self-assessment guides for specific Kubernetes and CIS benchmark versions.
+
+## Host-level requirements
+
+### Configure Kernel Runtime Parameters
+
+The following `sysctl` configuration is recommended for all nodes types in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
+
+```ini
+vm.overcommit_memory=1
+vm.panic_on_oom=0
+kernel.panic=10
+kernel.panic_on_oops=1
+```
+
+Run `sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
+
+### Configure `etcd` user and group
+
+A user account and group for the **etcd** service is required to be set up before installing RKE.
+
+#### Create `etcd` user and group
+
+To create the **etcd** user and group run the following console commands.
+The commands below use `52034` for **uid** and **gid** for example purposes.
+Any valid unused **uid** or **gid** could also be used in lieu of `52034`.
+
+```bash
+groupadd --gid 52034 etcd
+useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
+```
+
+When deploying RKE through its cluster configuration `config.yml` file, update the `uid` and `gid` of the `etcd` user:
+
+```yaml
+services:
+  etcd:
+    gid: 52034
+    uid: 52034
+```
+
+## Kubernetes runtime requirements
+
+### Configure `default` Service Account
+
+#### Set `automountServiceAccountToken` to `false` for `default` service accounts
+
+Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
+Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
+The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
+
+For each namespace including `default` and `kube-system` on a standard RKE install, the `default` service account must include this value:
+
+```yaml
+automountServiceAccountToken: false
+```
+
+Save the following configuration to a file called `account_update.yaml`.
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: default
+automountServiceAccountToken: false
+```
+
+Create a bash script file called `account_update.sh`.
+Be sure to `chmod +x account_update.sh` so the script has execute permissions.
+
+```bash
+#!/bin/bash -e
+
+for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
+  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
+done
+```
+
+Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
+
+### Configure Network Policy
+
+#### Ensure that all Namespaces have Network Policies defined
+
+Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
+
+Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace. To enforce network policies, a container network interface (CNI) plugin must be enabled. This guide uses [Canal](https://github.com/projectcalico/canal) to provide the policy enforcement. Additional information about CNI providers can be found [here](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/).
+
+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.
+
+:::caution
+This network policy is just an example and is not recommended for production use.
+:::
+
+```yaml
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-allow-all
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  egress:
+  - {}
+  policyTypes:
+  - Ingress
+  - Egress
+```
+
+Create a bash script file called `apply_networkPolicy_to_all_ns.sh`. Be sure to `chmod +x apply_networkPolicy_to_all_ns.sh` so the script has execute permissions.
+
+```bash
+#!/bin/bash -e
+
+for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
+  kubectl apply -f default-allow-all.yaml -n ${namespace}
+done
+```
+
+Execute this script to apply the `default-allow-all.yaml` configuration with the **permissive** `NetworkPolicy` to all namespaces.
+
+## Known Limitations
+
+- Rancher **exec shell** and **view logs** for pods are **not** functional in a hardened setup when only a public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
+- When setting `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates `RoleBindings` and `ClusterRoleBindings` on the `default` service accounts. The CIS check 5.1.5 requires that the `default` service accounts have no roles or cluster roles bound to it apart from the defaults. In addition, the `default` service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
+
+## Reference Hardened RKE `cluster.yml` Configuration
+
+The reference `cluster.yml` is used by the RKE CLI that provides the configuration needed to achieve a hardened installation of RKE. RKE [documentation](https://rancher.com/docs/rke/latest/en/installation/) provides 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](https://rancher.com/docs/rke/latest/en/config-options/nodes/).
+
+The example `cluster.yml` configuration file contains an Admission Configuration policy in the `services.kube-api.admission_configuration` field. This [sample](../reference-guides/rancher-security/psa-restricted-exemptions.md) policy contains the namespace exemptions necessary for an imported RKE cluster to run properly in Rancher, similar to Rancher's pre-defined [`rancher-restricted`](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) policy.
+
+If you prefer to use RKE's default `restricted` policy, then leave the `services.kube-api.admission_configuration` field empty and set `services.pod_security_configuration` to `restricted`. See [the RKE docs](https://rke.docs.rancher.com/config-options/services/pod-security-admission) for more information.
+
+<Tabs groupId="rke1-version">
+<TabItem value="v1.25 and Newer" default>
+
+:::note
+If you intend to import an RKE cluster into Rancher, please consult the [documentation](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for how to configure the PSA to exempt Rancher system namespaces.
+:::
+
+```yaml
+# If you intend to deploy Kubernetes in an air-gapped environment,
+# please consult the documentation on how to configure custom RKE images.
+nodes: []
+kubernetes_version: # Define RKE version
+services:
+  etcd:
+    uid: 52034
+    gid: 52034
+  kube-api:
+    secrets_encryption_config:
+      enabled: true
+    audit_log:
+      enabled: true
+    event_rate_limit:
+      enabled: true
+    # Leave `pod_security_configuration` out if you are setting a
+    # custom policy in `admission_configuration`. Otherwise set
+    # it to `restricted` to use RKE's pre-defined restricted policy,
+    # and remove everything inside `admission_configuration` field.
+    #
+    # pod_security_configuration: restricted
+    #
+    admission_configuration:
+      apiVersion: apiserver.config.k8s.io/v1
+      kind: AdmissionConfiguration
+      plugins:
+        - name: PodSecurity
+          configuration:
+            apiVersion: pod-security.admission.config.k8s.io/v1
+            kind: PodSecurityConfiguration
+            defaults:
+              enforce: "restricted"
+              enforce-version: "latest"
+              audit: "restricted"
+              audit-version: "latest"
+              warn: "restricted"
+              warn-version: "latest"
+            exemptions:
+              usernames: []
+              runtimeClasses: []
+              namespaces: [ calico-apiserver,
+                            calico-system,
+                            cattle-alerting,
+                            cattle-csp-adapter-system,
+                            cattle-epinio-system,
+                            cattle-externalip-system,
+                            cattle-fleet-local-system,
+                            cattle-fleet-system,
+                            cattle-gatekeeper-system,
+                            cattle-global-data,
+                            cattle-global-nt,
+                            cattle-impersonation-system,
+                            cattle-istio,
+                            cattle-istio-system,
+                            cattle-logging,
+                            cattle-logging-system,
+                            cattle-monitoring-system,
+                            cattle-neuvector-system,
+                            cattle-prometheus,
+                            cattle-sriov-system,
+                            cattle-system,
+                            cattle-ui-plugin-system,
+                            cattle-windows-gmsa-system,
+                            cert-manager,
+                            cis-operator-system,
+                            fleet-default,
+                            ingress-nginx,
+                            istio-system,
+                            kube-node-lease,
+                            kube-public,
+                            kube-system,
+                            longhorn-system,
+                            rancher-alerting-drivers,
+                            security-scan,
+                            tigera-operator ]
+  kube-controller:
+    extra_args:
+      feature-gates: RotateKubeletServerCertificate=true
+  kubelet:
+    extra_args:
+      feature-gates: RotateKubeletServerCertificate=true
+      protect-kernel-defaults: "true"
+    generate_serving_certificate: true
+addons: |
+  apiVersion: networking.k8s.io/v1
+  kind: NetworkPolicy
+  metadata:
+    name: default-allow-all
+  spec:
+    podSelector: {}
+    ingress:
+    - {}
+    egress:
+    - {}
+    policyTypes:
+    - Ingress
+    - Egress
+  ---
+  apiVersion: v1
+  kind: ServiceAccount
+  metadata:
+    name: default
+  automountServiceAccountToken: false
+```
+
+</TabItem>
+<TabItem value="v1.24 and Older">
+
+```yaml
+# If you intend to deploy Kubernetes in an air-gapped environment,
+# please consult the documentation on how to configure custom RKE images.
+nodes: []
+kubernetes_version: # Define RKE version
+services:
+  etcd:
+    uid: 52034
+    gid: 52034
+  kube-api:
+    secrets_encryption_config:
+      enabled: true
+    audit_log:
+      enabled: true
+    event_rate_limit:
+      enabled: true
+    pod_security_policy: true
+  kube-controller:
+    extra_args:
+      feature-gates: RotateKubeletServerCertificate=true
+  kubelet:
+    extra_args:
+      feature-gates: RotateKubeletServerCertificate=true
+      protect-kernel-defaults: true
+    generate_serving_certificate: true
+addons: |
+  # Upstream Kubernetes restricted PSP policy
+  # https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
+  apiVersion: policy/v1beta1
+  kind: PodSecurityPolicy
+  metadata:
+    name: restricted-noroot
+  spec:
+    privileged: false
+    # Required to prevent escalations to root.
+    allowPrivilegeEscalation: false
+    requiredDropCapabilities:
+      - ALL
+    # Allow core volume types.
+    volumes:
+      - 'configMap'
+      - 'emptyDir'
+      - 'projected'
+      - 'secret'
+      - 'downwardAPI'
+      # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
+      - 'csi'
+      - 'persistentVolumeClaim'
+      - 'ephemeral'
+    hostNetwork: false
+    hostIPC: false
+    hostPID: false
+    runAsUser:
+      # Require the container to run without root privileges.
+      rule: 'MustRunAsNonRoot'
+    seLinux:
+      # This policy assumes the nodes are using AppArmor rather than SELinux.
+      rule: 'RunAsAny'
+    supplementalGroups:
+      rule: 'MustRunAs'
+      ranges:
+        # Forbid adding the root group.
+        - min: 1
+          max: 65535
+    fsGroup:
+      rule: 'MustRunAs'
+      ranges:
+        # Forbid adding the root group.
+        - min: 1
+          max: 65535
+    readOnlyRootFilesystem: false
+  ---
+  apiVersion: rbac.authorization.k8s.io/v1
+  kind: ClusterRole
+  metadata:
+    name: psp:restricted-noroot
+  rules:
+  - apiGroups:
+    - extensions
+    resourceNames:
+    - restricted-noroot
+    resources:
+    - podsecuritypolicies
+    verbs:
+    - use
+  ---
+  apiVersion: rbac.authorization.k8s.io/v1
+  kind: ClusterRoleBinding
+  metadata:
+    name: psp:restricted-noroot
+  roleRef:
+    apiGroup: rbac.authorization.k8s.io
+    kind: ClusterRole
+    name: psp:restricted-noroot
+  subjects:
+  - apiGroup: rbac.authorization.k8s.io
+    kind: Group
+    name: system:serviceaccounts
+  - apiGroup: rbac.authorization.k8s.io
+    kind: Group
+    name: system:authenticated
+  ---
+  apiVersion: networking.k8s.io/v1
+  kind: NetworkPolicy
+  metadata:
+    name: default-allow-all
+  spec:
+    podSelector: {}
+    ingress:
+    - {}
+    egress:
+    - {}
+    policyTypes:
+    - Ingress
+    - Egress
+  ---
+  apiVersion: v1
+  kind: ServiceAccount
+  metadata:
+    name: default
+  automountServiceAccountToken: false
+```
+
+</TabItem>
+</Tabs>
+
+## Reference Hardened RKE Cluster Template Configuration
+
+The reference RKE cluster template provides the minimum required configuration to achieve a hardened installation of Kubernetes. RKE templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher [documentation](installation-and-upgrade.md) for additional information about installing RKE and its template details.
+
+<Tabs groupId="rke1-version">
+<TabItem value="v1.25 and Newer" default>
+
+```yaml
+#
+# Cluster Config
+#
+default_pod_security_admission_configuration_template_name: rancher-restricted
+enable_network_policy: true
+local_cluster_auth_endpoint:
+  enabled: true
+name: # Define cluster name
+
+#
+# Rancher Config
+#
+rancher_kubernetes_engine_config:
+  addon_job_timeout: 45
+  authentication:
+    strategy: x509|webhook
+  kubernetes_version: # Define RKE version
+  services:
+    etcd:
+      uid: 52034
+      gid: 52034
+    kube-api:
+      audit_log:
+        enabled: true
+      event_rate_limit:
+        enabled: true
+      pod_security_policy: false
+      secrets_encryption_config:
+        enabled: true
+    kube-controller:
+      extra_args:
+        feature-gates: RotateKubeletServerCertificate=true
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+    kubelet:
+      extra_args:
+        feature-gates: RotateKubeletServerCertificate=true
+        protect-kernel-defaults: true
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+      generate_serving_certificate: true
+    scheduler:
+      extra_args:
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+```
+
+</TabItem>
+<TabItem value="v1.24 and Older">
+
+```yaml
+#
+# Cluster Config
+#
+default_pod_security_policy_template_id: restricted-noroot
+enable_network_policy: true
+local_cluster_auth_endpoint:
+  enabled: true
+name: # Define cluster name
+
+#
+# Rancher Config
+#
+rancher_kubernetes_engine_config:
+  addon_job_timeout: 45
+  authentication:
+    strategy: x509|webhook
+  kubernetes_version: # Define RKE version
+  services:
+    etcd:
+      uid: 52034
+      gid: 52034
+    kube-api:
+      audit_log:
+        enabled: true
+      event_rate_limit:
+        enabled: true
+      pod_security_policy: true
+      secrets_encryption_config:
+        enabled: true
+    kube-controller:
+      extra_args:
+        feature-gates: RotateKubeletServerCertificate=true
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+    kubelet:
+      extra_args:
+        feature-gates: RotateKubeletServerCertificate=true
+        protect-kernel-defaults: true
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+      generate_serving_certificate: true
+    scheduler:
+      extra_args:
+        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+```
+
+</TabItem>
+</Tabs>
+
+## Conclusion
+
+If you have followed this guide, your RKE custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
@@ -0,0 +1,259 @@
+---
+title: RKE2 Hardening Guide
+---
+
+This document provides prescriptive guidance for how to harden an RKE2 cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
+
+:::note
+This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
+:::
+
+This hardening guide is intended to be used for RKE2 clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+| Rancher Version | CIS Benchmark Version | Kubernetes Version           |
+|-----------------|-----------------------|------------------------------|
+| Rancher v2.7    | Benchmark v1.23       | Kubernetes v1.23 up to v1.25 |
+
+:::note
+At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.2, 5.2.3, 5.2.5, 5.2.6, 5.2.7 and 5.2.8 might fail.
+:::
+
+For more details on how to evaluate a hardened RKE2 cluster against the official CIS benchmark, refer to the RKE2 self-assessment guides for specific Kubernetes and CIS benchmark versions.
+
+RKE2 passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
+
+1. RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
+2. Certain CIS controls for Network Policies and Pod Security Standards (or Pod Security Policies (PSP) on RKE2 versions prior to v1.25) will restrict the functionality of the cluster. You must opt into having RKE2 configure these for you. To help ensure these requirements are met, RKE2 can be started with the profile flag set to `cis-1.23` for v1.25 and newer or `cis-1.6` for v1.24 and older.
+
+## Host-level requirements
+
+There are two areas of host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
+
+### Set kernel parameters
+
+The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
+
+```ini
+vm.panic_on_oom=0
+vm.overcommit_memory=1
+kernel.panic=10
+kernel.panic_on_oops=1
+```
+
+Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
+
+### Ensure etcd is configured properly
+
+The CIS Benchmark requires that the etcd data directory be owned by the `etcd` user and group. This implicitly requires the etcd process run as the host-level `etcd` user. To achieve this, RKE2 takes several steps when started with a valid `cis-1.xx` profile:
+
+1. Check that the `etcd` user and group exists on the host. If they don't, exit with an error.
+2. Create etcd's data directory with `etcd` as the user and group owner.
+3. Ensure the etcd process is ran as the `etcd` user and group by setting the etcd static pod's `SecurityContext` appropriately.
+
+To meet the above requirements, you must:
+
+#### Create the etcd user
+
+On some Linux distributions, the `useradd` command will not create a group. The `-U` flag is included below to account for that. This flag tells `useradd` to create a group with the same name as the user.
+
+```bash
+sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
+```
+
+## Kubernetes runtime requirements
+
+The runtime requirements to pass the CIS Benchmark are centered around pod security, network policies and kernel parameters. Most of this is automatically handled by RKE2 when using a valid `cis-1.xx` profile, but some additional operator intervention is required. These are outlined in this section.
+
+### Ensure `protect-kernel-defaults` is set
+
+This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
+
+Both `protect-kernel-defaults` and `profile` flags can be set in the RKE2 template configuration file.
+When the `profile` flag is set, RKE2 will set the flag to `true` if it is unset.
+
+```yaml
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          profile: # use cis-1.23 or cis-1.6
+          protect-kernel-defaults: true
+```
+
+### PodSecurity
+
+RKE2 always runs with some amount of pod security.
+
+<Tabs groupId="rke2-version">
+<TabItem value="v1.25 and Newer" default>
+
+On v1.25 and newer, [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) are used for pod security.
+
+Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
+
+```yaml
+spec:
+  defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          profile: cis-1.23
+```
+
+When both the `defaultPodSecurityAdmissionConfigurationTemplateName` and `profile` flags are set, Rancher and RKE2 does the following:
+
+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. Applies network policies that allow the cluster to pass associated controls.
+3. Configures the Pod Security Admission Controller with the PSA configuration template `rancher-restricted`, to enforce restricted mode in all namespaces, except the ones in the template's exemption list.
+   These namespaces are exempted to allow system pods to run without restrictions, which is required for proper operation of the cluster.
+
+:::note
+If you intend to import an RKE cluster into Rancher, please consult the [documentation](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for how to configure the PSA to exempt Rancher system namespaces.
+:::
+
+</TabItem>
+
+<TabItem value="v1.24 and Older">
+
+On Kubernetes v1.24 and older, the `PodSecurityPolicy` admission controller is always enabled.
+
+Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
+
+:::note
+In the following example the profile is set to `cis-1.6` which is the value defined in the upstream RKE2, but the cluster is actually configured to pass the CIS v1.23 hardened profile
+:::
+
+```yaml
+spec:
+  defaultPodSecurityPolicyTemplateName: restricted-noroot
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          profile: cis-1.6
+```
+
+
+When both the `defaultPodSecurityPolicyTemplateName` and `profile` flags are set, Rancher and RKE2 does the following:
+
+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. Applies network policies that allow the cluster to pass associated controls.
+3. Configures runtime pod security policies that allow the cluster to pass associated controls.
+
+</TabItem>
+</Tabs>
+
+:::note
+The Kubernetes control plane components and critical additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
+:::
+
+### NetworkPolicies
+
+When ran with a valid `cis-1.xx` profile, RKE2 will put `NetworkPolicies` in place that passes the CIS Benchmark for Kubernetes' built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
+
+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.
+
+:::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**
+
+Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
+
+For each namespace including `default` and `kube-system` on a standard RKE2 install, the `default` service account must include this value:
+
+```yaml
+automountServiceAccountToken: false
+```
+
+For namespaces created by the cluster operator, the following script and configuration file can be used to configure the `default` service account.
+
+The configuration bellow must be saved to a file called `account_update.yaml`.
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: default
+automountServiceAccountToken: false
+```
+
+Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
+
+```bash
+#!/bin/bash -e
+
+for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
+  echo -n "Patching namespace $namespace - "
+  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
+done
+```
+
+Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
+
+### API Server audit configuration
+
+CIS requirements 1.2.19 to 1.2.22 are related to configuring audit logs for the API Server. When RKE2 is started with the `profile` flag set, it will automatically configure hardened `--audit-log-` parameters in the API Server to pass those CIS checks.
+
+RKE2's default audit policy is configured to not log requests in the API Server. This is done to allow cluster operators flexibility to customize an audit policy that suits their auditing requirements and needs, as these are specific to each users' environment and policies.
+
+A default audit policy is created by RKE2 when started with the `profile` flag set. The policy is defined in `/etc/rancher/rke2/audit-policy.yaml`.
+
+```yaml
+apiVersion: audit.k8s.io/v1
+kind: Policy
+metadata:
+  creationTimestamp: null
+rules:
+- level: None
+```
+
+## Reference Hardened RKE2 Template Configuration
+
+The reference template configuration is used in Rancher to create a hardened RKE2 custom cluster. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
+
+
+<Tabs groupId="rke2-version">
+<TabItem value="v1.25 and Newer" default>
+
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+metadata:
+  name: # Define cluster name
+spec:
+  defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
+  kubernetesVersion: # Define RKE2 version
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          profile: cis-1.23
+          protect-kernel-defaults: true
+```
+</TabItem>
+
+<TabItem value="v1.24 and Older">
+
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+metadata:
+  name: # Define cluster name
+spec:
+  defaultPodSecurityPolicyTemplateName: restricted-noroot
+  kubernetesVersion: # Define RKE2 version
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          profile: cis-1.6
+          protect-kernel-defaults: true
+```
+
+</TabItem>
+</Tabs>
+
+## Conclusion
+
+If you have followed this guide, your RKE2 custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE2 self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
@@ -0,0 +1,60 @@
+---
+title: Sample PodSecurityConfiguration
+---
+
+The following PodSecurityConfiguration contains the required Rancher namespace exemptions for a `rancher-restricted` cluster to run properly.
+
+```yaml
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+  - name: PodSecurity
+    configuration:
+      apiVersion: pod-security.admission.config.k8s.io/v1
+      kind: PodSecurityConfiguration
+      defaults:
+        enforce: "restricted"
+        enforce-version: "latest"
+        audit: "restricted"
+        audit-version: "latest"
+        warn: "restricted"
+        warn-version: "latest"
+      exemptions:
+        usernames: []
+        runtimeClasses: []
+        namespaces: [calico-apiserver,
+                     calico-system,
+                     cattle-alerting,
+                     cattle-csp-adapter-system,
+                     cattle-epinio-system,
+                     cattle-externalip-system,
+                     cattle-fleet-local-system,
+                     cattle-fleet-system,
+                     cattle-gatekeeper-system,
+                     cattle-global-data,
+                     cattle-global-nt,
+                     cattle-impersonation-system,
+                     cattle-istio,
+                     cattle-istio-system,
+                     cattle-logging,
+                     cattle-logging-system,
+                     cattle-monitoring-system,
+                     cattle-neuvector-system,
+                     cattle-prometheus,
+                     cattle-sriov-system,
+                     cattle-system,
+                     cattle-ui-plugin-system,
+                     cattle-windows-gmsa-system,
+                     cert-manager,
+                     cis-operator-system,
+                     fleet-default,
+                     ingress-nginx,
+                     istio-system,
+                     kube-node-lease,
+                     kube-public,
+                     kube-system,
+                     longhorn-system,
+                     rancher-alerting-drivers,
+                     security-scan,
+                     tigera-operator]
+```
@@ -1,644 +0,0 @@
---
-title: RKE Hardening Guide with CIS v1.6 Benchmark
---
-
-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).
-
-:::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:
-
-| Rancher Version | CIS Benchmark Version | Kubernetes Version |
-| --------------- | --------------------- | ------------------ |
-| Rancher v2.6 | Benchmark v1.6 | Kubernetes v1.18 up to v1.23 |
-
-[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.6/Rancher_v2-6_CIS_v1-6_Hardening_Guide.pdf).
-
-
-### Overview
-
-This document provides prescriptive guidance for hardening a RKE cluster to be used for installing Rancher v2.6 with Kubernetes v1.18 up to v1.23 or provisioning a RKE cluster with Kubernetes v1.18 up to v1.23 to be used within Rancher v2.6. It outlines the configurations required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
-
-For more details about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS 1.6 Benchmark - Self-Assessment Guide - Rancher v2.6](./rke1-self-assessment-guide-with-cis-v1.6-benchmark.md).
-
-#### Known Issues
-
- Rancher **exec shell** and **view logs** for pods are **not** functional in a CIS v1.6 hardened setup when only public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
- When setting the `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates **RoleBindings** and **ClusterRoleBindings** on the default service accounts. The CIS v1.6 check 5.1.5 requires that the default service accounts have no roles or cluster roles bound to it apart from the defaults. In addition the default service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
-
-### Configure Kernel Runtime Parameters
-
-The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
-
-```ini
-vm.overcommit_memory=1
-vm.panic_on_oom=0
-kernel.panic=10
-kernel.panic_on_oops=1
-kernel.keys.root_maxbytes=25000000
-```
-
-Run `sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
-
-### Configure `etcd` user and group
-
-A user account and group for the **etcd** service is required to be setup before installing RKE. The **uid** and **gid** for the **etcd** user will be used in the RKE **config.yml** to set the proper permissions for files and directories during installation time.
-
-#### Create `etcd` user and group
-
-To create the **etcd** user and group run the following console commands. The commands below use `52034` for **uid** and **gid** are for example purposes. Any valid unused **uid** or **gid** could also be used in lieu of `52034`.
-
-```bash
-groupadd --gid 52034 etcd
-useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
-```
-
-Update the RKE **config.yml** with the **uid** and **gid** of the **etcd** user:
-
-```yaml
-services:
-  etcd:
-    gid: 52034
-    uid: 52034
-```
-
-### Configure `default` Service Account
-
-#### Set `automountServiceAccountToken` to `false` for `default` service accounts
-
-Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
-
-For each namespace including **default** and **kube-system** on a standard RKE install, the **default** service account must include this value:
-
-```yaml
-automountServiceAccountToken: false
-```
-
-Save the following configuration to a file called `account_update.yaml`.
-
-```yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: default
-automountServiceAccountToken: false
-```
-
-Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
-
-```bash
-#!/bin/bash -e
-
-for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
-  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
-done
-```
-
-### Configure Network Policy
-
-#### Ensure that all Namespaces have Network Policies defined
-
-Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
-
-Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace. To enforce network policies, a CNI (container network interface) plugin must be enabled. This guide uses [Canal](https://github.com/projectcalico/canal) to provide the policy enforcement. Additional information about CNI providers can be found [here](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/).
-
-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.
-
-:::note
-
-This `NetworkPolicy` is just an example and is not recommended for production use.
-
-:::
-
-```yaml
---
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-allow-all
-spec:
-  podSelector: {}
-  ingress:
-  - {}
-  egress:
-  - {}
-  policyTypes:
-  - Ingress
-  - Egress
-```
-
-Create a bash script file called `apply_networkPolicy_to_all_ns.sh`. Be sure to `chmod +x apply_networkPolicy_to_all_ns.sh` so the script has execute permissions.
-
-```bash
-#!/bin/bash -e
-
-for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
-  kubectl apply -f default-allow-all.yaml -n ${namespace}
-done
-```
-
-Execute this script to apply the `default-allow-all.yaml` configuration with the **permissive** `NetworkPolicy` to all namespaces.
-
-### Reference Hardened RKE `cluster.yml` Configuration
-
-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](https://rancher.com/docs/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](https://rancher.com/docs/rke/latest/en/config-options/nodes/).
-
-:::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,
-# please consult the documentation on how to configure custom RKE images.
-# https://rancher.com/docs/rke/latest/en/installation/ .
-
-# The nodes directive is required and will vary depending on your environment.
-# Documentation for node configuration can be found here:
-# https://rancher.com/docs/rke/latest/en/config-options/nodes/
-nodes: []
-services:
-  etcd:
-    image: ""
-    extra_args: {}
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-    external_urls: []
-    ca_cert: ""
-    cert: ""
-    key: ""
-    path: ""
-    uid: 52034
-    gid: 52034
-    snapshot: false
-    retention: ""
-    creation: ""
-    backup_config: null
-  kube-api:
-    image: ""
-    extra_args: {}
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-    service_cluster_ip_range: ""
-    service_node_port_range: ""
-    pod_security_policy: true
-    always_pull_images: false
-    secrets_encryption_config:
-      enabled: true
-      custom_config: null
-    audit_log:
-      enabled: true
-      configuration: null
-    admission_configuration: null
-    event_rate_limit:
-      enabled: true
-      configuration: null
-  kube-controller:
-    image: ""
-    extra_args:
-      feature-gates: RotateKubeletServerCertificate=true
-      tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-      bind-address: 127.0.0.1
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-    cluster_cidr: ""
-    service_cluster_ip_range: ""
-  scheduler:
-    image: ""
-    extra_args:
-      tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-      bind-address: 127.0.0.1
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-  kubelet:
-    image: ""
-    extra_args:
-      feature-gates: RotateKubeletServerCertificate=true
-      protect-kernel-defaults: true
-      tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-    cluster_domain: cluster.local
-    infra_container_image: ""
-    cluster_dns_server: ""
-    fail_swap_on: false
-    generate_serving_certificate: true
-  kubeproxy:
-    image: ""
-    extra_args: {}
-    extra_binds: []
-    extra_env: []
-    win_extra_args: {}
-    win_extra_binds: []
-    win_extra_env: []
-network:
-  plugin: ""
-  options: {}
-  mtu: 0
-  node_selector: {}
-  update_strategy: null
-authentication:
-  strategy: ""
-  sans: []
-  webhook: null
-addons: |
-  # Upstream Kubernetes restricted PSP policy
-  # https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
-  apiVersion: policy/v1beta1
-  kind: PodSecurityPolicy
-  metadata:
-    name: restricted-noroot
-  spec:
-    privileged: false
-    # Required to prevent escalations to root.
-    allowPrivilegeEscalation: false
-    requiredDropCapabilities:
-      - ALL
-    # Allow core volume types.
-    volumes:
-      - 'configMap'
-      - 'emptyDir'
-      - 'projected'
-      - 'secret'
-      - 'downwardAPI'
-      # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
-      - 'csi'
-      - 'persistentVolumeClaim'
-      - 'ephemeral'
-    hostNetwork: false
-    hostIPC: false
-    hostPID: false
-    runAsUser:
-      # Require the container to run without root privileges.
-      rule: 'MustRunAsNonRoot'
-    seLinux:
-      # This policy assumes the nodes are using AppArmor rather than SELinux.
-      rule: 'RunAsAny'
-    supplementalGroups:
-      rule: 'MustRunAs'
-      ranges:
-        # Forbid adding the root group.
-        - min: 1
-          max: 65535
-    fsGroup:
-      rule: 'MustRunAs'
-      ranges:
-        # Forbid adding the root group.
-        - min: 1
-          max: 65535
-    readOnlyRootFilesystem: false
-  ---
-  apiVersion: rbac.authorization.k8s.io/v1
-  kind: ClusterRole
-  metadata:
-    name: psp:restricted-noroot
-  rules:
-  - apiGroups:
-    - extensions
-    resourceNames:
-    - restricted-noroot
-    resources:
-    - podsecuritypolicies
-    verbs:
-    - use
-  ---
-  apiVersion: rbac.authorization.k8s.io/v1
-  kind: ClusterRoleBinding
-  metadata:
-    name: psp:restricted-noroot
-  roleRef:
-    apiGroup: rbac.authorization.k8s.io
-    kind: ClusterRole
-    name: psp:restricted-noroot
-  subjects:
-  - apiGroup: rbac.authorization.k8s.io
-    kind: Group
-    name: system:serviceaccounts
-  - apiGroup: rbac.authorization.k8s.io
-    kind: Group
-    name: system:authenticated
-  ---
-  apiVersion: networking.k8s.io/v1
-  kind: NetworkPolicy
-  metadata:
-    name: default-allow-all
-  spec:
-    podSelector: {}
-    ingress:
-    - {}
-    egress:
-    - {}
-    policyTypes:
-    - Ingress
-    - Egress
-  ---
-  apiVersion: v1
-  kind: ServiceAccount
-  metadata:
-    name: default
-  automountServiceAccountToken: false
-addons_include: []
-system_images:
-  etcd: ""
-  alpine: ""
-  nginx_proxy: ""
-  cert_downloader: ""
-  kubernetes_services_sidecar: ""
-  kubedns: ""
-  dnsmasq: ""
-  kubedns_sidecar: ""
-  kubedns_autoscaler: ""
-  coredns: ""
-  coredns_autoscaler: ""
-  nodelocal: ""
-  kubernetes: ""
-  flannel: ""
-  flannel_cni: ""
-  calico_node: ""
-  calico_cni: ""
-  calico_controllers: ""
-  calico_ctl: ""
-  calico_flexvol: ""
-  canal_node: ""
-  canal_cni: ""
-  canal_controllers: ""
-  canal_flannel: ""
-  canal_flexvol: ""
-  weave_node: ""
-  weave_cni: ""
-  pod_infra_container: ""
-  ingress: ""
-  ingress_backend: ""
-  metrics_server: ""
-  windows_pod_infra_container: ""
-ssh_key_path: ""
-ssh_cert_path: ""
-ssh_agent_auth: false
-authorization:
-  mode: ""
-  options: {}
-ignore_docker_version: false
-kubernetes_version: ""
-private_registries: []
-ingress:
-  provider: ""
-  options: {}
-  node_selector: {}
-  extra_args: {}
-  dns_policy: ""
-  extra_envs: []
-  extra_volumes: []
-  extra_volume_mounts: []
-  update_strategy: null
-  http_port: 0
-  https_port: 0
-  network_mode: ""
-cluster_name:
-cloud_provider:
-  name: ""
-prefix_path: ""
-win_prefix_path: ""
-addon_job_timeout: 0
-bastion_host:
-  address: ""
-  port: ""
-  user: ""
-  ssh_key: ""
-  ssh_key_path: ""
-  ssh_cert: ""
-  ssh_cert_path: ""
-monitoring:
-  provider: ""
-  options: {}
-  node_selector: {}
-  update_strategy: null
-  replicas: null
-restore:
-  restore: false
-  snapshot_name: ""
-dns: null
-upgrade_strategy:
-  max_unavailable_worker: ""
-  max_unavailable_controlplane: ""
-  drain: null
-  node_drain_input: null
-```
-
-### Reference Hardened RKE Template Configuration
-
-The reference RKE template provides the configuration needed to achieve a hardened install of Kubernetes. RKE templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher [documentation](../../../pages-for-subheaders/installation-and-upgrade.md) for additional installation and RKE template details.
-
-```yaml
-#
-# Cluster Config
-#
-default_pod_security_policy_template_id: restricted-noroot
-docker_root_dir: /var/lib/docker
-enable_cluster_alerting: false
-enable_cluster_monitoring: false
-enable_network_policy: true
-local_cluster_auth_endpoint:
-  enabled: true
-name: ''
-#
-# Rancher Config
-#
-rancher_kubernetes_engine_config:
-  addon_job_timeout: 45
-  authentication:
-    strategy: x509
-  dns:
-    nodelocal:
-      ip_address: ''
-      node_selector: null
-      update_strategy: {}
-  enable_cri_dockerd: false
-  ignore_docker_version: true
-#
-# # Currently only nginx ingress provider is supported.
-# # To disable ingress controller, set `provider: none`
-# # To enable ingress on specific nodes, use the node_selector, eg:
-#    provider: nginx
-#    node_selector:
-#      app: ingress
-#
-  ingress:
-    default_backend: false
-    default_ingress_class: true
-    http_port: 0
-    https_port: 0
-    provider: nginx
-  kubernetes_version: v1.21.8-rancher1-1
-  monitoring:
-    provider: metrics-server
-    replicas: 1
-#
-#   If you are using calico on AWS
-#
-#    network:
-#      plugin: calico
-#      calico_network_provider:
-#        cloud_provider: aws
-#
-# # To specify flannel interface
-#
-#    network:
-#      plugin: flannel
-#      flannel_network_provider:
-#      iface: eth1
-#
-# # To specify flannel interface for canal plugin
-#
-#    network:
-#      plugin: canal
-#      canal_network_provider:
-#        iface: eth1
-#
-  network:
-    mtu: 0
-    options:
-      flannel_backend_type: vxlan
-    plugin: canal
-  rotate_encryption_key: false
-#
-#    services:
-#      kube-api:
-#        service_cluster_ip_range: 10.43.0.0/16
-#      kube-controller:
-#        cluster_cidr: 10.42.0.0/16
-#        service_cluster_ip_range: 10.43.0.0/16
-#      kubelet:
-#        cluster_domain: cluster.local
-#        cluster_dns_server: 10.43.0.10
-#
-  services:
-    scheduler:
-      extra_args:
-        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-      bind-address: 127.0.0.1
-    etcd:
-      backup_config:
-        enabled: true
-        interval_hours: 12
-        retention: 6
-        safe_timestamp: false
-        timeout: 300
-      creation: 12h
-      extra_args:
-        election-timeout: 5000
-        heartbeat-interval: 500
-      retention: 72h
-      snapshot: false
-      uid: 52034
-      gid: 52034
-    kube_api:
-      always_pull_images: false
-      audit_log:
-        enabled: true
-      event_rate_limit:
-        enabled: true
-      pod_security_policy: true
-      secrets_encryption_config:
-        enabled: true
-      service_node_port_range: 30000-32767
-    kube-controller:
-      extra_args:
-        feature-gates: RotateKubeletServerCertificate=true
-        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-      bind-address: 127.0.0.1
-    kubelet:
-      extra_args:
-        feature-gates: RotateKubeletServerCertificate=true
-        protect-kernel-defaults: true
-        tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-      fail_swap_on: false
-      generate_serving_certificate: true
-  ssh_agent_auth: false
-  upgrade_strategy:
-    max_unavailable_controlplane: '1'
-    max_unavailable_worker: 10%
-windows_prefered_cluster: false
-```
-
-### Reference Hardened **cloud-config** Configuration
-
-A **cloud-config** configuration file is generally used in cloud infrastructure environments to allow for configuration management of compute instances. The reference config configures SUSE Linux Enterprise Server (SLES), openSUSE Leap, Red Hat Enterprise Linux (RHEL) and Ubuntu operating system level settings needed before installing Kubernetes.
-
-#### Reference Hardened **cloud-config** for SUSE Linux Enterprise Server 15 (SLES 15) and openSUSE Leap 15
-
-```yaml
-#cloud-config
-system_info:
-  default_user:
-    groups:
-    - docker
-write_files:
- path: "/etc/sysctl.d/90-kubelet.conf"
-  owner: root:root
-  permissions: '0644'
-  content: |
-    vm.overcommit_memory=1
-    vm.panic_on_oom=0
-    kernel.panic=10
-    kernel.panic_on_oops=1
-    kernel.keys.root_maxbytes=25000000
-package_update: true
-ssh_pwauth: false
-runcmd:
-# Docker should already be installed in SLES 15 SP3
- zypper install docker containerd
- systemctl daemon-reload
- systemctl enable docker.service
- systemctl start --no-block docker.service
- sysctl -p /etc/sysctl.d/90-kubelet.conf
- groupadd --gid 52034 etcd
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
-```
-
-#### Reference Hardened **cloud-config** for Red Hat Enterprise Linux 8 (RHEL 8) and Ubuntu 20.04 LTS
-
-```yaml
-#cloud-config
-system_info:
-  default_user:
-    groups:
-    - docker
-write_files:
- path: "/etc/sysctl.d/90-kubelet.conf"
-  owner: root:root
-  permissions: '0644'
-  content: |
-    vm.overcommit_memory=1
-    vm.panic_on_oom=0
-    kernel.panic=10
-    kernel.panic_on_oops=1
-    kernel.keys.root_maxbytes=25000000
-package_update: true
-ssh_pwauth: false
-runcmd:
-# Install Docker from Rancher's Docker installation scripts - github.com/rancher/install-docker
- curl https://releases.rancher.com/install-docker/20.10.sh | sh
- sysctl -p /etc/sysctl.d/90-kubelet.conf
- groupadd --gid 52034 etcd
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
-```
@@ -1,409 +0,0 @@
---
-title: RKE2 Hardening Guide with CIS v1.6 Benchmark
---
-
-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).
-
-:::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:
-
-| Rancher Version | CIS Benchmark Version | Kubernetes Version |
-| --------------- | --------------------- | ------------------ |
-| Rancher v2.6.5+ | Benchmark v1.6 | Kubernetes v1.21 up to v1.23 |
-
-[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.6/Rancher_RKE2_v2-6_CIS_v1-6_Hardening_Guide.pdf).
-
-
-### Overview
-
-This document provides prescriptive guidance for hardening a RKE2 cluster to be provisioned through Rancher v2.6.5+ with Kubernetes v1.21 up to v1.23. It outlines the configurations required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
-
-For more details about evaluating a hardened RKE2 cluster against the official CIS benchmark, refer to the [RKE2 - CIS 1.6 Benchmark - Self-Assessment Guide - Rancher v2.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md).
-
-RKE2 is designed to be "hardened by default" and pass the majority of the Kubernetes CIS controls without modification. There are a few notable exceptions to this that require manual intervention to fully pass the CIS Benchmark:
-
-1. RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
-2. Certain CIS policy controls for `PodSecurityPolicies` and `NetworkPolicies` will restrict the functionality of the cluster. You must opt into having RKE2 configuring these out of the box.
-
-To help ensure these above requirements are met, RKE2 can be started with the `profile` flag set to `cis-1.6`. This flag generally does two things:
-
-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.
-
-:::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`.
-
-### Host-level requirements
-
-There are two areas of host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
-
-#### Ensure `protect-kernel-defaults` is set
-
-This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
-
-When the `profile` flag is set, RKE2 will set the flag to `true`.
-
-:::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.
-
-Both `protect-kernel-defaults` and `profile` flags can be set in RKE2 template configuration file.
-
-```yaml
-spec:
-  rkeConfig:
-    machineSelectorConfig:
-      - config:
-          profile: cis-1.6
-          protect-kernel-defaults: true
-```
-
-#### Ensure etcd is configured properly
-
-The CIS Benchmark requires that the etcd data directory be owned by the `etcd` user and group. This implicitly requires the etcd process to be ran as the host-level `etcd` user. To achieve this, RKE2 takes several steps when started with a valid "cis-1.x" profile:
-
-1. Check that the `etcd` user and group exists on the host. If they don't, exit with an error.
-2. Create etcd's data directory with `etcd` as the user and group owner.
-3. Ensure the etcd process is ran as the `etcd` user and group by setting the etcd static pod's `SecurityContext` appropriately.
-
-### Setting up hosts
-
-This section gives you the commands necessary to configure your host to meet the above requirements.
-
-#### Set kernel parameters
-
-The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
-
-```ini
-vm.panic_on_oom=0
-vm.overcommit_memory=1
-kernel.panic=10
-kernel.panic_on_oops=1
-```
-
-Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
-
-Please perform this step only on fresh installations, before actually deploying RKE2 through Rancher.
-
-#### Create the etcd user
-
-On some Linux distributions, the `useradd` command will not create a group. The `-U` flag is included below to account for that. This flag tells `useradd` to create a group with the same name as the user.
-
-```bash
-sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
-```
-
-### Kubernetes runtime requirements
-
-The runtime requirements to pass the CIS Benchmark are centered around pod security and network policies. These are outlined in this section.
-
-#### `PodSecurityPolicies`
-
-RKE2 always runs with the `PodSecurityPolicy` admission controller turned on. However, when it is **not** started with a valid "cis-1.x" profile, RKE2 will put an unrestricted policy in place that allows Kubernetes to run as though the `PodSecurityPolicy` admission controller was not enabled.
-
-When ran with a valid "cis-1.x" profile, RKE2 will put a much more restrictive set of policies in place. These policies meet the requirements outlined in section 5.2 of the CIS Benchmark.
-
-> The Kubernetes control plane components and critical additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
-
-#### `NetworkPolicies`
-
-When ran with a valid "cis-1.x" profile, RKE2 will put `NetworkPolicies` in place that passes the CIS Benchmark for Kubernetes' built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
-
-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.
-
-:::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**
-
-Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
-
-For each namespace including `default` and `kube-system` on a standard RKE2 install, the `default` service account must include this value:
-
-```yaml
-automountServiceAccountToken: false
-```
-
-For namespaces created by the cluster operator, the following script and configuration file can be used to configure the `default` service account.
-
-The configuration bellow must be saved to a file called `account_update.yaml`.
-
-```yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: default
-automountServiceAccountToken: false
-```
-
-Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
-
-```bash
-#!/bin/bash -e
-
-for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
-  echo -n "Patching namespace $namespace - "
-  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
-done
-```
-
-Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
-
-### API Server audit configuration
-
-CIS requirements 1.2.22 to 1.2.25 are related to configuring audit logs for the API Server. When RKE2 is started with the `profile` flag set to `cis-1.6`, it will automatically configure hardened `--audit-log-` parameters in the API Server to pass those CIS checks.
-
-RKE2's default audit policy is configured to not log requests in the API Server. This is done to allow cluster operators flexibility to customize an audit policy that suits their auditing requirements and needs, as these are specific to each users' environment and policies.
-
-A default audit policy is created by RKE2 when started with the `profile` flag set to `cis-1.6`. The policy is defined in `/etc/rancher/rke2/audit-policy.yaml`.
-
-```yaml
-apiVersion: audit.k8s.io/v1
-kind: Policy
-metadata:
-  creationTimestamp: null
-rules:
- level: None
-```
-
-To start logging requests to the API Server, at least `level` parameter must be modified, for example, to `Metadata`. Detailed information about policy configuration for the API server can be found in the Kubernetes [documentation](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/).
-
-After adapting the audit policy, RKE2 must be restarted to load the new configuration.
-
-```shell
-sudo systemctl restart rke2-server.service
-```
-
-API Server audit logs will be written to `/var/lib/rancher/rke2/server/logs/audit.log`.
-
-### Known issues
-
-The following are controls that RKE2 currently does not pass. Each gap will be explained and whether it can be passed through manual operator intervention or if it will be addressed in a future release.
-
-#### Control  1.1.12
-Ensure that the etcd data directory ownership is set to `etcd:etcd`.
-
-**Rationale**
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should be owned by `etcd:etcd`.
-
-**Remediation**
-This can be remediated by creating an `etcd` user and group as described above.
-
-#### Control 5.1.5
-Ensure that default service accounts are not actively used
-
-**Rationale** Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod.
-
-Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
-
-The `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
-
-This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
-
-**Remediation**
-You can manually update this field on service accounts in your cluster to pass the control as described above.
-
-#### Control 5.3.2
-Ensure that all Namespaces have Network Policies defined
-
-**Rationale**
-Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
-
-Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.
-
-**Remediation**
-This can be remediated by setting `profile: "cis-1.6"` in RKE2 template configuration file. An example can be found below.
-
-### Reference Hardened RKE2 Template Configuration
-
-The reference template configuration is used in Rancher to create a hardened RKE2 custom cluster. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
-
-```yaml
-apiVersion: provisioning.cattle.io/v1
-kind: Cluster
-metadata:
-  name: <replace_with_cluster_name>
-  annotations:
-    {}
-#    key: string
-  labels:
-    {}
-#    key: string
-  namespace: fleet-default
-spec:
-  defaultPodSecurityPolicyTemplateName: ''
-  kubernetesVersion: <replace_with_kubernetes_version>
-  localClusterAuthEndpoint:
-    caCerts: ''
-    enabled: false
-    fqdn: ''
-  rkeConfig:
-    chartValues:
-      rke2-canal:
-        {}
-    etcd:
-      disableSnapshots: false
-      s3:
-#        bucket: string
-#        cloudCredentialName: string
-#        endpoint: string
-#        endpointCA: string
-#        folder: string
-#        region: string
-#        skipSSLVerify: boolean
-      snapshotRetention: 5
-      snapshotScheduleCron: 0 */5 * * *
-    machineGlobalConfig:
-      cni: canal
-    machinePools:
-#      - cloudCredentialSecretName: string
-#        controlPlaneRole: boolean
-#        displayName: string
-#        drainBeforeDelete: boolean
-#        etcdRole: boolean
-#        labels:
-#          key: string
-#        machineConfigRef:
-#          apiVersion: string
-#          fieldPath: string
-#          kind: string
-#          name: string
-#          namespace: string
-#          resourceVersion: string
-#          uid: string
-#        machineDeploymentAnnotations:
-#          key: string
-#        machineDeploymentLabels:
-#          key: string
-#        machineOS: string
-#        maxUnhealthy: string
-#        name: string
-#        nodeStartupTimeout: string
-#        paused: boolean
-#        quantity: int
-#        rollingUpdate:
-#          maxSurge: string
-#          maxUnavailable: string
-#        taints:
-#          - effect: string
-#            key: string
-#            timeAdded: string
-#            value: string
-#        unhealthyNodeTimeout: string
-#        unhealthyRange: string
-#        workerRole: boolean
-    machineSelectorConfig:
-      - config:
-          profile: cis-1.6
-          protect-kernel-defaults: true
-#      - config:
-#
-#        machineLabelSelector:
-#          matchExpressions:
-#            - key: string
-#              operator: string
-#              values:
-#                - string
-#          matchLabels:
-#            key: string
-    registries:
-      configs:
-        {}
-        #authConfigSecretName: string
-#          caBundle: string
-#          insecureSkipVerify: boolean
-#          tlsSecretName: string
-      mirrors:
-        {}
-        #endpoint:
-#            - string
-#          rewrite:
-#            key: string
-    upgradeStrategy:
-      controlPlaneConcurrency: 10%
-      controlPlaneDrainOptions:
-#        deleteEmptyDirData: boolean
-#        disableEviction: boolean
-#        enabled: boolean
-#        force: boolean
-#        gracePeriod: int
-#        ignoreDaemonSets: boolean
-#        ignoreErrors: boolean
-#        postDrainHooks:
-#          - annotation: string
-#        preDrainHooks:
-#          - annotation: string
-#        skipWaitForDeleteTimeoutSeconds: int
-#        timeout: int
-      workerConcurrency: 10%
-      workerDrainOptions:
-#        deleteEmptyDirData: boolean
-#        disableEviction: boolean
-#        enabled: boolean
-#        force: boolean
-#        gracePeriod: int
-#        ignoreDaemonSets: boolean
-#        ignoreErrors: boolean
-#        postDrainHooks:
-#          - annotation: string
-#        preDrainHooks:
-#          - annotation: string
-#        skipWaitForDeleteTimeoutSeconds: int
-#        timeout: int
-#    additionalManifest: string
-#    etcdSnapshotCreate:
-#      generation: int
-#    etcdSnapshotRestore:
-#      generation: int
-#      name: string
-#      restoreRKEConfig: string
-#    infrastructureRef:
-#      apiVersion: string
-#      fieldPath: string
-#      kind: string
-#      name: string
-#      namespace: string
-#      resourceVersion: string
-#      uid: string
-#    provisionGeneration: int
-#    rotateCertificates:
-#      generation: int
-#      services:
-#        - string
-#    rotateEncryptionKeys:
-#      generation: int
-  machineSelectorConfig:
-    - config: {}
-#  agentEnvVars:
-#    - name: string
-#      value: string
-#  cloudCredentialSecretName: string
-#  clusterAPIConfig:
-#    clusterName: string
-#  defaultClusterRoleForProjectMembers: string
-#  enableNetworkPolicy: boolean
-#  redeploySystemAgentGeneration: int
-__clone: true
-```
-
-### Conclusion
-
-If you have followed this guide, your RKE2 custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE2 CIS Benchmark Self-Assessment Guide [v1.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) to understand how we verified each of the benchmarks and how you can do the same on your cluster.
@@ -1,549 +0,0 @@
---
-title: K3s Hardening Guide with CIS Benchmark
---
-
-This document provides prescriptive guidance for hardening a production installation of a K3s cluster to be provisioned with Rancher v2.7. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
-
-:::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 K3s clusters and associated with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
-
-| Rancher Version | CIS Benchmark Version | Kubernetes Version |
-| --------------- | --------------------- | ------------------ |
-| Rancher v2.7    | Benchmark v1.20       | Kubernetes v1.21   |
-| Rancher v2.7    | Benchmark v1.23       | Kubernetes v1.22 up to v1.24 |
-
-### Overview
-
-For more details about evaluating a hardened K3s cluster against the official CIS benchmark, refer to K3s - CIS Benchmark - Self-Assessment Guide - Rancher v2.7 for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md).
-
-K3s has a number of security mitigations applied and turned on by default and will pass a number of the Kubernetes CIS controls without modification. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
-
-1. K3s will not modify the host operating system. Any host-level modifications will need to be done manually.
-2. Certain CIS policy controls for `PodSecurityPolicies` and `NetworkPolicies` will restrict the functionality of the cluster. You must opt into having K3s configure these by adding the appropriate options (enabling of admission plugins) to your command-line flags or configuration file as well as manually applying appropriate policies. Further details are presented in the sections below.
-
-The first section (1.1) of the CIS Benchmark concerns itself primarily with pod manifest permissions and ownership. K3s doesn't utilize these for the core components since everything is packaged into a single binary.
-
-## Host-level Requirements
-
-### Ensure `protect-kernel-defaults` is set (control 4.2.6)
-
-This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
-
-This can be remediated by adding the following argument line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineSelectorConfig:
-    - config:
-        protect-kernel-defaults: true          # Control 4.2.6
-```
-
-#### Set kernel parameters
-
-Create a file called `/etc/sysctl.d/90-kubelet.conf` and add the snippet below. Then run `sysctl -p /etc/sysctl.d/90-kubelet.conf`.
-
-```bash
-vm.panic_on_oom=0
-vm.overcommit_memory=1
-kernel.panic=10
-kernel.panic_on_oops=1
-```
-
-This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
-
-## Kubernetes Runtime Requirements
-
-The runtime requirements to comply with the CIS Benchmark are centered around pod security policies (PSPs) and its admission control plugin, network policies and API Server auditing logs. These are outlined in this section. K3s doesn't apply any default PSPs or network policies. However, K3s ships with a controller that is meant to apply a given set of network policies. By default, K3s runs with the `NodeRestriction` admission controller. To enable PSPs, add the following line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-      - enable-admission-plugins=NodeRestriction,PodSecurityPolicy    # CIS 1.2.16 and CIS 5.2
-```
-
-This will have the effect of maintaining the `NodeRestriction` plugin as well as enabling the `PodSecurityPolicy`.
-
-### Pod Security Policies (control 5.2)
-
-When PSPs are enabled, a policy can be applied to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
-
-Here is an example of a compliant PSP.
-
-```yaml
-apiVersion: policy/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: restricted-psp
-spec:
-  privileged: false                # CIS - 5.2.1
-  allowPrivilegeEscalation: false  # CIS - 5.2.5
-  requiredDropCapabilities:        # CIS - 5.2.7/8/9
-    - ALL
-  volumes:
-    - 'configMap'
-    - 'emptyDir'
-    - 'projected'
-    - 'secret'
-    - 'downwardAPI'
-    - 'csi'
-    - 'persistentVolumeClaim'
-    - 'ephemeral'
-  hostNetwork: false               # CIS - 5.2.4
-  hostIPC: false                   # CIS - 5.2.3
-  hostPID: false                   # CIS - 5.2.2
-  runAsUser:
-    rule: 'MustRunAsNonRoot'       # CIS - 5.2.6
-  seLinux:
-    rule: 'RunAsAny'
-  supplementalGroups:
-    rule: 'MustRunAs'
-    ranges:
-      - min: 1
-        max: 65535
-  fsGroup:
-    rule: 'MustRunAs'
-    ranges:
-      - min: 1
-        max: 65535
-  readOnlyRootFilesystem: false
-```
-
-For the above PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" which is needed for system-level pods that require additional privileges, as exemplified below.
-
-```yaml
-apiVersion: policy/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: restricted-psp
-spec:
-  privileged: false
-  allowPrivilegeEscalation: false
-  requiredDropCapabilities:
-    - ALL
-  volumes:
-    - 'configMap'
-    - 'emptyDir'
-    - 'projected'
-    - 'secret'
-    - 'downwardAPI'
-    - 'csi'
-    - 'persistentVolumeClaim'
-    - 'ephemeral'
-  hostNetwork: false
-  hostIPC: false
-  hostPID: false
-  runAsUser:
-    rule: 'MustRunAsNonRoot'
-  seLinux:
-    rule: 'RunAsAny'
-  supplementalGroups:
-    rule: 'MustRunAs'
-    ranges:
-      - min: 1
-        max: 65535
-  fsGroup:
-    rule: 'MustRunAs'
-    ranges:
-      - min: 1
-        max: 65535
-  readOnlyRootFilesystem: false
---
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: psp:restricted-psp
-  labels:
-    addonmanager.kubernetes.io/mode: EnsureExists
-rules:
- apiGroups: ['extensions']
-  resources: ['podsecuritypolicies']
-  verbs:     ['use']
-  resourceNames:
-  - restricted-psp
---
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: default:restricted-psp
-  labels:
-    addonmanager.kubernetes.io/mode: EnsureExists
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: psp:restricted-psp
-subjects:
- kind: Group
-  name: system:authenticated
-  apiGroup: rbac.authorization.k8s.io
---
-apiVersion: policy/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: system-unrestricted-psp
-spec:
-  allowPrivilegeEscalation: true
-  allowedCapabilities:
-  - '*'
-  fsGroup:
-    rule: RunAsAny
-  hostIPC: true
-  hostNetwork: true
-  hostPID: true
-  hostPorts:
-  - max: 65535
-    min: 0
-  privileged: true
-  runAsUser:
-    rule: RunAsAny
-  seLinux:
-    rule: RunAsAny
-  supplementalGroups:
-    rule: RunAsAny
-  volumes:
-  - '*'
---
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: system-unrestricted-node-psp-rolebinding
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: system-unrestricted-psp-role
-subjects:
- apiGroup: rbac.authorization.k8s.io
-  kind: Group
-  name: system:nodes
---
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: system-unrestricted-psp-role
-rules:
- apiGroups:
-  - policy
-  resourceNames:
-  - system-unrestricted-psp
-  resources:
-  - podsecuritypolicies
-  verbs:
-  - use
-```
-
-The policy file `policy.yaml` can be placed in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
-
-```bash
-sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
-```
-
-### Network Policies (control 5.3.2)
-
-CIS requires that all namespaces have a network policy applied that reasonably limits traffic into namespaces and pods.
-
-:::note
-
-This is a manual check in the CIS Benchmark. The CIS scan will flag the result as `warning`, because manual inspection is necessary by the cluster operator.
-
-:::
-
-Here is an example of a compliant network policy.
-
-```yaml
-kind: NetworkPolicy
-apiVersion: networking.k8s.io/v1
-metadata:
-  name: intra-namespace
-  namespace: kube-system
-spec:
-  podSelector: {}
-  ingress:
-    - from:
-      - namespaceSelector:
-          matchLabels:
-            name: kube-system
-```
-
-:::note
-
-Kubernetes' additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
-
-:::
-
-With the applied restrictions, DNS will be blocked unless purposely allowed. Below is a network policy that will allow DNS related traffic.
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-network-dns-policy
-  namespace: <NAMESPACE>
-spec:
-  ingress:
-  - ports:
-    - port: 53
-      protocol: TCP
-    - port: 53
-      protocol: UDP
-  podSelector:
-    matchLabels:
-      k8s-app: kube-dns
-  policyTypes:
-  - Ingress
-```
-
-The metrics-server and Traefik ingress controller will be blocked by default if network policies are not created to allow access.
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all-metrics-server
-  namespace: kube-system
-spec:
-  podSelector:
-    matchLabels:
-      k8s-app: metrics-server
-  ingress:
-  - {}
-  policyTypes:
-  - Ingress
---
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all-svclbtraefik-ingress
-  namespace: kube-system
-spec:
-  podSelector: 
-    matchLabels:
-      svccontroller.k3s.cattle.io/svcname: traefik
-  ingress:
-  - {}
-  policyTypes:
-  - Ingress
-```
-
-:::note
-
-Operators must manage network policies as normal for additional namespaces that are created.
-
-:::
-
-The network policies can be added in the same policy file used for PSPs in `/var/lib/rancher/k3s/server/manifests/policy.yaml` or on its own file.
-
-### API Server audit configuration
-
-CIS requirements v1.20 - 1.2.22 to 1.2.25 and v1.23 - 1.2.19 to 1.2.22 are related to configuring audit logs for the API Server. K3s doesn't create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
-
-The log directory, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
-
-```bash
-sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
-```
-
-A starter audit policy to log request metadata is provided below. The policy should be written to a file named `audit.yaml` in `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the Kubernetes [documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
-
-```yaml
-apiVersion: audit.k8s.io/v1
-kind: Policy
-rules:
- level: Metadata
-```
-
-Further configurations, as described below, are also needed to pass CIS checks and are not configured by default in K3s, because they vary depending on the users' environment and needs:
-
- Ensure that the `--audit-log-path` argument is set.
- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
- Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
- Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
-
-To enable and configure audit logs, add the following line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-      - audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml    # CIS v1.20/v1.23 3.2.1
-      - audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log   # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
-      - audit-log-maxage=30                                         # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
-      - audit-log-maxbackup=10                                      # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
-      - audit-log-maxsize=100                                       # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
-```
-
-## Known Issues
-
-The following are controls that K3s currently does not pass by default. Each gap will be explained, along with a note clarifying whether it can be passed through manual operator intervention, or if it will be addressed in a future release of K3s.
-
-### Control CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
-Ensure that the admission control plugin `ServiceAccount` is set
-<details>
-<summary>Rationale</summary>
-Follow the documentation and create `ServiceAccount` objects as per your environment. Then, edit the API server pod specification file $apiserverconf
-on the control plane node and ensure that the `--disable-admission-plugins` parameter is set to a value that does not include `ServiceAccount`.
-
-This can be remediated by adding the following argument line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-      kube-apiserver-arg:
-        - enable-admission-plugins=ServiceAccount    # CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
-```
-</details>
-
-### Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
-Ensure that the `--request-timeout` argument is set as appropriate.
-<details>
-<summary>Rationale</summary>
-Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed.
-
-This can be remediated by adding the following argument line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-      - request-timeout=300s          # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
-```
-</details>
-
-### Control CIS v1.23 1.2.24
-Ensure that the `--service-account-lookup` argument is set to true.
-<details>
-<summary>Rationale</summary>
-If `--service-account-lookup` is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue.
-
-This can be remediated by adding the following argument line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-      - service-account-lookup=true   # Control CIS v1.23 1.2.24
-```
-</details>
-
-### CIS v1.20 1.2.32 and CIS v1.23 1.2.30
-Ensure that the `--encryption-provider-config` argument is set as appropriate.
-<details>
-<summary>Rationale</summary>
-`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
-
-Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
-</details>
-
-### Control CIS v1.20 1.2.33 and CIS v1.23 1.2.31
-Ensure that encryption providers are appropriately configured.
-<details>
-<summary>Rationale</summary>
-Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options.
-
-This can be remediated by passing a valid configuration to `k3s` as outlined above. Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
-</details>
-
-### Control 4.2.7
-Ensure that the `--make-iptables-util-chains` argument is set to true.
-<details>
-<summary>Rationale</summary>
-Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open.
-
-This can be remediated by adding the following argument line to K3s cluster configuration file:
-
-```yaml
-spec:
-  rkeConfig:
-    machineSelectorConfig:
-    - config:
-        kubelet-arg:
-        - make-iptables-util-chains=true          # Control 4.2.7
-```
-</details>
-
-### Control 5.1.5
-Ensure that default service accounts are not actively used
-<details>
-<summary>Rationale</summary>
-Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod.
-
-Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
-
-The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
-
-This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
-
-For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), K3s does not automatically do this. You can manually update this field on these service accounts to pass the control or use the script below to automate this task.
-
-Save the follow configuration to a file called `account_update.yaml`.
-
-```yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: default
-automountServiceAccountToken: false
-```
-
-Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
-
-```bash
-#!/bin/bash -e
-
-for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
-  echo -n "Patching namespace $namespace - "
-  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
-done
-```
-
-Execute the script to update the default service account in each namespace.
-</details>
-
-
-### Reference Hardened K3s Template Configuration
-
-The reference template configuration below is used in Rancher to create a hardened K3s custom cluster based on each CIS control presented in this guide. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
-
-```yaml
-apiVersion: provisioning.cattle.io/v1
-kind: Cluster
-metadata:
-  name: # Define cluster name
-  annotations:
-spec:
-  defaultPodSecurityPolicyTemplateName: '' # Define the PSP policy to use
-  enableNetworkPolicy: true
-  kubernetesVersion: # Define K3s version
-  rkeConfig:
-    machineGlobalConfig:
-      kube-apiserver-arg:
-        - enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount    # CIS 1.2.16, CIS 5.2 and CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
-        - audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml    # CIS v1.20/v1.23 3.2.1
-        - audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log   # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
-        - audit-log-maxage=30                                         # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
-        - audit-log-maxbackup=10                                      # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
-        - audit-log-maxsize=100                                       # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
-        - request-timeout=300s                                        # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
-        - service-account-lookup=true                                 # Control CIS v1.23 1.2.24
-      secrets-encryption: true
-    machineSelectorConfig:
-      - config:
-          kubelet-arg:
-            - make-iptables-util-chains=true                          # Control 4.2.7
-          protect-kernel-defaults: true                               # Control 4.2.6
-```
-
-### Conclusion
-
-If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s CIS Benchmark Self-Assessment Guide for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md) to understand how we verified each of the benchmarks and how you can do the same on your cluster.
@@ -2,16 +2,61 @@
 title: User Preferences
 ---

-Each user can choose preferences to personalize their Rancher experience. To change preference settings, open the **User Settings** menu and then select **Preferences**.
+You can set preferences to personalize your Rancher experience. To change preference settings:
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Preferences**.
+
+## Language
+
+Choose your language for the Rancher UI. Options include:
+
+- English
+- 简体中文 (Simplified Chinese)

 ## Theme

 Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.

-## My Account
+## Login Landing Page

-This section displays the **Name** (your display name) and **Username** (your login) used for your session. To change your login's current password, click the **Change Password** button.
+Choose the page displayed after logging in. Options include:

-## Table Row per Page
+- The home page.
+- The area you last visited.
+- A specific cluster of your choosing.

-On pages that display system objects like clusters or deployments in a table, you can set the number of objects that display on the page before you must paginate. The default setting is `50`.
+## Display Settings
+
+Choose how certain information is displayed:
+
+- Date format
+- Time format
+- Table rows per page
+- Number of clusters to show in side menu
+
+## Confirmation Setting
+
+_Available as of v2.7.2_
+
+Choose whether to ask for confirmation when scaling down node pools.
+
+## Advanced Features
+
+- Enable "View in API".
+- Show system Namespaces managed by Rancher (not intended for editing or deletion).
+- Enable Dark/Light Theme keyboard shortcut toggle (shift+T).
+- Hide All Type Descriptions.
+- Enable Extension developer features.
+
+![](/img/user-preferences-2-7.png)
+
+## YAML Editor Key Mapping
+
+- Normal human (Sublime)
+- Emacs
+- Vim
+
+## Helm Charts
+
+Choose whether to display released Helm charts only or to include prerelease versions as well. A version is considered to be a prerelease if it adheres to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` requires `Include Prerelease Versions` to be selected in order to be displayed.
@@ -109,7 +109,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
 :::

 ```plain
-helm fetch jetstack/cert-manager --version v1.7.1
+helm fetch jetstack/cert-manager --version v1.11.0
 ```


@@ -117,7 +117,7 @@ helm fetch jetstack/cert-manager --version v1.7.1

 为 cert-manager 下载所需的 CRD 文件：
 ```plain
-curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 ### 4. 安装 Rancher
@@ -148,7 +148,7 @@ curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/ce
 3. 安装 cert-manager。

   ```plain
-   helm install cert-manager ./cert-manager-v1.7.1.tgz \
+   helm install cert-manager ./cert-manager-v1.11.0.tgz \
       --namespace cert-manager \
       --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
       --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
@@ -56,7 +56,6 @@ title: '2. 收集镜像并发布到私有仓库'

 在 Kubernetes 安装中，如果你使用的是 Rancher 默认的自签名 TLS 证书，则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。

-
 :::note

 v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
@@ -74,7 +73,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
   ```plain
   helm repo add jetstack https://charts.jetstack.io
   helm repo update
-   helm fetch jetstack/cert-manager --version v1.7.1
+   helm fetch jetstack/cert-manager --version v1.11.0
   helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
   ```

@@ -253,7 +252,7 @@ Linux 镜像需要在 Linux 主机上收集和推送，但是你必须先将 Win
   ```plain
   helm repo add jetstack https://charts.jetstack.io
   helm repo update
-   helm fetch jetstack/cert-manager --version v0.12.0
+   helm fetch jetstack/cert-manager --version v1.11.0
   helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
   ```

@@ -37,14 +37,14 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
 :::

 ```
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：

 ```
 helm upgrade --install cert-manager jetstack/cert-manager \
-  --namespace cert-manager --version v1.7.1 \
+  --namespace cert-manager --version v1.11.0 \
  --set http_proxy=http://${proxy_host} \
  --set https_proxy=http://${proxy_host} \
  --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
@@ -93,7 +93,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
   helm install \
     cert-manager jetstack/cert-manager \
     --namespace cert-manager \
-     --version v0.12.0
+     --version v1.11.0
   ```

 1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)：
@@ -125,7 +125,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
 1. 从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart：

   ```plain
-   helm fetch jetstack/cert-manager --version v0.12.0
+   helm fetch jetstack/cert-manager --version v1.11.0
   ```

 1. 使用安装 Chart 的选项来渲染 cert-manager 模板。记住要设置 `image.repository` 选项，以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
@@ -153,7 +153,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
 1. 下载新旧版 cert-manager 所需的 CRD 文件：

   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+   curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
   curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
   ```

@@ -97,7 +97,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

 kubectl create namespace cattle-system

-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 helm repo add jetstack https://charts.jetstack.io

@@ -106,13 +106,13 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0

 # Windows Powershell
 helm install cert-manager jetstack/cert-manager `
  --namespace cert-manager `
  --create-namespace `
-  --version v1.7.1
+  --version v1.11.0
 ```

 安装 Rancher 的最终命令如下。该命令需要一个将流量转发到 Linux 主机的域名。为了简化本教程，你可以使用假域名。`<IP_OF_LINUX_NODE>.sslip.io` 是一个假域名的例子。
@@ -145,7 +145,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为

 ```
 # 如果你手动安装了CRD，而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项，你应该在升级 Helm Chart 之前升级 CRD 资源。
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 # 添加 Jetstack Helm 仓库
 helm repo add jetstack https://charts.jetstack.io
@@ -157,7 +157,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0
 ```

 安装完 cert-manager 后，你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署：
@@ -109,7 +109,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
 :::

 ```plain
-helm fetch jetstack/cert-manager --version v1.7.1
+helm fetch jetstack/cert-manager --version v1.11.0
 ```


@@ -117,7 +117,7 @@ helm fetch jetstack/cert-manager --version v1.7.1

 为 cert-manager 下载所需的 CRD 文件：
 ```plain
-curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 ### 4. 安装 Rancher
@@ -148,7 +148,7 @@ curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/ce
 3. 安装 cert-manager。

   ```plain
-   helm install cert-manager ./cert-manager-v1.7.1.tgz \
+   helm install cert-manager ./cert-manager-v1.11.0.tgz \
       --namespace cert-manager \
       --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
       --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
@@ -56,7 +56,6 @@ title: '2. 收集镜像并发布到私有仓库'

 在 Kubernetes 安装中，如果你使用的是 Rancher 默认的自签名 TLS 证书，则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。

-
 :::note

 v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
@@ -74,7 +73,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
   ```plain
   helm repo add jetstack https://charts.jetstack.io
   helm repo update
-   helm fetch jetstack/cert-manager --version v1.7.1
+   helm fetch jetstack/cert-manager --version v1.11.0
   helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
   ```

@@ -33,14 +33,14 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
 :::

 ```
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：

 ```
 helm upgrade --install cert-manager jetstack/cert-manager \
-  --namespace cert-manager --version v1.7.1 \
+  --namespace cert-manager --version v1.11.0 \
  --set http_proxy=http://${proxy_host} \
  --set https_proxy=http://${proxy_host} \
  --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
@@ -153,7 +153,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
 1. 下载新旧版 cert-manager 所需的 CRD 文件：

   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+   curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
   curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
   ```

@@ -95,7 +95,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

 kubectl create namespace cattle-system

-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 helm repo add jetstack https://charts.jetstack.io

@@ -104,13 +104,13 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0

 # Windows Powershell
 helm install cert-manager jetstack/cert-manager `
  --namespace cert-manager `
  --create-namespace `
-  --version v1.7.1
+  --version v1.11.0
 ```

 安装 Rancher 的最终命令如下。该命令需要一个将流量转发到 Linux 主机的域名。为了简化本教程，你可以使用假域名。`<IP_OF_LINUX_NODE>.sslip.io` 是一个假域名的例子。
@@ -144,7 +144,7 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为

 ```
 # 如果你手动安装了CRD，而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项，你应该在升级 Helm Chart 之前升级 CRD 资源。
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 # 添加 Jetstack Helm 仓库
 helm repo add jetstack https://charts.jetstack.io
@@ -156,7 +156,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0
 ```

 安装完 cert-manager 后，你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署：
@@ -115,6 +115,7 @@ const sidebars = {
                "getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks",
                "getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks",
                "getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke",
+                "getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrade-a-hardened-cluster-to-k8s-v1-25",
                "getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/troubleshooting",
              ]
            },
@@ -314,7 +315,8 @@ const sidebars = {
                  ]
                },
                "how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies",
-
+                "how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards",
+                "how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates",
                "how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry",

                "how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/custom-branding",
@@ -1047,29 +1049,51 @@ const sidebars = {
          items: [
            {
              type: 'category',
-              label: 'Rancher v2.6 Hardening Guides',
+              label: 'Hardening Guides',
              link: {
                type: 'doc',
-                id: "pages-for-subheaders/rancher-v2.6-hardening-guides",
+                id: "pages-for-subheaders/rancher-hardening-guides",
              },
              items: [
-                "reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark",
-                "reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark",
-                "reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark",
-                "reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark",
-              ],
-            },
-            {
-              type: 'category',
-              label: 'Rancher v2.7 Hardening Guides',
-              link: {
-                type: 'doc',
-                id: "pages-for-subheaders/rancher-v2.7-hardening-guides",
-              },
-              items: [
-                "reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-hardening-guide-with-cis-benchmark",
-                "reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark",
-                "reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-benchmark",
+                {
+                  type: 'category',
+                  label: 'RKE Hardening Guides',
+                  link: {
+                    type: 'doc',
+                    id: "pages-for-subheaders/rke1-hardening-guide",
+                  },
+                  items: [
+                    "reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23",
+                    "reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24",
+                    "reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25",
+                  ],
+                },
+                {
+                  type: 'category',
+                  label: 'RKE2 Hardening Guides',
+                  link: {
+                    type: 'doc',
+                    id: "pages-for-subheaders/rke2-hardening-guide",
+                  },
+                  items: [
+                    "reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23",
+                    "reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24",
+                    "reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25",
+                  ],
+                },
+                {
+                  type: 'category',
+                  label: 'K3s Hardening Guides',
+                  link: {
+                    type: 'doc',
+                    id: "pages-for-subheaders/k3s-hardening-guide",
+                  },
+                  items: [
+                    "reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23",
+                    "reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24",
+                    "reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25",
+                  ],
+                },
              ],
            },
            {
@@ -1085,8 +1109,8 @@ const sidebars = {
              ],
            },
            "reference-guides/rancher-security/kubernetes-security-best-practices",
-
            "reference-guides/rancher-security/security-advisories-and-cves",
+            "reference-guides/rancher-security/psa-restricted-exemptions",
          ],
        }
      ]
@@ -1136,7 +1160,7 @@ const sidebars = {
        },
        {
          type: 'category',
-          label: 'Fleet - GitOps at Scale',
+          label: 'Continuous Delivery with Fleet',
          link: {
            type: 'doc',
            id: "pages-for-subheaders/fleet-gitops-at-scale",
@@ -10,10 +10,10 @@ Below are the documentation and release notes for the currently released version

 <table>
  <tr>
-    <td><b>v2.7.1</b></td>
+    <td><b>v2.7.2</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/">Documentation</a></td>
-    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.1">Release Notes</a></td>
-    <td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-1/">Support Matrix</a></td>
+    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.2">Release Notes</a></td>
+    <td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-2/">Support Matrix</a></td>
  </tr>
 </table>

@@ -33,6 +33,12 @@ Below are the documentation and release notes for the currently released version
 Below are the documentation and release notes for previous versions of Rancher 2.7.x:

 <table>
+  <tr>
+    <td><b>v2.7.1</b></td>
+    <td><a href="https://ranchermanager.docs.rancher.com/">Documentation</a></td>
+    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.1">Release Notes</a></td>
+    <td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-1/">Support Matrix</a></td>
+  </tr>
  <tr>
    <td><b>v2.7.0</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/">Documentation</a></td>
@@ -104,7 +104,7 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat

 1. Download the required CRD file for cert-manager
   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.14/deploy/manifests/00-crds.yaml
+   curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.14/deploy/manifests/00-crds.yaml
   ```
 1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.

@@ -106,7 +106,7 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat

 1. Download the required CRD file for cert-manager
   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
+   curl -L -o cert-manager-crd.yaml https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
   ```

 1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
@@ -108,7 +108,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    ```

 ### Install cert-manager
@@ -151,7 +151,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager (old and new)

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
    ```

@@ -123,7 +123,7 @@ helm template cert-manager ./cert-manager-v1.5.1.tgz --output-dir . \

 Download the required CRD file for cert-manager:
   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/jetstack/cert-manager/releases/download/v1.5.1/cert-manager.crds.yaml
+   curl -L -o cert-manager-crd.yaml https://github.com/jetstack/cert-manager/releases/download/v1.5.1/cert-manager.crds.yaml
   ```

 ### 5. Render the Rancher template
@@ -109,7 +109,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    ```

 ### Install cert-manager
@@ -152,7 +152,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager (old and new)

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
    ```

@@ -73,7 +73,7 @@ For our new docs, we are working to build up this section as most of our previou

 Over time, Rancher has accrued several products and projects that have been integrated into the Rancher UI. To assist users in learning more about these integrations, this subsection has been added under **Explanations**. 

-Examples of some of these integrations are [Fleet - GitOps at Scale](../../pages-for-subheaders/fleet-gitops-at-scale.md) and [Monitoring and Alerting](../../pages-for-subheaders/monitoring-and-alerting.md).
+Examples of some of these integrations are [Continuous Delivery with Fleet](../../pages-for-subheaders/fleet-gitops-at-scale.md) and [Monitoring and Alerting](../../pages-for-subheaders/monitoring-and-alerting.md).

 ## Other Docs Categories

@@ -109,4 +109,4 @@ Because the previous docs structure was not based on the Divio paradigm, not eve

 As such, we have worked to move our existing documentation into the new paradigm based on each doc's function. Moving forward, we will be creating, rewriting, and reshaping our docs as needed to more closely align with the Divio structure, purpose, and its design concepts. 

-Ultimately, the finished product will much more cohesively and effectively assist our users by emphasizing functionality over individual topic or feature-based docs.
+Ultimately, the finished product will much more cohesively and effectively assist our users by emphasizing functionality over individual topic or feature-based docs.
@@ -1,10 +1,10 @@
 ---
-title: Fleet - GitOps at Scale
+title: Continuous Delivery with Fleet
 ---

 _Available as of Rancher v2.5_

-Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/multi-cluster-install/). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/multi-cluster-install/). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

@@ -4,4 +4,4 @@ title: Integrations in Rancher

 Over time, Rancher has accrued several products and projects that have been integrated into the Rancher UI.

-Examples of some of these integrations are [Fleet - GitOps at Scale](../pages-for-subheaders/fleet-gitops-at-scale.md) and [Monitoring and Alerting](../pages-for-subheaders/monitoring-and-alerting.md).
+Examples of some of these integrations are [Continuous Delivery with Fleet](../pages-for-subheaders/fleet-gitops-at-scale.md) and [Monitoring and Alerting](../pages-for-subheaders/monitoring-and-alerting.md).
@@ -74,21 +74,14 @@ When setting up the Rancher Helm template, there are several options in the Helm
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |

-### 3. Fetch the Cert-Manager chart 
+### 3. Fetch the Cert-Manager chart

 Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.

 #### Option A: Default Self-Signed Certificate

-
 By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.

-:::note
-
-Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade cert-manager documentation](../../resources/upgrade-cert-manager.md).
-
-:::
-
 ##### 1. Add the cert-manager repo

 From a system connected to the internet, add the cert-manager repo to Helm:
@@ -102,14 +95,8 @@ helm repo update

 Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).

-:::note
-
-New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
-
-:::
-
 ```plain
-helm fetch jetstack/cert-manager --version v1.7.1
+helm fetch jetstack/cert-manager --version v1.11.0
 ```


@@ -117,7 +104,7 @@ helm fetch jetstack/cert-manager --version v1.7.1

 Download the required CRD file for cert-manager:
   ```plain
-   curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+   curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
   ```

 ### 4. Install Rancher
@@ -128,6 +115,12 @@ Copy the fetched charts to a system that has access to the Rancher server cluste

 Install cert-manager with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 <details id="install-cert-manager">
  <summary>Click to expand</summary>

@@ -139,7 +132,7 @@ If you are using self-signed certificates, install cert-manager:
    kubectl create namespace cert-manager
    ```

-2. Create the cert-manager CustomResourceDefinitions (CRDs). 
+2. Create the cert-manager CustomResourceDefinitions (CRDs).

    ```plain
    kubectl apply -f cert-manager/cert-manager-crd.yaml
@@ -148,7 +141,7 @@ If you are using self-signed certificates, install cert-manager:
 3. Install cert-manager.

    ```plain
-    helm install cert-manager ./cert-manager-v1.7.1.tgz \
+    helm install cert-manager ./cert-manager-v1.11.0.tgz \
        --namespace cert-manager \
        --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
        --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
@@ -56,7 +56,6 @@ Skip this step if you are using your own certificates, or if you are terminating

 In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well.

-
 :::note

 New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
@@ -65,16 +64,10 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen

 1.  Fetch the latest `cert-manager` Helm chart and parse the template for image details:

-    :::note
-
-    Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../resources/upgrade-cert-manager.md).
-
-    :::
-
    ```plain
    helm repo add jetstack https://charts.jetstack.io
    helm repo update
-    helm fetch jetstack/cert-manager --version v1.7.1
+    helm fetch jetstack/cert-manager --version v1.11.0
    helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
    ```

@@ -33,14 +33,20 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
 :::

 ```
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
 ```

 And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 helm upgrade --install cert-manager jetstack/cert-manager \
-  --namespace cert-manager --version v1.7.1 \
+  --namespace cert-manager --version v1.11.0 \
  --set http_proxy=http://${proxy_host} \
  --set https_proxy=http://${proxy_host} \
  --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
@@ -153,7 +153,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
 1. Download the required CRD file for cert-manager (old and new)

    ```plain
-    curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
+    curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
    curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
    ```

@@ -90,12 +90,18 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work.

 Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed.

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

 kubectl create namespace cattle-system

-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 helm repo add jetstack https://charts.jetstack.io

@@ -104,13 +110,13 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0

 # Windows Powershell
 helm install cert-manager jetstack/cert-manager `
  --namespace cert-manager `
  --create-namespace `
-  --version v1.7.1
+  --version v1.11.0
 ```

 The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
@@ -1,8 +1,8 @@
 ---
-title: Fleet - GitOps at Scale
+title: Continuous Delivery with Fleet
 ---

-Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/multi-cluster-install/) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/multi-cluster-install/) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

@@ -5,7 +5,7 @@ title: Deploying Applications across Clusters

 Rancher v2.5 introduced Fleet, a new way to deploy applications across clusters.

-Fleet is GitOps at scale. For more information, refer to the [Fleet section.](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)
+Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section.](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)

 ### Multi-cluster Apps

@@ -1,8 +1,8 @@
 ---
-title: Fleet - GitOps at Scale
+title: Continuous Delivery with Fleet
 ---

-Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/multi-cluster-install/). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/single-cluster-install/) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/multi-cluster-install/). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.

 Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.

@@ -142,9 +142,15 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher

 These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm).

+:::note
+
+To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
+
+:::
+
 ```
 # If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
-kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

 # Add the Jetstack Helm repository
 helm repo add jetstack https://charts.jetstack.io
@@ -156,7 +162,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --version v1.7.1
+  --version v1.11.0
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -1098,7 +1098,7 @@
        },
        {
          "type": "category",
-          "label": "Fleet - GitOps at Scale",
+          "label": "Continuous Delivery with Fleet",
          "link": {
            "type": "doc",
            "id": "pages-for-subheaders/fleet-gitops-at-scale"