Merge pull request #2017 from sunilarjun/update-cve-sept25

Updating CVEs for September maintenance
Merge pull request #2016 from rancher/v2.12.2
2026-09-29 14:38:50 +00:00 · 2025-09-25 13:14:13 -07:00 · 2025-09-25 13:12:11 -07:00 · 2025-09-25 13:11:53 -07:00 · 2025-09-25 13:11:40 -07:00 · 2025-09-25 13:11:15 -07:00
990 changed files with 16249 additions and 270634 deletions
@@ -6,10 +6,13 @@ title: '<VERSION> - Rancher Manager Release Maintenance Task Checklist'

 This issue is to track tasks that need to be done every release regardless of whether the release has new feature content or not.

+- [ ] Create a new branch for the release. Release-specific updates should use this branch as its base
 - [ ] Update the [versions table](https://ranchermanager.docs.rancher.com/versions)
 - [ ] Update the [Rancher:webhook version mapping table](https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook)
 - [ ] Update the [CNI popularity table](https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers#cni-community-popularity)
- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix):
- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features):
+- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix)
+- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features)
+- [ ] Update the swagger-<VERSION>.json file
+- [ ] Create a PR merging the release branch back into the main branch
 - [ ] Create a new [release](https://github.com/rancher/rancher-docs/releases)
 - [ ] Update Algolia search index
@@ -4,8 +4,6 @@ on:
  pull_request_target:
    types:
      - closed
-    branches: 
-      - main
    paths-ignore:
      - '**/README.md'

@@ -25,7 +25,7 @@ jobs:
        run: yarn install --frozen-lockfile
      - name: Build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
+          NODE_OPTIONS: "--max_old_space_size=8192"
        run: yarn build --no-minify

      - name: Upload Build Artifact
@@ -15,7 +15,7 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t

 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).

-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of July 2025, the most recently released version of Rancher is 2.12.

 Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.

@@ -20,7 +20,7 @@ For information about how Fleet works, see [this page.](../../../integrations-in

 ## Accessing Fleet in the Rancher UI

-Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
+Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).

 Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.

@@ -26,7 +26,7 @@ Users can leverage continuous delivery to deploy their applications to the Kuber

 Follow the steps below to access Continuous Delivery in the Rancher UI:

-1. Click **☰ > Continous Delivery**.
+1. Click **☰ > Continuous Delivery**.

 1. Select your namespace at the top of the menu, noting the following:

@@ -40,4 +40,3 @@ However, metrics-driven capacity planning analysis should be the ultimate guidan
 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, and Grafana, which lets you visualize the metrics from Prometheus.

 After you [enable monitoring](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md) in the cluster, you can set up alerts to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
-
@@ -26,7 +26,7 @@ Users can leverage continuous delivery to deploy their applications to the Kuber

 Follow the steps below to access Continuous Delivery in the Rancher UI:

-1. Click **☰ > Continous Delivery**.
+1. Click **☰ > Continuous Delivery**.

 1. Select your namespace at the top of the menu, noting the following:

@@ -10,7 +10,7 @@ This guide contains our recommendations for running the Rancher server, and is i

 ### Recommended Architecture and Infrastructure

-Refer to this [guide](tips-for-running-rancher.md) for our general advice for setting up the Rancher server on a high-availability Kubernetes cluster.
+Refer to this [guide](tips-for-running-rancher.md) for our general advice for setting up the Rancher server for a production installation.

 ### Deployment Strategies

@@ -14,8 +14,42 @@ If you are installing Rancher in a vSphere environment, refer to the best practi

 When you set up your high-availability Rancher installation, consider the following:

