Merge branch 'release/v2.7' into 2.7-refresh-azuread-documentation

2026-09-25 04:28:15 +00:00 · 2022-11-22 16:45:32 -05:00
parent 1db1268baa bd23cfe40f
commit b651d2ef27
1130 changed files with 142779 additions and 1951 deletions
@@ -0,0 +1,16 @@
+---
+name: Request a New Feature
+about: For requesting new feature(s) to be added to the docs.
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Summary:**
+Describe the new feature. If QA has not yet tested the new feature/process, please also file a ticket with QA for their review.
+
+
+**Details:**
+- Include all pertinent information, e.g., screenshots, resource requirements, workarounds, links, etc.
+- List page link(s) in the current docs where the new feature applies, if applicable.
@@ -0,0 +1,11 @@
+---
+name: Request an Update
+about: For fixing docs errors/typos, adding needed/missing information, updating verbiage, deleting outdated info, etc.
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Summary:**
+Describe the requested update giving as much detail as possible. Please also list page link(s) in the current docs where the update applies.
@@ -72,7 +72,7 @@ Use `kubectl` to apply the rendered manifests.
 kubectl -n cattle-system apply -R -f ./rancher
 ```

-# Verify the Upgrade
+## Verify the Upgrade

 Log into Rancher to confirm that the upgrade succeeded.

@@ -84,6 +84,6 @@ See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/ge

 :::

-# Known Upgrade Issues
+## Known Upgrade Issues

 A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -168,7 +168,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-

 For details on installing Rancher with a private registry, see the [air gap installation docs.](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)

-# External TLS Termination
+## External TLS Termination

 We recommend configuring your load balancer as a Layer 4 balancer, forwarding plain 80/tcp and 443/tcp to the Rancher Management cluster nodes. The Ingress Controller on the cluster will redirect http traffic on port 80 to https on port 443.

@@ -4,14 +4,14 @@ title: TLS Settings

 Changing the default TLS settings depends on the chosen installation method.

-# Running Rancher in a highly available Kubernetes cluster
+## Running Rancher in a highly available Kubernetes cluster

 When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller:

 * nginx-ingress-controller (default for RKE1 and RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
 * traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).

-# Running Rancher in a single Docker container
+## Running Rancher in a single Docker container

 The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. You can change this by setting the following environment variables:

@@ -11,7 +11,7 @@ import PortsImportedHosted from '@site/src/components/PortsImportedHosted'

 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.

-# Rancher Nodes
+## Rancher Nodes

 The following table lists the ports that need to be open to and from nodes that are running the Rancher server.

@@ -174,7 +174,7 @@ The following tables break down the port requirements for Rancher nodes, for inb

 </details>

-# Downstream Kubernetes Cluster Nodes
+## Downstream Kubernetes Cluster Nodes

 Downstream Kubernetes clusters run your apps and services. This section describes what ports need to be opened on the nodes in downstream clusters so that Rancher can communicate with them.

@@ -249,7 +249,7 @@ The following table depicts the port requirements for [registered clusters](../.
 </details>


-# Other Port Considerations
+## Other Port Considerations

 ### Commonly Used Ports

@@ -74,7 +74,7 @@ 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. Render the Rancher Helm Template
+### 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.

@@ -112,30 +112,62 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
 helm fetch jetstack/cert-manager --version v1.7.1
 ```

-##### 3. Render the cert-manager template

-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.
-
-```plain
-helm template cert-manager ./cert-manager-v1.7.1.tgz --output-dir . \
-    --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 \
-    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector \
-    --set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
-```
-
-##### 4. Download the cert-manager CRD
+##### 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
   ```

-##### 5. Render the Rancher template
+### 4. Install Rancher

-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.
+Copy the fetched charts to a system that has access to the Rancher server cluster to complete installation.

+##### 1. Install Cert-Manager
+
+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.
+
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
+
+If you are using self-signed certificates, install cert-manager:
+
+1. Create the namespace for cert-manager.
+
+    ```plain
+    kubectl create namespace cert-manager
+    ```
+
+2. Create the cert-manager CustomResourceDefinitions (CRDs). 
+
+    ```plain
+    kubectl apply -f cert-manager/cert-manager-crd.yaml
+    ```
+
+3. Install cert-manager.
+
+    ```plain
+    helm install cert-manager ./cert-manager-v1.7.1.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 \
+        --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector \
+        --set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
+    ```
+
+</details>
+
+##### 2. Install Rancher
+First, refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
+
+Then, create the namespace for Rancher using kubectl:
+
+```plain
+kubectl create namespace cattle-system
+```
+
+Next, install Rancher, 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.

 Placeholder | Description
 ------------|-------------
@@ -145,8 +177,7 @@ Placeholder | Description
 `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.

 ```plain
-helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
-    --no-hooks \ # prevent files for Helm hooks from being generated
+   helm install rancher ./rancher-<VERSION>.tgz \
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
    --set certmanager.version=<CERTMANAGER_VERSION> \
@@ -159,14 +190,13 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \

 #### Option B: Certificates From Files using Kubernetes Secrets

-
 ##### 1. Create secrets

 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.

-##### 2. Render the Rancher template
+##### 2. Install Rancher

-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.
+Install Rancher, 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.

 | Placeholder                      | Description                                     |
 | -------------------------------- | ----------------------------------------------- |
@@ -175,8 +205,7 @@ Render the Rancher template, declaring your chosen options. Use the reference ta
 | `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.         |

 ```plain
-   helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
-    --no-hooks \ # prevent files for Helm hooks from being generated
+   helm install rancher ./rancher-<VERSION>.tgz --output-dir . \
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
@@ -188,8 +217,7 @@ Render the Rancher template, declaring your chosen options. Use the reference ta
 If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:

 ```plain
-   helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
-    --no-hooks \ # prevent files for Helm hooks from being generated
+   helm install rancher ./rancher-<VERSION>.tgz --output-dir . \
    --namespace cattle-system \
    --set hostname=<RANCHER.YOURDOMAIN.COM> \
    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
@@ -199,55 +227,8 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
    --set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```

-**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`

-Then refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
-
-### 4. Install Rancher
-
-Copy the rendered manifest directories to a system that has access to the Rancher server cluster to complete installation.
-
-Use `kubectl` to create namespaces and apply the rendered manifests.
-
-If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
-
-#### For Self-Signed Certificate Installs, Install Cert-manager
-
-<details id="install-cert-manager">
-  <summary>Click to expand</summary>
-
-If you are using self-signed certificates, install cert-manager:
-
-1. Create the namespace for cert-manager.
-    ```plain
-    kubectl create namespace cert-manager
-    ```
-2. Create the cert-manager CustomResourceDefinitions (CRDs).
-    ```plain
-    kubectl apply -f cert-manager/cert-manager-crd.yaml
-    ```
-
-    :::note
-
-    If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false` flag to your `kubectl apply` command above, or else you will receive a validation error relating to the `x-kubernetes-preserve-unknown-fields` field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
-
-    :::
-
-3. Launch cert-manager.
-    ```plain
-    kubectl apply -R -f ./cert-manager
-    ```
-
-</details>
-
-#### Install Rancher with kubectl
-
-```plain
-kubectl create namespace cattle-system
-kubectl -n cattle-system apply -R -f ./rancher
-```
 The installation is complete.
-
 :::caution

 If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
@@ -127,7 +127,7 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct

 For Rancher servers that will provision Linux and Windows clusters, there are distinctive steps to populate your private registry for the Windows images and the Linux images. Since a Windows cluster is a mix of Linux and Windows nodes, the Linux images pushed into the private registry are manifests.

-# Windows Steps
+## Windows Steps

 The Windows images need to be collected and pushed from a Windows server workstation.

@@ -206,7 +206,7 @@ The `rancher-windows-images.txt` is expected to be on the workstation in the sam
   ./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
   ```

-# Linux Steps
+## Linux Steps

 The Linux images need to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images.

@@ -2,7 +2,7 @@
 title: '1. Set up Infrastructure'
 ---

-In this section, you will provision the underlying infrastructure for your Rancher management server with internete access through a HTTP proxy.
+In this section, you will provision the underlying infrastructure for your Rancher management server with internet access through a HTTP proxy.

 To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:

@@ -23,7 +23,7 @@ If you want to replace the certificate, you can delete the `tls-rancher-ingress`

 :::

-# Using a Private CA Signed Certificate
+## Using a Private CA Signed Certificate

 If you are using a private CA, Rancher requires a copy of the CA certificate which is used by the Rancher Agent to validate the connection to the server.

@@ -40,6 +40,6 @@ The configured `tls-ca` secret is retrieved when Rancher starts. On a running Ra

 :::

-# Updating a Private CA Certificate
+## Updating a Private CA Certificate

 Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -6,7 +6,7 @@ The [System Charts](https://github.com/rancher/system-charts) repository contain

 In an air gapped installation of Rancher, you will need to configure Rancher to use a local copy of the system charts. This section describes how to use local system charts using a CLI flag.

-# Using Local System Charts
+## Using Local System Charts

 A local copy of `system-charts` has been packaged into the `rancher/rancher` container. To be able to use these features in an air gap install, you will need to run the Rancher install command with an extra environment variable, `CATTLE_SYSTEM_CATALOG=bundled`, which tells Rancher to use the local copy of the charts instead of attempting to fetch them from GitHub.

@@ -2,7 +2,7 @@
 title: Updating the Rancher Certificate
 ---

-# Updating a Private CA Certificate
+## Updating a Private CA Certificate

 Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.

@@ -16,7 +16,7 @@ A summary of the steps is as follows:

 The details of these instructions are below.

-## 1. Create/update the certificate secret resource
+### 1. Create/update the certificate secret resource

 First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.

@@ -37,7 +37,7 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 2. Create/update the CA certificate secret resource
+### 2. Create/update the CA certificate secret resource

 If the new certificate was signed by a private CA, you will need to copy the corresponding root CA certificate into a file named `cacerts.pem` and create or update the `tls-ca secret` in the `cattle-system` namespace. If the certificate was signed by an intermediate CA, then the `cacerts.pem` must contain both the intermediate and root CA certificates (in this order).

@@ -56,7 +56,7 @@ $ kubectl -n cattle-system create secret generic tls-ca \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 3. Reconfigure the Rancher deployment
+### 3. Reconfigure the Rancher deployment

 :::note

@@ -95,18 +95,18 @@ helm upgrade rancher rancher-stable/rancher \

 When the upgrade is completed, navigate to `https://<Rancher_SERVER>/v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier.

-## 4. Reconfigure Rancher agents to trust the private CA
+### 4. Reconfigure Rancher agents to trust the private CA

 This section covers three methods to reconfigure Rancher agents to trust the private CA. This step is required if either of the following is true:

 - Rancher was initially configured to use the Rancher self-signed certificate (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`)
 - The root CA certificate for the new custom certificate has changed

-### Why is this step required?
+#### Why is this step required?

 When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the `CATTLE_CA_CHECKSUM` environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable `CATTLE_CA_CHECKSUM` must be updated accordingly.

-### Which method should I choose?
+#### Which method should I choose?

 Method 1 is the easiest one but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating the Rancher deployment (Step 3).

@@ -114,7 +114,7 @@ If the clusters have lost connection to Rancher but you have [Authorized Cluster

 Method 3 can be used as a fallback if method 1 and 2 are unfeasible.

-### Method 1: Kubectl command
+#### Method 1: Kubectl command

 For each cluster under Rancher management (except the `local` Rancher management cluster) run the following command using the Kubeconfig file of the Rancher management cluster (RKE or K3S).

@@ -125,7 +125,7 @@ kubectl patch clusters.management.cattle.io <REPLACE_WITH_CLUSTERID> -p '{"statu
 This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate.


-### Method 2: Manually update checksum
+#### Method 2: Manually update checksum

 Manually patch the agent Kubernetes resources by updating the `CATTLE_CA_CHECKSUM` environment variable to the value matching the checksum of the new CA certificate. Generate the new checksum value like so:

@@ -141,7 +141,7 @@ $ kubectl edit -n cattle-system ds/cattle-node-agent
 $ kubectl edit -n cattle-system deployment/cattle-cluster-agent
 ```

-### Method 3: Recreate Rancher agents
+#### Method 3: Recreate Rancher agents

 With this method you are recreating the Rancher agents by running a set of commands on a controlplane node of each downstream cluster.

@@ -150,15 +150,15 @@ First, generate the agent definitions as described here: https://gist.github.com
 Then, connect to a controlplane node of the downstream cluster via SSH, create a Kubeconfig and apply the definitions:
 https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b

-## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
+### 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher

 Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

-### Why is this step required?
+#### Why is this step required?

 Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.

-# Updating from a Private CA Certificate to a Common Certificate
+## Updating from a Private CA Certificate to a Common Certificate

 :::note

@@ -166,7 +166,7 @@ It is possible to perform the opposite procedure as shown above: you may change

 :::

-## 1. Create/update the certificate secret resource
+### 1. Create/update the certificate secret resource

 First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.

@@ -187,7 +187,7 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --dry-run --save-config -o yaml | kubectl apply -f -
 ```

-## 2. Delete the CA certificate secret resource
+### 2. Delete the CA certificate secret resource

 You will delete the `tls-ca secret` in the `cattle-system` namespace as it is no longer needed. You may also optionally save a copy of the `tls-ca secret` if desired.

@@ -203,7 +203,7 @@ To delete the existing `tls-ca` secret:
 kubectl -n cattle-system delete secret tls-ca
 ```

-## 3. Reconfigure the Rancher deployment
+### 3. Reconfigure the Rancher deployment

 :::note Important:

@@ -249,14 +249,14 @@ On upgrade, you can either
 set privateCA=false
 ```

-## 4. Reconfigure Rancher agents for the non-private/common certificate
+### 4. Reconfigure Rancher agents for the non-private/common certificate

 `CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string).

-## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
+### 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher

 Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

-### Why is this step required?
+#### Why is this step required?

 Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.
@@ -19,7 +19,7 @@ If you are upgrading cert-manager to the latest version from a version older tha

 :::

-# Upgrade Cert-Manager
+## Upgrade Cert-Manager

 The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.

@@ -4,11 +4,11 @@ title: Overview

 Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.

-# Run Kubernetes Everywhere
+## Run Kubernetes Everywhere

 Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.

-# Meet IT Requirements
+## Meet IT Requirements

 Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:

@@ -16,7 +16,7 @@ Rancher supports centralized authentication, access control, and monitoring for
 - Setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds.
 - View the health and capacity of your Kubernetes clusters from a single-pane-of-glass.

-# Empower DevOps Teams
+## Empower DevOps Teams

 Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.

@@ -24,7 +24,7 @@ The following figure illustrates the role Rancher plays in IT and DevOps organiz

 ![Platform](/img/platform.png)

-# Features of the Rancher API Server
+## Features of the Rancher API Server

 The Rancher API server is built on top of an embedded Kubernetes API server and an etcd database. It implements the following functionalities:

@@ -52,7 +52,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 - **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
 - **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.

-# Editing Downstream Clusters with Rancher
+## Editing Downstream Clusters with Rancher

 The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE](../pages-for-subheaders/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.

@@ -3,4 +3,4 @@ title: Rancher AWS Marketplace Quick Start
 description: Use Amazon EKS to deploy Rancher server.
 ---

-There is now an additional way for you to deploy the Rancher server in AWS by using Amazon EKS. To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-2yzbnvagmi4as).
+There is now an additional way for you to deploy the Rancher server in AWS by using Amazon EKS. To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-go7ent7goo5ae).
@@ -16,7 +16,7 @@ title: 1. Enable Istio in the Cluster
 1. Click **Apps & Marketplace**.
 1. Click **Charts**.
 1. Click **Istio**.
-1. If you have not already installed your own monitoring app, you will be prompted to install the rancher-monitoring app. Optional: Set your Selector or Scrape config options on rancher-monitoring app install. 
+1. If you have not already installed your own monitoring app, you will be prompted to install the rancher-monitoring app. Optional: Set your Selector or Scrape config options on rancher-monitoring app install.
 1. Optional: Configure member access and [resource limits](../../../integrations-in-rancher/istio/cpu-and-memory-allocations.md) for the Istio components. Ensure you have enough resources on your worker nodes to enable Istio.
 1. Optional: Make additional configuration changes to values.yaml if needed.
 1. Optional: Add additional resources or configuration via the [overlay file.](../../../pages-for-subheaders/configuration-options.md#overlay-file)
@@ -24,6 +24,6 @@ title: 1. Enable Istio in the Cluster

 **Result:** Istio is installed at the cluster level.

-# Additional Config Options
+## Additional Config Options

 For more information on configuring Istio, refer to the [configuration reference.](../../../pages-for-subheaders/configuration-options.md)
@@ -4,7 +4,7 @@ title: 6. Generate and View Traffic

 This section describes how to view the traffic that is being managed by Istio.

-# The Kiali Traffic Graph
+## The Kiali Traffic Graph

 The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.

@@ -16,7 +16,7 @@ For more information on the Istio gateway, refer to the [Istio documentation.](h

 ![In an Istio-enabled cluster, you can have two Ingresses: the default Nginx Ingress, and the default Istio controller.](/img/istio-ingress.svg)

-# Enable an Istio Gateway
+## Enable an Istio Gateway

 The ingress gateway is a Kubernetes service that will be deployed in your cluster. The Istio Gateway allows for more extensive customization and flexibility.

@@ -29,7 +29,7 @@ The ingress gateway is a Kubernetes service that will be deployed in your cluste

 **Result:** The gateway is deployed, and will now route traffic with applied rules.

-# Example Istio Gateway
+## Example Istio Gateway

 We add the BookInfo app deployments in services when going through the Workloads example. Next we add an Istio Gateway so that the app is accessible from outside your cluster.

@@ -127,7 +127,7 @@ To get the ingress gateway URL and port,

 For help inspecting the Istio controller URL and ports, try the commands the [Istio documentation.](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports)

-# Troubleshooting
+## Troubleshooting

 The [official Istio documentation](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#troubleshooting) suggests `kubectl` commands to inspect the correct ingress host and ingress port for external requests.

@@ -10,7 +10,7 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
 - [Creating a Persistent Grafana Dashboard](#creating-a-persistent-grafana-dashboard)
 - [Known Issues](#known-issues)

-# Creating a Persistent Grafana Dashboard
+## Creating a Persistent Grafana Dashboard

 <Tabs>
 <TabItem value="Rancher v2.5.8+">
@@ -144,7 +144,7 @@ helm.sh/resource-policy: "keep"
 </TabItem>
 </Tabs>

-# Known Issues
+## Known Issues

 For users who are using Monitoring V2 v9.4.203 or below, uninstalling the Monitoring chart will delete the `cattle-dashboards` namespace, which will delete all persisted dashboards, unless the namespace is marked with the annotation `helm.sh/resource-policy: "keep"`.

@@ -8,7 +8,7 @@ This page describes how to enable monitoring and alerting within a cluster using

 You can enable monitoring with or without SSL.

-# Requirements
+## Requirements

 - Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
 - Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
@@ -27,13 +27,13 @@ If you want to set up Alertmanager, Grafana or Ingress, it has to be done with t

 :::

-# Setting Resource Limits and Requests
+#Setting Resource Limits and Requests

 The resource requests and limits can be configured when installing `rancher-monitoring`.  To configure Prometheus resources from the Rancher UI, click **Apps & Marketplace > Monitoring** in the upper left corner.

 For more information about the default limits, see [this page.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)

-# Install the Monitoring Application
+## Install the Monitoring Application

 ### Enable Monitoring for use without SSL

@@ -10,7 +10,7 @@ This section assumes familiarity with how monitoring components work together. F

 :::

-# About the Prometheus Custom Resource
+## About the Prometheus Custom Resource

 The Prometheus CR defines a desired Prometheus deployment. The Prometheus Operator observes the Prometheus CR. When the CR changes, the Prometheus Operator creates `prometheus-rancher-monitoring-prometheus`, a Prometheus deployment based on the CR configuration.

@@ -45,7 +45,7 @@ Use the label selector field `ruleSelector` in the Prometheus object to define t

 For examples, refer to the Prometheus documentation on [recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) and [alerting rules.](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)

-# Configuration
+## Configuration

 ### Rule Group

@@ -6,7 +6,7 @@ Administrators have the permission to create RKE templates, and only administrat

 For more information on administrator permissions, refer to the [documentation on global permissions](../manage-role-based-access-control-rbac/global-permissions.md).

-# Giving Users Permission to Create Templates
+## Giving Users Permission to Create Templates

 Templates can only be created by users who have the global permission **Create RKE Templates**.

@@ -290,4 +290,3 @@ Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2
 >- 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:
    - 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.
-
@@ -8,7 +8,7 @@ Only admins of the G Suite domain have access to the Admin SDK. Therefore, only

 Within Rancher, only administrators or users with the **Manage Authentication** [global role](../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) can configure authentication.

-# Prerequisites
+## Prerequisites

 - You must have a [G Suite admin account](https://admin.google.com) configured.
 - G Suite requires a [top private domain FQDN](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) as an authorized domain. One way to get an FQDN is by creating an A-record in Route53 for your Rancher server. You do not need to update your Rancher Server URL setting with that record, because there could be clusters using that URL.
@@ -17,7 +17,7 @@ Within Rancher, only administrators or users with the **Manage Authentication**
 After the Admin SDK API is enabled, your G Suite domain's API screen should look like this:
 ![Enable Admin APIs](/img/Google-Enable-APIs-Screen.png)

-# Setting up G Suite for OAuth with Rancher
+## Setting up G Suite for OAuth with Rancher

 Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following:

@@ -93,7 +93,7 @@ Using the Unique ID of the service account key, register it as an Oauth Client u

 **Result:** The service account is registered as an OAuth client in your G Suite account.

-# Configuring Google OAuth in Rancher
+## Configuring Google OAuth in Rancher

 1. Sign into Rancher using a local user assigned the [administrator](../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) role. This user is also called the local principal.
 1.	In the top left corner, click **☰ > Users & Authentication**.
@@ -28,7 +28,7 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f

 **Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.

-# Configuration
+## Configuration

 | Field | Description                |
 |---------------------------|-----------------|
@@ -16,7 +16,7 @@ For further details on configuring OpenLDAP, refer to the [official documentatio
 3. Once the user has been found, they are authenticated with another LDAP bind request using the user's DN and provided password.
 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute.

-# OpenLDAP Server Configuration
+## OpenLDAP Server Configuration

 You will need to enter the address, port, and protocol to connect to your OpenLDAP server. `389` is the standard port for insecure traffic, `636` for TLS traffic.

@@ -39,7 +39,7 @@ If you are in doubt about the correct values to enter in the user/group Search B
 | User Search Base | Enter the Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".|
 | Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave this field empty. For example: "ou=groups,dc=acme,dc=com".|

-# User/Group Schema Configuration
+## User/Group Schema Configuration

 If your OpenLDAP directory deviates from the standard OpenLDAP schema, you must complete the **Customize Schema** section to match it.

@@ -160,7 +160,7 @@ Can be any link, even to links outside of the cluster.

 It is required to provide either the `toService` directive or the `toURL` directive.

-# Link Examples
+## Link Examples

 ### Example of Link with `toUrl`

@@ -38,7 +38,6 @@ The following table lists the permissions and actions that a `restricted-admin`
 | Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
 | | Create Projects/namespaces | Yes | No | No | |
 | | Add cluster/project members | Yes | No | No | |
-| | Deploy MulticlusterApp in local cluster | Yes | No | No | |
 | | Global DNS | Yes | No | No | |
 | | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
 | | Save as RKE Template | Yes | No | No | |
@@ -60,8 +59,6 @@ The following table lists the permissions and actions that a `restricted-admin`
 | | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
 | Settings | | | | | |
 | | Manage Settings | Yes | No (Can list) | No (Can list) | |
-| Apps | | | | | |
-| | Launch Multicluster Apps | Yes | Yes | Yes | Not in local cluster |
 | User | | | | | |
 | | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
 | | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
@@ -8,7 +8,7 @@ Rancher recommends configuring recurrent `etcd` snapshots for all production clu

 Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.

-# How Snapshots Work
+## How Snapshots Work

 ### Snapshot Components

@@ -64,7 +64,7 @@ On restore, the following process is used:
 4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
 5.  The cluster is restored and post-restore actions will be done in the cluster.

-# Configuring Recurring Snapshots
+## Configuring Recurring Snapshots

 Select how often you want recurring snapshots to be taken as well as how many snapshots to keep. The amount of time is measured in hours. With timestamped snapshots, the user has the ability to do a point-in-time recovery.

@@ -81,7 +81,7 @@ In the **Advanced Cluster Options** section, there are several options available
 | Recurring etcd Snapshot Creation Period | Time in hours between recurring snapshots| 12 hours |
 | Recurring etcd Snapshot Retention Count | Number of snapshots to retain| 6 |

-# One-Time Snapshots
+## One-Time Snapshots

 In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure.

@@ -91,7 +91,7 @@ In addition to recurring snapshots, you may want to take a "one-time" snapshot.

 **Result:** Based on your [snapshot backup target](#snapshot-backup-targets), a one-time snapshot will be taken and saved in the selected backup target.

-# Snapshot Backup Targets
+## Snapshot Backup Targets

 Rancher supports two different backup targets:

@@ -130,7 +130,7 @@ The `S3` backup target supports using IAM authentication to AWS API in addition

 To give an application access to S3, refer to the AWS documentation on [Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)

-# Viewing Available Snapshots
+## Viewing Available Snapshots

 The list of all available snapshots for the cluster is available in the Rancher UI.

@@ -138,7 +138,7 @@ The list of all available snapshots for the cluster is available in the Rancher
 1. In the **Clusters** page, go to the cluster where you want to view the snapshots and click its name.
 1. Click the **Snapshots** tab to view the list of saved snapshots. These snapshots include a timestamp of when they were created.

-# Safe Timestamps
+## Safe Timestamps

 Snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable.

@@ -146,6 +146,6 @@ The option `safe_timestamp` is added to support compatible file names. When this

 This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.

-# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
+## Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0

 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restore-rancher-launched-kubernetes-clusters-from-backup.md).
@@ -70,8 +70,8 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa

 5. Run the revised command.

-6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](../manage-clusters/clean-cluster-nodes.md) before attempting to add them back into a cluster.  
+6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](../manage-clusters/clean-cluster-nodes.md) before attempting to add them back into a cluster.

-# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
+## Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0

 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restore-rancher-launched-kubernetes-clusters-from-backup.md).
@@ -12,7 +12,7 @@ For a complete walkthrough of developing charts, see the [Chart Template Develop



-# Chart Types
+## Chart Types

 Rancher supports two different types of charts: Helm charts and Rancher charts.

@@ -26,7 +26,7 @@ Rancher charts are native helm charts with two files that enhance user experienc

 Rancher charts add simplified chart descriptions and configuration forms to make the application deployment easy. Rancher users do not need to read through the entire list of Helm variables to understand how to launch an application.

-# Chart Directory Structure
+## Chart Directory Structure

 You can provide Helm Charts in a standard, HTTP based Helm Repository. For more information see the [Chart Repository Guide](https://helm.sh/docs/topics/chart_repository) in the official Helm documentation.

@@ -48,7 +48,7 @@ The following table demonstrates the directory structure for a Git repository. T
 │   │   │   ├── templates/        # Directory containing templates that, when combined with values.yml, generates Kubernetes YAML.
 ```

-# Additional Files for Rancher Charts
+## Additional Files for Rancher Charts

 Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not.

@@ -149,7 +149,7 @@ Look over the load balancer details and click **Create** when you're satisfied.

 After AWS creates the NLB, click **Close**.

-# 4. Add listener to NLB for TCP port 80
+## 4. Add listener to NLB for TCP port 80

 1. Select your newly created NLB and select the **Listeners** tab.

@@ -163,7 +163,7 @@ After AWS creates the NLB, click **Close**.

 6. Click **Save** in the top right of the screen.

-# Health Check Paths for NGINX Ingress and Traefik Ingresses
+## Health Check Paths for NGINX Ingress and Traefik Ingresses

 K3s and RKE Kubernetes clusters handle health checks differently because they use different Ingresses by default.

@@ -16,12 +16,12 @@ In both single-node setups, Rancher can be installed with Helm on the Kubernetes

 :::

-# Prerequisites
+## Prerequisites

 These instructions assume you have set up two nodes, a load balancer, a DNS record, and an external MySQL database as described in [this section.](../infrastructure-setup/ha-k3s-kubernetes-cluster.md)

 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
-# Installing Kubernetes
+## Installing Kubernetes

 ### 1. Install Kubernetes and Set up the K3s Server

@@ -23,7 +23,7 @@ In both single-node setups, Rancher can be installed with Helm on the Kubernetes

 :::

-# Installing Kubernetes
+## Installing Kubernetes

 ### Required CLI Tools

@@ -85,7 +85,7 @@ ingress:
 RKE has many configuration options for customizing the install to suit your specific environment.

 Please see the [RKE Documentation](https://rancher.com/docs/rke/latest/en/config-options/) for the full list of options and capabilities.
- 
+
 For tuning your etcd cluster for larger Rancher installations, see the [etcd settings guide](../../advanced-user-guides/tune-etcd-for-large-installs.md).

 For more information regarding Dockershim support, refer to [this page](../../../getting-started/installation-and-upgrade/installation-requirements/dockershim.md)
@@ -6,14 +6,15 @@ _Tested on v2.5.6_

 This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#environment-for-kubernetes-installations)

-# Prerequisites
+## Prerequisites

 These instructions assume you have set up three nodes, a load balancer, and a DNS record, as described in [this section.](../infrastructure-setup/ha-rke2-kubernetes-cluster.md)

 Note that in order for RKE2 to work correctly with the load balancer, you need to set up two listeners: one for the supervisor on port 9345, and one for the Kubernetes API on port 6443.

 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the RKE2 version, use the INSTALL_RKE2_VERSION environment variable when running the RKE2 installation script.
-# Installing Kubernetes
+
+## Installing Kubernetes

 ### 1. Install Kubernetes and Set up the RKE2 Server

@@ -15,7 +15,7 @@ The following account types are not supported for Azure Subscriptions:
 - Single tenant accounts (i.e. accounts with no subscriptions).
 - Multi-subscription accounts.

-# Prerequisites for RKE and RKE2
+## Prerequisites for RKE and RKE2

 To set up the Azure cloud provider for both RKE and RKE2, the following credentials need to be configured:

@@ -70,7 +70,7 @@ You should already assign custom hosts to this Network Security Group during pro

 Only hosts expected to be load balancer back ends need to be in this group.

-# RKE2 Cluster Set-up in Rancher
+## RKE2 Cluster Set-up in Rancher

 1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.

@@ -6,7 +6,7 @@ Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has

 This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after bringing up a cluster.

-# Prerequisites
+## Prerequisites

 The vSphere versions supported:

@@ -17,7 +17,7 @@ The Kubernetes version must be 1.19 or higher.

 Using the vSphere out-of-tree cloud provider requires Linux nodes and is not supported on Windows.

-# Installation
+## Installation

 The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).

@@ -55,7 +55,7 @@ The Cloud Provider Interface (CPI) should be installed first before installing t
 1. Click **Install**.


-# Using the CSI driver for provisioning volumes
+## Using the CSI driver for provisioning volumes

 The CSI chart by default creates a storageClass.

@@ -29,12 +29,12 @@ Upstream bug: https://github.com/kubernetes-sigs/vsphere-csi-driver/issues/628

 Rancher issue tracking this bug: https://github.com/rancher/rancher/issues/31105

-# Prerequisites
+## Prerequisites

 - vSphere CSI Migration requires vSphere 7.0u1. In order to be able to manage existing in-tree vSphere volumes, upgrade vSphere to 7.0u1.
 - The Kubernetes version must be 1.19 or higher.

-# Migration
+## Migration

 ### 1. Install the CPI plugin

@@ -22,13 +22,9 @@ Fleet | Supported | Supported
 EKS Operator | Supported | Not Supported
 AKS Operator | Not Supported | Not Supported
 GKE Operator | Not Supported | Not Supported
-Alerting v1 | Supported | Supported
-Monitoring v1 | Supported | Supported
-Logging v1 | Supported | Supported
 Monitoring/Alerting v2 | Supported | Supported
 Logging v2 | Supported | Supported
 Istio | Supported | Not Supported
-Catalog v1 | Supported | Not Supported
 Catalog v2 | Supported | Not Supported
 OPA | Supported | Not Supported
 Longhorn | Supported | Not Supported
@@ -13,7 +13,7 @@ Deployments use the Kubernetes registry secret to authenticate with a private Do

 Currently, deployments pull the private registry credentials automatically only if the workload is created in the Rancher UI and not when it is created via kubectl.

-# Creating a Registry in Namespaces
+## Creating a Registry in Namespaces

 :::note Prerequisite:

@@ -44,7 +44,7 @@ You must have a [private registry](https://docs.docker.com/registry/deploying/)
 - You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
 - Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope.

-# Creating a Registry in Projects
+## Creating a Registry in Projects

 :::note Prerequisites:

@@ -87,7 +87,7 @@ Project-scoped registries on the local cluster are only visible when a single pr

 :::

-# Using a Private Registry
+## Using a Private Registry

 You can deploy a workload with an image from a private registry through the Rancher UI, or with `kubectl`.

@@ -7,7 +7,7 @@ description: Ingress configuration

 For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork but uses hostPorts for port 80 and port 443. This was done so the admission webhook can be configured to be accessed using ClusterIP so it can only be reached inside the cluster.

-# Ingress Rule Configuration
+## Ingress Rule Configuration

 - [Specify a hostname to use](#specify-a-hostname-to-use)
 - [Use as the default backend](#use-as-the-default-backend)
@@ -14,7 +14,7 @@ When configuring a workload, you'll be able to choose which secrets to include.

 Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)

-# Creating Secrets in Namespaces
+## Creating Secrets in Namespaces

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. Go to the cluster where you want to add a secret and click **Explore**.
@@ -47,7 +47,7 @@ Mounted secrets will be updated automatically unless they are mounted as subpath
 Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)


-# Creating Secrets in Projects
+## Creating Secrets in Projects

 Before v2.6, secrets were required to be in a project scope. Projects are no longer required, and you may use the namespace scope instead. As a result, the Rancher UI was updated to reflect this new functionality. However, you may still create project-scoped secrets if desired. Note that you have to first enable the `legacy` feature flag and look at a single project to do so. Use the following steps to set up your project-level secret:

@@ -69,7 +69,7 @@ Project-scoped secrets on the local cluster are only visible when a single proje

 :::

-# What's Next?
+## What's Next?

 Now that you have a secret added to a namespace, you can add it to a workload that you deploy.

@@ -93,7 +93,8 @@ You can access your cluster after its state is updated to **Active**.

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
-# Optional Next Steps
+
+## Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:

@@ -21,7 +21,7 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
  - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
 - **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.

-# Creating an EC2 Cluster
+## Creating an EC2 Cluster

 The steps to create a cluster differ based on your Rancher version.

@@ -133,7 +133,7 @@ After creating your cluster, you can access it through the Rancher UI. As a best
 - **Access your cluster with the kubectl CLI:** Follow [these steps](../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
 - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.

-# IAM Policies
+## IAM Policies

 ### Example IAM Policy

@@ -29,7 +29,7 @@ For more information on configuring Azure node templates, refer to the [Azure no
 - [Preparation in Azure](#preparation-in-azure)
 - [Creating an Azure Cluster](#creating-an-azure-cluster)

-# Preparation in Azure
+## Preparation in Azure

 Before creating a node template in Rancher using a cloud infrastructure such as Azure, we must configure Rancher to allow the manipulation of resources in an Azure subscription.

@@ -46,7 +46,7 @@ az ad sp create-for-rbac \

 The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, and *The client secret*. This information will be used when you create a node template for Azure.

-# Creating an Azure Cluster
+## Creating an Azure Cluster

 <Tabs>
 <TabItem value="RKE">
@@ -17,7 +17,7 @@ For details on configuring RKE Kubernetes clusters in Rancher, refer to the [clu
 - [Preparation in Nutanix AOS](#preparation-in-nutanix-aos)
 - [Creating a Nutanix AOS Cluster](#creating-a-nutanix-aos-cluster)

-# Preparation in Nutanix AOS
+## Preparation in Nutanix AOS

 The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters.

@@ -26,6 +26,7 @@ The following sections describe the requirements for setting up Nutanix AOS so t
 The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.

 :::
+
 ### Create Credentials in Nutanix AOS

 Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials.
@@ -43,7 +44,7 @@ See [Node Networking Requirements](../../../kubernetes-clusters-in-rancher-setup

 Setting up [VM-VM Anti-Affinity Policies](https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_1:ahv-vm-anti-affinity-t.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate AHV hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.

-# Creating a Nutanix AOS Cluster
+## Creating a Nutanix AOS Cluster

 1. [Create a node template ](#1-create-a-node-template)
 2. [Create a cluster with node pools using the node template](#2-create-a-cluster-with-node-pools-using-the-node-template)
@@ -82,8 +83,7 @@ You can access your cluster after its state is updated to **Active**.
 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces

-
-# Optional Next Steps
+## Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:

@@ -16,7 +16,7 @@ For details on configuring RKE Kubernetes clusters in Rancher, refer to the [clu
 - [Preparation in vSphere](#preparation-in-vsphere)
 - [Creating a vSphere Cluster](#creating-a-vsphere-cluster)

-# Preparation in vSphere
+## Preparation in vSphere

 This section describes the requirements for setting up vSphere so that Rancher can provision VMs and clusters.

@@ -513,7 +513,7 @@ Cluster-autoscaler deployment can also be set up using [manual configuration](ht

 :::

-# Testing
+## Testing

 At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:

@@ -17,9 +17,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 :::

 | Rancher Version | Adapter Version |
-| --------------- | :-------------: |
-| v2.6.7          |     v1.0.1      |
-| v2.6.8          |     v1.0.1      |
+|-----------------|:---------------:|
+| v2.7.0          |     v2.0.0      |
+

 ### 1. Gain Access to the Local Cluster

@@ -71,31 +71,29 @@ helm repo add rancher-charts https://charts.rancher.io

 Next, install the CSP adapter. You must specify several values, including the account number, and the name of the role created in the prerequisites.

-For the below instructions, replace `$MY_ACC_NUM` with your AWS account number and `$MY_ROLE_NAME` with the name of the role created in the prerequisites.
+Ensure that you use the version of the CSP adapter that matches the version of Rancher that you are running, as defined [above](#rancher-vs-adapter-compatibility-matrix).
+
+For the below instructions, replace `$MY_ACC_NUM` with your AWS account number and `$MY_ROLE_NAME` with the name of the role created in the prerequisites. In addition, replace `$CSP_ADAPTER_VERSION` with the version that matches your Rancher version in the [version matrix](#rancher-vs-adapter-compatibility-matrix).

 > **Note:** If you use shell variables, do not specify quotation marks. For example, MY_ACC_NUM=123456789012 will work, but MY_ACC_NUM="123456789012" will fail.

 > **Note:** Accounts using the AWS Marketplace listing for the EU and the UK will need to specify an additional `--set image.repository=rancher/rancher-csp-adapter-eu` option. To see if your account needs this option when installing the adapter, refer to the usage instructions of the marketplace listing.

-> **Note:** It is important that you follow the instructions below exactly. In particular, the command to install version 1.0.1 of the adapter (by using --set image.tag=v1.0.1) is key to ensure that node counts are accurate.
-
 <Tabs>
 <TabItem value="Let's Encrypt/ Public Certificate Authority">

  ```bash
-  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set image.tag=v1.0.1
+  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --version $CSP_ADAPTER_VERSION
  ```


  Alternatively, you can use a `values.yaml` and specify options like below:

  ```yaml
-  image:
-  tag: v1.0.1
  aws:
-  enabled: true
-  accountNumber: "$MY_ACC_NUM"
-  roleName: $MY_ROLE_NAME
+    enabled: true
+    accountNumber: "$MY_ACC_NUM"
+    roleName: $MY_ROLE_NAME
  ```

  > **Note:** The account number needs to be specified in a string format, like the above, or the installation will fail.
@@ -103,25 +101,23 @@ For the below instructions, replace `$MY_ACC_NUM` with your AWS account number a
  You can then install the adapter with the following command:

  ```bash
-  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
+  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml --version $CSP_ADAPTER_VERSION
  ```

  </TabItem>
  <TabItem value="Private CA Authority / Rancher-generated Certificates">

  ```bash
-  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set additionalTrustedCAs=true --set image.tag=v1.0.1
+  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set additionalTrustedCAs=true --version $CSP_ADAPTER_VERSION
  ```

  Alternatively, you can use a `values.yaml` and specify options the below:

  ```yaml
-  image:
-  tag: v1.0.1
  aws:
-  enabled: true
-  accountNumber: "$MY_ACC_NUM"
-  roleName: $MY_ROLE_NAME
+    enabled: true
+    accountNumber: "$MY_ACC_NUM"
+    roleName: $MY_ROLE_NAME
  additionalTrustedCAs: true
  ```

@@ -130,7 +126,7 @@ For the below instructions, replace `$MY_ACC_NUM` with your AWS account number a
  You can then install the adapter with the following command:

  ```bash
-  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
+  helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml --version $CSP_ADAPTER_VERSION
  ```

  </TabItem>
@@ -14,7 +14,7 @@ For public downstream clusters, it is sufficient to [set the required environmen

 For private nodes or private clusters, the environment variables need to be set on the nodes themselves. Then the environment variables are configured from the Rancher UI, typically when provisioning a custom cluster or when registering the private cluster. For an example of how to set the environment variables on Ubuntu node in a K3s Kubernetes cluster, see [this section.](#setting-environment-variables-on-private-nodes)

-# Required Environment Variables
+## Required Environment Variables

 When adding Fleet agent environment variables for the proxy, replace <PROXY_IP> with your private proxy IP.

@@ -65,6 +65,43 @@ Admins should use these roles to provide more fine-grained access to users:
 | monitoring-dashboard-edit | Allow admins to assign roles to users to be able to edit / view ConfigMaps within the cattle-dashboards namespace. ConfigMaps in this namespace will correspond to Grafana Dashboards that are persisted onto the cluster. |
 | monitoring-dashboard-view | Allow admins to assign roles to users to be able to view ConfigMaps within the cattle-dashboards namespace. ConfigMaps in this namespace will correspond to Grafana Dashboards that are persisted onto the cluster. |

+
+### Assigning Monitoring Roles through Custom Roles
+
+Admins may assign custom roles in the Rancher UI for admin, editing, and viewing monitoring. These "roles" are created by default when the monitoring app is installed. Additionally, these roles are also deployed to the corresponding Kubernetes roles: admin, edit, and view `ClusterRoles`.
+
+:::note Important
+
+The UI will not offer `monitoring-admin`, `monitoring-edit`, and `monitoring-view` options when users are being added to a cluster. These monitoring roles can only be assigned by manually creating a custom role that inherits from Project Owner and Project Monitoring View roles. 
+
+:::
+
+  1. Create the custom role:
+
+    1.1 Click **☰ > Users & Authentication > Roles**.
+
+    1.2 Select the appropriate tab, e.g., **Cluster** role. Then click **Create Cluster Role**.
+
+    1.3 In the **Name** field, create a custom role such as `View Monitoring`, `Edit Monitoring`, or `Admin Monitoring`.
+
+    1.4 Click **Inherit From > Add Resource**, then select the Kubernetes role, as applicable, from the dropdown.
+
+    1.5 Click **Create**.
+
+
+  2. Assign the custom role to a new user:
+
+    2.1 Click **☰ > Cluster Management > Cluster Explore > Cluster > Cluster Members > Add**.
+
+    2.2 Search for your new user name from **Select Member** options displayed.
+
+    2.3 Assign the new custom role from **Cluster Permissions** to the new user.
+
+    2.4 Click **Create**.
+
+
+**Result:** The new user should now be able to see the monitoring tools.
+
 ### Additional Monitoring ClusterRoles

 Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster.  They are not aggregated by default but can be bound to a namespace by deploying a `RoleBinding` or `ClusterRoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl).
@@ -6,13 +6,6 @@ _Available as of v2.5.8_

 Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).

-
-## Comparison to Monitoring V1
-
-Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.
-
-In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process.
-
 ## Cluster Requirements

 Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0.  To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement.
@@ -25,8 +18,6 @@ If the cluster was provisioned before Rancher 2.5.8 (even if the current Rancher

 To facilitate this upgrade, Rancher 2.5.8 has released a brand new Helm chart called `rancher-wins-upgrader`.

-> **Prerequisite:** Make sure Monitoring V1 for Windows is uninstalled.
-
 1. Deploy `rancher-wins-upgrader` with the following override:
    ```yaml
    # Masquerading bootstraps the wins-upgrader installation via
@@ -16,14 +16,14 @@ If you install Rancher following the Docker installation guide, there is no upgr

 :::

-# Installation Outline
+## Installation Outline

 1. [Set up infrastructure and private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md)
 2. [Collect and publish images to your private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md)
 3. [Set up a Kubernetes cluster (Skip this step for Docker installations)](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md)
 4. [Install Rancher](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)

-# Upgrades
+## Upgrades

 To upgrade Rancher with Helm CLI in an air gap environment, follow [this procedure.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md)

@@ -2,11 +2,11 @@
 title: AWS Marketplace Integration
 ---

-# Overview
+## Overview

 Rancher offers an integration with the AWS Marketplace which allows users to purchase a support contract with SUSE. This integration allows you easily adjust your support needs as you start to support more clusters.

-# Limitations
+## Limitations

 - You must be running Rancher v2.6.7 or higher
 - Rancher must be deployed with additional metrics enabled.
@@ -14,11 +14,12 @@ Rancher offers an integration with the AWS Marketplace which allows users to pur
 - You must purchase at least one entitlement to Rancher support through AWS Marketplace.
 - You may need additional setup to support proxy/airgap use cases. See the [prerequisites](../integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/adapter-requirements.md) for more information.

-# How to Use
+## How to Use
+
 1. Complete the [prerequisite steps](../integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/adapter-requirements.md).
 2. [Install the CSP Adapter](../integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md).

-# FAQ
+## FAQ

 **Can I purchase support for more nodes later on?**

@@ -11,7 +11,7 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S
 > The instructions in this section assume that you understand how Rancher, Shibboleth, and OpenLDAP work together. For a more detailed explanation of how it works, refer to [this page.](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml/about-group-permissions.md)


-# Setting up Shibboleth in Rancher
+## Setting up Shibboleth in Rancher

 ### Shibboleth Prerequisites
 >
@@ -73,7 +73,7 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to

 To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.

-# Setting up OpenLDAP in Rancher
+## Setting up OpenLDAP in Rancher

 If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.

@@ -92,10 +92,10 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli
 > Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users](authentication-config.md#external-authentication-configuration-and-principal-users).

 1. Log into the Rancher UI using the initial local `admin` account.
-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**.
 1. Click **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.

-# Troubleshooting
+## Troubleshooting

 If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -20,7 +20,7 @@ Because the API sets the actual value and the command line sets the default valu

 For example, if you install Rancher, then set a feature flag to true with the Rancher API, then upgrade Rancher with a command that sets the feature flag to false, the default value will still be false, but the feature will still be enabled because it was set with the Rancher API. If you then deleted the set value (true) with the Rancher API, setting it to NULL, the default value (false) would take effect. See the [feature flags page](../getting-started/installation-and-upgrade/installation-references/feature-flags.md) for more information.

-# Enabling Features when Starting Rancher
+## Enabling Features when Starting Rancher

 When you install Rancher, enable the feature you want with a feature flag. The command is different depending on whether you are installing Rancher on a single node or if you are doing a Kubernetes Installation of Rancher.

@@ -81,7 +81,7 @@ docker run -d -p 80:80 -p 443:443 \
 ```


-# Enabling Features with the Rancher UI
+## Enabling Features with the Rancher UI

 1. In the upper left corner, click **☰ > Global Settings**.
 1. Click **Feature Flags**.
@@ -97,7 +97,7 @@ docker run -d -p 80:80 -p 443:443 \

 **Result:** The feature is disabled.

-# Enabling Features with the Rancher API
+## Enabling Features with the Rancher API

 1. Go to `<RANCHER-SERVER-URL>/v3/features`.
 1. In the `data` section, you will see an array containing all of the features that can be turned on with feature flags. The name of the feature is in the `id` field. Click the name of the feature you want to enable.
@@ -133,7 +133,7 @@ _Mutable: yes_

 Enable control plane authorized networks to block untrusted non-GCP source IPs from accessing the Kubernetes master through HTTPS. If selected, additional authorized networks may be added. If the cluster is created with a public endpoint, this option is useful for locking down access to the public endpoint to only certain networks, such as the network where your Rancher service is running. If the cluster only has a private endpoint, this setting is required.

-# Additional Options
+## Additional Options

 ### Cluster Addons

@@ -182,7 +182,7 @@ _Mutable: yes_

 Set the start time for a 4 hour maintenance window. The time is specified in the UTC time zone using the HH:MM format. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions)

-# Node Pools
+## Node Pools

 In this section, enter details describing the configuration of each node in the node pool.

@@ -256,7 +256,7 @@ You can add network tags to the node pool to make firewall rules and routes betw

 For details on tag syntax and requirements, see the [Kubernetes documentation](https://cloud.google.com/vpc/docs/add-remove-network-tags).

-# Group Details
+## Group Details

 In this section, enter details describing the node pool.

@@ -15,7 +15,7 @@ Cluster Autoscaler is designed to run on Kubernetes master nodes. It can run in

 It's possible to run a customized deployment of Cluster Autoscaler on worker nodes, but extra care needs to be taken to ensure that Cluster Autoscaler remains up and running.

-# Cloud Providers
+## Cloud Providers

 Cluster Autoscaler provides support to distinct cloud providers. For more information, go to [cluster-autoscaler supported cloud providers.](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment)

@@ -9,7 +9,7 @@ import TabItem from '@theme/TabItem';
 In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.


-# Prerequisites
+## Prerequisites

 - [Kubernetes Cluster](#kubernetes-cluster)
 - [Ingress Controller](#ingress-controller)
@@ -47,7 +47,7 @@ The following CLI tools are required for setting up the Kubernetes cluster. Plea
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
 - [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements](../getting-started/installation-and-upgrade/resources/helm-version-requirements.md) to choose a version of Helm to install Rancher. Refer to the [instructions provided by the Helm project](https://helm.sh/docs/intro/install/) for your specific platform.

-# Install the Rancher Helm Chart
+## Install the Rancher Helm Chart

 Rancher is installed using the [Helm](https://helm.sh/) package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, we can create configurable deployments instead of just using static files.

@@ -5,7 +5,7 @@ description: Learn how to install Rancher in development and production environm

 This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.

-# Terminology
+## Terminology

 In this section,

@@ -16,7 +16,7 @@ In this section,

 Note the `restrictedAdmin` Helm chart option available for **the Rancher Server**. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)

-# Overview of Installation Options
+## Overview of Installation Options

 Rancher can be installed on these main architectures:

@@ -62,10 +62,11 @@ When the nodes in your Kubernetes cluster are running and fulfill the [node requ

 For a longer discussion of Rancher architecture, refer to the [architecture overview,](rancher-manager-architecture.md) [recommendations for production-grade architecture,](../reference-guides/rancher-manager-architecture/architecture-recommendations.md) or our [best practices guide.](../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)

-# Prerequisites
+## Prerequisites
+
 Before installing Rancher, make sure that your nodes fulfill all of the [installation requirements.](installation-requirements.md)

-# Architecture Tip
+## Architecture Tip

 For the best performance and greater security, we recommend a separate, dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](kubernetes-clusters-in-rancher-setup.md) for running your workloads.

@@ -35,7 +35,7 @@ For a list of best practices that we recommend for running the Rancher server in

 The Rancher UI works best in Firefox or Chromium based browsers (Chrome, Edge, Opera, Brave, ...).

-# Operating Systems and Container Runtime Requirements
+## Operating Systems and Container Runtime Requirements

 Rancher should work with any modern Linux distribution.

@@ -77,11 +77,11 @@ For the container runtime, RKE2 bundles its own containerd. Docker is not requir

 For details on which OS versions were tested with RKE2, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)

-# Hardware Requirements
+## Hardware Requirements

 The following sections describe the CPU, memory, and disk requirements for the nodes where the Rancher server is installed.

-# CPU and Memory
+## CPU and Memory

 Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. The requirements are different depending on if you are installing Rancher in a single container with Docker, or if you are installing Rancher on a Kubernetes cluster.

@@ -134,7 +134,7 @@ These CPU and memory requirements apply to a host with a [single-node](rancher-o
 | Small           | Up to 5  | Up to 50  | 1     | 4 GB |
 | Medium          | Up to 15 | Up to 200 | 2     | 8 GB |

-# Ingress
+## Ingress

 Each node in the Kubernetes cluster that Rancher is installed on should run an Ingress.

@@ -148,11 +148,11 @@ For hosted Kubernetes clusters (EKS, GKE, AKS), you will need to set up the ingr
 - **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
 - **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md)

-# Disks
+## Disks

 Rancher performance depends on etcd in the cluster performance. To ensure optimal speed, we recommend always using SSD disks to back your Rancher management Kubernetes cluster. On cloud providers, you will also want to use the minimum size that allows the maximum IOPS. In larger clusters, consider using dedicated storage devices for etcd data and wal directories.

-# Networking Requirements
+## Networking Requirements

 This section describes the networking requirements for the node(s) where the Rancher server is installed.

@@ -170,6 +170,6 @@ Each node used should have a static IP configured, regardless of whether you are

 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md) lists all the necessary ports for Rancher and Downstream Clusters for the different cluster types.

-# Dockershim Support
+## Dockershim Support

 For more information on Dockershim support, refer to [this page](../getting-started/installation-and-upgrade/installation-requirements/dockershim.md).
@@ -6,7 +6,7 @@ This section describes how to enable Istio and start using it in your projects.

 If you use Istio for traffic management, you will need to allow external traffic to the cluster. In that case, you will need to follow all of the steps below.

-# Prerequisites
+## Prerequisites

 This guide assumes you have already [installed Rancher,](installation-and-upgrade.md) and you have already [provisioned a separate Kubernetes cluster](kubernetes-clusters-in-rancher-setup.md) on which you will install Istio.

@@ -14,8 +14,7 @@ The nodes in your cluster must meet the [CPU and memory requirements.](../integr

 The workloads and services that you want to be controlled by Istio must meet [Istio's requirements.](https://istio.io/docs/setup/additional-setup/requirements/)

-
-# Install
+## Install

 :::tip Quick Setup Tip:

@@ -65,14 +65,6 @@ Refer to the [setup guide](istio-setup-guide.md) for instructions on how to set

 To remove Istio components from a cluster, namespace, or workload, refer to the section on [uninstalling Istio.](../integrations-in-rancher/istio/disable-istio.md)

-## Migrate From Previous Istio Version
-
-There is no upgrade path for Istio versions less than 1.7.x. To successfully install Istio through **Apps & Marketplace,** you will need to disable your existing Istio from the global view in the legacy Rancher UI.
-
-If you have a significant amount of additional Istio CRDs you might consider manually migrating CRDs that are supported in both versions of Istio. You can do this by running `kubectl get <resource> -n istio-system -o yaml`, save the output yaml and re-apply in the new version.
-
-Another option is to manually uninstall istio resources one at a time, but leave the resources that are supported in both versions of Istio and that will not be installed by the newest version. This method is more likely to result in issues installing the new version, but could be a good option depending on your situation.
-
 ## Accessing Visualizations

 > By default, only cluster-admins have access to Kiali. For instructions on how to allow admin, edit or views roles to access them, see [this section.](../integrations-in-rancher/istio/rbac-for-istio.md)
@@ -93,7 +85,7 @@ To access the Kiali visualization,
 1. In the left navigation bar, click **Istio**.
 1. Click **Kiali**. From here you can access the **Traffic Graph** tab or the **Traffic Metrics** tab to see network visualizations and metrics.

-By default, all namespace will picked up by prometheus and make data available for Kiali graphs. Refer to [selector/scrape config setup](../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) if you would like to use a different configuration for prometheus data scraping. 
+By default, all namespace will picked up by prometheus and make data available for Kiali graphs. Refer to [selector/scrape config setup](../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) if you would like to use a different configuration for prometheus data scraping.

 Your access to the visualizations depend on your role. Grafana and Prometheus are only available for `cluster-admin` roles. The Kiali UI is available only to `cluster-admin` by default, but `cluster-admin` can allow other roles to access them by editing the Istio values.yaml.

@@ -11,7 +11,7 @@ This section includes troubleshooting tips in the following categories:
 - [Troubleshooting nginx-proxy Nodes](../troubleshooting/kubernetes-components/troubleshooting-nginx-proxy.md)
 - [Troubleshooting Worker Nodes and Generic Components](../troubleshooting/kubernetes-components/troubleshooting-worker-nodes-and-generic-components.md)

-# Kubernetes Component Diagram
+## Kubernetes Component Diagram

 ![Cluster diagram](/img/clusterdiagram.svg)<br/>
 <sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>
@@ -34,7 +34,7 @@ If you want to reuse a node from a previous custom cluster, [clean the node](../

 For more information, refer to the section on [custom nodes.](use-existing-nodes.md)

-# Programmatically Creating RKE Clusters
+### Programmatically Creating RKE Clusters

 The most common way to programmatically deploy RKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)

@@ -75,6 +75,6 @@ RKE2 provisioning also allows you to install custom clusters on pre-provisioned

 If you want to reuse a node from a previous custom cluster, clean the node before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.

-# Programmatically Creating RKE2 Clusters
+### Programmatically Creating RKE2 Clusters

 The most common way to programmatically deploy RKE2 clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster_v2)
@@ -5,8 +5,7 @@ description: Rancher integrates with popular logging services. Learn the require

 The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.

-For an overview of the changes in v2.5, see [this section.](../integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](../integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md)
-
+For an overview of the changes in v2.5, see [this section.](../integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5)

 ## Enabling Logging

@@ -8,4 +8,3 @@ title: Monitoring Guides
 - [Customizing Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)
 - [Persistent Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)
 - [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
- [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)
@@ -23,11 +23,11 @@ The monitoring application allows you to:
 - Defines precomputed, frequently needed or computationally expensive expressions as new time series based on metrics collected via Prometheus
 - Expose collected metrics from Prometheus to the Kubernetes Custom Metrics API via Prometheus Adapter for use in HPA

-# How Monitoring Works
+## How Monitoring Works

 For an explanation of how the monitoring components work together, see [this page.](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)

-# Default Components and Deployments
+## Default Components and Deployments

 ### Built-in Dashboards

@@ -48,11 +48,11 @@ The monitoring application deploys some alerts by default. To see the default al

 For a list of monitoring components exposed in the Rancher UI, along with common use cases for editing them, see [this section.](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#components-exposed-in-the-rancher-ui)

-# Role-based Access Control
+## Role-based Access Control

 For information on configuring access to monitoring, see [this page.](../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)

-# Guides
+## Guides

 - [Enable monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md)
 - [Uninstall monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/uninstall-monitoring.md)
@@ -60,9 +60,8 @@ For information on configuring access to monitoring, see [this page.](../integra
 - [Customizing Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)
 - [Persistent Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)
 - [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
- [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)

-# Configuration
+## Configuration

 ### Configuring Monitoring Resources in Rancher

@@ -79,7 +78,7 @@ For information on configuring access to monitoring, see [this page.](../integra

 For more information on `rancher-monitoring` chart options, including options to set resource limits and requests, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md)

-# Windows Cluster Support
+## Windows Cluster Support

 When deployed onto an RKE1 Windows cluster, Monitoring V2 will now automatically deploy a [windows-exporter](https://github.com/prometheus-community/windows_exporter) DaemonSet and set up a ServiceMonitor to collect metrics from each of the deployed Pods. This will populate Prometheus with `windows_` metrics that are akin to the `node_` metrics exported by [node_exporter](https://github.com/prometheus/node_exporter) for Linux hosts.

@@ -88,8 +87,7 @@ To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts
 For more details on how to upgrade wins on existing Windows hosts, refer to the section on [Windows cluster support for Monitoring V2.](../integrations-in-rancher/monitoring-and-alerting/windows-support.md)


-
-# Known Issues
+## Known Issues

 There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more default memory. If you are enabling monitoring on a K3s cluster, we recommend to setting `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.

@@ -6,17 +6,17 @@ This page captures some of the most important options for configuring Monitoring

 For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.

-# Setting Resource Limits and Requests
+## Setting Resource Limits and Requests

 The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)

-:::note
+:::tip

-On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
+On an idle cluster, Monitoring may have high CPU usage. To improve performance, turn off the Prometheus adapter.

 :::

-# Prometheus Configuration
+## Prometheus Configuration

 It is usually not necessary to directly edit the Prometheus custom resource.

@@ -31,7 +31,7 @@ For details, see [this page.](../reference-guides/monitoring-v2-configuration/se

 For more information about directly editing the Prometheus custom resource, which may be helpful in advanced use cases, see [this page.](../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheus.md)

-# Alertmanager Configuration
+## Alertmanager Configuration

 The Alertmanager custom resource usually doesn't need to be edited directly. For most common use cases, you can manage alerts by updating Routes and Receivers.

@@ -12,6 +12,6 @@ A Nutanix cluster may consist of multiple groups of VMs with distinct properties
 - [Creating a Nutanix Cluster](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix/provision-kubernetes-clusters-in-aos.md#creating-a-nutanix-aos-cluster)
 - [Provisioning Storage](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix/provision-kubernetes-clusters-in-aos)

-# Creating a Nutanix Cluster
+## Creating a Nutanix Cluster

 In [this section,](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix/provision-kubernetes-clusters-in-aos.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Nutanix AOS.
@@ -6,7 +6,7 @@ In a lot of enterprise environments, servers or VMs running on premise do not ha

 Alternatively, it is also possible to set up Rancher completely air-gapped without any Internet access. This process is described in detail in the [Rancher docs](air-gapped-helm-cli-install.md).

-# Installation Outline
+## Installation Outline

 1. [Set up infrastructure](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/set-up-infrastructure.md)
 2. [Set up a Kubernetes cluster](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md)
@@ -17,19 +17,19 @@ A Docker installation of Rancher is recommended only for development and testing

 The Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)

-### Privileged Access for Rancher
+## Privileged Access for Rancher

 When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.

-# Requirements for OS, Docker, Hardware, and Networking
+## Requirements for OS, Docker, Hardware, and Networking

 Make sure that your node fulfills the general [installation requirements.](installation-requirements.md)

-# 1. Provision Linux Host
+## 1. Provision Linux Host

 Provision a single Linux host according to our [Requirements](installation-requirements.md) to launch your Rancher server.

-# 2. Choose an SSL Option and Install Rancher
+## 2. Choose an SSL Option and Install Rancher

 For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.

@@ -40,9 +40,9 @@ These guides have been tested along with the Rancher v2.6 release. Each self-ass

 ### K3s Guides

-| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
-| ------------------ | --------------------- | --------------------- | ---------------- |
-| Kubernetes v1.21 and v1.22 | CIS v1.6 | [Link](https://rancher.com/docs/k3s/latest/en/security/self_assessment/) | [Link](https://rancher.com/docs/k3s/latest/en/security/hardening_guide/) |
+| 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

@@ -0,0 +1,52 @@
+---
+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)
@@ -9,7 +9,7 @@ To use this option you'll need access to servers you intend to use in your Kuber

 This section describes how to set up a custom cluster.

-# Creating a Cluster with Custom Nodes
+## Creating a Cluster with Custom Nodes

 :::note Want to use Windows hosts as Kubernetes workers?

@@ -17,7 +17,6 @@ See [Configuring Custom Clusters for Windows](use-windows-clusters.md) before yo

 :::

-
 ### 1. Provision a Linux Host

 Begin creation of a custom cluster by provisioning a Linux host. Your host can be:
@@ -130,7 +129,7 @@ If you share resources between clusters, you can change the tag to:
 Key=kubernetes.io/cluster/CLUSTERID, Value=shared
 ```

-# Optional Next Steps
+## Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:

@@ -242,7 +242,7 @@ spec:
  encryptionConfigSecretName: test-encryptionconfig
 ```

-# Example Credential Secret for Storing Backups in S3
+## Example Credential Secret for Storing Backups in S3

 ```yaml
 apiVersion: v1
@@ -255,7 +255,7 @@ data:
  secretKey: <Enter your base64-encoded secret key>
 ```

-# Example EncryptionConfiguration
+## Example EncryptionConfiguration

 The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.

@@ -13,7 +13,7 @@ This guide outlines a reference architecture for provisioning downstream Rancher

 ![Solution Overview](/img/solution_overview.drawio.svg)

-# 1. VM Considerations
+## 1. VM Considerations

 ### Leverage VM Templates to Construct the Environment

@@ -31,7 +31,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin

 It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node.

-# 2. Network Considerations
+## 2. Network Considerations

 ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes

@@ -41,13 +41,13 @@ Deploy etcd members within a single data center where possible to avoid latency

 Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated.

-# 3. Storage Considerations
+## 3. Storage Considerations

 ### Leverage SSD Drives for ETCD Nodes

 ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.

-# 4. Backups and Disaster Recovery
+## 4. Backups and Disaster Recovery

 ### Perform Regular Downstream Cluster Backups

@@ -2,7 +2,7 @@
 title: kubectl Utility
 ---

-# kubectl
+## kubectl

 Interact with Rancher using kubectl.

@@ -4,7 +4,7 @@ title: Architecture Recommendations

 If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)

-# Separation of Rancher and User Clusters
+## Separation of Rancher and User Clusters

 A user cluster is a downstream Kubernetes cluster that runs your apps and services.

@@ -14,7 +14,7 @@ If Rancher is intended to manage downstream Kubernetes clusters, the Kubernetes

 ![Separation of Rancher Server from User Clusters](/img/rancher-architecture-separation-of-rancher-server.svg)

-# Why HA is Better for Rancher in Production
+## Why HA is Better for Rancher in Production

 We recommend installing the Rancher server on a high-availability Kubernetes cluster, primarily because it protects the Rancher server data. In a high-availability installation, a load balancer serves as the single point of contact for clients, distributing network traffic across multiple servers in the cluster and helping to prevent any one server from becoming a point of failure.

@@ -36,7 +36,7 @@ In an RKE installation, the cluster data is replicated on each of three etcd nod

 ![Architecture of an RKE Kubernetes cluster running the Rancher management server](/img/rke-server-storage.svg)

-# Recommended Load Balancer Configuration for Kubernetes Installations
+## Recommended Load Balancer Configuration for Kubernetes Installations

 We recommend the following configurations for the load balancer and Ingress controllers:

@@ -49,13 +49,13 @@ We recommend the following configurations for the load balancer and Ingress cont

 ![Rancher HA](/img/ha/rancher2ha.svg)

-# Environment for Kubernetes Installations
+## Environment for Kubernetes Installations

 It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.

 For the best performance and greater security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for running your workloads.

-# Recommended Node Roles for Kubernetes Installations
+## Recommended Node Roles for Kubernetes Installations

 The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.

@@ -97,7 +97,7 @@ Because no additional workloads will be deployed on the Rancher server cluster,

 For more best practices for downstream clusters, refer to the [production checklist](../../pages-for-subheaders/checklist-for-production-ready-clusters.md) or our [best practices guide.](../../pages-for-subheaders/best-practices.md)

-# Architecture for an Authorized Cluster Endpoint (ACE)
+## Architecture for an Authorized Cluster Endpoint (ACE)

 If you are using an [authorized cluster endpoint (ACE),](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.

@@ -71,11 +71,11 @@ Like the authorized cluster endpoint, the `kube-api-auth` authentication service

 > **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.

-With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`. 
+With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.

 You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)

-# Important Files
+## Important Files

 The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:

@@ -87,7 +87,7 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your

 For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) documentation.

-# Tools for Provisioning Kubernetes Clusters
+## Tools for Provisioning Kubernetes Clusters

 The tools that Rancher uses to provision downstream user clusters depends on the type of cluster that is being provisioned.

@@ -113,7 +113,7 @@ Rancher provisions this type of cluster using [kontainer-engine.](https://github

 In this type of cluster, Rancher connects to a Kubernetes cluster that has already been set up. Therefore, Rancher does not provision Kubernetes, but only sets up the Rancher agents to communicate with the cluster.

-# Rancher Server Components and Source Code
+## Rancher Server Components and Source Code

 This diagram shows each component that the Rancher server is composed of:

@@ -0,0 +1,549 @@
+---
+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.
@@ -8,11 +8,11 @@ System Tools has been deprecated since June 2022.

 :::

-# Logs
+## Logs

 Please use [logs-collector](https://github.com/rancherlabs/support-tools/tree/master/collection/rancher/v2.x/logs-collector) to collect logs from your cluster.

-# Stats
+## Stats

 If you want to replicate the stats command, you can run the following command on your cluster nodes:

@@ -26,6 +26,6 @@ This command below requires the package `sysstat` on the cluster node.
 /usr/bin/sar -u -r -F 1 1
 ```

-# Remove
+## Remove

 Please use the [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) tool.
@@ -15,7 +15,7 @@
 | [Cleaning Kubernetes components when clusters are no longer reachable from Rancher](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) | ✓ | | | |
 | [Configuring Pod Security Policies](../how-to-guides/new-user-guides/manage-clusters/add-a-pod-security-policy.md) | ✓ | ✓ |  ||

-1. Registered GKE and EKS clusters have the same options available as GKE and EKS clusters created from the Rancher UI. The  difference is that when a registered cluster is deleted from the Rancher UI, it is not destroyed.
+1. Registered EKS, GKE and AKS clusters have the same options available as EKS, GKE and AKS clusters created from the Rancher UI. The  difference is that when a registered cluster is deleted from the Rancher UI, it is not destroyed.

 2. Cluster configuration options can't be edited for registered clusters, except for [K3s and RKE2 clusters.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)

@@ -4,7 +4,7 @@ title: Troubleshooting Controlplane Nodes

 This section applies to nodes with the `controlplane` role.

-# Check if the Controlplane Containers are Running
+## Check if the Controlplane Containers are Running

 There are three specific containers launched on nodes with the `controlplane` role:

@@ -26,7 +26,7 @@ f3d287ca4549        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."
 bdf3898b8063        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kube-controller-manager
 ```

-# Controlplane Container Logging
+## Controlplane Container Logging

 :::note

@@ -42,7 +42,7 @@ docker logs kube-controller-manager
 docker logs kube-scheduler
 ```

-# RKE2 Server Logging
+## RKE2 Server Logging

 If Rancher provisions an RKE2 cluster that can't communicate with Rancher, you can run this command on a server node in the downstream cluster to get the RKE2 server logs:

@@ -4,7 +4,7 @@ title: Troubleshooting nginx-proxy

 The `nginx-proxy` container is deployed on every node that does not have the `controlplane` role. It provides access to all the nodes with the `controlplane` role by dynamically generating the NGINX configuration based on available nodes with the `controlplane` role.

-# Check if the Container is Running
+## Check if the Container is Running

 The container is called `nginx-proxy` and should have status `Up`. The duration shown after `Up` is the time the container has been running.

@@ -20,7 +20,7 @@ CONTAINER ID        IMAGE                       COMMAND                  CREATED
 c3e933687c0e        rancher/rke-tools:v0.1.15   "nginx-proxy CP_HO..."   3 hours ago         Up 3 hours                              nginx-proxy
 ```

-# Check Generated NGINX Configuration
+## Check Generated NGINX Configuration

 The generated configuration should include the IP addresses of the nodes with the `controlplane` role. The configuration can be checked using the following command:

@@ -59,7 +59,7 @@ stream {
 }
 ```

-# nginx-proxy Container Logging
+## nginx-proxy Container Logging

 The logging of the containers can contain information on what the problem could be.

@@ -4,7 +4,7 @@ title: Troubleshooting Worker Nodes and Generic Components

 This section applies to every node as it includes components that run on nodes with any role.

-# Check if the Containers are Running
+## Check if the Containers are Running

 There are two specific containers launched on nodes with the `worker` role:

@@ -24,7 +24,7 @@ CONTAINER ID        IMAGE                                COMMAND
 a30717ecfb55        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."   3 hours ago         Up 3 hours                              kubelet
 ```

-# Container Logging
+## Container Logging

 The logging of the containers can contain information on what the problem could be.

@@ -107,10 +107,11 @@ module.exports = {
            current: {
              label: 'v2.7'
            },
-            // 2.6: {
-            //   label: 'v2.6',
-            //   path: 'v2.6'
-            // },
+            2.6: {
+              label: 'v2.6',
+              path: 'v2.6',
+              banner: 'none'
+            },
            2.5: {
              label: 'v2.5',
              path: 'v2.5'
@@ -579,10 +580,6 @@ module.exports = {
            to: '/integrations-in-rancher/logging/logging-architecture',
            from: '/explanations/integrations-in-rancher/logging/logging-architecture'
          },
-          {
-            to: '/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging',
-            from: '/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging'
-          },
          {
            to: '/integrations-in-rancher/logging/rbac-for-logging',
            from: '/explanations/integrations-in-rancher/logging/rbac-for-logging'
@@ -26,7 +26,7 @@ Harvester 已 GA。有关所有更新，请参阅 [Harvester 发行说明](https

 ### Harvester 主机驱动

-在 Rancher 的 RKE 和 RKE2 选项中，[Harvester 主机驱动](https://docs.harvesterhci.io/v0.3/rancher/node-driver/)被标记为`技术预览`。在**创建**页面和启用驱动后的页面都是一样的情况。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
+从 Rancher v2.6.3 开始，[Harvester 主机驱动](https://docs.harvesterhci.io/v0.3/rancher/node-driver/) 已在 Rancher 的 RKE 和 RKE2 选项中 GA。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。

 Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像，但 Rancher UI 不支持。这是因为 `.ISO` 镜像通常需要额外的设置，这会干扰干净的部署（即无需用户干预），并且它们通常不用于云环境。

@@ -103,3 +103,9 @@ Rancher 依赖用户和组来决定允许登录到 Rancher 的用户，以及他
   ![Sign In External Principal](/img/users-page.png)

 6. 外部主体和本地主体共享相同的访问权限。
+
+:::note 重新配置以前设置的身份验证提供程序
+
+如果你需要重新配置或禁用以前设置的提供程序然后再重新启用它，请确保进行此操作的用户使用外部用户身份登录 Rancher，而不是本地管理员。
+
+:::
@@ -0,0 +1,6 @@
+---
+title: 备份和恢复 Docker 安装的 Rancher
+---
+
+- [备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
+- [还原](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
@@ -0,0 +1,5 @@
+---
+title: RKE 集群配置
+---
+
+本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
@@ -0,0 +1,136 @@
+---
+title: 参与 Rancher 社区贡献
+---
+
+本节介绍 Rancher 使用的仓库、如何构建仓库以及提交 issue 时要包含的信息。
+
+有关如何为 Rancher 项目开发做出贡献的更多详细信息，请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源：
+
+- 如何搭建 Rancher 开发环境并运行测试
+- Issue 在开发生命周期中的典型流程
+- 编码指南和开发最佳实践
+- 调试和故障排除
+- 开发 Rancher API
+
+在 Rancher Users Slack 上，开发者的频道是 **#developer**。
+
+## 仓库
+
+所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库，以下是部分主要仓库的描述：
+
+| 仓库 | URL | 描述 |
+-----------|-----|-------------
+| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
+| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
+| API Framework | https://github.com/rancher/norman | API 框架，用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
+| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
+| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
+| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
+| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库，它是配置托管 Kubernetes 集群的工具。 |
+| RKE repository | https://github.com/rancher/rke | Rancher Kubernetes Engine 的源码仓库，该工具可在任何主机上配置 Kubernetes 集群。 |
+| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
+| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
+| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
+| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库，用于动态更改日志级别。 |
+
+要查看 Rancher 使用的所有库/项目，请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
+
+![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)<br/>
+<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
+
+## 构建
+
+每个仓库都应该有一个 Makefile，并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本，每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作，它包含了所需的所有构建工具。
+
+默认目标是 `ci`，它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中，通常也打包在 Docker 镜像中。
+
+## Bug、Issue 和疑问
+
+如果你发现任何 bug 或问题，由于有人可能遇到过同样的问题，或者我们已经正在寻找解决方案，因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
+
+如果找不到与你的问题相关的内容，请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多，但请将 issue 提交到 Rancher 仓库中，这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户，你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
+
+### 提交 Issue 的检查清单
+
+提交问题时请遵循此清单，以便我们调查和解决问题。如果你能提供更多信息，我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
+
+:::note
+
+如果数据量很大，请使用 [GitHub Gist](https://gist.github.com/) 或类似工具，并在 issue 中链接你创建的资源。
+
+:::
+
+:::note 重要提示：
+
+请删除所有敏感数据。
+
+:::
+
+- **资源**：请尽量详细地提供所使用的资源。导致问题的原因可能很多，因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例：
+   - **主机**：主机的规格（例如 CPU/内存/磁盘），运行在什么云厂商上，使用的 Amazon Machine Image，使用的 DigitalOcean droplet，配置的镜像（复现时用于重新构建或使用）。
+   - **操作系统**：使用的是什么操作系统。在此处提供详细信息，例如 `cat /etc/os-release` 的输出（确切的操作系统版本）和 `uname -r` 的输出（确切的内核）。
+   - **Docker**：使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
+   - **环境**：是否使用了代理，是否使用可信的 CA/自签名证书，是否使用了外部负载均衡器。
+   - **Rancher**：使用的 Rancher 版本，可以在 UI 左下角或者从主机运行的 image 标签中获取。
+   - **集群**：创建了什么样的集群，如何创建的，在创建时指定了什么参数。
+- **复现 issue 的步骤**：尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
+   - 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
+- **日志**：提供使用资源的数据/日志。
+   - Rancher
+      - Docker 安装
+
+      ```
+      docker logs \
+      --timestamps \
+      $(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
+      ```
+      - 使用 `kubectl` 的 Kubernetes 安装
+
+      :::note
+
+      确保你配置了正确的 kubeconfig（例如，如果 Rancher 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
+
+      :::
+
+      ```
+      kubectl -n cattle-system \
+      logs \
+      -l app=rancher \
+      --timestamps=true
+      ```
+      - 在 RKE 集群的每个节点上使用 `docker` 的 Docker 安装
+
+      ```
+      docker logs \
+      --timestamps \
+      $(docker ps | grep -E "rancher/rancher@|rancher_rancher" | awk '{ print $1 }')
+      ```
+      - 使用 RKE 附加组件的 Kubernetes 安装
+
+      :::note
+
+      确保你配置了正确的 kubeconfig（例如，如果 Rancher Server 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
+
+      :::
+
+      ```
+      kubectl -n cattle-system \
+      logs \
+      --timestamps=true \
+      -f $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name="cattle-server") | .metadata.name')
+      ```
+   - 系统日志记录（可能不存在，取决于操作系统）
+      - `/var/log/messages`
+      - `/var/log/syslog`
+      - `/var/log/kern.log`
+   - Docker Daemon 日志记录（可能并不全部存在，取决于操作系统）
+      - `/var/log/docker.log`
+- **指标**：如果你遇到性能问题，请提供尽可能多的指标数据（文件或屏幕截图）来帮助我们确定问题。如果你遇到主机相关的问题，你可以提供 `top`、`free -m`、`df` 的输出，这些输出会显示进程/内存/磁盘的使用情况。
+
+## 文档
+
+如果你对我们的文档有修改意见，请在我们的文档仓库中提交 PR。
+
+- [Rancher 2.x 文档仓库](https://github.com/rancher/docs)：Rancher 2.x 所有文档都在这个仓库中。具体位于仓库的 `content` 文件夹中。
+
+- [Rancher 1.x 文档仓库](https://github.com/rancher/rancher.github.io)：Rancher 1.x 所有文档都在这个仓库中。具体位于仓库的 `rancher` 文件夹中。
@@ -0,0 +1,204 @@
+---
+title: CNI 网络插件
+description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能，以及如何选择网络提供商
+---
+
+## 什么是 CNI？
+
+CNI（容器网络接口）是一个[云原生计算基金会项目](https://cncf.io/)，它包含了一些规范和库，用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接，并在容器被删除时移除所分配的资源。
+
+Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
+
+![CNI Logo](/img/cni-logo.png)
+
+有关更多信息，请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
+
+## CNI 使用了哪些网络模型？
+
+CNI 网络插件使用封装网络模型（例如 Virtual Extensible Lan，缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)）或非封装网络模型（例如 Border Gateway Protocol，缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)）来实现网络结构。
+
+### 什么是封装网络？
+
+此网络模型提供了一个逻辑二层（L2）网络，该网络封装在跨 Kubernetes 集群节点的现有三层（L3）网络拓扑上。使用此模型，你可以为容器提供一个隔离的 L2 网络，而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发，交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
+
+简单来说，这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥，其中连接了 pod。
+
+如果你偏向使用扩展 L2 网桥，则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置，请确保它们之间的延迟较低，以避免最终的网络分段。
+
+使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下，Calico 不会使用此模型，但你可以对其进行配置。
+
+![封装网络](/img/encapsulated-network.png)
+
+### 什么是非封装网络？
+
+该网络模型提供了一个 L3 网络，用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络，也不会产生开销。这些好处的代价是，Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装，而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接，例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
+
+简而言之，这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器，提供了如何连接 Pod 的信息。
+
+如果你偏向使用 L3 网络，则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
+
+使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置，即使这不是默认模式。
+
+![非封装网络](/img/unencapsulated-network.png)
+
+## Rancher 提供哪些 CNI 插件？
+
+### RKE Kubernetes 集群
+
+Rancher 开箱即用地为 RKE Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。
+
+如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
+
+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal 是一个 CNI 网络插件，它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案，将 Calico 的网络策略执行与 Calico（未封装）和 Flannel（封装）丰富的网络连接选项结合起来。
+
+Canal 是 Rancher 默认的 CNI 网络插件，并采用了 Flannel 和 VXLAN 封装。
+
+Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`（健康检查）。如果使用 Wireguard，则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
+
+![](/img/canal-diagram.png)
+
+有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
+
+#### Flannel
+
+![Flannel Logo](/img/flannel-logo.png)
+
+Flannel 是为 Kubernetes 配置 L3 网络结构的简单方法。Flannel 在每台主机上运行一个名为 flanneld 的二进制 Agent，该 Agent 负责从更大的预配置地址空间中为每台主机分配子网租约。Flannel 通过 Kubernetes API 或直接使用 etcd 来存储网络配置、分配的子网、以及其他辅助数据（例如主机的公共 IP）。数据包使用某种后端机制来转发，默认封装为 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)。
+
+默认情况下，封装的流量是不加密的。Flannel 提供了两种加密方案：
+
+* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec)：使用 [strongSwan](https://www.strongswan.org/) 在 Kubernetes worker 之间建立加密的 IPSec 隧道。它是加密的实验性后端。
+* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard)：比 strongSwan 更快的替代方案。
+
+Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN)。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
+
+![Flannel Diagram](/img/flannel-diagram.png)
+
+有关详细信息，请参阅 [Flannel GitHub 页面](https://github.com/flannel-io/flannel)。
+
+#### Weave
+
+![Weave Logo](/img/weave-logo.png)
+
+Weave 在云上的 Kubernetes 集群中启用网络和网络策略。此外，它还支持加密对等节点之间的流量。
+
+Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口 `6783` 和 UDP 端口 `6784`（数据端口）。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
+
+有关详细信息，请参阅以下页面：
+
+- [Weave Net 官网](https://www.weave.works/)
+
+### RKE2 Kubernetes 集群
+
+Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件，分别是 [Canal](#canal)（见上一节）、Calico 和 Cilium。
+
+如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下，Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
+
+Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要，你可以使用它。Calico 还支持策略隔离，让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
+
+如果使用 BGP，Kubernetes Worker 需要打开 TCP 端口 `179`，如果使用 VXLAN 封装，则需要打开 UDP 端口 `4789`。另外，使用 Typha 时需要 TCP 端口 `5473`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
+
+:::note 重要提示：
+
+在 Rancher 2.6.3 中，Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意，此问题已在 v2.6.4 中解决。</b>
+
+- 要解决此问题，请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
+
+- 在那里，将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
+
+:::
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+有关详细信息，请参阅以下页面：
+
+- [Project Calico 官方网站](https://www.projectcalico.org/)
+- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
+
+#### Cilium
+
+![Cilium Logo](/img/cilium-logo.png)
+
+Cilium 在 Kubernetes 中启用网络和网络策略（L3、L4 和 L7）。默认情况下，Cilium 使用 eBPF 技术在节点内部路由数据包，并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
+
+Cilium 推荐大于 5.2 的内核版本，从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`（VXLAN）和 TCP 端口 `4240`（健康检查）。此外，还必须为健康检查启用 ICMP 8/0。有关详细信息，请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
+
+##### Cilium 中跨节点的 Ingress 路由
+<br/>
+默认情况下，Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题，请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
+
+选择 Cilium CNI 并为新集群启用项目网络隔离后，配置如下：
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {}
+  ingress:
+    - fromEntities:
+      - remote-node
+```
+
+## 各个网络插件的 CNI 功能
+
+下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能：
+
+| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
+| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
+| Calico | 封装（VXLAN，IPIP）或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
+| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+
+- 网络模型：封装或未封装。如需更多信息，请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
+
+- 路由分发：一种外部网关协议，用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的，并且通常由 BGP 完成。如果你想构建跨网段拆分的集群，路由分发是一个很好的功能。
+
+- 网络策略：Kubernetes 提供了强制执行规则的功能，这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能，可以与某些网络插件一起使用。
+
+- 网格：允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
+
+- 外部数据存储：具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
+
+- 加密：允许加密和安全的网络控制和数据平面。
+
+- Ingress/Egress 策略：允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
+
+
+## CNI 社区人气
+
+下表总结了不同的 GitHub 指标，让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
+
+| 提供商 | 项目 | Stars | Forks | Contributors |
+| ---- | ---- | ---- | ---- | ---- |
+| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
+| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
+| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
+| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
+| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
+
+<br/>
+
+## 使用哪个 CNI 插件？
+
+这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
+
+Canal 是默认的 CNI 网络插件。对于大多数用例，我们推荐你使用它。它使用 Flannel 为容器提供封装网络，同时添加 Calico 网络策略，可以在网络方面提供项目/命名空间隔离。
+
+## 如何配置 CNI 网络插件？
+
+如需了解如何为你的集群配置网络插件，请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项，请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。
@@ -0,0 +1,26 @@
+---
+title: Rancher 弃用的功能
+---
+
+### Rancher 的弃用策略是什么？
+
+我们在支持[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方弃用策略。
+
+### 在哪里可以找到 Rancher 已弃用的功能？
+
+Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/releases)中公布已弃用的功能。请参阅以下补丁版本了解已弃用的功能：
+
+| 补丁版本 | 发布日期 |
+|---------------|---------------|
+| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | 2021 年 8 月 31 日 |
+| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | 2021 年 10 月 11 日 |
+| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | 2021 年 10 月 19 日 |
+| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | 2021 年 12 月 21 日 |
+| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | 2022 年 3 月 31 日 |
+| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | 2022 年 5 月 12 日 |
+| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | 2022 年 6 月 30 日 |
+
+
+### 如果某个功能标记为弃用，我要怎么做？
+
+如果某个发行版将某功能标记为"Deprecated"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
@@ -0,0 +1,45 @@
+---
+title: Dockershim
+---
+
+Dockershim 是 Kubelet 和 Docker Daemon 之间的 CRI 兼容层。Kubernetes 1.20 版本宣布了[移除树内 Dockershim](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。目前计划在 Kubernetes 1.24 中移除。有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
+
+从 Kubernetes 1.21 开始。RKE 集群支持外部 Dockershim，来让用户继续使用 Docker 作为 CRI 运行时。现在，我们通过使用 [Mirantis 和 Docker ](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) 来确保 RKE 集群可以继续使用 Docker，从而实现上游开源社区的 Dockershim。
+
+要启用外部 Dockershim，配置以下选项：
+
+```
+enable_cri_dockerd: true
+```
+
+如果你想使用其他容器运行时，Rancher 也提供使用 Containerd 作为默认运行时的，以边缘为中心的 K3s，和以数据中心为中心的 RKE2 Kubernetes 发行版。即使在 Kubernetes 1.24 删除了树内 Dockershim 之后，你也可以通过 Rancher 升级和管理导入的 RKE2 和 K3s Kubernetes 集群。
+
+### 常见问题
+
+<br/>
+
+Q. 如果要获得 Rancher 对上游 Dockershim 的支持，我需要升级 Rancher 吗？
+
+对于 RKE，Dockershim 的上游支持从 Kubernetes 1.21 开始。你需要使用 Rancher 2.6 或更高版本才能获取使用 Kubernetes 1.21 的 RKE 的支持。详情请参阅我们的[支持矩阵](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。
+
+<br/>
+
+Q. 我目前的 RKE 使用 Kubernetes 1.20。为了避免出现不再支持 Dockershim 的情况，我是否需要尽早将 RKE 升级到 Kubernetes 1.21？
+
+A. 在使用 Kubernetes 1.20 的 RKE 中，Dockershim 版本依然可用，而且在 Kubernetes 1.24 之前不会在上游弃用。Kubernetes 会发出弃用 Dockershim 的警告，而 Rancher 在使用 Kubernetes 1.21 的 RKE 中已经缓解了这个问题。你可以按照计划正常升级到 Kubernetes 1.21，但也应该考虑在升级到 Kubernetes 1.22 时启用外部 Dockershim。在升级到 Kubernetes 1.24 之前，你需要启用外部 Dockershim，此时现有的实现都会被删除。
+
+有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
+
+<br/>
+
+Q: 如果我不想再依赖 Dockershim，我还有什么选择？
+
+A: 你可以为 Kubernetes 使用不需要 Dockershim 支持的运行时，如 Containerd。RKE2 和 K3s 就是其中的两个选项。
+
+<br/>
+
+Q: 如果我目前使用 RKE1，但想切换到 RKE2，我可以怎样进行迁移？
+
+A: Rancher 也在探索就地升级路径的可能性。此外，你始终可以使用 kubectl 将工作负载迁移到另一个集群。
+
+<br/>
@@ -0,0 +1,69 @@
+---
+title: 一般常见问题解答
+---
+
+本文包含了用户常见的 Rancher 2.x 问题。
+
+有关常见技术问题，请参阅[常见技术问题解答](technical-items.md)。
+
+<br/>
+
+**Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？**
+
+如果你在 Rancher 2.x 中创建环境，Swarm 和 Mesos 将不再是可选的标准选项。但是，Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定，但这是大势所趋。比如说，15,000 多个集群可能只有大约 200 个在运行 Swarm。
+
+<br/>
+
+**是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？**
+
+是的。
+
+<br/>
+
+**Rancher 是否支持 Windows？**
+
+从 Rancher 2.3.0 开始，我们支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
+
+<br/>
+
+**Rancher 是否支持 Istio？**
+
+从 Rancher 2.3.0 开始，我们支持 [Istio.](../pages-for-subheaders/istio.md)
+
+此外，Istio 是在我们的微型 PaaS “Rio” 中实现的，它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
+
+<br/>
+
+**Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？**
+
+密文管理已在我们的 roadmap 上，但我们尚未将该功能分配给特定版本。
+
+<br/>
+
+**Rancher 2.x 是否也支持 RKT 容器？**
+
+目前，我们只支持 Docker。
+
+<br/>
+
+**Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？**
+
+Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息，请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
+
+<br/>
+
+**Rancher 是否计划支持 Traefik？**
+
+目前，我们不打算提供嵌入式 Traefik 支持，但我们仍在探索负载均衡方案。
+
+<br/>
+
+**我可以将 OpenShift Kubernetes 集群导入 2.x 吗？**
+
+我们的目标是运行任何上游 Kubernetes 集群。因此，Rancher 2.x 应该可以与 OpenShift 一起使用，但我们尚未对此进行测试。
+
+<br/>
+
+**Rancher 会集成 Longhorn 吗？**
+
+是的。Longhorn 已集成到 Rancher 2.5+ 中。
@@ -0,0 +1,29 @@
+---
+title: 安装和配置 kubectl
+---
+
+`kubectl` 是一个 CLI 工具，用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
+
+### 安装
+
+请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
+
+### 配置
+
+使用 RKE 创建 Kubernetes 集群时，RKE 会在本地目录中创建一个 `kube_config_cluster.yml`，该文件包含使用 `kubectl` 或 `helm` 等工具连接到新集群的凭证。
+
+你可以将此文件复制为 `$HOME/.kube/config`。如果你使用多个 Kubernetes 集群，将 `KUBECONFIG` 环境变量设置为 `kube_config_cluster.yml` 的路径：
+
+```
+export KUBECONFIG=$(pwd)/kube_config_cluster.yml
+```
+
+使用 `kubectl` 测试你的连接性，并查看你是否可以获取节点列表：
+
+```
+kubectl get nodes
+ NAME                          STATUS    ROLES                      AGE       VERSION
+165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.116.167               Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.127.226               Ready     controlplane,etcd,worker   11m       v1.10.1
+```
--- a/Show More
+++ b/Show More