-### Run Rancher on a Separate Cluster
-Don't run other workloads or microservices in the Kubernetes cluster that Rancher is installed on.
+### Minimize Third-Party Software on the Upstream Cluster
+
+We generally recommend running Rancher on a dedicated cluster, free of other workloads, to avoid potential performance and compatibility issues.
+
+Rancher, especially when managing a growing number of clusters, nodes, and workloads, places a significant load on core Kubernetes components like `etcd` and `kube-apiserver` on the upstream cluster. Third-party software can interfere with the performance of these components and Rancher, potentially leading to instability.
+
+Furthermore, third-party software can functionally interfere with Rancher. To minimize compatibility risks, deploy only essential Kubernetes system components and Rancher on the upstream cluster.
+
+The following applications and components generally do not interfere with Rancher or the Kubernetes system:
+ * Rancher internal components, such as Fleet
+ * Rancher extensions
+ * Cluster API components
+ * CNIs, CPIs, CSIs
+ * Cloud controller managers
+ * Observability and monitoring tools (except prometheus-rancher-exporter)
+
+Note that each of these components has its own minimum resource requirements, which must be met in addition to Rancher's. For high-scale deployments, also consider dedicating separate nodes to non-Rancher software using [taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) to minimize interference.
+
+The following software can interfere with Rancher performance and is therefore discouraged on the upstream cluster:
+ * [CrossPlane](https://www.crossplane.io/)
+ * [Argo CD](https://argoproj.github.io/cd/)
+ * [Flux](https://fluxcd.io/)
+ * [prometheus-rancher-exporter](https://github.com/David-VTUK/prometheus-rancher-exporter) (see [issue 33](https://github.com/David-VTUK/prometheus-rancher-exporter/issues/33))
+ * Container registries such as [Harbor](https://goharbor.io/), which can require significant bandwidth for serving images
+
+### Guidance for Container Registries
+
+Container registries, such as [Harbor](https://goharbor.io/), can consume significant network bandwidth when serving images. This demand increases with the number of images, the frequency of image pulls, and the quantity of clusters and container runtimes they serve. Due to this potential for interference with Rancher UI and API traffic, we recommend against running container registries on the same cluster as the Rancher management server.
+
+Regardless of your deployment strategy for a container registry, ensure sufficient bandwidth is available, ideally reserved using Quality of Service (QoS) mechanisms.
+
+Consider the following recommendations based on your needs:
+
+* **Simple Setups (HA Not a Primary Concern):** A container registry deployed as a single Virtual Machine (VM) can be a viable solution.
+* **High Availability (HA) Requirements:** We recommend running the registry in a dedicated Kubernetes cluster. All other clusters should then be configured to pull images from this centralized, HA registry.
+* **Very Large-Scale or Complex Network Topologies:** Multiple registry clusters might be necessary. These can be deployed in a hierarchical or federated model to efficiently distribute images and manage traffic.

 ### Make sure nodes are configured correctly for Kubernetes
 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, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.5/op-guide/performance/).
@@ -37,4 +71,3 @@ However, metrics-driven capacity planning analysis should be the ultimate guidan
 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, and Grafana, which lets you visualize the metrics from Prometheus.

 After you [enable monitoring](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md) in the cluster, you can set up alerts to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
-
@@ -23,23 +23,7 @@ When scaling up Rancher, one typical bottleneck is resource growth in the upstre

 ### Minimizing Third-Party Software on the Upstream Cluster

-Running Rancher at scale can put significant load on internal Kubernetes components, such as `etcd` or `kubeapiserver`. Issues may arise if third-party software interferes with the performance of those components or with Rancher.
-
-Every third-party piece of software carries a risk of interference. To prevent performance issues on the upstream cluster, you should avoid running any other apps or components, beyond Kubernetes system components and Rancher itself.
-
-Software in the following categories generally won't interfere with Rancher or Kubernetes system performance:
- * Rancher internal components, such as Fleet
- * Rancher extensions
- * Cluster API components
- * CNIs
- * Cloud controller managers
- * Observability and monitoring tools (with the exception of prometheus-rancher-exporter)
-
-On the other hand, the following software are found to interfere with Rancher performance at scale:
- * [CrossPlane](https://www.crossplane.io/)
- * [Argo CD](https://argoproj.github.io/cd/)
- * [Flux](https://fluxcd.io/)
- * [prometheus-rancher-exporter](https://github.com/David-VTUK/prometheus-rancher-exporter) (see [issue 33](https://github.com/David-VTUK/prometheus-rancher-exporter/issues/33))
+Recommendations outlined in the [general Rancher recommendations](./tips-for-running-rancher.md#minimize-third-party-software-on-the-upstream-cluster) are particularly important in a high scale context.

 ### Managing Your Object Counts

@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api-v2-11" />
+<ApiDocMdx id="rancher-api-v2-12" />
@@ -8,8 +8,13 @@ title: Extension API Server

 Rancher extends Kubernetes with additional APIs by registering an extension API server using the [Kubernetes API Aggregation Layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).

-## Disabling the extension API server
+## Aggregation Layer is Required

-The [aggregation layer must be configured](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) on the local Kubernetes cluster for the `imperative-api-extension` feature to be enabled and to work correctly. The feature assumes this is configured and is enabled by default. If it is not possible to configure the aggregation layer for your local Kubernetes cluster, then you must disable the feature. The `imperative-api-extension` feature flag can be disabled by either using the [Rancher UI](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-ui) or [Rancher API](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-api).
+The API aggregation layer must be configured on the local Kubernetes cluster for the `v1.ext.cattle.io` `APIService` to work correctly. If the `APIService` does not receive a registration request after the Rancher server starts, the pod will crash with a log entry indicating the error. If your pods are consistently failing to detect registration despite having a correctly configured cluster, you can increase the timeout by setting the `.Values.aggregationRegistrationTimeout` in Helm.

-It will still be possible to access the additional APIs when the feature is disabled. The additional APIs are available at `https://<rancher url>/ext` and they are compatible with the Kubernetes apiserver. This means you can use `curl` or `kubectl` to interact with the APIs.
+All versions of Kubernetes supported in this Rancher versions K8s distributions (RKE2/K3s) will have the aggregation layer configured and enabled by default. However, if you suspect that your cluster configuration is incorrect, refer to the [Kubernetes Aggregation Layer documentation](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) for information on configuring the aggregation layer.
+
+
+:::note
+If the underlying Kubernetes distribution does not support the aggregation layer, you must migrate to a Kubernetes distribution that does before upgrading.
+:::
@@ -72,7 +72,7 @@ API responses are paginated with a limit of 100 resources per page by default. T

 ## Capturing v3 API Calls

-You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster:
+You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning a Rancher Kubernetes distribution cluster:

 1. In the Rancher UI, go to **Cluster Management** and click **Create.**
 1. Click one of the cluster types. This example uses Digital Ocean.
@@ -0,0 +1,205 @@
+---
+title: Kubeconfigs
+---
+
+<head>
+    <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/kubeconfigs"/>
+</head>
+
+## Kubeconfig Resource
+
+Kubeconfig is a Rancher resource `kubeconfigs.ext.cattle.io` that allows generating `v1.Config` kubeconfig files for interacting with Rancher and clusters managed by Rancher.
+
+```sh
+kubectl api-resources --api-group=ext.cattle.io
+```
+
+To get a description of the fields and structure of the Kubeconfig resource, run:
+
+```sh
+kubectl explain kubeconfigs.ext.cattle.io
+```
+
+## Feature Flag
+
+The Kubeconfigs Public API is available since Rancher v2.12.0 and is enabled by default. It can be disabled by setting the `ext-kubeconfigs` feature flag to `false`.
+
+```sh
+kubectl patch feature ext-kubeconfigs -p '{"spec":{"value":false}}'
+```
+
+## Creating a Kubeconfig
+
+Only a **valid and active** Rancher user can create a Kubeconfig. For example, trying to create a Kubeconfig using a `system:admin` service account will lead to an error:
+
+```bash
+kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: Kubeconfig
+EOF
+Error from server (Forbidden): error when creating "STDIN": kubeconfigs.ext.cattle.io is forbidden: user system:admin is not a Rancher user
+```
+
+:::warning Important
+
+The kubeconfig content is generated and returned in the `.status.value` field **only once** when the Kubeconfig is successfully created because it contains secret values for created tokens. Therefore it has to be captured by using an appropriate output option, such as `-o jsonpath='{.status.value}'`, or `-o yaml`.
+
+:::
+
+A kubeconfig can be created for more than one cluster at a time by specifying a list of cluster names in the `spec.clusters` field. You can look up cluster names by listing `clusters.management.cattle.io` resources.
+
+```sh
+kubectl get clusters.management.cattle.io -o=jsonpath="{.items[*]['metadata.name', 'spec.displayName']}{'\n'}"
+local local
+c-m-p66cdvlj downstream1
+```
+
+The `metadata.name` and `metadata.generateName` fields are ignored, and the name of the new Kubeconfig is automatically generated using the prefix `kubeconfig-`.
+
+You can use the `spec.currentContext` field to set the cluster name, and it is used to set the current context in the kubeconfig. If you do not set the `spec.currentContext` field, then the first cluster in the `spec.clusters` list will be used as the current context. For ACE-enabled clusters that don't have an FQDN set, the first control plane node will be used as the current context.
+
+For ACE-enabled clusters, if the FQDN is set, then that will be used as a cluster entry in the kubeconfig; otherwise, entries for all control plane nodes will be created.
+
+```bash
+kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: Kubeconfig
+spec:
+  clusters: [c-m-p66cdvlj, c-m-fcd3g5h]
+  description: My Kubeconfig
+  currentContext: c-m-p66cdvlj
+EOF
+```
+
+If `"*"` is specified as the first item in the `spec.clusters` field, the kubeconfig will be created for all clusters that the user has access to, if any.
+
+```bash
+kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: Kubeconfig
+spec:
+  clusters: ["*"]
+  description: My Kubeconfig
+EOF
+```
+
+If `spec.ttl` is not specified, the Kubeconfig's tokens will be created with the expiration time defined in the `kubeconfig-default-token-ttl-minutes` setting, which is 30 days by default. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `kubeconfig-default-token-ttl-minutes` setting expressed in seconds.
+
+```bash
+kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: Kubeconfig
+spec:
+  clusters: [c-m-p66cdvlj] # Downstream cluster
+  ttl: 7200 # 2 hours
+EOF
+```
+
+## Listing Kubeconfigs
+
+Listing previously generated Kubeconfigs can be useful for cleaning up backing tokens if the Kubeconfig is no longer needed (e.g., it was issued temporarily). Admins can list all Kubeconfigs, while regular users can only view their own.
+
+```sh
+kubectl get kubeconfig
+NAME               TTL   TOKENS   STATUS     AGE
+kubeconfig-zp786   30d   2/2      Complete   18d
+kubeconfig-7zvzp   30d   1/1      Complete   12d
+kubeconfig-jznml   30d   1/1      Complete   12d
+```
+Use `-o wide` to get more details:
+
+```sh
+kubectl get kubeconfig -o wide
+NAME               TTL   TOKENS   STATUS     AGE     USER         CLUSTERS       DESCRIPTION
+kubeconfig-zp786   30d   2/2      Complete   18d     user-w5gcf   *              all clusters
+kubeconfig-7zvzp   30d   1/1      Complete   12d     u-w7drc      *
+kubeconfig-jznml   30d   1/1      Complete   12d     u-w7drc      *
+```
+
+## Viewing a Kubeconfig
+
+Admins can get any Kubeconfig, while regular users can only get their own.
+
+```sh
+kubectl get kubeconfig kubeconfig-zp786
+NAME               TTL   TOKENS   STATUS     AGE
+kubeconfig-zp786   30d   2/2      Complete   18d
+```
+
+Use `-o wide` to get more details:
+
+```sh
+kubectl get kubeconfig kubeconfig-zp786 -o wide
+NAME               TTL   TOKENS   STATUS     AGE     USER         CLUSTERS       DESCRIPTION
+kubeconfig-zp786   30d   2/2      Complete   18d     user-w5gcf   *              all clusters
+```
+
+## Deleting a Kubeconfig
+
+Admins can delete any Kubeconfig, while regular users can only delete their own. When a Kubeconfig is deleted, the kubeconfig tokens are also deleted.
+
+```sh
+kubectl delete kubeconfig kubeconfig-zp786
+kubeconfig.ext.cattle.io "kubeconfig-zp786" deleted
+```
+
+To delete a Kubeconfig using preconditions:
+
+```sh
+cat <<EOF | k delete --raw /apis/ext.cattle.io/v1/kubeconfigs/kubeconfig-zp786 -f -
+{
+  "apiVersion": "v1",
+  "kind": "DeleteOptions",
+  "preconditions": {
+    "uid": "52183e05-d382-47d2-b4b9-d0735823ce90",
+    "resourceVersion": "31331505"
+  }
+}
+EOF
+```
+
+## Deleting a Collection of Kubeconfigs
+
+Admins can delete any Kubeconfig, while regular users can only delete their own.
+
+To delete all Kubeconfigs:
+
+```sh
+kubectl delete --raw /apis/ext.cattle.io/v1/kubeconfigs
+```
+
+To delete a collection of Kubeconfigs by label:
+
+```sh
+kubectl delete --raw /apis/ext.cattle.io/v1/kubeconfigs?labelSelector=foo%3Dbar
+```
+
+## Updating a Kubeconfig
+
+Only the `metadata`, e.g. adding a label or an annotation, and the `spec.description` field can be updated. All other `spec` fields are immutable.
+
+To edit a Kubeconfig:
+
+```sh
+kubectl edit kubeconfig kubeconfig-zp786
+```
+
+To patch a Kubeconfig and update its description:
+
+```sh
+kubectl patch kubeconfig kubeconfig-zp786 -type merge -p '{"spec":{"description":"Updated description"}}'
+kubeconfig.ext.cattle.io/kubeconfig-zp786 patched
+
+kubectl get kubeconfig kubeconfig-fdcpl -o jsonpath='{.spec.description}'
+Updated description
+```
+
+To patch a Kubeconfig and add a label:
+
+```sh
+kubectl patch kubeconfig kubeconfig-zp786 -type merge -p '{"metadata":{"labels":{"foo":"bar"}}}'
+kubeconfig.ext.cattle.io/kubeconfig-zp786 patched
+
+kubectl get kubeconfig kubeconfig-zp786 -o jsonpath='{.metadata.labels.foo}'
+bar
+```
@@ -0,0 +1,132 @@
+---
+title: Tokens
+---
+
+<head>
+    <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/tokens"/>
+</head>
+
+## Token Resource
+
+Rancher has an imperative API resource `tokens.ext.cattle.io` that allows you to generate tokens for authenticating with Rancher.
+
+```sh
+kubectl api-resources --api-group=ext.cattle.io
+```
+
+To get a description of the fields and structure of the Token resource, run:
+
+```sh
+kubectl explain tokens.ext.cattle.io
+```
+
+## Feature Flag
+
+The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
+
+```sh
+kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
+```
+
+## Creating a Token
+
+:::caution
+The Token value is only returned once in the `status.value` field.
+:::
+
+Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
+
+```bash
+kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: Token
+EOF
+Error from server (Forbidden): error when creating "STDIN": tokens.ext.cattle.io is forbidden: user system:admin is not a Rancher user
+```
+
+A Token is always created for the user making the request. Attempting to create a Token for a different user, by specifying a different `spec.userID`, is forbidden and will fail.
+
+- The `spec.description` field can be set to an arbitrary human-readable description of the Token's purpose. The default value is empty.
+
+- The `spec.kind` field can be set to the kind of Token. The value `session` indicates a login Token. All other values, including the default empty string, indicate a kind of derived Token.
+
+- The `metadata.name` and `metadata.generateName` fields are ignored, and the name of the new Token is automatically generated using the prefix `token-`.
+
+	```bash
+	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+	apiVersion: ext.cattle.io/v1
+	kind: Token
+	spec:
+	  description: My Token
+	EOF
+	```
+
+- If the `spec.ttl` is not specified, the Token is created with the expiration time defined in the `auth-token-max-ttl-minutes` setting. The default expiration time is 90 days. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `auth-token-max-ttl-minutes` setting expressed in milliseconds.
+
+	```bash
+	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
+	apiVersion: ext.cattle.io/v1
+	kind: Token
+	spec:
+	  ttl: 7200000 # 2 hours
+	EOF
+	```
+
+## Listing Tokens
+
+Listing previously generated Tokens can help clean up tokens that are no longer needed (e.g., they were issued temporarily). Admins can list all Tokens, while regular users can only see their own.
+
+```sh
+kubectl get tokens.ext.cattle.io
+NAME          KIND   TTL   AGE
+token-chjc9          90d   18s
+token-6fzgj          90d   16s
+token-8nbrm          90d   14s
+```
+
+Use `-o wide` to get more details:
+
+```sh
+kubectl get tokens.ext.cattle.io -o wide
+NAME          USER         KIND   TTL   AGE   DESCRIPTION
+token-chjc9   user-jtghh          90d   24s   example
+token-6fzgj   user-jtghh          90d   22s   box
+token-8nbrm   user-jtghh          90d   20s   jinx
+```
+
+## Viewing a Token
+
+Admins can get any Token, while regular users can only get their own.
+
+```sh
+kubectl get tokens.ext.cattle.io token-chjc9
+NAME          KIND   TTL   AGE
+token-chjc9          90d   18s
+```
+
+Use `-o wide` to get more details:
+
+```sh
+kubectl get tokens.ext.cattle.io token-chjc9 -o wide
+NAME          USER         KIND   TTL   AGE   DESCRIPTION
+token-chjc9   user-jtghh          90d   24s   example
+```
+
+## Deleting a Token
+
+Admins can delete any Token, while regular users can only delete their own.  
+
+```sh
+kubectl delete tokens.ext.cattle.io token-chjc9
+token.ext.cattle.io "token-chjc9" deleted
+```
+
+## Updating a Token
+
+Only the metadata fields `spec.description`, `spec.ttl`, and `spec.enabled` can be updated. All other `spec` fields are immutable. Admins can extend the `spec.ttl` field, while regular users can only reduce the value.
+
+An example `kubectl` command to edit a Token:
+
+```sh
+kubectl edit tokens.ext.cattle.io token-zp786
+```
@@ -39,7 +39,6 @@ User Interface | https://github.com/rancher/dashboard/ | This repository is the
 (Rancher) Docker Machine | https://github.com/rancher/machine | This repository is the source of the Docker Machine binary used when using Node Drivers. This is a fork of the `docker/machine` repository.
 machine-package | https://github.com/rancher/machine-package | This repository is used to build the Rancher Docker Machine binary.
 kontainer-engine | https://github.com/rancher/kontainer-engine | This repository is the source of kontainer-engine, the tool to provision hosted Kubernetes clusters.
-RKE repository | https://github.com/rancher/rke | This repository is the source of Rancher Kubernetes Engine, the tool to provision Kubernetes clusters on any machine.
 CLI | https://github.com/rancher/cli | This repository is the source code for the Rancher CLI used in Rancher 2.x.
 (Rancher) Helm repository | https://github.com/rancher/helm | This repository is the source of the packaged Helm binary. This is a fork of the `helm/helm` repository.
 loglevel repository | https://github.com/rancher/loglevel | This repository is the source of the loglevel binary, used to dynamically change log levels.
@@ -109,27 +108,6 @@ Please remove any sensitive data as it will be publicly viewable.
        -l app=rancher \
        --timestamps=true
        ```
-        - Docker install using `docker` on each of the nodes in the RKE cluster
-
-        ```
-        docker logs \
-        --timestamps \
-        $(docker ps | grep -E "rancher/rancher@|rancher_rancher" | awk '{ print $1 }')
-        ```
-        - Kubernetes Install with RKE Add-On
-
-        :::note
-
-        Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.
-
-        :::
-
-        ```
-        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')
-        ```
    - System logging (these might not all exist, depending on operating system)
        - `/var/log/messages`
        - `/var/log/syslog`
@@ -47,60 +47,9 @@ CNI network providers using this network model include Calico and Cilium. Cilium

 ## What CNI Providers are Provided by Rancher?

-### RKE Kubernetes clusters
-
-Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, Calico, and Weave.
-
-You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
-
-#### Canal
-
-![Canal Logo](/img/canal-logo.png)
-
-Canal is a CNI network provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
-
-In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.
-
-Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (health checks). If using Wireguard, you should open UDP ports `51820` and `51821`. For more details, refer to [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
-
-![](/img/canal-diagram.png)
-
-For more information, see the [Canal GitHub Page.](https://github.com/projectcalico/canal)
-
-#### Flannel
-
-![Flannel Logo](/img/flannel-logo.png)
-
-Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan).
-
-Encapsulated traffic is unencrypted by default. Flannel provides two solutions for encryption:
-
-* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. It is an experimental backend for encryption.
-* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard), which is a more faster-performing alternative to strongSwan.
-
-Kubernetes workers should open UDP port `8472` (VXLAN). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
-
-![Flannel Diagram](/img/flannel-diagram.png)
-
-For more information, see the [Flannel GitHub Page](https://github.com/flannel-io/flannel).
-
-#### Weave
-
-<DeprecationWeave />
-
-![Weave Logo](/img/weave-logo.png)
-
-Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
-
-Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` and UDP port `6784` (data ports). See the [port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
-
-For more information, see the following pages:
-
- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
-
 ### RKE2 Kubernetes clusters

-Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
+Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: Calico, Canal, Cilium, and Flannel.

 You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.

@@ -131,6 +80,20 @@ For more information, see the following pages:
 - [Project Calico Official Site](https://www.projectcalico.org/)
 - [Project Calico GitHub Page](https://github.com/projectcalico/calico)

+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal is a CNI network provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
+
+In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (health checks). If using Wireguard, you should open UDP ports `51820` and `51821`. For more details, refer to [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+
+![](/img/canal-diagram.png)
+
+For more information, see the [Canal GitHub Page.](https://github.com/projectcalico/canal)
+
 #### Cilium

 ![Cilium Logo](/img/cilium-logo.png)
@@ -158,6 +121,23 @@ spec:
      - remote-node
 ```

+#### Flannel
+
+![Flannel Logo](/img/flannel-logo.png)
+
+Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan).
+
+Encapsulated traffic is unencrypted by default. Flannel provides two solutions for encryption:
+
+* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. It is an experimental backend for encryption.
+* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard), which is a more faster-performing alternative to strongSwan.
+
+Kubernetes workers should open UDP port `8472` (VXLAN). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+![Flannel Diagram](/img/flannel-diagram.png)
+
+For more information, see the [Flannel GitHub Page](https://github.com/flannel-io/flannel).
+
 ## CNI Features by Provider

 The following table summarizes the different features available for each CNI network provider provided by Rancher.
@@ -196,4 +176,4 @@ Canal is the default CNI network provider. We recommend it for most use cases. I

 ## How can I configure a CNI network provider?

-Please see [Cluster Options](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) and the options for [Network Plug-ins](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/).
+Please see [Cluster Options](../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#cluster-config-file-reference).
@@ -16,11 +16,10 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.11.3](https://github.com/rancher/rancher/releases/tag/v2.11.3) | June 25, 2025 |
-| [2.11.2](https://github.com/rancher/rancher/releases/tag/v2.11.2) | May 22, 2025 |
-| [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | Apr 24, 2025 |
-| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | Mar 31, 2025 |
+| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | September 25, 2025 |
+| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | August 28, 2025 |
+| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 30, 2025 |

 ## What can I expect when a feature is marked for deprecation?

-In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -1,49 +0,0 @@
---
-title: Dockershim FAQ
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/dockershim"/>
-</head>
-
-The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Removal is currently scheduled for Kubernetes 1.24. For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
-
-RKE clusters, starting with Kubernetes 1.21, now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
-
-To enable the external Dockershim, configure the following option.
-
-```
-enable_cri_dockerd: true
-```
-
-For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.
-
-## FAQ
-
-<br/>
-
-Q: Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
-
-The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.
-
-<br/>
-
-Q: I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
-
-A: The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
-
-For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
-
-<br/>
-
-Q: What are my other options if I don’t want to depend on the Dockershim?
-
-A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
-
-<br/>
-
-Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-
-A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl.
-
-<br/>
@@ -14,17 +14,11 @@ See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubect

 ## Configuration

-When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.
-
-You can copy this file as `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`.
-
-```
-export KUBECONFIG=$(pwd)/kube_config_cluster.yml
-```
+When you create a Kubernetes cluster with RKE2/K3s, the Kubeconfig file is stored at `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` depending on your chosen distribution. These files are used to configure access to the Kubernetes cluster.

 Test your connectivity with `kubectl` and see if you can get the list of nodes back.

-```
+```shell
 kubectl get nodes
 NAME                          STATUS    ROLES                      AGE       VERSION
 165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.10.1
@@ -17,9 +17,9 @@ If Rancher is ever deleted or unrecoverable, all workloads in the downstream Kub

 The capability to access a downstream cluster without Rancher depends on the type of cluster and the way that the cluster was created. To summarize:

- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
+- **Registered/Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
 - **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
- **RKE clusters:** To access an [RKE cluster,](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
+- **Rancher provisioned clusters:** To access an [RKE2/K3s cluster](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.

 ## What if I don't want Rancher anymore?

@@ -56,10 +56,10 @@ To detach the cluster,

 **Result:** The registered cluster is detached from Rancher and functions normally outside of Rancher.

-## What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
+## What if I don't want my hosted Kubernetes cluster managed by Rancher?

 At this time, there is no functionality to detach these clusters from Rancher. In this context, "detach" is defined as the ability to remove Rancher components from the cluster and manage access to the cluster independently of Rancher.

 The capability to manage these clusters without Rancher is being tracked in this [issue.](https://github.com/rancher/rancher/issues/25234)

-For information about how to access clusters if the Rancher server is deleted, refer to [this section.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
+For information about how to access clusters if the Rancher server is deleted, refer to [this section.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
@@ -64,7 +64,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
 ## Where is the state of Rancher stored?

 - Docker Install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
- Kubernetes install: in the etcd of the RKE cluster created to run Rancher.
+- Kubernetes install: default location is in the `/var/lib/rancher/rke2` or `/var/lib/rancher/k3s` directories of the respective RKE2/K3s cluster created to run Rancher.

 ## How are the supported Docker versions determined?

@@ -99,7 +99,7 @@ When the node is removed from the cluster, and the node is cleaned, you can add

 ## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?

-You can add more arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
+You can add more arguments/binds/environment variables via the respective [RKE2 Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#cluster-configuration) or [K3s Config File](../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md#cluster-configuration).

 ## How do I check if my certificate chain is valid?

@@ -24,7 +24,6 @@ Rancher can be installed on any Kubernetes cluster. This cluster can use upstrea

 For help setting up a Kubernetes cluster, we provide these tutorials:

- **RKE:** For the tutorial to install an RKE Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md) For help setting up the infrastructure for a high-availability RKE cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster.md)
 - **K3s:** For the tutorial to install a K3s Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)
 - **RKE2:** For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher.md) For help setting up the infrastructure for a high-availability RKE2 cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md)
 - **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-amazon-eks.md)
@@ -36,7 +35,7 @@ For help setting up a Kubernetes cluster, we provide these tutorials:

 The Rancher UI and API are exposed through an Ingress. This means the Kubernetes cluster that you install Rancher in must contain an Ingress controller.

-For RKE, RKE2, and K3s installations, you don't have to install the Ingress controller manually because one is installed by default.
+For RKE2 and K3s installations, you don't have to install the Ingress controller manually because one is installed by default.

 For distributions that do not include an Ingress Controller by default, like a hosted Kubernetes cluster such as EKS, GKE, or AKS, you have to deploy an Ingress controller first. Note that the Rancher Helm chart does not set an `ingressClassName` on the ingress by default. Because of this, you have to configure the Ingress controller to also watch ingresses without an `ingressClassName`.

@@ -199,7 +198,6 @@ Because `rancher` is the default option for `ingress.tls.source`, we are not spe
 - Set the `hostname` to the DNS name you pointed at your load balancer.
 - Set the `bootstrapPassword` to something unique for the `admin` user.
 - To install a specific Rancher version, use the `--version` flag, example: `--version 2.7.0`
- For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
@@ -240,7 +238,6 @@ In the following command,
 - `ingress.tls.source` is set to `letsEncrypt`
 - `letsEncrypt.email` is set to the email address used for communication about your certificate (for example, expiry notices)
 - Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
- For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 :::warning

@@ -289,7 +286,6 @@ If you want to check if your certificates are correct, see [How do I check Commo
 - Set the `hostname`.
 - Set the `bootstrapPassword` to something unique for the `admin` user.
 - Set `ingress.tls.source` to `secret`.
- For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
@@ -175,18 +175,10 @@ $ nc xxx.xxx.xxx.xxx 22
 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
 ```

-### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: no key found
-
-The key file specified as `ssh_key_path` cannot be accessed. Make sure that you specified the private key file (not the public key, `.pub`), and that the user that is running the `rke` command can access the private key file.
-
 ### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

 The key file specified as `ssh_key_path` is not correct for accessing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with.

-### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
-
-If you want to use encrypted private keys, you should use `ssh-agent` to load your keys with your passphrase. If the `SSH_AUTH_SOCK` environment variable is found in the environment where the `rke` command is run, it will be used automatically to connect to the node.
-
 ### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

 The node is not reachable on the configured `address` and `port`.
@@ -1,72 +0,0 @@
---
-title: Upgrading a Hardened Custom/Imported Cluster to Kubernetes v1.25
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrade-a-hardened-cluster-to-k8s-v1-25"/>
-</head>
-
-Kubernetes v1.25 changes how clusters describe and implement security policies. From this version forward, [Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are no longer available. Kubernetes v1.25 replaces them with new security objects: [Pod Security Standards (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/), and [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/).
-
-If you have custom or imported hardened clusters, you must take special preparations to ensure that the upgrade from an earlier version of Kubernetes to v1.25 or later goes smoothly.
-
-:::note
-
-After you upgrade to v1.25, add the necessary Rancher namespace exemptions. See [Pod Security Admission (PSA) Configuration Templates](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) for more details.
-
-:::
-
-## Upgrading Imported Hardened Clusters to Kubernetes v1.25 or Later
-
-<Tabs groupId="k8s-distro">
-<TabItem value="RKE2" default>
-
-Perform the following on each node in the cluster:
-1. Save [`rancher-psact.yaml`](./rancher-psact.yaml) in `/etc/rancher/rke2`.
-1. Edit the RKE2 configuration file:
-   1. Update the `profile` field to `cis-1.23`.
-   1. Specify the path for the configuration file that you just added: `pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`.
-
-</TabItem>
-<TabItem value="K3s">
-
-Perform the following on each node in the cluster:
-
-Follow the official K3s instructions on [Upgrading Hardened Clusters from v1.24.x to v1.25.x](https://docs.k3s.io/known-issues#hardened-125), but use a [custom](./rancher-psact.yaml) Rancher PSA configuration template, instead of the configuration provided on the official K3s site.
-</TabItem>
-</Tabs>
-
-After you perform these steps, you can upgrade the cluster's Kubernetes version through the Rancher UI:
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
-1. Select **Edit Config**.
-1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
-1. Click **Save**.
-
-## Upgrading Custom Hardened Clusters to Kubernetes v1.25 or Later
-
-<Tabs groupId="k8s-distro">
-<TabItem value="RKE2" default>
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
-1. Select **Edit Config**.
-1. Under **Basics > Security**, in the **CIS Profile** dropdown menu, select `cis-1.23`.
-1. In the **Pod Security Admission Configuration Template** dropdown menu, select `rancher-restricted`.
-1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
-1. Click **Save**.
-
-</TabItem>
-<TabItem value="K3s">
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
-1. Select **Edit YAML**.
-1. Delete `PodSecurityPolicy` from `kube-apiserver-arg.enable-admission-plugins`
-1. Add this line to the `spec` field: `defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
-1. Update `kubernetesVersion` to your chosen version (v1.25 or later).
-1. Click **Save**.
-
-</TabItem>
-</Tabs>
@@ -10,18 +10,15 @@ The following instructions will guide you through upgrading a Rancher server tha

 For the instructions to upgrade Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)

-To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
-
-
 ## Prerequisites

-### Access to kubeconfig
+### Access to Kubeconfig

-Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
+Helm should be run from the same location as your Kubeconfig file, or the same location where you run your `kubectl` commands from.

-If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
+If you installed Kubernetes with RKE2/K3s, the Kubeconfig is stored in the `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` directory depending on your chosen distribution.

-The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
+The Kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)

 ### Review Known Issues

@@ -152,7 +149,6 @@ Upgrade Rancher to the latest version with all your settings.

 Take all the values from the previous step and append them to the command using `--set key=value`.

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 ```
 helm upgrade rancher rancher-<CHART_REPO>/rancher \
@@ -186,8 +182,7 @@ Alternatively, it's possible to export the current values to a file and referenc
    ```
 1. Update only the Rancher version:

-    For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
-
+    
    ```
    helm upgrade rancher rancher-<CHART_REPO>/rancher \
      --namespace cattle-system \
@@ -26,32 +26,52 @@ The following is a list of feature flags available in Rancher. If you've upgrade
 - `imperative-api-extension`: Enables Rancher's [extension API server](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) to register new APIs to Kubernetes. This flag is enabled by default. See the [Extension API Server](../../../api/extension-apiserver.md) page for more information.
 - `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
 - `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
+- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream imported RKE2/K3s clusters, as well as in the local cluster if it is an RKE2/K3s cluster.
+
+:::note Important:
+
+This `managed-system-upgrade-controller` flag is intended for **internal use only** and does not have an associated Feature CR. Use with caution.
+
+To control whether Rancher should manage the Kubernetes version of imported RKE2/K3s clusters, it is recommended to use the [imported-cluster-version-management](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#configuring-version-management-for-rke2-and-k3s-clusters) feature that is available in Rancher v2.11.0 or newer.
+
+:::
+
+:::danger
+
+If the `managed-system-upgrade-controller` flag was **disabled** in Rancher v2.10.x, and any imported RKE2/K3s clusters were upgraded **outside of Rancher**, follow the steps below to prevent the unexpected installation of the system-upgrade-controller app and to ensure the [imported-cluster-version-management](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#configuring-version-management-for-rke2-and-k3s-clusters) feature works correctly:
+
+1. Upgrade Rancher to v2.11.0 or newer, making sure to **retain** the `managed-system-upgrade-controller=false` feature flag in Helm values if it was set during the v2.10.x installation.
+1. After Rancher is fully up and running, disable the `imported-cluster-version-management` setting. You can do this either through the Rancher UI by clicking **☰ > Global Settings > Settings > imported-cluster-version-management**, or by editing the corresponding `Setting.management.cattle.io/v3` custom resource via kubectl.
+1. Perform a second Helm upgrade, this time omitting the `managed-system-upgrade-controller=false` feature flag.
+
+Now, the imported cluster version management is disabled by default, and Rancher no longer installs the system-upgrade-controller app on imported clusters automatically.
+
+You can enable this feature on a per-cluster basis. For more information, please refer to the [documentation](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#configuring-version-management-for-rke2-and-k3s-clusters).
+
+:::
+
 - `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
 - `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
 - `token-hashing`: Enables token hashing. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically with the SHA256 algorithm. Once a token is hashed it can't be undone. This flag can't be disabled after its enabled. See [API Tokens](../../../api/api-tokens.md#token-hashing) for more information.
- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
+- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `Active`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `Disabled`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `Disabled` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
 - `unsupported-storage-drivers`: Enables types for storage providers and provisioners that aren't enabled by default. See [Allow Unsupported Storage Drivers](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md) for more information.
- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
-
+- `ui-sql-cache`: Enables an SQLite-based cache for UI tables and Server-Side Pagination. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/ui-server-side-pagination.md) for more information.

 The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:

 | Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
 | ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
-| `aggregated-roletemplates` | `false` | Highly experimentatl | v2.11.0 | This flag value is locked on install and can't be changed. |
-| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
-| `continuous-delivery` | `true` | GA | v2.6.0 | |
-| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
-| `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
-| `fleet`  | `true` | GA | v2.5.0 | |
-| `harvester` | `true` | Experimental | v2.6.1 | |
-| `imperative-api-extension` | `true` | GA | v2.11.0 | |
-| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
-| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
-| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
+| `aggregated-roletemplates` | `Disabled` | Highly experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
+| `clean-stale-secrets` | `Active` | GA | v2.10.2 | |
+| `continuous-delivery` | `Active` | GA | v2.6.0 | |
+| `external-rules` | v2.7.14: `Disabled`, v2.8.5: `Active` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
+| `fleet`  | `Active` | Can no longer be disabled | v2.6.0 | |
+| `fleet`  | `Active` | GA | v2.5.0 | |
+| `harvester` | `Active` | Experimental | v2.6.1 | |
+| `imperative-api-extension` | `Active` | GA | v2.11.0 | |
+| `legacy` | `Disabled` for new installs, `Active` for upgrades | GA | v2.6.0 | |
+| `managed-system-upgrade-controller` | `Active` | GA | v2.10.0 | |
 | `rke2` | `true` | Experimental | v2.6.0 | |
-| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
-| `uiextension` | `true` | GA | v2.9.0 | |
-| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
+| `token-hashing` | `Disabled` for new installs, `Active` for upgrades | GA | v2.6.0 | |
+| `uiextension` | `Active` | GA | v2.9.0 | |
+| `ui-sql-cache` | `Active` | GA | v2.9.0 | |
@@ -36,7 +36,8 @@ For information on enabling experimental features, refer to [this page.](../../.
 | `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
 | `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
 | `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
-| `auditLog.level`               | 0                                                     | `int` - set the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level. 0 is off. [0-3]                                   |
+| `auditLog.enabled`            |  false                            | `bool` - Enables / disables audit logging.                                           |
+| `auditLog.level`               | 0                                                     | `int` - Sets the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level [0-3].                                  |
 | `auditLog.maxAge`              | 1                                                     | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`)                      |
 | `auditLog.maxBackup`           | 1                                                     | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`)                               |
 | `auditLog.maxSize`             | 100                                                   | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`)    |
@@ -62,7 +63,9 @@ For information on enabling experimental features, refer to [this page.](../../.
 | `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
 | `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
 | `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |
-| `global.cattle.psp.enabled`        | `true`                                               | `bool` - select 'false' to disable PSPs for Kubernetes v1.25 and above when using Rancher v2.7.2-v2.7.4. When using Rancher v2.7.5 and above, Rancher attempts to detect if a cluster is running a Kubernetes version where PSPs are not supported, and will default it's usage of PSPs to false if it can determine that PSPs are not supported in the cluster. Users can still manually override this by explicitly providing `true` or `false` for this value. Rancher will still use PSPs by default in clusters which support PSPs (such as clusters running Kubernetes v1.24 or lower). |
+
+
+When using Rancher v2.12.0 and above, Rancher will use an audit logging controller that watches `AuditPolicy` CRs for configuring additional redactions, for more info see [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md).


 ### Bootstrap Password
@@ -78,7 +81,7 @@ Enabling the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-
 You can collect this log as you would any container log. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the `System` Project on the Rancher server cluster.

 ```plain
--set auditLog.level=1
+--set auditLog.enabled=true --set auditLog.level=1
 ```

 By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the Rancher server cluster or System Project.
@@ -216,14 +219,6 @@ Your load balancer must support long lived websocket connections and will need t

 In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:

-For RKE installations, edit the `cluster.yml` to add the following settings.
-```yaml
-ingress:
-  provider: nginx
-  options:
-    use-forwarded-headers: 'true'
-```
-
 For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)

 ```yaml
@@ -12,7 +12,7 @@ Changing the default TLS settings depends on the chosen installation method.

 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).
+* nginx-ingress-controller (default for 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
@@ -23,6 +23,8 @@ See our page on [best practices](../../../reference-guides/best-practices/ranche

 Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to ensure that your intended version of Kubernetes is supported.

+Regardless of version and distribution, the Kubernetes cluster must have the aggregation API layer properly configured to support the [extension API](../../../api/extension-apiserver.md) used by Rancher.
+
 ### Install Rancher on a Hardened Kubernetes cluster

 If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.
@@ -212,7 +212,7 @@ configs:
      ca_file: <path to the ca file used in the registry>
 ```

-For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
+For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)

 ## 3. Install RKE2

@@ -172,7 +172,6 @@ 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.

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 Placeholder | Description
 ------------|-------------
@@ -203,7 +202,6 @@ Create Kubernetes secrets from your own certificates for Rancher to use. The com

 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.

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 | Placeholder                      | Description                                     |
 | -------------------------------- | ----------------------------------------------- |
@@ -10,7 +10,15 @@ Once the infrastructure is ready, you can continue with setting up a Kubernetes

 The steps to set up RKE, RKE2, or K3s are shown below.

-For convenience, export the IP address and port of your proxy into an environment variable and set up the HTTP_PROXY variables for your current shell on every node:
+For convenience, export the IP address and port of your proxy into an environment variable and set up the `HTTP_PROXY` variables for your current shell on every node:
+
+:::caution
+
+The `NO_PROXY` environment variable is not standardized, and the accepted format of the value can differ between applications. When configuring the `NO_PROXY` variable for Rancher, the value must adhere to the format expected by Golang. 
+
+Specifically, the value should be a comma-delimited string which only contains IP addresses, CIDR notation, domain names, or special DNS labels (e.g. `*`). For a full description of the expected value format, refer to the [**upstream Golang documentation**](https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config)
+
+:::

 ```
 export proxy_host="10.0.0.5:8888"
@@ -53,6 +53,10 @@ You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by loggi

 ## Upgrade

+:::danger 
+Rancher upgrades to version 2.12.0 and later will be blocked if any RKE1-related resources are detected, as the Rancher Kubernetes Engine (RKE/RKE1) is end of life as of **July 31, 2025**. For detailed cleanup and recovery steps, refer to the [RKE1 Resource Validation and Upgrade Requirements in Rancher v2.12](#rke1-resource-validation-and-upgrade-requirements-in-rancher-v212).
+:::
+
 During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data.
 ### 1. Create a copy of the data from your Rancher server container

@@ -388,6 +392,45 @@ See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/

 Remove the previous Rancher server container. If you only stop the previous Rancher server container (and don't remove it), the container may restart after the next server reboot.

+## RKE1 Resource Validation and Upgrade Requirements in Rancher v2.12
+
+Rancher v2.12.0 and later has removed support for the Rancher Kubernetes Engine (RKE/RKE1). During upgrade, Rancher validates the cluster resources and blocks the upgrade if any RKE1-related resources are detected.
+
+This validation affects the following resource types:
+
+- Clusters with `rkeConfig` (`clusters.management.cattle.io`)
+- NodeTemplates (`nodetemplates.management.cattle.io`)
+- ClusterTemplates (`clustertemplates.management.cattle.io`)
+
+This is particularly relevant for single-node Docker installations, where Rancher is not running during the upgrade. In such cases, controllers are not available to automatically clean up deprecated resources, and the upgrade process will fail early with an error listing the blocking resources.
+
+### 1. Pre-Upgrade (Recommended)
+
+Before upgrading, while Rancher is still running:
+
+- Run the `pre-upgrade-hook` cleanup script to delete all RKE1 clusters and templates. You can find the script in the Rancher GitHub repository: [pre-upgrade-hook.sh](https://github.com/rancher/rancher/blob/v2.12.0/chart/scripts/pre-upgrade-hook.sh).
+- This allows Rancher to clean up associated resources and finalizers.
+
+### 2. Post-Upgrade Failure Due to Residual RKE1 Resources
+
+If the upgrade to Rancher v2.12.0 or later is attempted without prior cleanup of RKE1 resources:
+
+- The upgrade will fail and display an error listing the resource names that are preventing the upgrade.
+- This occurs because Rancher includes validation to detect and block upgrades when unsupported RKE1 resources are still present.
+- To proceed, [rollback](#rolling-back) to the previous Rancher version, delete the identified resources, and then retry after [manual cleanup](#manual-cleanup-after-rollback).
+
+:::note Helm-based Rancher
+Helm-based Rancher installations are not affected by this issue, as Rancher remains available during the upgrade and can perform resource cleanup as needed.
+:::
+
+### Manual Cleanup After Rollback
+
+Users should perform the following steps after rolling back to a previous Rancher version:
+
+- **Manually delete** the resources listed in the upgrade error message (e.g., RKE1 clusters, NodeTemplates, ClusterTemplates).
+- If deletion is blocked due to **finalizers**, edit the resources and remove the `metadata.finalizers` field.
+- If a **validating webhook** prevents deletion (e.g., for the `system-project`), please refer to the [Bypassing the Webhook](../../../../reference-guides/rancher-webhook.md#bypassing-the-webhook) documentation.
+
 ## Rolling Back

 If your upgrade does not complete successfully, you can roll back Rancher server and its data back to its last healthy state. For more information, see [Docker Rollback](roll-back-docker-installed-rancher.md).
@@ -12,7 +12,24 @@ This section contains the requirements for Helm, which is the tool used to insta

 <DeprecationHelm2 />

+## Identifying the Proper Helm v3 Version
+
+Select any Helm v3 version that is officially compatible with the Kubernetes version range you are using from our [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions).
+
+To apply this rule, you may need to reference two external resources:
+
+- **Helm Version Compatibility:** Refer to the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) and select the version matching the rule for your Rancher minor target.
+- **Rancher's Kubernetes Support Range:** Use the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to identify the Kubernetes versions supported by your target Rancher minor version.
+
+### Example
+
+- **Scenario:** You are targeting Rancher v2.11.4, which supports Kubernetes versions 1.30 through 1.32.
+- **Application:** Our rule requires a Helm version that supports this range. You can verify this by checking the Helm version's compatibility with the highest version in the range, Kubernetes v1.32.
+- **Result:** You find that both Helm v3.17 and Helm v3.18 support the Kubernetes v1.30-v1.32 range.
+- Although both work, we recommend Helm v3.18 because it is the newest Helm minor version overlapping the supported Kubernetes range.
+
+## Additional Notes
+
 - Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
- Helm v2.15.0 should not be used, because of an issue with converting/comparing numbers.
- Helm v2.12.0 should not be used, because of an issue with `cert-manager`.
+- Helm v2 support was removed in Rancher v2.9.x.
+- When using tools that run Helm commands for you (like Terraform), you must make sure they are configured to use the correct Helm version.
@@ -10,7 +10,7 @@ Rancher is a container management platform built for organizations that deploy c

 ## 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.
+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 distributions (RKE2/K3s) 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

@@ -35,7 +35,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 ### Authorization and Role-Based Access Control

 - **User management:** The Rancher API server [manages user identities](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md) that correspond to external authentication providers like Active Directory or GitHub, in addition to local users.
- **Authorization:** The Rancher API server manages [access control](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) and [security](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) policies.
+- **Authorization:** The Rancher API server manages [access control](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) and [security](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) standards.

 ### Working with Kubernetes

@@ -58,7 +58,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and

 ## 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](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.
+The options and settings available for an existing cluster change based on the method that you used to provision it.

 After a cluster is created with Rancher, a cluster administrator can manage cluster membership or manage node pools, among [other options.](../reference-guides/cluster-configuration/cluster-configuration.md)

@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
 - [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
 - [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
 - [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
+- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.

 ### Example IAM Policy

@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
 - [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
 - [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
 - [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.


 ## Getting Started
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.

 - [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
 - [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.


 ## Getting Started
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
 - [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
 - [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
 - [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.


 ## Getting Started
@@ -128,7 +128,6 @@ The final command to install Rancher is below. The command requires a domain nam

 To install a specific Rancher version, use the `--version` flag (e.g., `--version 2.6.6`). Otherwise, the latest Rancher is installed by default. Refer to [Choosing a Rancher Version](../../installation-and-upgrade/resources/choose-a-rancher-version.md).

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.

@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.

 - [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
 - [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.


 ## Getting Started
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.

 :::

- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
+- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
+- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.


 ## Getting Started
@@ -48,7 +48,7 @@ See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Lino
   - `prefix` - The prefix for all created infrastructure.
   - `linode_type` - The type/plan that all infrastructure Linodes should use.
     - Default: `g6-standard-2` 
-     - For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
+     - For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).

 6. Run `terraform init`.

@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.

 - [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
 - [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
+- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.


 ## Getting Started
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev

 ## Prerequisites

- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
+- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

@@ -1,17 +0,0 @@
---
-title: CIS Scan Guides
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides"/>
-</head>
-
- [Install rancher-cis-benchmark](install-rancher-cis-benchmark.md)
- [Uninstall rancher-cis-benchmark](uninstall-rancher-cis-benchmark.md)
- [Run a Scan](run-a-scan.md)
- [Run a Scan Periodically on a Schedule](run-a-scan-periodically-on-a-schedule.md)
- [Skip Tests](skip-tests.md)
- [View Reports](view-reports.md)
- [Enable Alerting for rancher-cis-benchmark](enable-alerting-for-rancher-cis-benchmark.md)
- [Configure Alerts for Periodic Scan on a Schedule](configure-alerts-for-periodic-scan-on-a-schedule.md)
- [Create a Custom Benchmark Version to Run](create-a-custom-benchmark-version-to-run.md)
@@ -1,13 +0,0 @@
---
-title: Create a Custom Benchmark Version for Running a Cluster Scan
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/create-a-custom-benchmark-version-to-run"/>
-</head>
-
-There could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.
-
-It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.
-
-For details, see [this page.](../../../integrations-in-rancher/cis-scans/custom-benchmark.md)
@@ -1,24 +0,0 @@
---
-title: Enable Alerting for Rancher CIS Benchmark
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark"/>
-</head>
-
-Alerts can be configured to be sent out for a scan that runs on a schedule.
-
-:::note Prerequisite:
-
-Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
-
-While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
-
-:::
-
-While installing or upgrading the `rancher-cis-benchmark` Helm chart, set the following flag to `true` in the `values.yaml`:
-
-```yaml
-alerts:
-  enabled: true
-```
@@ -1,21 +0,0 @@
---
-title: Install Rancher CIS Benchmark
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/install-rancher-cis-benchmark"/>
-</head>
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to install CIS Benchmark and click **Explore**.
-1. In the left navigation bar, click **Apps > Charts**.
-1. Click **CIS Benchmark**
-1. Click **Install**.
-
-**Result:** The CIS scan application is deployed on the Kubernetes cluster.
-
-:::note
-
-If you are running Kubernetes v1.24 or earlier, and have a [Pod Security Policy](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) (PSP) hardened cluster, CIS Benchmark 4.0.0 and later disable PSPs by default. To install CIS Benchmark on a PSP-hardened cluster, set `global.psp.enabled` to `true` in the values before installing the chart. [Pod Security Admission](../../new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) (PSA) hardened clusters aren't affected.
-
-:::
@@ -1,26 +0,0 @@
---
-title: Run a Scan
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan"/>
-</head>
-
-When a ClusterScan custom resource is created, it launches a new CIS scan on the cluster for the chosen ClusterScanProfile.
-
-:::note
-
-There is currently a limitation of running only one CIS scan at a time for a cluster. If you create multiple ClusterScan custom resources, they will be run one after the other by the operator, and until one scan finishes, the rest of the ClusterScan custom resources will be in the "Pending" state.
-
-:::
-
-To run a scan,
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
-1. Click **CIS Benchmark > Scan**.
-1. Click **Create**.
-1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
-1. Click **Create**.
-
-**Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
@@ -1,38 +0,0 @@
---
-title: Skip Tests
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests"/>
-</head>
-
-CIS scans can be run using test profiles with user-defined skips.
-
-To skip tests, you will create a custom CIS scan profile. A profile contains the configuration for the CIS scan, which includes the benchmark versions to use and any specific tests to skip in that benchmark.
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
-1. Click **CIS Benchmark > Profile**.
-1. From here, you can create a profile in multiple ways. To make a new profile, click **Create** and fill out the form in the UI. To make a new profile based on an existing profile, go to the existing profile and click **⋮ Clone**.  If you are filling out the form, add the tests to skip using the test IDs, using the relevant CIS Benchmark as a reference. If you are creating the new test profile as YAML, you will add the IDs of the tests to skip in the `skipTests` directive. You will also give the profile a name:
-
-    ```yaml
-    apiVersion: cis.cattle.io/v1
-    kind: ClusterScanProfile
-    metadata:
-      annotations:
-        meta.helm.sh/release-name: clusterscan-operator
-        meta.helm.sh/release-namespace: cis-operator-system
-      labels:
-        app.kubernetes.io/managed-by: Helm
-      name: "<example-profile>"
-    spec:
-      benchmarkVersion: cis-1.5
-      skipTests:
-        - "1.1.20"
-        - "1.1.21"
-    ```
-1. Click **Create**.
-
-**Result:** A new CIS scan profile is created.
-
-When you [run a scan](./run-a-scan.md) that uses this profile, the defined tests will be skipped during the scan. The skipped tests will be marked in the generated report as `Skip`.
@@ -1,13 +0,0 @@
---
-title: Uninstall Rancher CIS Benchmark
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/uninstall-rancher-cis-benchmark"/>
-</head>
-
-1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps > Installed Apps**.
-1. Go to the `cis-operator-system` namespace and check the boxes next to `rancher-cis-benchmark-crd` and `rancher-cis-benchmark`.
-1. Click **Delete** and confirm **Delete**.
-
-**Result:** The `rancher-cis-benchmark` application is uninstalled.
@@ -1,23 +0,0 @@
---
-title: View Reports
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/view-reports"/>
-</head>
-
-To view the generated CIS scan reports,
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
-1. Click **CIS Benchmark > Scan**.
-1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
-
-One can download the report from the Scans list or from the scan detail page.
-
-To get the verbose version of the CIS scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
-
-```console
-export REPORT="scan-report-name"
-kubectl get clusterscanreport $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
-```
@@ -0,0 +1,16 @@
+---
+title: Compliance Scan Guides
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides"/>
+</head>
+
+- [Install rancher-compliance](install-rancher-compliance.md)
+- [Uninstall rancher-compliance](uninstall-rancher-compliance.md)
+- [Run a Scan](run-a-scan.md)
+- [Run a Scan Periodically on a Schedule](run-a-scan-periodically-on-a-schedule.md)
+- [View Reports](view-reports.md)
+- [Enable Alerting for rancher-compliance](enable-alerting-for-rancher-compliance.md)
+- [Configure Alerts for Periodic Scan on a Schedule](configure-alerts-for-periodic-scan-on-a-schedule.md)
+- [Create a Custom Benchmark Version to Run](create-a-custom-compliance-version-to-run.md)
@@ -3,7 +3,7 @@ title: Configure Alerts for Periodic Scan on a Schedule
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/configure-alerts-for-periodic-scan-on-a-schedule"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/configure-alerts-for-periodic-scan-on-a-schedule"/>
 </head>

 It is possible to run a ClusterScan on a schedule.
@@ -12,27 +12,27 @@ A scheduled scan can also specify if you should receive alerts when the scan com

 Alerts are supported only for a scan that runs on a schedule.

-The CIS Benchmark application supports two types of alerts:
+The compliance application supports two types of alerts:

 - Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
 - Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.

 :::note Prerequisite

-Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
+Before enabling alerts for `rancher-compliance`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)

-While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
+While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-compliance-scan-alerts)

 :::

 To configure alerts for a scan that runs on a schedule,

-1. Please enable alerts on the `rancher-cis-benchmark` application. For more information, see [this page](../../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md).
+1. Please enable alerts on the `rancher-compliance` application. For more information, see [this page](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance.md).
 1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
-1. Click **CIS Benchmark > Scan**.
+1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
+1. Click **compliance > Scan**.
 1. Click **Create**.
-1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
+1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
 1. Choose the option **Run scan on a schedule**.
 1. Enter a valid [cron schedule expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) in the field **Schedule**.
 1. Check the boxes next to the Alert types under **Alerting**.
@@ -41,4 +41,4 @@ To configure alerts for a scan that runs on a schedule,

 **Result:** The scan runs and reschedules to run according to the cron schedule provided. Alerts are sent out when the scan finishes if routes and receiver are configured under `rancher-monitoring` application.

-A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.
+A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.
@@ -0,0 +1,13 @@
+---
+title: Create a Custom Compliance Version for Running a Cluster Scan
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/create-a-custom-compliance-version-to-run"/>
+</head>
+
+There could be some Kubernetes cluster setups that require custom configurations of the Compliance tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream Compliance look for them.
+
+It is now possible to create a custom compliance version for running a cluster scan using the `rancher-compliance` application.
+
+For details, see [this page.](../../../integrations-in-rancher/compliance-scans/custom-benchmark.md)
@@ -0,0 +1,24 @@
+---
+title: Enable Alerting for Rancher Compliance
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance"/>
+</head>
+
+Alerts can be configured to be sent out for a scan that runs on a schedule.
+
+:::note Prerequisite:
+
+Before enabling alerts for `rancher-compliance`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
+
+While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-compliance-scan-alerts)
+
+:::
+
+While installing or upgrading the `rancher-compliance` Helm chart, set the following flag to `true` in the `values.yaml`:
+
+```yaml
+alerts:
+  enabled: true
+```
@@ -0,0 +1,15 @@
+---
+title: Install Rancher Compliance
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/install-rancher-compliance"/>
+</head>
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to install Compliance and click **Explore**.
+1. In the left navigation bar, click **Apps > Charts**.
+1. Click **Compliance**
+1. Click **Install**.
+
+**Result:** The compliance scan application is deployed on the Kubernetes cluster.
@@ -3,15 +3,15 @@ title: Run a Scan Periodically on a Schedule
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan-periodically-on-a-schedule"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/run-a-scan-periodically-on-a-schedule"/>
 </head>

 To run a ClusterScan on a schedule,

 1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
-1. Click **CIS Benchmark > Scan**.
-1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
+1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
+1. Click **Compliance > Scan**.
+1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
 1. Choose the option **Run scan on a schedule**.
 1. Enter a valid <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">cron schedule expression</a> in the field **Schedule**.
 1. Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
@@ -21,4 +21,4 @@ To run a ClusterScan on a schedule,

 A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.

-You can also see the previous reports by choosing the report from the **Reports** dropdown on the scan detail page.
+You can also see the previous reports by choosing the report from the **Reports** dropdown on the scan detail page.
@@ -0,0 +1,26 @@
+---
+title: Run a Scan
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/run-a-scan"/>
+</head>
+
+When a ClusterScan custom resource is created, it launches a new compliance scan on the cluster for the chosen ClusterScanProfile.
+
+:::note
+
+There is currently a limitation of running only one compliance scan at a time for a cluster. If you create multiple ClusterScan custom resources, they will be run one after the other by the operator, and until one scan finishes, the rest of the ClusterScan custom resources will be in the "Pending" state.
+
+:::
+
+To run a scan,
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a compliance scan and click **Explore**.
+1. Click **Compliance > Scan**.
+1. Click **Create**.
+1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
+1. Click **Create**.
+
+**Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
@@ -0,0 +1,13 @@
+---
+title: Uninstall Rancher Compliance
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/uninstall-rancher-compliance"/>
+</head>
+
+1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps > Installed Apps**.
+1. Go to the `compliance-operator-system` namespace and check the boxes next to `rancher-compliance-crd` and `rancher-compliance`.
+1. Click **Delete** and confirm **Delete**.
+
+**Result:** The `rancher-compliance` application is uninstalled.
@@ -0,0 +1,23 @@
+---
+title: View Reports
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/view-reports"/>
+</head>
+
+To view the generated Compliance scan reports,
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
+1. Click **Compliance > Scan**.
+1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
+
+One can download the report from the Scans list or from the scan detail page.
+
+To get the verbose version of the compliance scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
+
+```console
+export REPORT="scan-report-name"
+kubectl get clusterscanreports.compliance.cattle.io $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
+```
@@ -185,6 +185,7 @@ For help troubleshooting certificates, see [this section.](../../getting-started
 If you want to record all transactions with the Rancher API, enable the [API Auditing](enable-api-audit-log.md) feature by adding the flags below into your install command.

    -e AUDIT_LEVEL=1 \
+    -e AUDIT_LOG_ENABLED=true \
    -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
    -e AUDIT_LOG_MAXAGE=20 \
    -e AUDIT_LOG_MAXBACKUP=20 \
@@ -0,0 +1,138 @@
+---
+title: Configure Rancher as an OIDC provider
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/configure-oidc-provider"/>
+</head>
+
+Rancher can function as a standard OpenID Connect (OIDC) provider, allowing external applications to use Rancher for authentication.
+This can be used for enabling single sign-on (SSO) across Rancher Prime components. For example, see the [documentation](https://documentation.suse.com/cloudnative/suse-observability/latest/en/setup/security/authentication/oidc.html) for configuring the OIDC provider for SUSE Observability.
+
+The OIDC provider can be enabled with the `oidc-provider` feature flag. When this flag is on the following endpoints are available:
+
+- `https://{rancher-url}/oidc/authorize`: This endpoint initiates the authentication flow. If a user is already logged into Rancher, it returns an authorization code. Otherwise, it redirects the user to the Rancher login page. Authorization codes and related request information are securely stored in session secrets. Codes are single-use and expire after 10 minutes.
+
+- `https://{rancher-url}/oidc/token`: This endpoint exchanges an authorization code for an `id_token`, `access_token`, and `refresh_token`.
+
+- `https://{rancher-url}/oidc/.well-known/openid-configuration`: This endpoint returns a JSON document containing the OIDC provider's configuration, including endpoint URLs, supported scopes, claims, and other relevant details.
+
+- `https://{rancher-url}/oidc/userinfo`: This endpoint provides information about the authenticated user.
+
+The OIDC provider supports the OIDC Authentication Code Flow with PKCE.
+
+## Configure OIDCClient
+
+An `OIDCClient` represents an external application that will be authenticating against Rancher.
+
+### Programmatically
+
+Create an `OIDCClient`:
+
+```yaml
+apiVersion: management.cattle.io/v3
+kind: OIDCClient
+metadata:
+  name: oidc-client-test
+spec:
+  tokenExpirationSeconds: 600 # expiration of the id_token and access_token
+  refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
+  redirectURIs:
+    - "https://myredirecturl.com" # replace with your redirect url
+```
+Rancher automatically generates a client ID and client secret for each `OIDCClient`.
+Once the resource is created, Rancher populates the status field with the client id:
+
+```yaml
+apiVersion: management.cattle.io/v3
+kind: OIDCClient
+metadata:
+  name: oidc-client-test
+spec:
+  tokenExpirationSeconds: 600 # expiration of the id_token and access_token
+  refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
+  redirectURIs:
+    - "https://myredirecturl.com" # replace with your redirect url
+status:
+  clientID: client-xxx
+  clientSecrets:
+    client-secret-1:
+      createdAt: "xxx"
+      lastFiveCharacters: xxx
+```
+
+Rancher automatically generates a Kubernetes `Secret` in the `cattle-oidc-client-secrets` namespace for each `OIDCClient` resource. The Secret's name matches the `OIDCClient` client ID.
+Initially, the `Secret` contains a single client secret.
+
+To retrieve the client secret:
+
+```
+kubectl get secret client-xxx -n cattle-oidc-client-secrets -o jsonpath="{.data.client-secret-1}" | base64 -d
+```
+
+Output:
+
+```
+secret-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+```
+
+You can now use this client ID and client secret in your OIDC client application.
+
+#### Managing Client Secrets
+
+You can manage multiple client secrets per `OIDCClient`. Use annotations on the `OIDCClient` resource to perform secret operations:
+
+- Creation: Adding the `cattle.io/oidc-client-secret-create: true` annotation triggers the creation of a new client secret.
+- Removal: Adding the `cattle.io/oidc-client-secret-remove:client-secret-1` annotation removes the specified client secrets.
+- Regeneration: Adding the `cattle.io/oidc-client-secret-regenerate:client-secret-1` annotation regenerates the specified client secrets.
+
+### Rancher UI
+
+Create an OIDCClient:
+
+1. In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **OIDC Apps**.
+1. Click **Add Application**. Fill out the **Create OIDC App** form.
+1. Click **Add Application**.
+
+#### Managing Client Secrets
+
+In the OIDC App page:
+
+- Creation: Click **Add new secret**.
+- Removal: Click **⋮ > Delete**
+- Regeneration: Click **⋮ > Regenerate**
+
+## Signing key
+
+A default key pair for signing the `id_token`, `access_token`, and `refresh_token` tokens is created by Rancher in a `Secret` called `oidc-signing-key` in the `cattle-system` namespace. Only one key will be used for signing, but multiple public keys can be returned in the jwks endpoint in order to avoid disruption when doing a key rotation. 
+
+### Rotation without disruption
+
+In order to create a new key pair for signing you need to manually create a new keypair and add it to the `oidc-signing-key` `Secret`
+
+Example:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: oidc-signing-key
+type: Opaque
+data:
+ key2.pem: <base64-encoded-new-private-key>
+ key1.pub: <base64-encoded-old-public-key>
+ key2.pub: <base64-encoded-new-public-key>
+```
+
+Rancher will sign tokens using `key2.pem`, while the JWKS endpoint will serve both `key1.pub` and `key2.pub`. This ensures a smooth 
+key rotation from `key1` to `key2` without disrupting existing token verification. Note that only one private key (.pem) can be stored in the 
+secret at a time, and each key pair must share the same base name, differing only by their suffix: .pem for the private key and .pub for the public key.
+
+### Rotation with disruption
+
+Removing the `oidc-signing-key` `Secret` will cause Rancher to regenerate the signing key on the next restart.
+
+:::warning
+This will invalidate all previously issued `id_token`, `access_token`, and `refresh_token` tokens making them unusable.
+:::
@@ -39,7 +39,6 @@ Values set from the Rancher API will override the value passed in through the co

 When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 ```
 helm install rancher rancher-latest/rancher \
@@ -1,41 +0,0 @@
---
-title: UI Server-Side Pagination
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination"/>
-</head>
-
-:::caution
-UI server-side pagination is not intended for use in production at this time. This feature is considered highly experimental. SUSE customers should consult SUSE Support before activating this feature.
-:::
-
-
-UI server-side pagination caching provides an optional SQLite-backed cache of Kubernetes objects to improve performance. This unlocks sorting, filtering and pagination features used by the UI to restrict the amount of resources it fetches and stores in browser memory. These features are primarily used to improve list performance for resources with high counts.
-
-This feature creates file system based caches in the `rancher` pods of the upstream cluster, and in the `cattle-cluster-agent` pods of the downstream clusters. In most environments, disk usage and I/O should not be significant. However, you should monitor activity after you enable caching.
-
-SQLite-backed caching persists copies of any cached Kubernetes objects to disk. See [Encrypting SQLite-backed Caching](#encrypting-sqlite-backed-caches) if this is a security concern.
-
-## Enabling UI Server-Side Pagination
-
-1. In the upper left corner, click **☰ > Global Settings > Feature Flags**.
-1. Find **`ui-sql-cache`** and select **⋮ > Activate > Activate**.
-1. Wait for Rancher to restart. This also restarts agents on all downstream clusters.
-1. In the upper left corner, click **☰ > Global Settings > Performance**.
-1. Go to **Server-side Pagination** and check the **Enable Server-side Pagination** option.
-1. Click **Apply**.
-1. Reload the page with the browser button (or the equivalent keyboard combination, typically `CTRL + R` on Windows and Linux, and `⌘ + R` on macOS).
-
-
-## Encrypting SQLite-backed Caches
-
-UI server-side pagination persists copies of any cached Kubernetes objects to disk. If you're concerned about the safety of this data, you can encrypt all objects before they are persisted to disk, by setting the environment variable `CATTLE_ENCRYPT_CACHE_ALL` to `true` in `rancher` pods in the upstream cluster and `cattle-cluster-agent` pods in the downstream clusters.
-
-Secrets and security Tokens are always encrypted regardless of the above setting.
-
-## Known Limitations of UI Server-Side Pagination
-
-This initial release improves the performance of Pods, Secrets, Nodes and ConfigMaps in the Cluster Explorer pages, and most resources in the Explorer's **More Resources** section.
-
-Pages can't be automatically refreshed. You can manually refresh table contents by clicking the **Refresh** button.
@@ -17,7 +17,6 @@ Detailed information can be found in [this announcement](https://forums.suse.com
 :::note Prerequisites:

 - Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
- If you have pod security policies, you will need to install Istio with the CNI enabled. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/pod-security-policies.md)
 - To install Istio on an RKE2 cluster, additional steps are required. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md)
 - To install Istio in a cluster where project network isolation is enabled, additional steps are required. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/project-network-isolation.md)

@@ -1,43 +0,0 @@
---
-title: Applying Pod Security Policies to Projects
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-pod-security-policies"/>
-</head>
-
-:::note
-
-These cluster options are only available for [clusters in which Rancher has launched Kubernetes](../../new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
-
-:::
-
-You can always assign a pod security policy (PSP) to an existing project if you didn't assign one during creation.
-
-### Prerequisites
-
- Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md).
- Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [the documentation about adding a pod security policy to a cluster](../../new-user-guides/manage-clusters/add-a-pod-security-policy.md). 
-
-### Applying a Pod Security Policy
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to move a namespace and click **Explore**.
-1. Click **Cluster > Projects/Namespaces**.
-1. Find the project that you want to add a PSP to. From that project, select **⋮ > Edit Config**.
-1. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project.
-  Assigning a PSP to a project will:
-
-  - Override the cluster's default PSP.
-  - Apply the PSP to the project.
-  - Apply the PSP to any namespaces you add to the project later.
-
-1. Click **Save**.
-
-**Result:** The PSP is applied to the project and any namespaces added to the project.
-
-:::note
-
-Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked to determine if they comply with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
-
-:::
@@ -24,7 +24,6 @@ You can use projects to perform actions like:
 - [Set resource quotas](manage-project-resource-quotas/manage-project-resource-quotas.md)
 - [Manage namespaces](../../new-user-guides/manage-namespaces.md)
 - [Configure tools](../../../reference-guides/rancher-project-tools.md)
- [Configure pod security policies](manage-pod-security-policies.md)

 ### Authorization

@@ -0,0 +1,81 @@
+---
+title: UI Server-Side Pagination
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/ui-server-side-pagination"/>
+</head>
+
+Server-Side Pagination (SSP) is a Rancher feature to provide significant performance improvements across the UI for resources with high counts, restricting the amount of resources browser fetches and stores in memory.
+
+Note that SSP is optional, **enabled by default**, and it can be disabled via the feature flag `ui-sql-cache`.
+
+## Disk Space
+
+:::important
+It is crucial that you review the available disk space on your nodes and plan accordingly before upgrading to Rancher v2.12.0 and later to avoid potential disk pressure and pod eviction issues.
+:::
+
+The SSP relies on a caching mechanism that introduces a new requirement for ephemeral disk space on your cluster nodes. This cache, an internal SQLite database, is stored within the container's file system. This affects the nodes running the **Rancher server pods** (`rancher` in the `cattle-system` namespace on the local cluster) and the nodes running the **Rancher agent pods** (`cattle-cluster-agent` in the `cattle-system` namespace on all downstream clusters).
+
+The amount of disk space required is dynamic and depends on the quantity and size of Kubernetes resources visualized in the UI. As a guideline, the cache may consume approximately **twice the size of the raw Kubernetes objects** it stores.
+
+For example, internal tests showed that caching 5000 ConfigMaps, totaling 50 MB, consumed 81 MB of disk space. For a conservative, high-level estimate, you can plan for the available disk space on each relevant node to be at least **twice the size of your etcd snapshot**. For most production environments, ensuring a few extra gigabytes of storage are available on the relevant nodes is a safe starting point.
+
+Please note this space counts against [ephemeral storage](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#setting-requests-and-limits-for-local-ephemeral-storage) requests and limits you might have set for your Rancher container via the `resource` value in the Helm chart. Make sure those settings provide for abundant available space.
+
+If you see the error `database or disk is full (13)` in the pod logs, this is a symptom that more space needs to be allocated.
+
+SQLite-backed caching persists copies of any cached Kubernetes objects to disk. See [Encrypting SQLite-backed Caching](#encrypting-sqlite-backed-caches) if this is a security concern.
+
+## Enabling Server-Side Pagination
+
+1. In the upper left corner, click **☰ > Global Settings > Feature Flags**.
+1. Find **`ui-sql-cache`** and select **⋮ > Activate > Activate**.
+1. Wait for Rancher to restart. This also restarts agents on all downstream clusters.
+1. Reload the page with the browser button (or the equivalent keyboard combination, typically `CTRL + R` on Windows and Linux, and `⌘ + R` on macOS).
+
+## Disabling Server-Side Pagination
+
+1. In the upper left corner, click **☰ > Global Settings > Feature Flags**.
+1. Find **`ui-sql-cache`** and select **⋮ > Deactivate > Deactivate**.
+1. Wait for Rancher to restart. This also restarts agents on all downstream clusters.
+1. Reload the page with the browser button (or the equivalent keyboard combination, typically `CTRL + R` on Windows and Linux, and `⌘ + R` on macOS).
+
+## Encrypting SQLite-backed Caches
+
+UI server-side pagination persists copies of any cached Kubernetes objects to disk. If you're concerned about the safety of this data, you can encrypt all objects before they are persisted to disk, by setting the environment variable `CATTLE_ENCRYPT_CACHE_ALL` to `true` in `rancher` pods in the upstream cluster and `cattle-cluster-agent` pods in the downstream clusters.
+
+Secrets and security Tokens are always encrypted regardless of the above setting.
+
+## Known Limitations of UI Server-Side Pagination
+
+This release improves the performance of most pages used to view, create or edit resources within the `local` or downstream clusters i.e. the Cluster Explorer view. However, RBAC related resources and areas outside the Cluster Explorer are not yet covered by this feature.
+
+Additionally, the following limitations are present when the feature is enabled. These mainly revolve around different sort or filter behaviors in affected lists:
+
+- Resources in lists are automatically updated, however, not instantaneously.
+- All lists that utilize Server-Side Pagination:
+  - `State` column sort and filter features work on the resources `metadata.state.name` field instead of one deduced locally by the UI.
+  - Updates are shown every 5 seconds, rather than instantly.
+- Cluster Explorer:
+  - Project/Namespace filter does not support filtering namespaces by all namespaces not in a project via the `Not in a Project` entry.
+  - `Cluster` group --> `Nodes` page
+    - The following columns are not sortable or filterable: `Roles`, `External/Internal IP`, `CPU`, `RAM` (logic to determine their value is calculated in the browser)
+  - `Workloads` list:
+    - The `Workloads` list, which showed multiple different resource types has been removed.
+      - Server-Side Pagination of multiple resources is not currently possible.
+  - `Workloads` group --> All lists
+    - `Pod Restarts` and `Workload Health` columns have been removed.
+      - [Re-enable Pod Restart Count and Pod Health columns for Workload lists #14211](https://github.com/rancher/dashboard/issues/14211)
+  - `Workloads` group / `Job` List
+    - `Duration` is not sortable (sorting on a duration).
+      - [Implement more complex server-side pagination sorting #12815](https://github.com/rancher/dashboard/issues/12815)
+  - `Workloads` group / `Pod` List
+    - `Images` is not sortable (sorting on an array).
+  - `Service Discovery` group / `Ingresses`
+    - `Default` is not sortable/filterable (logic to determine their value is calculated in the browser).
+  - `Storage` group / `ConfigMaps`
+    - `Data` is not sortable/filterable (logic to determine their value is calculated in the browser).
+  - `Storage` group / `Secrets`
+    - `Data` is not sortable/filterable (logic to determine their value is calculated in the browser).
@@ -27,12 +27,6 @@ By default, Rancher has activated several hosted Kubernetes cloud providers incl
 *  [Google GKE](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md)
 *  [Azure AKS](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md)

-There are several other hosted Kubernetes cloud providers that are disabled by default, but are packaged in Rancher:
-
-* [Alibaba ACK](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md)
-* [Huawei CCE](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md)
-* [Tencent](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md)
-
 ### Node Drivers

 Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://github.com/docker/docs/blob/vnext-engine/machine/drivers/index.md). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
@@ -49,3 +43,4 @@ Rancher supports several major cloud providers, but by default, these node drive
 There are several other node drivers that are disabled by default, but are packaged in Rancher:

 *   [Harvester](../../../../integrations-in-rancher/harvester/overview.md#harvester-node-driver/), available as of Rancher v2.6.1
+*   [Google GCE](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-google-compute-engine-cluster.md), available as of Rancher v2.12.0
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and

 In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.

-The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
+The [`ldapsearch`](https://manpages.ubuntu.com/manpages/noble/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.

 For the purpose of the example commands provided below we will assume:

@@ -0,0 +1,60 @@
+---
+title: Configure Amazon Cognito
+description: Create an Amazon Cognito user pool and configure Rancher to work with Amazon Cognito. Your users can then sign into Rancher using their login from Amazon Cognito.
+---
+
+<head> 
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-amazon-cognito"/>
+</head>
+
+If your organization uses Amazon Cognito for user authentication, you can configure Rancher to allow login using Amazon Cognito credentials. The following instructions describe how to configure Rancher to work with Amazon Cognito:
+
+## Prerequisites
+
+- In Rancher:
+  - Amazon Cognito is disabled.
+
+:::note
+Consult the Amazon Cognito [documentation](https://aws.amazon.com/cognito/getting-started/) to configure the user pool.
+:::
+
+- In Amazon Cognito:
+  - Create a new user pool or use an existing one. 
+  - In the `App client` settings, set the redirect URL to `https://yourRancherHostURL/verify-auth`. Replace `yourRancherHostURL` with the actual hostname of your Rancher instance (e.g., https://rancher.example.com/verify-auth).
+
+## Configuring Amazon Cognito in Rancher
+
+1. In the upper left corner of the Rancher UI, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Auth Provider**.
+1. Select **Amazon Cognito**.
+1. Complete the **Configure an Amazon Cognito account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
+1. Click **Enable**.
+
+   Rancher will redirect you to the Amazon Cognito login page. Enter your Amazon Cognito credentials to validate your Rancher configuration.
+
+   :::note
+
+   You may need to disable your popup blocker to see the Amazon Cognito login page.
+
+   :::
+
+**Result:** Rancher is configured to work with your Amazon Cognito using the OIDC protocol. Your users can now sign into Rancher using their Amazon Cognito logins.
+
+:::note
+User and group search is not supported for Amazon Cognito. When assigning permissions to a Project or Cluster, you must manually enter the UserID generated by Cognito 
+if the user has not yet logged in to Rancher. However, if the user has previously logged in, you can assign permissions using their username or email address.
+:::
+
+## Configuration Reference
+
+| Field                     | Description                                                                                                                                                                                                                                         |
+| ------------------------- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Client ID                 | The Client ID of your Amazon Cognito App Client.                                                                                                                                                                                                    |
+| Client Secret             | The generated Secret of your Amazon Cognito App Client.                                                                                                                                                                                             |
+| Issuer                    | The Issuer URL of your Amazon Cognito App Client. It follows the format `https://cognito-idp.{region}.amazonaws.com/{userPoolId}`, and can be found in the App Client settings page. Rancher uses the Issuer URL to fetch all of the required URLs. |
+
+## Troubleshooting
+
+### You are not redirected to your authentication provider
+
+If you fill out the **Configure an Amazon Cognito account** form and click on **Enable**, and you are not redirected to Amazon Cognito, verify your Amazon Cognito configuration.
@@ -38,12 +38,6 @@ The user retention feature is disabled by default.

 For more information, see [Enabling User Retention](../../advanced-user-guides/enable-user-retention.md).

-## Pod Security Policies
-
-_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
-
-For more information how to create and use PSPs, see [Pod Security Policies](create-pod-security-policies.md).
-
 ## Provisioning Drivers

 Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) or [nodes in an infrastructure provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) to allow Rancher to deploy and manage Kubernetes.
@@ -1,82 +0,0 @@
---
-title: Creating Pod Security Policies
---
-
-<head> 
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies"/>
-</head>
-
-:::caution
-Pod Security Policies are only available in Kubernetes until v1.24. [Pod Security Standards](pod-security-standards.md) are the built-in alternative.
-:::
-
-[Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are objects that control security-sensitive aspects of the pod specification (such as root privileges).
-
-If a pod doesn't meet the conditions specified in the PSP, Kubernetes won't allow it to start, and Rancher will display the following error message: `Pod <NAME> is forbidden: unable to validate...`.
-
-
-## How PSPs Work
-
-You can assign PSPs at the cluster or project level.
-
-PSPs work through inheritance:
-
- By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects.
- **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior.
- You can override the default PSP by assigning a different PSP directly to the project.
-
-Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
-
-Read more about Pod Security Policies in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
-
-## Default PSPs
-
-Rancher ships with three default Pod Security Policies (PSPs): the `restricted-noroot`, `restricted` and `unrestricted` policies.
-
-### Restricted-NoRoot
-
-This policy is based on the Kubernetes [example restricted policy](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
-
- Prevents pods from running as a privileged user and prevents escalation of privileges.
- Validates that server-required security mechanisms are in place, such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added.
-
-### Restricted
-
-This policy is a relaxed version of the `restricted-noroot` policy, with almost all the restrictions in place, except for the fact that it allows running containers as a privileged user.
-
-### Unrestricted
-
-This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
-
-:::note important
-
-When disabling PSPs, default PSPs are **not** automatically deleted from your cluster. You must manually delete them if they're no longer needed.
-
-:::
-
-## Creating PSPs
-
-Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.
-
-### Requirements
-
-Rancher can only assign PSPs for clusters that are [launched using RKE](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
-
-You must enable PSPs at the cluster level before you can assign them to a project. This can be configured by [editing the cluster](../../../reference-guides/cluster-configuration/cluster-configuration.md).
-
-It is a best practice to set PSP at the cluster level.
-
-We recommend adding PSPs during cluster and project creation instead of adding it to an existing one.
-
-### Creating PSPs in the Rancher UI
-
-1. In the upper left corner, click **☰ > Cluster Management**.
-1. In the left navigation bar, click **Pod Security Policies**.
-1. Click **Add Policy**.
-1. Name the policy.
-1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
-1. Click **Create**.
-
-## Configuration
-
-The Kubernetes documentation on PSPs is [here](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
@@ -196,6 +196,34 @@ As previously mentioned, custom roles can be defined for use at the cluster or p

 When defining a custom role, you can grant access to specific resources or specify roles from which the custom role should inherit. A custom role can be made up of a combination of specific grants and inherited roles. All grants are additive. This means that defining a narrower grant for a specific resource **will not** override a broader grant defined in a role that the custom role is inheriting from.

+#### UpdatePSA For Project Level
+
+About defining custom roles, you can grant permission to a user to create or update *PSA* policies when defining namespaces within projects.
+
+To do so, you can use the following `RoleTemplate` to be applied on the cluster:
+
+```yaml
+apiVersion: management.cattle.io/v3
+builtin: false
+context: project
+description: ''
+displayName: Manage PSA Labels
+external: false
+hidden: false
+kind: RoleTemplate
+metadata:
+  name: namespaces-psa
+rules:
+  - apiGroups:
+      - management.cattle.io
+    resources:
+      - projects
+    verbs:
+      - updatepsa
+```
+
+When creating a new project (from the **Members** tab), click **Add** to add the user and select **Custom** > **Create Namespaces** (to allow the user to create namespaces). Then click **Add** again and select `UpdatePSA` project role template from the list of **Project Permissions**.
+
 ### Default Cluster and Project Roles

 By default, when a standard user creates a new cluster or project, they are automatically assigned an ownership role: either [cluster owner](#cluster-roles) or [project owner](#project-roles). However, in some organizations, these roles may overextend administrative access. In this use case, you can change the default role to something more restrictive, such as a set of individual roles or a custom role.
@@ -6,6 +6,8 @@ title: Global Permissions
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
 </head>

+<PermissionsWarning />
+
 _Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.

 Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Standard User` and `User-base`.
@@ -0,0 +1,23 @@
+---
+title: Notification Center
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/notification-center"/>
+</head>
+
+## What is the Notification Center?
+
+The Notification Center, located in the upper-right corner of your Rancher dashboard and marked by a bell icon, is your central hub for staying informed about various events within Rancher.
+
+Notifications are categorized by severity and type:
+
+* **Error** indicates a high-severity issue.
+* **Warning** indicates a medium-severity concern.
+* **Information** provides general updates of lower severity.
+* **Task** shows that a process or action is currently in progress.
+* **Success** confirms that a process or action has completed successfully.
+
+For example, you might receive a notification when a new version of Rancher is available, or a direct link to the Rancher Release Notes.
+
+You can easily browse through your notifications using the up and down arrow keys. Certain notifications may also include an associated action, allowing you to respond immediately.
@@ -11,114 +11,6 @@ They became available and were turned on by default in Kubernetes v1.23, and rep

 PSS define security levels for workloads. PSAs describe requirements for pod security contexts and related fields. PSAs reference PSS levels to define security restrictions.

-## Upgrade to Pod Security Standards (PSS)
-
-Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
-
-:::caution
-You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
-:::
-
-### Removing PodSecurityPolicies from Rancher-Maintained Apps & Marketplace Workloads
-
-Rancher v2.7.2 offers a new major version of Rancher-maintained Helm charts. v102.x.y allows you to remove PSPs that were installed with previous versions of the chart. This new version replaces non-standard PSPs switches with the standardized `global.cattle.psp.enabled` switch, which is turned off by default.
-
-You must perform the following steps _while still in Kubernetes v1.24_:
-1. Configure the PSA controller to suit your needs. You can use one of Rancher's built-in [PSA Configuration Templates](#pod-security-admission-configuration-templates), or create a custom template and apply it to the clusters that you are migrating.
-
-1. Map your active PSPs to Pod Security Standards:
-    1. See which PSPs are still active in your cluster:
-       :::caution
-       This strategy may miss workloads that aren't currently running, such as CronJobs, workloads currently scaled to zero, or workloads that haven't rolled out yet.
-       :::
-       
-       ```shell
-       kubectl get pods \
-         --all-namespaces \
-         --output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
-         | tr " " "\n" | sort -u
-       ```
-
-    1. Follow the Kubernetes guide on [Mapping PSPs to Pod Security Standards](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/) to apply PSSs to your workloads that were relying on PSPs. See [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission controller](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) for more details.
-
-1. To remove PSPs from Rancher charts, upgrade the charts to the latest v102.x.y version _before_ you upgrade to Kubernetes v1.25. Make sure that the **Enable PodSecurityPolicies** option is **disabled**. This will remove any PSPs that were installed with previous chart versions.
-
-:::info important
-If you want to upgrade your charts to v102.x.y, but don't plan on upgrading your clusters to Kubernetes v1.25 and moving away from PSPs, make sure that you select the option **Enable PodSecurityPolicies** for each chart that you are upgrading.
-:::
-
-### Cleaning Up Releases After a Kubernetes v1.25 Upgrade
-
-If you experience problems while removing PSPs from your charts, or have charts that don't contain a built-in mechanism for removing PSPs, your chart upgrades or deletions might fail with an error message such as the following:
-```console
-Error: UPGRADE FAILED: resource mapping not found for name: "<object-name>" namespace: "<object-namespace>" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
-ensure CRDs are installed first
-```
-
-This happens when Helm tries to query the cluster for objects that were stored in a previous release's data blob. To clean up these releases and avoid this error, use the `helm-mapkubeapis` Helm  plugin. To learn more about `helm-mapkubeapis`, how it works, and how it can be fine-tuned for your use case, see the [official Helm documentation](https://github.com/helm/helm-mapkubeapis#readme).
-
-Note that Helm plugin installation is local to the machine that you run the commands from. Therefore, make sure that you run both the installation and cleanup from the same machine.
-
-#### Install `helm-mapkubeapis`
-
-1. Open your terminal in the machine you intend to use `helm-mapkubeapis` from and install the plugin:
-    ```shell
-    helm plugin install https://github.com/helm/helm-mapkubeapis
-    ```
-    
-    You will see output similar to the following:
-    ```console
-    Downloading and installing helm-mapkubeapis v0.4.1 ...
-    https://github.com/helm/helm-mapkubeapis/releases/download/v0.4.1/helm-mapkubeapis_0.4.1_darwin_amd64.tar.gz
-    Installed plugin: mapkubeapis
-    ```
-   
-    :::info important
-    Ensure that the `helm-mapkubeapis` plugin is at least v0.4.1, as older versions _do not_ support removal of resources.
-    :::
-
-1. Verify that the plugin was correctly installed:
-    ```shell
-    helm mapkubeapis --help
-    ```
-    
-    You will see output similar to the following:
-    ```console
-    Map release deprecated or removed Kubernetes APIs in-place
-    
-    Usage:
-    mapkubeapis [flags] RELEASE
-    
-    Flags:
-    --dry-run               simulate a command
-    -h, --help              help for mapkubeapis
-    --kube-context string   name of the kubeconfig context to use
-    --kubeconfig string     path to the kubeconfig file
-    --mapfile string        path to the API mapping file
-    --namespace string      namespace scope of the release
-    ```
-
-#### Cleaning Up Broken Releases
-
-After you install the `helm-mapkubeapis` plugin, clean up the releases that became broken after the upgrade to Kubernetes v1.25.
-
-1. Open your preferred terminal and make sure it's connected to the cluster you wish to target by running `kubectl cluster-info`.
-
-1. List all the releases you have installed in your cluster by running `helm list --all-namespaces`.
-
-1. Perform a dry run for each release you would like to clean up by running `helm mapkubeapis --dry-run <release-name> --namespace <release-namespace>`. The result of this command will inform you what resources are going to be replaced or removed.
-
-1. Finally, after reviewing the changes, perform a full run with `helm mapkubeapis <release-name> --namespace <release-namespace>`.
-
-#### Upgrading Charts to a Version That Supports Kubernetes v1.25
-
-You can proceed with your upgrade once any releases that had lingering PSPs are cleaned up. For Rancher-maintained workloads, follow the steps outlined in the [Removing PodSecurityPolicies from Rancher-maintained Apps & Marketplace workloads](#removing-podsecuritypolicies-from-rancher-maintained-apps--marketplace-workloads) section of this document.
-For workloads not maintained by Rancher, refer to the vendor documentation.
-
-:::caution
-Do not skip this step. Applications incompatible with Kubernetes v1.25 aren't guaranteed to work after a cleanup.
-:::
-
 ## Pod Security Admission Configuration Templates

 Rancher offers PSA configuration templates. These are pre-defined security configurations that you can apply to a cluster. Rancher admins (or those with the right permissions) can [create, manage, and edit](./psa-config-templates.md) PSA templates.
@@ -38,9 +38,6 @@ You can assign a PSA template at the same time that you create a downstream clus
 1. In the **Pod Security Admission Configuration Template** dropdown menu, select the template you want to assign.
 1. Click **Save**.

-### Hardening the Cluster
-
-If you select the **rancher-restricted** template but don't select a **CIS Profile**, you won't meet required CIS benchmarks. See the [RKE2 hardening guide](../../../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-hardening-guide.md) for more details.

 </TabItem>
 <TabItem value="RKE1">
@@ -120,6 +117,7 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
 - `cert-manager`
 - `cis-operator-system`
 - `fleet-default`
+- `fleet-local`
 - `ingress-nginx`
 - `istio-system`
 - `kube-node-lease`
@@ -70,7 +70,7 @@ To perform a backup, a custom resource of type Backup must be created.
          folder: rancher
          region: us-west-2
          endpoint: s3.us-west-2.amazonaws.com
-      resourceSetName: rancher-resource-set
+      resourceSetName: rancher-resource-set-full
      encryptionConfigSecretName: encryptionconfig
      schedule: "@every 1h"
      retentionCount: 10
@@ -78,7 +78,7 @@ To perform a backup, a custom resource of type Backup must be created.

    :::note

-    When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set`
+    When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set-full` or `rancher-resource-set-basic`.

    :::

@@ -128,6 +128,35 @@ Trying to delete and restore a downstream cluster can lead to a variety of issue

 Other services, which are backed up by Rancher Backups, often change and evolve. As this happens, their resources and backup needs may change as well. Some resources may not need to be backed up and some may not be backed up at all. It is important for teams to consider this in their development process and assess whether their related resourceSets are correctly capturing the proper set of resources for their services to be restored correctly.

+## Monitoring backups and restores
+
+Rancher offers out-of-the box monitoring features for the Backup Operator. They are disabled by default but can be easily enabled when deploying the operator Helm Chart.
+
+### Metrics
+
+Metrics can be enabled by setting `monitoring.metrics.enabled: true` and `monitoring.serviceMonitor.enabled: true` in the Helm Chart values. When enabled, the Operator exports the following metrics. Note that *rancher-monitoring* needs to be previously installed for the metrics to be properly exported.
+
+| **Metric Name**                                    | **Description**                                                                                                                              |
+|----------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
+| `rancher_backup_info`                              | Details on a specific Rancher Backup CR (labels: `name`, `status`, `resourceSetName`, `retentionCount`, `backupType`, `filename`, `storageLocation`, `nextSnapshot`, `lastSnapshot`). Type *GaugeVec*.                    |
+| `rancher_backup_count`                             | Number of existing Rancher Backup CRs. Type *Gauge*.                                                                                         |
+| `rancher_backups_attempted_total`                  | Total number of Rancher Backups processed by the Operator (labels: `name`). Type *CounterVec*.                                               |
+| `rancher_backups_failed_total`                     | Total number of failed Rancher Backups processed by this operator (labels: `name`). Type *CounterVec*.                                       |
+| `rancher_backup_duration_seconds`                  | Duration of each backup processed by the Operator in seconds (labels: `name`). Type *HistogramVec*, buckets can be customized by the user.   |
+| `rancher_backup_last_processed_timestamp_seconds`  | Unix time of when the last Backup was processed (in seconds) (labels: `name`). Type *GaugeVec*.                                              |
+| `rancher_restore_info`                             | Details on a specific Rancher Restore CR (labels: `name`, `status`, `fileName`, `prune`, `storageLocation`, `restoreTime`). Type *GaugeVec*. |
+| `rancher_restore_count`                            | Number of existing Rancher Restore CRs. Type *Gauge*.                                                                                        |
+
+### Alerting
+
+Only one alert is provided by default, 'BackupFailed', which warns users when a Backup fails to be processed by the Operator. It can be enabled by setting `monitoring.prometheusRules.defaultAlert.enabled: true`.
+
+Users can also deploy their own alerting rules by setting `monitoring.prometheusRules.customRules.enabled: true` and defining them under `monitoring.prometheusRules.customRules.rules`.
+
+### Dashboards
+
+Rancher also provides Grafana dashboards to help monitor the Backup Operator health. These, however, can only be deployed by the *rancher-monitoring* Helm Chart. To do so `rancherBackupMonitoring.dashboards.enabled: true` needs to be set.
+
 ## Conclusion

 Rancher Backups is a very useful tool, however it is somewhat limited in its scope and intended purposes. In order to avoid possible difficulties, it is important to follow the specific procedures described to ensure the proper operation of the chart.
@@ -28,7 +28,7 @@ The `rancher-backup` operator introduces three custom resources: Backups, Restor

 The ResourceSet defines which Kubernetes resources need to be backed up. The ResourceSet is not available to be configured in the Rancher UI because the values required to back up Rancher are predefined. This ResourceSet should not be modified.

-When a Backup custom resource is created, the `rancher-backup` operator calls the `kube-apiserver` to get the resources in the ResourceSet (specifically, the predefined `rancher-resource-set`) that the Backup custom resource refers to.
+When a Backup custom resource is created, the `rancher-backup` operator calls the `kube-apiserver` to get the resources in the ResourceSet that the Backup custom resource refers to.

 The operator then creates the backup file in the .tar.gz format and stores it in the location configured in the Backup resource.

@@ -168,7 +168,6 @@ Follow the steps to [install cert-manager](../../../getting-started/installation

 Use the same version of Helm to install Rancher, that was used on the first cluster.

-For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

 ```bash
 helm install rancher rancher-latest/rancher \
@@ -18,6 +18,12 @@ While restoring Rancher on the same setup, the operator will scale down the Ranc

 :::

+:::note Warning for Fleet users
+You must consider how to handle Kubernetes API server availability and paused GitRepos when restoring a Rancher setup
+that is running Fleet workloads. See the [Fleet
+documentation](http://fleet.rancher.io/gitrepo-add#backing-up-and-restoring) for more details.
+:::
+
 :::tip

 * Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
@@ -42,26 +42,6 @@ To display prerelease versions:
 1. Click **Preferences**.
 1. Under **Helm Charts**, select **Include Prerelease Versions**.

-### Feature Charts
-
-| **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
-| ---------------- | ------------ | ------------ |
-| external-ip-webhook | 100.0.0+up1.0.0 | 100.0.1+up1.0.1 |
-| harvester-cloud-provider | 100.0.2+up0.1.12 | 100.0.2+up0.1.12 |
-| harvester-csi-driver | 100.0.2+up0.1.11 | 100.0.2+up0.1.11 |
-| neuvector | 100.0.0+up2.2.0 | 100.0.0+up2.2.0 |
-| rancher-alerting-drivers | 100.0.0 | 100.0.2 |
-| rancher-backup | 2.0.1 | 2.1.2 |
-| rancher-cis-benchmark | 2.0.1 | 2.0.4 |
-| rancher-istio | 105.0.0+up1.19.6 | 105.4.0+up1.23.2 |
-| rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
-| rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
-| rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
-| rancher-sriov<sup>[1](#sriov-chart-deprecation-and-migration)</sup> | 100.0.0+up0.1.0 | 100.0.3+up0.1.0 |
-| rancher-vsphere-cpi | 100.3.0+up1.2.1 | 100.3.0+up1.2.1 |
-| rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
-| rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |
-
 ## Access Charts

 The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:
@@ -236,7 +216,7 @@ Rancher and Partner charts may have extra configurations available through custo

 To view all recent changes, click **Apps > Recent Operations** in the left navigation menu. From there you can view the calls, conditions, events, and logs.

-After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during inital installation. 
+After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during initial installation.

 Most Rancher tools have additional pages located in the toolbar below the **Apps** section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.

@@ -295,4 +275,4 @@ To migrate, follow these steps:
 - When determining the most recent version to display for the **Upgradable** column on the **Apps > Installed Apps** page, rather than only considering versions of the Helm chart from the repository it was installed from, Rancher considers versions of the Helm chart from all repositories on the cluster.

  For example, suppose you install `cert-manager` v1.13.0 from repository A, where v1.14.0 is now the most recent version available. In this case, you expect **Upgradable** to display v1.14.0. However, if the cluster also has access to repository B where v1.15.0 of `cert-manager` is available, then **Upgradable** displays v1.15.0 even though the original installation used repository A.
-  
+
@@ -57,6 +57,14 @@ GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard
 9. If you are using self-signed certificates, you will receive the message `certificate signed by unknown authority`. To work around this validation, copy the command starting with `curl` displayed in Rancher to your clipboard. Then run the command on a node where kubeconfig is configured to point to the cluster you want to import.
 10. When you finish running the command(s) on your node, click **Done**.

+:::important
+
+The `NO_PROXY` environment variable is not standardized, and the accepted format of the value can differ between applications. When configuring the `NO_PROXY` variable in Rancher, the value must adhere to the format expected by Golang.
+
+Specifically, the value should be a comma-delimited string which only contains IP addresses, CIDR notation, domain names, or special DNS labels (e.g. `*`). For a full description of the expected value format, refer to the [**upstream Golang documentation**](https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config)
+
+:::
+
 **Result:**

 - Your cluster is registered and assigned a state of **Pending**. Rancher is deploying resources to manage your cluster.
@@ -162,6 +170,13 @@ You can define the default behavior for newly created clusters or existing ones

 Changes to the global **imported-cluster-version-management** setting take effect during the cluster’s next reconciliation cycle.

+:::note
+
+If version management is enabled for a cluster, Rancher will deploy the system-upgrade-controller app, along with the associated Plans and other required Kubernetes resources, to the cluster. 
+If version management is disabled, Rancher will remove these components from the cluster.
+
+:::
+
 ## Configuring RKE2 and K3s Cluster Upgrades

 :::tip
@@ -269,15 +284,7 @@ Therefore, when Rancher registers a cluster, it assumes that several capabilitie

 However, if the cluster has a certain capability, such as the ability to use a pod security policy, a user of that cluster might still want to select pod security policies for the cluster in the Rancher UI. In order to do that, the user will need to manually indicate to Rancher that pod security policies are enabled for the cluster.

-By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given a pod security policy, or another capability, outside of Rancher.
-
-This example annotation indicates that a pod security policy is enabled:
-
-```json
-"capabilities.cattle.io/pspEnabled": "true"
-```
-
-The following annotation indicates Ingress capabilities. Note that the values of non-primitive objects need to be JSON encoded, with quotations escaped.
+By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given Ingress capabilities, or another capability, outside of Rancher. The following annotation indicates Ingress capabilities. Note that the values of non-primitive objects need to be JSON encoded, with quotations escaped.

 ```json
 "capabilities.cattle.io/ingressCapabilities": "[
@@ -294,7 +301,6 @@ These capabilities can be annotated for the cluster:
 - `loadBalancerCapabilities`
 - `nodePoolScalingSupported`
 - `nodePortRange`
- `pspEnabled`
 - `taintSupport`

 All the capabilities and their type definitions can be viewed in the Rancher API view, at `[Rancher Server URL]/v3/schemas/capabilities`.
@@ -159,7 +159,7 @@ stringData:
      "tenantId": "<tenant-id>",
      "subscriptionId": "<subscription-id>",
      "aadClientId": "<client-id>",
-      "aadClientSecret": "<tenant-id>",
+      "aadClientSecret": "<client-secret>",
      "resourceGroup": "docker-machine",
      "location": "westus",
      "subnetName": "docker-machine",  
@@ -244,7 +244,7 @@ Note that this chart reads the Cloud Provider Config from the secret in the `kub
        "tenantId": "<tenant-id>",
        "subscriptionId": "<subscription-id>",
        "aadClientId": "<client-id>",
-        "aadClientSecret": "<tenant-id>",
+        "aadClientSecret": "<client-secret>",
        "resourceGroup": "docker-machine",
        "location": "westus",
        "subnetName": "docker-machine",
@@ -1,63 +0,0 @@
---
-title: Creating an Aliyun ACK Cluster
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba"/>
-</head>
-
-You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK). Rancher has already implemented and packaged the [cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for ACK, but by default, this cluster driver is `inactive`. In order to launch ACK clusters, you will need to [enable the ACK cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activatingdeactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning ACK clusters.
-
-## Prerequisites Outside of Rancher
-
-:::caution
-
-Deploying to ACK will incur charges.
-
-:::
-
-1. In Aliyun, activate the following services in their respective consoles.
-
-    - [Container Service](https://cs.console.aliyun.com)
-    - [Resource Orchestration Service](https://ros.console.aliyun.com)
-    - [RAM](https://ram.console.aliyun.com)
-
-2. Make sure that the account you will be using to create the ACK cluster has the appropriate permissions. Referring to the official Alibaba Cloud documentation about [Role authorization](https://www.alibabacloud.com/help/doc-detail/86483.htm) and [Use the Container Service console as a RAM user](https://www.alibabacloud.com/help/doc-detail/86484.htm) for details.
-
-3. In Alibaba Cloud, create an [access key](https://www.alibabacloud.com/help/doc-detail/53045.html).
-
-4. In Alibaba Cloud, create an [SSH key pair](https://www.alibabacloud.com/help/doc-detail/51793.html). This key is used to access nodes in the Kubernetes cluster.
-
-## Prerequisite in Rancher
-
-You will need to enable the Alibaba ACK cluster driver:
-
-1. Click **☰ > Cluster Management**.
-1. Click **Drivers**.
-1. In the **Cluster Drivers** tab, go to the **Alibaba ACK** cluster driver and click **⋮ > Activate**.
-
-When the cluster driver is finished downloading, you will be able to create Alibaba ACK clusters in Rancher.
-
-## Create an ACK Cluster
-
-1. Click **☰ > Cluster Management**.
-1. From the **Clusters** page, click **Create**.
-1. Choose **Alibaba ACK**.
-1. Enter a **Cluster Name**.
-1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
-1. Configure **Account Access** for the ACK cluster. Choose the geographical region in which to build your cluster, and input the access key that was created as part of the prerequisite steps.
-1. Click **Next: Configure Cluster**, then choose cluster type, the version of Kubernetes and the availability zone.
-1. If you choose **Kubernetes** as the cluster type, Click **Next: Configure Master Nodes**, then complete the **Master Nodes** form.
-1. Click **Next: Configure Worker Nodes**, then complete the **Worker Nodes** form.
-1. Review your options to confirm they're correct. Then click **Create**.
-
-**Result:**
-
-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
-
-You can access your cluster after its state is updated to **Active**.
-
-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -1,104 +0,0 @@
---
-title: Creating a Huawei CCE Cluster
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei"/>
-</head>
-
-You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine (CCE). Rancher has already implemented and packaged the [cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for CCE, but by default, this cluster driver is `inactive`. In order to launch CCE clusters, you will need to [enable the CCE cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activatingdeactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning CCE clusters.
-
-## Prerequisites in Huawei
-
-:::caution
-
-Deploying to CCE will incur charges.
-
-:::
-
-1. Find your project ID in Huawei CCE portal. See the CCE documentation on how to [manage your projects](https://doc.hcs.huawei.com/api/cce/cce_02_0341.html#cce_02_0341__section17571944123214).
-
-2. Create an [Access Key ID and Secret Access Key](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0079477318.html).
-
-## Prerequisite in Rancher
-
-You will need to enable the Huawei CCE cluster driver:
-
-1. Click **☰ > Cluster Management**.
-1. Click **Drivers**.
-1. In the **Cluster Drivers** tab, go to the **Huawei CCE** cluster driver and click **⋮ > Activate**.
-
-When the cluster driver is finished downloading, you will be able to create Huawei CCE clusters in Rancher.
-
-## Limitations
-
-Huawei CCE service doesn't support the ability to create clusters with public access through their API. You are required to run Rancher in the same VPC as the CCE clusters that you want to provision.
-
-## Create the CCE Cluster
-
-1. From the **Clusters** page, click **Create**.
-1. Click **Huawei CCE**.
-1. Enter a **Cluster Name**.
-1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
-1. Enter **Project Id**, Access Key ID as **Access Key** and Secret Access Key **Secret Key**. Then Click **Next: Configure cluster**. Fill in the cluster configuration. For help filling out the form, refer to [Huawei CCE Configuration.](#huawei-cce-configuration)
-1. Fill the following node configuration of the cluster. For help filling out the form, refer to [Node Configuration.](#node-configuration)
-1. Click **Create** to create the CCE cluster.
-
-**Result:**
-
-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
-
-You can access your cluster after its state is updated to **Active**.
-
-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
-
-## Huawei CCE Configuration
-
-|Settings|Description|
-|---|---|
-| Cluster Type | Which type or node you want to include into the cluster, `VirtualMachine` or `BareMetal`. |
-| Description | The description of the cluster. |
-| Master Version | The Kubernetes version. |
-| Management Scale Count | The max node count of the cluster. The options are 50, 200 and 1000. The larger of the scale count, the more the cost. |
-| High Availability | Enable master node high availability. The cluster with high availability enabled will have more cost. |
-| Container Network Mode | The network mode used in the cluster. `overlay_l2` and `vpc-router` is supported in `VirtualMachine` type and `underlay_ipvlan` is supported in `BareMetal` type |
-| Container Network CIDR | Network CIDR for the cluster. |
-| VPC Name | The VPC name which the cluster is going to deploy into. Rancher will create one if it is blank. |
-| Subnet Name | The Subnet name which the cluster is going to deploy into. Rancher will create one if it is blank. |
-| External Server | This option is reserved for the future we can enable CCE cluster public access via API. For now, it is always disabled. |
-| Cluster Label | The labels for the cluster. |
-| Highway Subnet | This option is only supported in `BareMetal` type. It requires you to select a VPC with high network speed for the bare metal machines. |
-
-:::note
-
-If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher)
-
-:::
-
-## Node Configuration
-
-|Settings|Description|
-|---|---|
-| Zone | The available zone at where the node(s) of the cluster is deployed. |
-| Billing Mode | The bill mode for the cluster node(s). In `VirtualMachine` type, only `Pay-per-use` is supported. in `BareMetal`, you can choose `Pay-per-use` or `Yearly/Monthly`. |
-| Validity Period | This option only shows in `Yearly/Monthly` bill mode. It means how long you want to pay for the cluster node(s). |
-| Auto Renew | This option only shows in `Yearly/Monthly` bill mode. It means that the cluster node(s) will renew the `Yearly/Monthly` payment automatically or not. |
-| Data Volume Type | Data volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
-| Data Volume Size | Data volume size for the cluster node(s) |
-| Root Volume Type | Root volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
-| Root Volume Size | Root volume size for the cluster node(s) |
-| Node Flavor | The node flavor of the cluster node(s). The flavor list in Rancher UI is fetched from Huawei Cloud. It includes all the supported node flavors. |
-| Node Count | The node count of the cluster |
-| Node Operating System | The operating system for the cluster node(s). Only `EulerOS 2.2` and `CentOS 7.4` are supported right now. |
-| SSH Key Name | The ssh key for the cluster node(s) |
-| EIP | The public IP options for the cluster node(s). `Disabled` means that the cluster node(s) are not going to bind a public IP. `Create EIP` means that the cluster node(s) will bind one or many newly created Eips after provisioned and more options will be shown in the UI to set the to-create EIP parameters. And `Select Existed EIP` means that the node(s) will bind to the EIPs you select.  |
-| EIP Count | This option will only be shown when `Create EIP` is selected. It means how many EIPs you want to create for the node(s). |
-| EIP Type | This option will only be shown when `Create EIP` is selected. The options are `5_bgp` and `5_sbgp`. |
-| EIP Share Type | This option will only be shown when `Create EIP` is selected. The only option is `PER`. |
-| EIP Charge Mode | This option will only be shown when `Create EIP` is selected. The options are pay by `BandWidth` and pay by `Traffic`. |
-| EIP Bandwidth Size | This option will only be shown when `Create EIP` is selected. The BandWidth of the EIPs. |
-| Authentication Mode | It means enabling `RBAC` or also enabling `Authenticating Proxy`. If you select `Authenticating Proxy`, the certificate which is used for authenticating proxy will be also required. |
-| Node Label | The labels for the cluster node(s). Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) |
@@ -17,9 +17,6 @@ Rancher supports the following Kubernetes providers:
 - [Google GKE (Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)
 - [Amazon EKS (Amazon Elastic Container Service for Kubernetes)](https://aws.amazon.com/eks/)
 - [Microsoft AKS (Azure Kubernetes Service)](https://azure.microsoft.com/en-us/services/kubernetes-service/)
- [Alibaba ACK (Alibaba Cloud Container Service for Kubernetes)](https://www.alibabacloud.com/product/kubernetes)
- [Tencent TKE (Tencent Kubernetes Engine)](https://intl.cloud.tencent.com/product/tke)
- [Huawei CCE (Huawei Cloud Container Engine)](https://www.huaweicloud.com/en-us/product/cce.html)

 ## Hosted Kubernetes Provider Authentication

@@ -28,6 +25,3 @@ When using Rancher to create a cluster hosted by a provider, you are prompted fo
 - [Creating a GKE Cluster](gke.md)
 - [Creating an EKS Cluster](eks.md)
 - [Creating an AKS Cluster](aks.md)
- [Creating an ACK Cluster](alibaba.md)
- [Creating a TKE Cluster](tencent.md)
- [Creating a CCE Cluster](huawei.md)
@@ -1,103 +0,0 @@
---
-title: Creating a Tencent TKE Cluster
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent"/>
-</head>
-
-You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE). Rancher has already implemented and packaged the [cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for TKE, but by default, this cluster driver is `inactive`. In order to launch TKE clusters, you will need to [enable the TKE cluster driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activatingdeactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning TKE clusters.
-
-## Prerequisites in Tencent
-
-:::caution
-
-Deploying to TKE will incur charges.
-
-:::
-
-1. Make sure that the account you will be using to create the TKE cluster has the appropriate permissions by referring to the  [Cloud Access Management](https://intl.cloud.tencent.com/document/product/598/10600) documentation for details.
-
-2. Create a [Cloud API Secret ID and Secret Key](https://console.cloud.tencent.com/capi).
-
-3. Create a [Private Network and Subnet](https://intl.cloud.tencent.com/document/product/215/4927) in the region that you want to deploy your Kubernetes cluster.
-
-4. Create a [SSH key pair](https://intl.cloud.tencent.com/document/product/213/6092). This key is used to access the nodes in the Kubernetes cluster.
-
-## Prerequisite in Rancher
-
-You will need to enable the Tencent TKE cluster driver:
-
-1. Click **☰ > Cluster Management**.
-1. Click **Drivers**.
-1. In the **Cluster Drivers** tab, go to the **Tencent TKE** cluster driver and click **⋮ > Activate**.
-
-When the cluster driver is finished downloading, you will be able to create Tencent TKE clusters in Rancher.
-
-## Create a TKE Cluster
-
-1. From the **Clusters** page, click **Create**.
-
-2. Choose **Tencent TKE**.
-
-3. Enter a **Cluster Name**.
-
-4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
-
-5. Configure **Account Access** for the TKE cluster. Complete each drop-down and field using the information obtained in [Prerequisites](#prerequisites-in-tencent).
-
-    | Option    | Description                                                                                                          |
-    | ---------- | -------------------------------------------------------------------------------------------------------------------- |
-    | Region     | From the drop-down chooses the geographical region in which to build your cluster.                                    |
-    | Secret ID  | Enter the Secret ID that you obtained from the Tencent Cloud Console. |
-    | Secret Key | Enter the Secret key that you obtained from Tencent Cloud Console. |
-
-6. Click `Next: Configure Cluster` to set your TKE cluster configurations.
-
-    | Option | Description                                                                                                          |
-    | ---------- | -------------------------------------------------------------------------------------------------------------------- |
-    | Kubernetes Version | The TKE only supports Kubernetes version 1.10.5 now.  |
-    | Node Count  | Enter the amount of worker node you want to purchase for your Kubernetes cluster, up to 100. |
-    | VPC | Select the VPC name that you have created in the Tencent Cloud Console. |
-    | Container Network CIDR | Enter the CIDR range of your Kubernetes cluster, you may check the available range of the CIDR in the VPC service of the Tencent Cloud Console. Default to 172.16.0.0/16. |
-
-    :::note
-
-    If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher)
-
-    :::
-
-7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster.
-
-    | Option | Description                                                                                                          |
-    | ---------- | -------------------------------------------------------------------------------------------------------------------- |
-    | Availability Zone | Choose the availability zone of the VPC region.  |
-    | Subnet  | Select the Subnet that you have created within the VPC, and add a new one if you don't have it in the chosen availability zone. |
-    | Instance Type | From the drop-down chooses the VM instance type that you want to use for the TKE cluster, default to S2.MEDIUM4 (CPU 2 Memory 4 GiB). |
-
-8. Click `Next: Configure Instance` to configure the VM instance that will use for your TKE cluster.
-
-    Option | Description
-    -------|------------
-    Operating System | The name of the operating system, currently supports Centos7.2x86_64 or ubuntu16.04.1 LTSx86_64
-    Security Group | Security group ID, default does not bind any security groups.
-    Root Disk Type | System disk type. System disk type restrictions are detailed in the [CVM instance configuration](https://cloud.tencent.com/document/product/213/11518).
-    Root Disk Size | System disk size. Linux system adjustment range is 20 - 50G, step size is 1.
-    Data Disk Type | Data disk type, default value to the SSD cloud drive
-    Data Disk Size | Data disk size (GB), the step size is 10
-    Band Width Type | Type of bandwidth, PayByTraffic or PayByHour
-    Band Width | Public network bandwidth (Mbps)
-    Key Pair | Key id, after associating the key can be used to logging to the VM node
-
-9. Click **Create**.
-
-**Result:**
-
-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
-
-You can access your cluster after its state is updated to **Active**.
-
-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -14,15 +14,16 @@ This page is about secrets in general. For details on setting up a private regis

 :::

-When configuring a workload, you'll be able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount.
+When configuring a workload, you are able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount.

-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)
+Mounted secrets are 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

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. Go to the cluster where you want to add a secret and click **Explore**.
 1. To navigate to secrets, you may click either **Storage > Secrets** or **More Resources > Core > Secrets**.
+1. Select the **Namespaced** tab.
 1. Click **Create**.
 1. Select the type of secret you want to create.
 1. Select a **Namespace** for the secret.
@@ -48,32 +49,66 @@ Mounted secrets will be updated automatically unless they are mounted as subpath

 **Result:** Your secret is added to the namespace you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.

-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)
+Mounted secrets are 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

-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:
+When creating a secret in a project scope, the secret is copied into all namespaces within the project.

-1. In the upper left corner, click **☰ > Global Settings** in the dropdown.
-1. Click **Feature Flags**.
-1. Go to the `legacy` feature flag and click **Activate**.
-1. In the upper left corner, click **☰ > Cluster Management** in the dropdown.
-1. Go to the cluster that you created and click **Explore.**
-1. Click **Legacy > Projects**.
-1. In the top navigation bar, filter to see only one project.
-1. In the left navigation bar, click **Secrets**.
-1. Click **Add Secret**.
+### Creating a Project Scoped Secret in the UI

-**Result:** Your secret is added to the individual project you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Go to the cluster where you want to add a secret and click **Explore**.
+1. To navigate to secrets, you may click either **Storage > Secrets** or **More Resources > Core > Secrets**.
+1. Select the **Project Scoped** tab.
+1. Click **Create Project Scoped Secret**.
+1. Select the type of secret you want to create.
+1. Select a **Project** for the secret.
+1. Enter a **Name** for the secret.

-Since project-scoped secrets are set at the project level, any changes made at the namespace level will be overwritten.
+    :::note

-:::note
+    Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a namespace can have duplicate names. If you create a project scoped secret that has the same name as an existing secret in one of the project namespaces, the existing secret is overwritten.

-Project-scoped secrets on the local cluster are only visible when a single project is selected.
+    :::

-:::
+1. From **Data**, click **Add** to add a key-value pair. Add as many values as you need.
+
+    :::tip
+
+    You can add multiple key-value pairs to the secret by copying and pasting.
+
+    :::
+
+    ![](/img/bulk-key-values.gif)
+
+1. Click **Save**.
+
+**Result:** Your secret is added to each namespace within the project. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
+
+### Creating a Project Scoped Secret with kubectl
+
+Project scoped secrets work by creating the original secret on the management cluster in what's known as the "Project Backing Namespace". Rancher stores important project related information in this namespace. You can find it in the `status.backingNamespace` field in the project CRD, or by doing `kubectl get projects -A` in the management cluster.
+
+In order for the secret to be acknowledged by Rancher as a project scoped secret, it also needs the label `management.cattle.io/project-scoped-secret: <projectID>`.
+
+Example yaml:
+
+```
+apiVersion: v1
+data:
+  key: ZG9n
+kind: Secret
+metadata:
+  labels:
+    management.cattle.io/project-scoped-secret: p-vwxyz
+  name: test-secret
+  namespace: c-abc123-p-vwxyz
+type: Opaque
+```
+
+In the above YAML, the namespace is the backing namespace of project `p-vwxyz` and the project scoped secret label references the projectID. When applied to the management cluster, all namespaces within the project `p-vwxyz` contain a copy of `test-secret`.

 ## What's Next?

@@ -6,41 +6,11 @@ title: Launching Kubernetes with Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher"/>
 </head>

-You can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, you can choose between [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) or [RKE2](https://docs.rke2.io) distributions. Rancher can launch Kubernetes on any computers, including:
-
- Bare-metal servers
- On-premise virtual machines
- Virtual machines hosted by an infrastructure provider
+Rancher allows you to launch a Kubernetes cluster on different types of nodes, including bare-metal servers, on-premise virtual machines, and virtual machines from an infrastructure provider. When deploying Kubernetes to these nodes, Rancher gives you the option to use [RKE2](https://docs.rke2.io).

 Rancher can install Kubernetes on existing nodes, or it can dynamically provision nodes in an infrastructure provider and install Kubernetes on them.

-Rancher can also create pools of nodes. One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
-
-## RKE
-
-### Requirements
-
-If you use RKE to set up a cluster, your nodes must meet the [requirements](../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) for nodes in downstream user clusters.
-
-### Launching Kubernetes on New Nodes in an Infrastructure Provider
-
-Using Rancher, you can create pools of nodes based on a [node template](use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates). This node template defines the parameters you want to use to launch nodes in your cloud providers.
-
-One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
-
-For more information, refer to the section on [launching Kubernetes on new nodes.](use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
-
-### Launching Kubernetes on Existing Custom Nodes
-
-In this scenario, you want to install Kubernetes on bare-metal servers, on-prem virtual machines, or virtual machines that already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
-
-If you want to reuse a node from a previous custom cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
-
-For more information, refer to the section on [custom nodes.](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md)
-
-### 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)
+Rancher can also create pools of machines. One benefit of installing Kubernetes on machine pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the machine pool is as expected.

 ## RKE2

@@ -54,11 +24,17 @@ If you use RKE2 to set up a cluster, your nodes must meet the [requirements](htt

 ### Launching Kubernetes on New Nodes in an Infrastructure Provider

-RKE2 provisioning is built on top of a new provisioning framework that leverages the upstream [Cluster API](https://github.com/kubernetes-sigs/cluster-api) project. With this new provisioning framework, you can:
+RKE2 provisioning is built on top of a new provisioning framework that leverages the upstream [Cluster API (CAPI)](https://github.com/kubernetes-sigs/cluster-api) project. With this new provisioning framework, you can:

- Provision RKE2 clusters onto any provider for which Rancher has a node driver
- Fully configure RKE2 clusters within Rancher
- Choose CNI options Calico, Cilium, and Multus in addition to Canal
+- Provision RKE2 clusters onto any provider for which Rancher has a node driver.
+- Fully configure RKE2 clusters within Rancher.
+- Choose CNI options Calico, Cilium, and Multus in addition to Canal.
+
+When you make changes to your cluster configuration in RKE2, this may result in nodes reprovisioning. This is controlled by CAPI controllers and not by Rancher itself. Note that for etcd nodes, the same behavior does not apply.
+
+The following are some specific example configuration changes that may cause the described behavior:
+
+- When editing the cluster and enabling drain before delete, the existing control plane nodes and worker are deleted and new nodes are created.

 RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.

@@ -75,10 +51,10 @@ Windows Support for RKE2 Custom Clusters requires choosing Calico as the CNI.

 ### Launching Kubernetes on Existing Custom Nodes

-RKE2 provisioning also allows you to install custom clusters on pre-provisioned VMs or bare-metal nodes.
+RKE2 provisioning also allows you to install custom clusters on previously provisioned VMs or bare-metal nodes.

-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.
+If you want to reuse a node from a previous custom cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) 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

-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)
+The most common way to programmatically deploy RKE2 clusters through Rancher is by using the [Rancher2 Terraform provider](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster_v2).
@@ -1,37 +0,0 @@
---
-title: Behavior Differences Between RKE1 and RKE2
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/rke1-vs-rke2-differences"/>
-</head>
-
-<EOLRKE1Warning />
-
-RKE2, also known as RKE Government, is a Kubernetes distribution that focuses on security and compliance for U.S. Federal Government entities. It is considered the next iteration of the Rancher Kubernetes Engine, now known as RKE1.
-
-RKE1 and RKE2 have several slight behavioral differences to note, and this page will highlight some of these at a high level.
-
-### Control Plane Components
-
-RKE1 uses Docker for deploying and managing control plane components, and it also uses Docker as the container runtime for Kubernetes. By contrast, RKE2 launches control plane components as static pods that are managed by the kubelet. RKE2's container runtime is containerd, which allows things such as mirroring a container image registry. RKE1 with Docker does not allow mirroring.
-
-### Cluster API
-
-RKE2/K3s provisioning is built on top of the Cluster API (CAPI) upstream framework which often makes RKE2-provisioned clusters behave differently than RKE1-provisioned clusters.
-
-When you make changes to your cluster configuration in RKE2, this **may** result in nodes reprovisioning. This is controlled by CAPI controllers and not by Rancher itself. Note that for etcd nodes, the same behavior does not apply.
-
-The following are some specific example configuration changes that may cause the described behavior:
-
- When editing the cluster and enabling `drain before delete`, the existing control plane nodes and worker are deleted and new nodes are created.
-
-Users who are used to RKE1 provisioning should take note of this new RKE2 behavior which may be unexpected.
-
-### Terminology
-
-You will notice that some terms have changed or gone away going from RKE1 to RKE2. For example, in RKE1 provisioning, you use **node templates**; in RKE2 provisioning, you can configure your cluster node pools when creating or editing the cluster. Another example is that the term **node pool** in RKE1 is now known as **machine pool** in RKE2.
-
-
-
-
@@ -6,53 +6,11 @@ title: Creating a DigitalOcean Cluster
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster"/>
 </head>

-In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in DigitalOcean.
+In this section, you'll learn how to deploy an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in DigitalOcean.

-First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
+First, you will set up your DigitalOcean cloud credentials in Rancher.

-Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
-
-<Tabs>
-<TabItem value="RKE">
-
-1. [Create your cloud credentials](#1-create-your-cloud-credentials)
-2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
-3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
-
-### 1. Create your cloud credentials
-
-1. Click **☰ > Cluster Management**.
-1. Click **Cloud Credentials**.
-1. Click **Create**.
-1. Click **DigitalOcean**.
-1. Enter your Digital Ocean credentials.
-1. Click **Create**.
-
-**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
-
-### 2. Create a node template with your cloud credentials
-
-Creating a [node template](use-new-nodes-in-an-infra-provider.md#node-templates) for DigitalOcean will allow Rancher to provision new nodes in DigitalOcean. Node templates can be reused for other clusters.
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**.
-1. Click **Add Template**.
-1. Click **DigitalOcean**.
-1. Fill out a node template for DigitalOcean. For help filling out the form, refer to [DigitalOcean Node Template Configuration.](../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean.md)
-
-### 3. Create a cluster with node pools using the node template
-
-1. Click **☰ > Cluster Management**.
-1. On the **Clusters** page, click **Create**.
-1. Click **DigitalOcean**.
-1. Enter a **Cluster Name**.
-1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.](use-new-nodes-in-an-infra-provider.md)
-1. **In the Cluster Configuration** section, choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
-1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
-1. Click **Create**.
-
-</TabItem>
-<TabItem value="RKE2">
+Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define machine pools for it. Each machine pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the machine pool.

 ### 1. Create your cloud credentials

@@ -77,13 +35,10 @@ Use Rancher to create a Kubernetes cluster in DigitalOcean.
 1. Enter a **Cluster Name**.
 1. Create a machine pool for each Kubernetes role. Refer to the [best practices](use-new-nodes-in-an-infra-provider.md#node-roles) for recommendations on role assignments and counts.
    1. For each machine pool, define the machine configuration. Refer to the [DigitalOcean machine configuration reference](../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean.md) for information on configuration options.
-1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2 cluster configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md)
+1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) and [K3s](../../../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) cluster configuration reference.
 1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
 1. Click **Create**.

-</TabItem>
-</Tabs>
-
 **Result:**

 Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
@@ -0,0 +1,107 @@
+---
+title: Creating a Google Compute Engine cluster
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-google-gce-cluster"/>
+</head>
+
+
+In this section, you'll learn how to use Rancher to provision an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster on the Google Cloud Platform (GCP) using Google Compute Engine (GCE) through Rancher.
+
+
+First, you will enable the GCE node driver in the Rancher UI. Then, you follow the steps to create a GCP service account with the necessary permissions, and generate a JSON key file. This key file will be used to create a cloud credential in Rancher. 
+
+
+Then, you will create a GCE cluster in Rancher, and when configuring the cluster, you will define machine pools for it. Each machine pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE2 onto the new nodes, and it will set up each node with the Kubernetes role defined by the machine pool.
+
+
+1. [Enable the GCE node driver](#1-enable-the-gce-node-driver)
+1. [Create your cloud credential](#2-create-a-cloud-credential)
+1. [Create a GCE cluster with your cloud credential](#3-create-a-cluster-using-the-cloud-credential)
+1. [GCE Best Practices](#gce-best-practices)
+
+### Prerequisites
+
+1.   A valid Google Cloud Platform account and project.
+1.   A GCP Service Account JSON key file. The service account associated with this key must have the following IAM roles:
+      1. **Compute Admin**
+      1. **Service Account User**
+      1. **Viewer**
+1. A VPC Network to provision VMs within. 
+
+Refer to the [GCP documentation](https://cloud.google.com/iam/docs/service-account-overview) on creating and managing service account keys for more details.
+
+
+### 1. Enable the GCE node driver
+
+The GCE node driver is not enabled by default in Rancher. You must enable it before you can provision GCE clusters, or work with GCE specific CRDs.
+
+1.  Click **☰ > Cluster Management**.
+1.  On the left hand side, click **Drivers**.
+1.  Open the **Node Drivers** tab.
+1.  Find the **Google GCE** driver and select **⋮ > Activate**.
+
+
+### 2. Create a cloud credential
+
+1. Click **☰ > Cluster Management**.
+1. Click **Cloud Credentials**.
+1. Click **Create**.
+1. Click **Google**.
+1. Enter your GCP Service Account JSON key file.
+1. Click **Create**.
+
+**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials in other clusters. Depending on the permissions granted to the service account, this credential may also be used for GKE clusters.
+
+
+### 3. Create a cluster using the cloud credential
+
+1. Click **☰ > Cluster Management**.
+1. On the **Clusters** page, click **Create**.
+1. Click **Google GCE**.
+1. Select a **Cloud Credential** and provide the GCP project to create the VM in.
+1. Enter a **Cluster Name**.
+1. Create a machine pool for each Kubernetes role. Refer to the [best practices](use-new-nodes-in-an-infra-provider.md#node-roles) for recommendations on role assignments and counts.
+  1. For each machine pool, define the machine configuration. Refer to the [Google GCE machine configuration reference](../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/google-gce.md) for information on configuration options.
+1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) and [K3s](../../../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) cluster configuration reference.
+1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
+1. Click **Create**.
+
+
+**Result:**
+
+Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+
+You can access your cluster after its state is updated to **Active**.
+
+**Active** clusters are assigned two Projects:
+
+- `Default`, containing the `default` namespace
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
+### GCE Best Practices
+
+#### External Firewall Rules, Open Ports, and ACE
+
+If the cluster being provisioned will utilize the [Authorized Cluster Endpoint (ACE) feature](../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster), controlplane nodes must expose port `6443`. This port is not exposed in the default machine pool configuration to prevent it from being exposed across all cluster nodes, and to reduce the number of firewall rules created by Rancher. 
+
+In order for ACE to work as expected, you must specify this port in the Rancher UI when configuring the controlplane machine pool by enabling the `Expose external ports` checkbox, under the `Show Advanced` section of the machine pool configuration UI. Alternatively, you may manually create a custom firewall rule in GCP and provide the related network tag in the controlplane machine-pool configuration.
+
+#### Internal Firewall Rules
+
+Rancher will automatically create a firewall rule and network tag to facilitate communication between cluster nodes internally within the specified VPC network. This rule will contain the minimum number of ports required to create an RKE2/K3s cluster. 
+
+If you need to extend the number of ports exposed internally between cluster nodes, a new firewall rule should be manually created, and the associated network tag assigned to the relevant machine pools. If desired, the automatic creation of the internal firewall rule can be disabled for each given machine pool when creating or updating the cluster. 
+
+#### Cross Network Deployments
+
+While it is possible to deploy different machine pools into different VPC networks, the internal firewall rule created by Rancher does not support this configuration by default. To create machine pools in different networks, additional firewall rules to facilitate communication between nodes in different networks must be manually created.
+
+
+## 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:
+
+- **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-from-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.
@@ -7,11 +7,11 @@ description: Learn the prerequisites and steps required in order for you to crea
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster"/>
 </head>

-In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Amazon EC2.
+In this section, you'll learn how to deploy an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in Amazon EC2.

-First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
+First, you will set up your EC2 cloud credentials in Rancher.

-Then you will create an EC2 cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
+Then you will create an EC2 cluster in Rancher, and when configuring the new cluster, you will define machine pools for it. Each machine pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the machine pool.

 ### Prerequisites

@@ -26,64 +26,6 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu

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

-<Tabs>
-<TabItem value="RKE">
-
-1. [Create your cloud credentials](#1-create-your-cloud-credentials)
-2. [Create a node template with your cloud credentials and information from EC2](#2-create-a-node-template-with-your-cloud-credentials-and-information-from-ec2)
-3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
-
-### 1. Create your cloud credentials
-
-1. Click **☰ > Cluster Management**.
-1. Click **Cloud Credentials**.
-1. Click **Create**.
-1. Click **Amazon**.
-1. Enter a name for the cloud credential.
-1. In the **Default Region** field, select the AWS region where your cluster nodes will be located.
-1. Enter your AWS EC2 **Access Key** and **Secret Key**.
-1. Click **Create**.
-
-**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
-
-### 2. Create a node template with your cloud credentials and information from EC2
-
-Creating a [node template](use-new-nodes-in-an-infra-provider.md#node-templates) for EC2 will allow Rancher to provision new nodes in EC2. Node templates can be reused for other clusters.
-
-1. Click **☰ > Cluster Management**.
-1. Click **RKE1 Configuration > Node Templates**
-1. Click **Add Template**.
-1. Fill out a node template for EC2. For help filling out the form, refer to [EC2 Node Template Configuration.](../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2.md)
-1. Click **Create**.
-
-    :::note
-
-    If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
-
-    :::
-
-### 3. Create a cluster with node pools using the node template
-
-Add one or more node pools to your cluster. For more information about node pools, see [this section.](use-new-nodes-in-an-infra-provider.md)
-
-1. Click **☰ > Cluster Management**.
-1. On the **Clusters** page, click **Create**.
-1. Click **Amazon EC2**.
-1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.](use-new-nodes-in-an-infra-provider.md)
-1. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
-1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers](../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
-
-    :::note
-
-    If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
-
-    :::
-
-1. Click **Create**.
-
-</TabItem>
-<TabItem value="RKE2">
-
 ### 1. Create your cloud credentials

 If you already have a set of cloud credentials to use, skip this section.
@@ -97,7 +39,7 @@ If you already have a set of cloud credentials to use, skip this section.
 1. Enter your AWS EC2 **Access Key** and **Secret Key**.
 1. Click **Create**.

-**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
+**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster.

 ### 2. Create your cluster

@@ -109,13 +51,10 @@ If you already have a set of cloud credentials to use, skip this section.
 1. Enter a **Cluster Name**.
 1. Create a machine pool for each Kubernetes role. Refer to the [best practices](use-new-nodes-in-an-infra-provider.md#node-roles) for recommendations on role assignments and counts.
    1. For each machine pool, define the machine configuration. Refer to [the EC2 machine configuration reference](../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2.md) for information on configuration options.
-1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2 cluster configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md)
+1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) and [K3s](../../../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) cluster configuration reference.
 1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
 1. Click **Create**.

-</TabItem>
-</Tabs>
-
 **Result:**

 Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
--- a/Show More
+++ b/Show More