Merge branch 'v2.12.0' into gce

2026-09-25 20:48:11 +00:00 · 2025-07-25 16:34:02 -07:00
parent c35593dd27 2ada0bb001
commit 8f9fa152d4
480 changed files with 3560 additions and 233657 deletions
@@ -4,8 +4,6 @@ on:
  pull_request_target:
    types:
      - closed
-    branches: 
-      - main
    paths-ignore:
      - '**/README.md'

@@ -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.

@@ -8,8 +8,14 @@ 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 k8s supported by Rancher with the feature will have the aggregation layer configured by default. If you suspect your cluster may not be configured properly, see the [Kubernetes Aggregation Layer docs](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) for information on configuring the aggregation layer.
+
+:::note
+
+If the underlying kubernetes distro does not support the aggregation layer, you must migrate to a distro that does before upgrading.
+
+:::
@@ -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
+
+Admins can delete any Kubeconfig, while regular users can only delete their own. When a Kubeconfig is deleted, the kubeconfig tokens are also deleted.
+E.g. using a service account `system:admin` will lead to the following 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,114 @@
+---
+title: Tokens
+---
+
+<head>
+    <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/tokens"/>
+</head>
+
+## 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
+
+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`
@@ -16,10 +16,7 @@ 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.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 31, 2025 |

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

@@ -199,7 +199,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 +239,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 +287,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 \
@@ -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>
@@ -152,8 +152,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 \
  --namespace cattle-system \
@@ -186,8 +184,6 @@ 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,7 +26,30 @@ 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.
@@ -62,8 +62,6 @@ 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). |
-

 ### Bootstrap Password

@@ -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).
@@ -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

@@ -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.

@@ -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 compliance 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**.
@@ -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 Compliance 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.
@@ -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 Compliance 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 .
+```
@@ -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/next/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 \
@@ -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,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.
@@ -11,54 +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:
@@ -110,15 +62,6 @@ After you install the `helm-mapkubeapis` plugin, clean up the releases that beca

 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.
@@ -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`.

    :::

@@ -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 \
@@ -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`.
@@ -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?

@@ -1,43 +0,0 @@
---
-title: Adding a Pod Security Policy
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/add-a-pod-security-policy"/>
-</head>
-
-:::note Prerequisite:
-
-The options below are available only for clusters that are [launched using RKE.](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)
-
-:::
-
-When your cluster is running pods with security-sensitive configurations, assign it a [pod security policy](../authentication-permissions-and-global-configuration/create-pod-security-policies.md), which is a set of rules that monitors the conditions and settings in your pods. If a pod doesn't meet the rules specified in your policy, the policy stops it from running.
-
-You can assign a pod security policy when you provision a cluster. However, if you need to relax or restrict security for your pods later, you can update the policy while editing your cluster.
-
-1. Click **☰ > Cluster Management**.
-1. Go to the cluster to which you want to apply a pod security policy and click **⋮ > Edit Config**.
-1. From **Pod Security Policy Support**, select **Enabled**.
-
-    :::note
-
-    This option is only available for clusters [provisioned by RKE](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
-
-    :::
-
-4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
-
-    Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-psps) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#creating-psps) as well.
-
-5. Click **Save**.
-
-**Result:** The pod security policy is applied to the cluster and any projects within the cluster.
-
-:::note
-
-Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run.
-
-To check if a running workload passes your pod security policy, clone or upgrade it.
-
-:::
@@ -1,29 +0,0 @@
---
-title: Assigning Pod Security Policies
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/assign-pod-security-policies"/>
-</head>
-
-_Pod Security Policies_ are objects that control security-sensitive aspects of pod specification (like root privileges).
-
-## Adding a Default Pod Security Policy
-
-When you create a new cluster with RKE, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster.
-
-:::note Prerequisite:
-
-Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md).
-
-:::
-
-:::note
-
-For security purposes, we recommend assigning a PSP as you create your clusters.
-
-:::
-
-To enable a default Pod Security Policy, set the **Pod Security Policy Support** option to  **Enabled**, and then make a selection from the **Default Pod Security Policy** drop-down.
-
-When the cluster finishes provisioning, the PSP you selected is applied to all projects within the cluster.
@@ -126,12 +126,11 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h

 This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas.

-1. [Name a new project.](#1-name-a-new-project)
-2. [Optional: Select a pod security policy.](#2-optional-select-a-pod-security-policy)
-3. [Recommended: Add project members.](#3-recommended-add-project-members)
-4. [Optional: Add resource quotas.](#4-optional-add-resource-quotas)
+1. [Name a new project.](#name-a-new-project)
+1. [Recommended: Add project members.](#recommended-add-project-members)
+1. [Optional: Add resource quotas.](#optional-add-resource-quotas)

-### 1. Name a New Project
+### Name a New Project

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster you want to project in and click **Explore**.
@@ -139,17 +138,7 @@ This section describes how to create a new project with a name and with optional
 1. Click **Create Project**.
 1. Enter a **Project Name**.

-### 2. Optional: Select a Pod Security Policy
-
-This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md).
-
-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.
-
-### 3. Recommended: Add Project Members
+### Recommended: Add Project Members

 Use the **Members** section to provide other users with project access and roles.

@@ -179,7 +168,7 @@ To add members:
    :::
 1. In the **Project Permissions** section, choose a role. For more information, refer to the [documentation on project roles.](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)

-### 4. Optional: Add Resource Quotas
+### Optional: Add Resource Quotas

 Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).

@@ -1,52 +0,0 @@
---
-title: Roles-based Access Control
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans/rbac-for-cis-scans"/>
-</head>
-
-This section describes the permissions required to use the rancher-cis-benchmark App.
-
-The rancher-cis-benchmark is a cluster-admin only feature by default.
-
-However, the `rancher-cis-benchmark` chart installs these two default `ClusterRoles`:
-
- cis-admin
- cis-view
-
-In Rancher, only cluster owners and global administrators have `cis-admin` access by default.
-
-Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has now been removed since
-Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings
-for `cis-edit`, please update them to use `cis-admin` ClusterRole instead.
-
-## Cluster-Admin Access
-
-Rancher CIS Scans is a cluster-admin only feature by default.
-This means only the Rancher global admins, and the cluster’s cluster-owner can:
-
- Install/Uninstall the rancher-cis-benchmark App
- See the navigation links for CIS Benchmark CRDs - ClusterScanBenchmarks, ClusterScanProfiles, ClusterScans
- List the default ClusterScanBenchmarks and ClusterScanProfiles
- Create/Edit/Delete new ClusterScanProfiles
- Create/Edit/Delete a new ClusterScan to run the CIS scan on the cluster
- View and Download the ClusterScanReport created after the ClusterScan is complete
-
-
-## Summary of Default Permissions for Kubernetes Default Roles
-
-The rancher-cis-benchmark creates three `ClusterRoles` and adds the CIS Benchmark CRD access to the following default K8s `ClusterRoles`:
-
-| ClusterRole created by chart | Default K8s ClusterRole  | Permissions given with Role
-| ------------------------------| ---------------------------| ---------------------------|
-| `cis-admin` | `admin`| Ability to CRUD clusterscanbenchmarks, clusterscanprofiles, clusterscans, clusterscanreports CR
-| `cis-view` | `view `| Ability to List(R) clusterscanbenchmarks, clusterscanprofiles, clusterscans, clusterscanreports CR
-
-
-By default only cluster-owner role will have ability to manage and use `rancher-cis-benchmark` feature.
-
-The other Rancher roles (cluster-member, project-owner, project-member) do not have any default permissions to manage and use rancher-cis-benchmark resources.
-
-But if a cluster-owner wants to delegate access to other users, they can do so by creating ClusterRoleBindings between these users and the above CIS ClusterRoles manually.
-There is no automatic role aggregation supported for the `rancher-cis-benchmark` ClusterRoles.
@@ -1,57 +0,0 @@
---
-title: Skipped and Not Applicable Tests
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests"/>
-</head>
-
-This section lists the tests that are skipped in the permissive test profile for RKE.
-
-> All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile.
-
-## CIS Benchmark v1.5
-
-### CIS Benchmark v1.5 Skipped Tests
-
-| Number | Description | Reason for Skipping |
-| ---------- | ------------- | --------- |
-| 1.1.12 |  Ensure that the etcd data directory ownership is set to etcd:etcd (Automated) |  A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership.     |
-| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)  |  When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers.  |
-| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Automated) |  Enabling Pod Security Policy can cause applications to unexpectedly fail.     |
-| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Manual)  |  Enabling encryption changes how data can be recovered as data is encrypted.     |
-| 1.2.34 | Ensure that encryption providers are appropriately configured (Manual) |  Enabling encryption changes how data can be recovered as data is encrypted.     |
-| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Automated) |  System level configurations are required before provisioning the cluster in order for this argument to be set to true.     |
-| 4.2.10 |  Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Automated) |  When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers.     |
-| 5.1.5 |  Ensure that default service accounts are not actively used. (Automated)  |  Kubernetes provides default service accounts to be used.     |
-| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Automated) |  Enabling Pod Security Policy can cause applications to unexpectedly fail.     |
-| 5.2.3 |  Minimize the admission of containers wishing to share the host IPC namespace (Automated) |  Enabling Pod Security Policy can cause applications to unexpectedly fail.     |
-| 5.2.4 |  Minimize the admission of containers wishing to share the host network namespace (Automated) |  Enabling Pod Security Policy can cause applications to unexpectedly fail.     |
-| 5.2.5 |   Minimize the admission of containers with allowPrivilegeEscalation (Automated)  |  Enabling Pod Security Policy can cause applications to unexpectedly fail.     |
-| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Automated) |  Enabling Network Policies can prevent certain applications from communicating with each other.     |
-| 5.6.4 | The default namespace should not be used (Automated)  |  Kubernetes provides a default namespace.     |
-
-### CIS Benchmark v1.5 Not Applicable Tests
-
-| Number | Description | Reason for being not applicable |
-| ---------- | ------------- | --------- |
-| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)  |  Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time.     |
-| 1.1.2 |  Ensure that the API server pod specification file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time.     |
-| 1.1.3 |  Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time.     |
-| 1.1.4 |  Ensure that the controller manager pod specification file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time.     |
-| 1.1.5 |  Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time.     |
-| 1.1.6 |  Ensure that the scheduler pod specification file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time.     |
-| 1.1.7 |  Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated)  |  Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time.     |
-| 1.1.8 |  Ensure that the etcd pod specification file ownership is set to root:root (Automated)  |  Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time.     |
-| 1.1.13 |  Ensure that the admin.conf file permissions are set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes.     |
-| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Automated)  |  Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes.     |
-| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Automated)  |  Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time.  |
-| 1.1.16 |  Ensure that the scheduler.conf file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time.     |
-| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time.     |
-| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time.     |
-| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated)  |  Clusters provisioned by RKE handles certificate rotation directly through RKE.     |
-| 4.1.1 |  Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time.     |
-| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time.     |
-| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Automated) |  Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time.     |
-| 4.1.10 |  Ensure that the kubelet configuration file ownership is set to root:root (Automated) |  Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time.     |
-| 4.2.12 |  Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) |  Clusters provisioned by RKE handles certificate rotation directly through RKE.     |
@@ -19,10 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
-| v2.11.3         | v106.0.0+up6.0.0 |
-| v2.11.2         | v106.0.0+up6.0.0 |
-| v2.11.1         | v106.0.0+up6.0.0 |
-| v2.11.0         | v106.0.0+up6.0.0 |
+| v2.12.0         |  107.0.0+up7.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -1,14 +1,14 @@
 ---
-title: CIS Scans
+title: Compliance Scans
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/compliance-scans"/>
 </head>

-Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark. The CIS scans can run on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE.
+Rancher can run a security scan to check whether a cluster is deployed according to security best practices as defined in Kubernetes security benchmarks, such as the ones provided by STIG, BSI or CIS. The Compliance scans can run on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE.

-The `rancher-cis-benchmark` app leverages <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench,</a> an open-source tool from Aqua Security, to check clusters for CIS Kubernetes Benchmark compliance. Also, to generate a cluster-wide report, the application utilizes <a href="https://github.com/vmware-tanzu/sonobuoy" target="_blank">Sonobuoy</a> for report aggregation.
+The `rancher-compliance` app leverages <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench,</a> an open-source tool from Aqua Security, to check the compliance of clusters against Kubernetes Benchmarks. Also, to generate a cluster-wide report, the application utilizes <a href="https://github.com/vmware-tanzu/sonobuoy" target="_blank">Sonobuoy</a> for report aggregation.


 ## About the CIS Benchmark
@@ -94,7 +94,7 @@ In order to pass the "Hardened" profile, you will need to follow the steps on th

 The default profile and the supported CIS benchmark version depends on the type of cluster that will be scanned:

-The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
+The `rancher-compliance` supports the CIS 1.6 Benchmark version.

 - For RKE Kubernetes clusters, the RKE Permissive 1.6 profile is the default.
 - EKS and GKE have their own CIS Benchmarks published by `kube-bench`. The corresponding test profiles are used by default for those clusters.
@@ -103,15 +103,13 @@ The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.

 ## About Skipped and Not Applicable Tests

-For a list of skipped and not applicable tests, refer to [this page](../../how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests.md).
-
 For now, only user-defined skipped tests are marked as skipped in the generated report.

 Any skipped tests that are defined as being skipped by one of the default profiles are marked as not applicable.

 ## Roles-based Access Control

-For information about permissions, refer to [this page](rbac-for-cis-scans.md)
+For information about permissions, refer to [this page](rbac-for-compliance-scans.md)

 ## Configuration

@@ -119,4 +117,4 @@ For more information about configuring the custom resources for the scans, profi

 ## How-to Guides

-Please refer to the [CIS Scan Guides](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) to learn how to run CIS scans.
+Please refer to the [Compliance Scan Guides](../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) to learn how to run Compliance scans.
@@ -3,27 +3,27 @@ title: Configuration
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans/configuration-reference"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/compliance-scans/configuration-reference"/>
 </head>

-This configuration reference is intended to help you manage the custom resources created by the `rancher-cis-benchmark` application. These resources are used for performing CIS scans on a cluster, skipping tests, setting the test profile that will be used during a scan, and other customization.
+This configuration reference is intended to help you manage the custom resources created by the `rancher-compliance` application. These resources are used for performing compliance scans on a cluster, skipping tests, setting the test profile that will be used during a scan, and other customization.

-To configure the custom resources, go to the **Cluster Dashboard** To configure the CIS scans,
+To configure the custom resources, go to the **Cluster Dashboard** To configure the compliance scans,

 1. In the upper left corner, click **☰ > Cluster Management**.
-1. On the **Clusters** page, go to the cluster where you want to configure CIS scans and click **Explore**.
-1. In the left navigation bar, click **CIS Benchmark**.
+1. On the **Clusters** page, go to the cluster where you want to configure compliance scans and click **Explore**.
+1. In the left navigation bar, click **Compliance**.

 ## Scans

-A scan is created to trigger a CIS scan on the cluster based on the defined profile. A report is created after the scan is completed.
+A scan is created to trigger a compliance scan on the cluster based on the defined profile. A report is created after the scan is completed.

 When configuring a scan, you need to define the name of the scan profile that will be used with the `scanProfileName` directive.

 An example ClusterScan custom resource is below:

 ```yaml
-apiVersion: cis.cattle.io/v1
+apiVersion: compliance.cattle.io/v1
 kind: ClusterScan
 metadata:
  name: rke-cis
@@ -33,11 +33,11 @@ spec:

 ## Profiles

-A profile contains the configuration for the CIS scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.
+A profile contains the configuration for the compliance scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.

 :::caution

-By default, a few ClusterScanProfiles are installed as part of the `rancher-cis-benchmark` chart. If a user edits these default benchmarks or profiles, the next chart update will reset them back. So it is advisable for users to not edit the default  ClusterScanProfiles.
+By default, a few ClusterScanProfiles are installed as part of the `rancher-compliance` chart. If a user edits these default benchmarks or profiles, the next chart update will reset them back. So it is advisable for users to not edit the default  ClusterScanProfiles.

 :::

@@ -50,12 +50,12 @@ When you create a new profile, you will also need to give it a name.
 An example `ClusterScanProfile` is below:

 ```yaml
-apiVersion: cis.cattle.io/v1
+apiVersion: compliance.cattle.io/v1
 kind: ClusterScanProfile
 metadata:
  annotations:
    meta.helm.sh/release-name: clusterscan-operator
-    meta.helm.sh/release-namespace: cis-operator-system
+    meta.helm.sh/release-namespace: compliance-operator-system
  labels:
    app.kubernetes.io/managed-by: Helm
  name: "<example-profile>"
@@ -70,9 +70,9 @@ spec:

 A benchmark version is the name of benchmark to run using `kube-bench`, as well as the valid configuration parameters for that benchmark.

-A `ClusterScanBenchmark` defines the CIS `BenchmarkVersion` name and test configurations. The `BenchmarkVersion` name is a parameter provided to the `kube-bench` tool.
+A `ClusterScanBenchmark` defines the Compliance `BenchmarkVersion` name and test configurations. The `BenchmarkVersion` name is a parameter provided to the `kube-bench` tool.

-By default, a few `BenchmarkVersion` names and test configurations are packaged as part of the CIS scan application. When this feature is enabled, these default BenchmarkVersions will be automatically installed and available for users to create a ClusterScanProfile.
+By default, a few `BenchmarkVersion` names and test configurations are packaged as part of the Compliance scan application. When this feature is enabled, these default BenchmarkVersions will be automatically installed and available for users to create a ClusterScanProfile.

 :::caution

@@ -89,12 +89,12 @@ A ClusterScanBenchmark consists of the fields:
 An example `ClusterScanBenchmark` is below:

 ```yaml
-apiVersion: cis.cattle.io/v1
+apiVersion: compliance.cattle.io/v1
 kind: ClusterScanBenchmark
 metadata:
  annotations:
    meta.helm.sh/release-name: clusterscan-operator
-    meta.helm.sh/release-namespace: cis-operator-system
+    meta.helm.sh/release-namespace: compliance-operator-system
  creationTimestamp: "2020-08-28T18:18:07Z"
  generation: 1
  labels:
@@ -106,4 +106,4 @@ metadata:
 spec:
  clusterProvider: ""
  minKubernetesVersion: 1.15.0
-```
+```
@@ -3,19 +3,20 @@ title: Creating a Custom Benchmark Version for Running a Cluster Scan
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans/custom-benchmark"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/compliance-scans/custom-benchmark"/>
 </head>

-Each Benchmark Version defines a set of test configuration files that define the CIS tests to be run by the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool.
-The `rancher-cis-benchmark` application installs a few default Benchmark Versions which are listed under CIS Benchmark application menu.
+Each Benchmark Version defines a set of test configuration files that define the Compliance tests to be run by the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool.
+The `rancher-compliance` application installs a few default Benchmark Versions which are listed under Compliance application menu.

-But 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.
+But in the following cases, a custom configuration or remediation may be required:

-When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version.
+- Non-standard file locations: When Kubernetes binaries, configuration or certificate paths deviate from upstream benchmark defaults.
+Example: Unlike traditional Kubernetes, K3s bundles control plane components into a single binary. Therefore,` --anonymous-auth` flag presence and configuration should be verified in K3s' logs (`journalctl`), not via `kube-apiserver` process checks (`ps`).

-Follow all the steps below to add a custom Benchmark Version and run a scan using it.
+- Alternative risk mitigations: If a setup doesn't meet a check but has an equally effective compensating control with justification. Or simply is not concerned by the check requirement because of its design.
+Example: By default, K3s embeds the api server within the k3s process. There is no API server pod specification file, so verifying the latter's file permissions is not required.

 ## 1. Prepare the Custom Benchmark Version ConfigMap

@@ -46,7 +47,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
-1. In the left navigation bar, click **CIS Benchmark > Benchmark Version**.
+1. In the left navigation bar, click **Compliance > Benchmark Version**.
 1. Click **Create**.
 1. Enter the **Name** and a description for your custom benchmark version.
 1. Choose the cluster provider that your benchmark version applies to.
@@ -60,7 +61,7 @@ To run a scan using your custom benchmark version, you need to add a new Profile

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
-1. In the left navigation bar, click **CIS Benchmark > Profile**.
+1. In the left navigation bar, click **Compliance > Profile**.
 1. Click **Create**.
 1. Provide a **Name** and description. In this example, we name it `foo-profile`.
 1. Choose the Benchmark Version from the dropdown.
@@ -74,7 +75,7 @@ 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 add a custom benchmark and click **Explore**.
-1. In the left navigation bar, click **CIS Benchmark > Scan**.
+1. In the left navigation bar, click **Compliance > Scan**.
 1. Click **Create**.
 1. Choose the new cluster scan profile.
 1. Click **Create**.
@@ -0,0 +1,48 @@
+---
+title: Roles-based Access Control
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/compliance-scans/rbac-for-compliance-scans"/>
+</head>
+
+This section describes the permissions required to use the rancher-compliance App.
+
+The rancher-compliance is a cluster-admin only feature by default.
+
+However, the `rancher-compliance` chart installs these two default `ClusterRoles`:
+
+- compliance-admin
+- compliance-view
+
+In Rancher, only cluster owners and global administrators have `compliance-admin` access by default.
+
+## Cluster-Admin Access
+
+Rancher Compliance Scans is a cluster-admin only feature by default.
+This means only the Rancher global admins, and the cluster’s cluster-owner can:
+
+- Install/Uninstall the rancher-compliance App
+- See the navigation links for Compliance CRDs - ClusterScanBenchmarks, ClusterScanProfiles, ClusterScans
+- List the default ClusterScanBenchmarks and ClusterScanProfiles
+- Create/Edit/Delete new ClusterScanProfiles
+- Create/Edit/Delete a new ClusterScan to run the Compliance scan on the cluster
+- View and Download the ClusterScanReport created after the ClusterScan is complete
+
+
+## Summary of Default Permissions for Kubernetes Default Roles
+
+The rancher-compliance creates three `ClusterRoles` and adds the Compliance CRD access to the following default K8s `ClusterRoles`:
+
+| ClusterRole created by chart | Default K8s ClusterRole  | Permissions given with Role
+| ------------------------------| ---------------------------| ---------------------------|
+| `compliance-admin` | `admin`| Ability to CRUD clusterscanbenchmarks, clusterscanprofiles, clusterscans, clusterscanreports CR
+| `compliance-view` | `view `| Ability to List(R) clusterscanbenchmarks, clusterscanprofiles, clusterscans, clusterscanreports CR
+
+
+By default only cluster-owner role will have ability to manage and use `rancher-compliance` feature.
+
+The other Rancher roles (cluster-member, project-owner, project-member) do not have any default permissions to manage and use rancher-compliance resources.
+
+But if a cluster-owner wants to delegate access to other users, they can do so by creating ClusterRoleBindings between these users and the above Compliance ClusterRoles manually.
+There is no automatic role aggregation supported for the `rancher-compliance` ClusterRoles.
@@ -22,6 +22,14 @@ For private nodes or private clusters, the environment variables need to be set

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

+:::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 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)
+
+:::
+
 | Variable Name | Value |
 |------------------|--------|
 | `HTTP_PROXY` | http://<PROXY_IP>:8888 |
@@ -38,10 +38,6 @@ If you would like to limit Prometheus to specific namespaces, set `prometheus.pr

 For details, refer to [this section.](selectors-and-scrape-configurations.md)

-### Enable Istio with Pod Security Policies
-
-Refer to [this section.](pod-security-policies.md)
-
 ### Additional Steps for Installing Istio on an RKE2 Cluster

 Refer to [this section.](install-istio-on-rke2-cluster.md)
@@ -1,65 +0,0 @@
---
-title: Enable Istio with Pod Security Policies
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options/pod-security-policies"/>
-</head>
-
-:::warning
-
-[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
-
-Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
-
-:::
-
-If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.
-
-The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).
-
-:::note Prerequisites:
-
- The cluster must be an RKE Kubernetes cluster.
- The cluster must have been created with a default PodSecurityPolicy.
-
-To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
-
-:::
-
-1. [Set the PodSecurityPolicy to unrestricted](#1-set-the-podsecuritypolicy-to-unrestricted)
-2. [Enable the CNI](#2-enable-the-cni)
-3. [Verify that the CNI is working.](#3-verify-that-the-cni-is-working)
-
-### 1. Set the PodSecurityPolicy to unrestricted
-
-An unrestricted PSP allows Istio to be installed.
-
-Set the PSP to `unrestricted` in the project where is Istio is installed, or the project where you plan to install Istio.
-
-1.  Click **☰ > Cluster Management**.
-1. Go to the cluster that you created and click **Explore**.
-1. Click **Cluster > Projects/Namespaces**.
-1. Find the **Project: System** and select the **⋮ > Edit Config**.
-1. Change the Pod Security Policy option to be unrestricted, then click **Save**.
-
-### 2. Enable the CNI
-
-When installing or upgrading Istio through **Apps,**
-
-1. Click **Components**.
-2. Check the box next to **Enabled CNI**.
-3. Finish installing or upgrading Istio.
-
-The CNI can also be enabled by editing the `values.yaml`:
-
-```
-istio_cni.enabled: true
-```
-
-Istio should install successfully with the CNI enabled in the cluster.
-
-### 3. Verify that the CNI is working
-
-Verify that the CNI is working by deploying a [sample application](https://istio.io/latest/docs/examples/bookinfo/) or deploying one of your own applications.
-
@@ -33,12 +33,6 @@ While you can create your own ResourceSets to back up custom applications, two R

 `rancher-resource-set-full` includes all essential secrets in the backup files to ensure Rancher continues running smoothly after a restore or migration. To avoid storing sensitive information in plain text, we strongly advise you to enable encryption with a strong key.

-:::note Important:
-
-`rancher-resource-set` is also included by default with the `rancher-backup` operator. However, this ResourceSet is deprecated and is only being kept for backwards compatibility reasons. `rancher-resource-set` will be removed in Rancher v2.12. Please update your Backup custom resources to use either `rancher-resource-set-full` or `rancher-resource-set-basic`.
-
-:::
-
 | YAML Directive Name | Description |
 | ---------------- | ---------------- |
 | `resourceSetName` |  Provide the name of the ResourceSet to define which resources will be included in this backup. |
@@ -98,7 +98,7 @@ Monitoring the availability and performance of all your internal workloads is vi

 ## Security Monitoring

-In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) which check if the cluster is configured according to security best practices.
+In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [Compliance Scans](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) which check if the cluster is configured according to security best practices.

 For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).

@@ -151,10 +151,6 @@ Option to enable or disable [Metrics Server](https://rancher.com/docs/rke/latest

 Each cloud provider capable of launching a cluster using RKE can collect metrics and monitor for your cluster nodes. Enable this option to view your node metrics from your cloud provider's portal.

-### Pod Security Policy Support
-
-Enables [pod security policies](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) for the cluster. After enabling this option, choose a policy using the **Default Pod Security Policy** drop-down.
-
 You must have an existing Pod Security Policy configured before you can use this option.

 ### Docker Version on Nodes
@@ -129,17 +129,13 @@ If the cloud provider you want to use is not listed as an option, you will need

 :::

-##### Default Pod Security Policy
-
-The default [pod security policy](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) for the cluster. Please refer to the [RKE2 documentation](https://docs.rke2.io/security/pod_security_policies) on the specifications of each available policy.
-
 ##### Pod Security Admission Configuration Template

 The default [pod security admission configuration template](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for the cluster.

-##### Worker CIS Profile
+##### Worker Compliance Profile

-Select a [CIS benchmark](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) to validate the system configuration against.
+Select a [compliance benchmark](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) to validate the system configuration against.

 ##### Project Network Isolation

@@ -351,29 +351,29 @@ receivers:
  - service_key: 'database-integration-key'
 ```

-## Example Route Config for CIS Scan Alerts
+## Example Route Config for Compliance Scan Alerts

-While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`.
+While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`.

-For example, the following example route configuration could be used with a Slack receiver named `test-cis`:
+For example, the following example route configuration could be used with a Slack receiver named `test-compliance`:

 ```yaml
 spec:
-  receiver: test-cis
+  receiver: test-compliance
  group_by:
 #    - string
  group_wait: 30s
  group_interval: 30s
  repeat_interval: 30s
  match:
-    job: rancher-cis-scan
+    job: rancher-compliance-scan
 #    key: string
  match_re:
    {}
 #    key: string
 ```

-For more information on enabling alerting for `rancher-cis-benchmark`, see [this section.](../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md)
+For more information on enabling alerting for `rancher-compliance-benchmark`, see [this section.](../../how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance.md)

 ## Trusted CA for Notifiers

@@ -42,8 +42,8 @@ Rancher's integration with Istio was improved in Rancher v2.5.

 For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)

-## CIS Scans
+## Compliance Scans

-Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.
+Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in most recognized Kubernetes Security Benchmarks, such as STIG.

-For more information, refer to the CIS scan documentation [here.](../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)
+For more information, refer to the Compliance scan documentation [here.](../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md)
@@ -26,25 +26,19 @@ Each self-assessment guide is accompanied by a hardening guide. These guides wer

 | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
 |--------------------|-----------------------|-----------------------|------------------|
-| Kubernetes v1.23 | CIS v1.23 | [Link](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke1-hardening-guide/rke1-hardening-guide.md) |
-| Kubernetes v1.24 | CIS v1.24 | [Link](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](rke1-hardening-guide/rke1-hardening-guide.md) |
 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](rke1-hardening-guide/rke1-hardening-guide.md) |

 ### RKE2 Guides

 | Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
 |------|--------------------|-----------------------|-----------------------|------------------|
-| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [Link](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke2-hardening-guide/rke2-hardening-guide.md) |
-| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.24 | [Link](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](rke2-hardening-guide/rke2-hardening-guide.md) |
 | Rancher provisioned RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](rke2-hardening-guide/rke2-hardening-guide.md) |
-| Standalone RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.27-v1.32 | CIS v1.9 | [Link](https://docs.rke2.io/security/cis_self_assessment19) | [Link](https://docs.rke2.io/security/hardening_guide) |

 ### K3s Guides

 | Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
 |------|--------------------|-----------------------|-----------------------|------------------|
-| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [Link](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](k3s-hardening-guide/k3s-hardening-guide.md) |
-| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.24 | [Link](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](k3s-hardening-guide/k3s-hardening-guide.md) |
 | Rancher provisioned K3s cluster | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](k3s-hardening-guide/k3s-hardening-guide.md) |
 | Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment-1.8) | [Link](https://docs.k3s.io/security/hardening-guide) |

@@ -79,7 +79,7 @@ This configuration needs to be done before setting the kubelet flag, otherwise K

 ## Kubernetes Runtime Requirements

-The CIS Benchmark runtime requirements center around pod security (via PSP or PSA), network policies and API Server auditing logs.
+The CIS Benchmark runtime requirements center around pod security (via PSA), network policies and API Server auditing logs.

 By default, K3s does not include any pod security or network policies. However, K3s ships with a controller that enforces any network policies you create. By default, K3s enables both the `PodSecurity` and `NodeRestriction` admission controllers, among others.

@@ -153,7 +153,6 @@ Execute this script to apply the `default-allow-all.yaml` configuration with the
 ## Known Limitations

 - Rancher **exec shell** and **view logs** for pods are **not** functional in a hardened setup when only a public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
- When setting `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates `RoleBindings` and `ClusterRoleBindings` on the `default` service accounts. The CIS check 5.1.5 requires that the `default` service accounts have no roles or cluster roles bound to it apart from the defaults. In addition, the `default` service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.

 ## Reference Hardened RKE `cluster.yml` Configuration

@@ -31,22 +31,14 @@ On this page, we provide security related documentation along with resources to

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-## Running a CIS Security Scan on a Kubernetes Cluster
+## Running a Compliance Security Scan on a Kubernetes Cluster

-Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.
+Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices.

-The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes.
-
-The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace".
-
-CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.
-
-The Benchmark provides recommendations of two types: Automated and Manual. We run tests related to only Automated recommendations.
-
-When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests.
-
-For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).
+When Rancher runs a Compliance scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests.

+For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md).
+`
 ## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
@@ -20,10 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.11.3         |     v0.7.3      | &check;               | &check;                   |
-| v2.11.2         |     v0.7.2      | &check;               | &check;                   |
-| v2.11.1         |     v0.7.1      | &check;               | &check;                   |
-| v2.11.0         |     v0.7.0      | &cross;               | &check;                   |
+| v2.12.0         |     v0.8.0      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -10,11 +10,11 @@ If you operate Rancher behind a proxy and you want to access services through th

 Make sure `NO_PROXY` contains the network addresses, network address ranges and domains that should be excluded from using the proxy.

-| Environment variable | Purpose                                                                                                                 |
-| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
-| HTTP_PROXY           | Proxy address to use when initiating HTTP connection(s)                                                                 |
-| HTTPS_PROXY          | Proxy address to use when initiating HTTPS connection(s)                                                                |
-| NO_PROXY             | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s) |
+| Environment variable | Purpose                                                                                                                                                                                                                                                                                                                                                                                                                              |
+|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| HTTP_PROXY           | Proxy address to use when initiating HTTP connection(s)                                                                                                                                                                                                                                                                                                                                                                              |
+| HTTPS_PROXY          | Proxy address to use when initiating HTTPS connection(s)                                                                                                                                                                                                                                                                                                                                                                             |
+| NO_PROXY             | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s). <br/><br/> The value must be a comma-delimited string which contains IP addresses, CIDR notation, domain names, or special DNS labels (*). 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) |

 :::note Important:

@@ -62,4 +62,4 @@ acl SSL_ports port 2376

 acl Safe_ports port 22      # ssh
 acl Safe_ports port 2376    # docker port
-```
+```
@@ -8,11 +8,10 @@
 | [Managing Projects, Namespaces and Workloads](../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) | ✓ | ✓ | ✓ | ✓ |
 | [Using App Catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) | ✓ | ✓ | ✓ | ✓ |
 | Configuring Tools ([Alerts, Notifiers, Monitoring](../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md), [Logging](../integrations-in-rancher/logging/logging.md), [Istio](../integrations-in-rancher/istio/istio.md)) | ✓ | ✓ | ✓ | ✓ |
-| [Running Security Scans](../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) | ✓ | ✓ | ✓ | ✓ |
+| [Running Security Scans](../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) | ✓ | ✓ | ✓ | ✓ |
 | [Ability to rotate certificates](../how-to-guides/new-user-guides/manage-clusters/rotate-certificates.md) | ✓ | ✓  |  | |
 | Ability to [backup](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) and [restore](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Rancher-launched clusters | ✓ | ✓ |  | ✓<sup>4</sup> |
 | [Cleaning Kubernetes components when clusters are no longer reachable from Rancher](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) | ✓ | | | |
-| [Configuring Pod Security Policies](../how-to-guides/new-user-guides/manage-clusters/add-a-pod-security-policy.md) | ✓ | ✓ |  ||

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

@@ -35,7 +35,6 @@ title: 参与 Rancher 社区贡献
 | (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
 | machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
 | kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库，它是配置托管 Kubernetes 集群的工具。 |
-| RKE repository | https://github.com/rancher/rke | Rancher Kubernetes Engine 的源码仓库，该工具可在任何主机上配置 Kubernetes 集群。 |
 | CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
 | (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
 | Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
@@ -106,27 +105,6 @@ title: 参与 Rancher 社区贡献
      -l app=rancher \
      --timestamps=true
      ```
-      - 在 RKE 集群的每个节点上使用 `docker` 的 Docker 安装
-
-      ```
-      docker logs \
-      --timestamps \
-      $(docker ps | grep -E "rancher/rancher@|rancher_rancher" | awk '{ print $1 }')
-      ```
-      - 使用 RKE 附加组件的 Kubernetes 安装
-
-      :::note
-
-      确保你配置了正确的 kubeconfig（例如，如果 Rancher Server 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
-
-      :::
-
-      ```
-      kubectl -n cattle-system \
-      logs \
-      --timestamps=true \
-      -f $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name="cattle-server") | .metadata.name')
-      ```
   - 系统日志记录（可能不存在，取决于操作系统）
      - `/var/log/messages`
      - `/var/log/syslog`
@@ -16,10 +16,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
-| [2.11.3](https://github.com/rancher/rancher/releases/tag/v2.11.2) | 2025 年 6 月 25 日  |
-| [2.11.2](https://github.com/rancher/rancher/releases/tag/v2.11.2) | 2025 年 5 月 22 日  |
-| [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | 2025 年 4 月 24 日  |
-| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | 2025 年 3 月 31 日  |
+| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | 2025 年 7 月 31 日  |

 ## 当一个功能被标记为弃用我可以得到什么样的预期？

@@ -194,7 +194,6 @@ cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
 - 将 `hostname` 设置为解析到你的负载均衡器的 DNS 名称。
 - 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
 - 如果你需要安装指定的 Rancher 版本，使用 `--version` 标志，例如 `--version 2.7.0`。
- 对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
@@ -235,7 +234,6 @@ deployment "rancher" successfully rolled out
 - 将 `ingress.tls.source` 设置为 `letsEncrypt`。
 - 将 `letsEncrypt.email` 设置为可通讯的电子邮件地址，用于发送通知（例如证书到期的通知）。
 - 将 `letsEncrypt.ingress.class` 设为你的 Ingress Controller（例如 `traefik`，`nginx`，`haproxy`）
- 对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
@@ -278,7 +276,6 @@ deployment "rancher" successfully rolled out
 - 设置 `hostname`。
 - 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
 - 将 `ingress.tls.source` 设置为 `secret`。
- 对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
@@ -1,68 +0,0 @@
---
-title: 将加固的自定义/导入集群升级到 Kubernetes v1.25
---
-
-Kubernetes v1.25 改变了集群描述和执行安全策略的方式。从这个版本开始，[Pod 安全策略 (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)不再可用。Kubernetes v1.25 将它们替换为新的安全对象：[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)。
-
-如果你具有自定义或导入的加固集群，你需要做好准备，确保将旧版本的 Kubernetes 顺利升级到 v1.25 或更高版本。
-
-:::note
-
-升级到 v1.25 后，添加必要的 Rancher 命名空间豁免。有关详细信息，请参阅 [Pod 安全准入 (PSA) 配置模板](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)。
-
-:::
-
-## 将导入的加固集群升级到 Kubernetes v1.25 或更高版本
-
-<Tabs groupId="k8s-distro">
-<TabItem value="RKE2" default>
-
-在集群中的每个节点上执行以下操作：
-1. 将 [`rancher-psact.yaml`](./rancher-psact.yaml) 保存到 `/etc/rancher/rke2` 中。
-1. 编辑 RKE2 配置文件：
-   1. 将 `profile` 字段更新为 `cis-1.23`。
-   1. 指定刚才添加的配置文件的路径：`pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`。
-
-</TabItem>
-<TabItem value="K3s">
-
-在集群中的每个节点上执行以下操作：
-
-遵循 K3s [将加固集群从 v1.24.x 升级到 v1.25.x](https://docs.k3s.io/known-issues#hardened-125)的官方说明，但使用[自定义](./rancher-psact.yaml)Rancher PSA 配置模板，而不是 K3s 官方网站上提供的配置。
-</TabItem>
-</Tabs>
-
-执行这些步骤后，你可以通过 Rancher UI 升级集群的 Kubernetes 版本：
-
-1. 在左上角，单击 **☰ > 集群管理**。
-1. 在**集群**表中找到要更新的集群，点击 **⋮**。
-1. 选择**编辑配置**。
-1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
-1. 单击**保存**。
-
-## 将自定义加固集群升级到 Kubernetes v1.25 或更高版本
-
-<Tabs groupId="k8s-distro">
-<TabItem value="RKE2" default>
-
-1. 在左上角，单击 **☰ > 集群管理**。
-1. 在**集群**表中找到要更新的集群，点击 **⋮**。
-1. 选择**编辑配置**。
-1. 在**基本信息 > 安全**下的 **CIS 配置文件**下拉菜单中，选择 `cis-1.23`。
-1. 在 **PSA 配置模板**下拉菜单中，选择 `rancher-restricted`。
-1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
-1. 单击**保存**。
-
-</TabItem>
-<TabItem value="K3s">
-
-1. 在左上角，单击 **☰ > 集群管理**。
-1. 在**集群**表中找到要更新的集群，点击 **⋮**。
-1. 选择**编辑 YAML**。
-1. 从 `kube-apiserver-arg.enable-admission-plugins` 中删除 `PodSecurityPolicy`。
-1. 在 `spec` 字段中，添加一行：`defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
-1. 将 `kubernetesVersion` 更新为你选择的版本（v1.25 或更高版本）。
-1. 单击**保存**。
-
-</TabItem>
-</Tabs>
@@ -149,8 +149,6 @@ hostname: rancher.my.org

 将上一步中的所有值用 `--set key=value` 追加到命令中。

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 ```
 helm upgrade rancher rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
@@ -183,8 +181,6 @@ helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
   ```
 1. 只更新 Rancher 版本：

-   对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
   ```
   helm upgrade rancher rancher-<CHART_REPO>/rancher \
     --namespace cattle-system \
@@ -58,8 +58,6 @@ keywords: [rancher helm chart, rancher helm 选项, rancher helm chart 选项, h
 | `systemDefaultRegistry` | "" | `string` - 用于所有系统容器镜像的私有仓库，例如 http://registry.example.com/ |
 | `tls` | "ingress" | `string` - 详情请参见[外部 TLS 终止](#外部-tls-终止)。- "ingress, external" |
 | `useBundledSystemChart` | `false` | `bool` - 选择 Rancher Server 打包的 system-charts。此参数用于离线环境安装。 |
-| `global.cattle.psp.enabled` | `true` | `bool` - 使用 Rancher v2.7.2-v2.7.4 时，选择 `false` 以禁用 Kubernetes v1.25 及更高版本的 PSP。使用 Rancher v2.7.5 及更高版本时，Rancher 会尝试检测集群是否运行不支持 PSP 的 Kubernetes 版本，如果确定集群不支持 PSP，则将默认 PSP 的使用设置为 false。你仍然可以通过显式提供此值的 `true` 或 `false` 来手动覆盖此值。在支持 PSP 的集群中（例如使用 Kubernetes v1.24 或更低版本的集群），Rancher 仍将默认使用 PSP。 |
-

 ### 引导密码

@@ -168,8 +168,6 @@ kubectl create namespace cattle-system

 然后安装 Rancher，并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 | 占位符 | 描述 |
 ------------|-------------
 | `<VERSION>` | 输出压缩包的版本号。 |
@@ -199,8 +197,6 @@ kubectl create namespace cattle-system

 安装 Rancher，并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 | 占位符 | 描述 |
 | -------------------------------- | ----------------------------------------------- |
 | `<VERSION>` | 输出压缩包的版本号。 |
@@ -31,7 +31,7 @@ Rancher API Server 是基于嵌入式 Kubernetes API Server 和 etcd 数据库
 ### 授权和基于角色的权限控制（RBAC）

 - **用户管理**：Rancher API Server 除了管理本地用户，还[管理用户用来访问外部服务所需的认证信息](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md)，如登录 Active Directory 和 GitHub 所需的账号密码。
- **授权**：Rancher API Server 可以管理[访问控制策略](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)和[安全策略](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
+- **授权**：Rancher API Server 可以管理[访问控制策略](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)和[安全标准](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md)。

 ### 使用 Kubernetes 的功能

@@ -124,8 +124,6 @@ helm install cert-manager jetstack/cert-manager `

 要安装特定的 Rancher 版本，请使用 `--version` 标志（例如，`--version 2.6.6`）。否则，默认安装最新的 Rancher。请参阅[选择 Rancher 版本](../../installation-and-upgrade/resources/choose-a-rancher-version.md)。

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 请注意，密码至少需要 12 个字符。

 ```
@@ -9,9 +9,3 @@ title: 安装 Rancher CIS Benchmark
 1. 单击**安装**。

 **结果**：CIS 扫描应用已经部署在 Kubernetes 集群上。
-
-:::note
-
-如果你使用 Kubernetes v1.24 或更早版本，并且具有使用 [Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) (PSP) 加固的集群，则 CIS Benchmark 4.0.0 及更高版本会默认禁用 PSP。要在 PSP 加固集群上安装 CIS Benchmark，请在安装 Chart 之前将 values 中的 `global.psp.enabled` 设置为 `true`。[Pod 安全准入](../../new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) (PSA) 加固集群不受影响。
-
-:::
@@ -39,8 +39,6 @@ Rancher 包含一些默认关闭的实验功能。在某些情况下，例如当

 使用 Helm Chart 安装 Rancher 时，使用 `--set` 选项。下面的示例通过传递功能开关名称（用逗号分隔）来启用两个功能：

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 ```
 helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
@@ -5,7 +5,6 @@ title: 1. 在集群中启用 Istio
 :::note 先决条件：

 - 只有分配了 `cluster-admin` [Kubernetes 默认角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)的用户可以在 Kubernetes 集群中配置和安装 Istio。
- 如果你有 pod 安全策略，则需要安装启用了 CNI 的 Istio。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/pod-security-policies.md)。
 - 要在 RKE2 集群上安装 Istio，则需要执行额外的步骤。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md)。
 - 要在启用了项目网络隔离的集群中安装 Istio，则需要执行额外的步骤。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/project-network-isolation.md)。

@@ -1,39 +0,0 @@
---
-title: Pod 安全策略
---
-
-:::note
-
-本文介绍的集群选项仅适用于 [Rancher 已在其中启动 Kubernetes 的集群](../../new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)。
-
-:::
-
-你可以在创建项目的时候设置 Pod 安全策略（PSP）。如果在创建项目期间没有为项目分配 PSP，你也随时可以将 PSP 分配给现有项目。
-
-## 先决条件
-
- 在 Rancher 中创建 Pod 安全策略。在将默认 PSP 分配给现有项目之前，你必须有一个可分配的 PSP。有关说明，请参阅[创建 Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
- 将默认 Pod 安全策略分配给项目所属的集群。如果 PSP 还没有应用到集群，你无法将 PSP 分配给项目。有关详细信息，请参阅[将 pod 安全策略添加到集群](../../new-user-guides/manage-clusters/add-a-pod-security-policy.md)。
-
-## 应用 Pod 安全策略
-
-1. 在左上角，单击 **☰ > 集群管理**。
-1. 在**集群**页面上，转到需要移动命名空间的集群，然后单击 **Explore**。
-1. 单击**集群 > 项目/命名空间**。
-1. 找到要添加 PSP 的项目。在该项目中选择 **⋮ > 编辑配置**。
-1. 从 **Pod 安全策略**下拉列表中，选择要应用于项目的 PSP。
-   将 PSP 分配给项目将：
-
- 覆盖集群的默认 PSP。
- 将 PSP 应用于项目。
- 将 PSP 应用到后续添加到项目中的命名空间。
-
-1. 单击**保存**。
-
-**结果**：已将 PSP 应用到项目以及项目内的命名空间。
-
-:::note
-
-对于在分配 PSP 之前已经在集群或项目中运行工作负载，Rancher 不会检查它们是否符合 PSP。你需要克隆或升级工作负载以查看它们是否通过 PSP。
-
-:::
@@ -24,7 +24,6 @@ _项目_ 是 Rancher 中引入的对象，可帮助你更有组织地管理 Kube
 - [设置资源配额](manage-project-resource-quotas/manage-project-resource-quotas.md)
 - [管理命名空间](../../new-user-guides/manage-namespaces.md)
 - [配置工具](../../../reference-guides/rancher-project-tools.md)
- [配置 Pod 安全策略](manage-pod-security-policies.md)

 ## 授权

@@ -29,13 +29,6 @@ Rancher 为 Kubernetes 增加了一项关键特性是集中式的用户认证。
 在 Rancher 中，每个人都是以 _用户_ 的身份进行鉴权，这是一个授予你访问 Rancher 的登录身份。用户登录 Rancher 后，他们的 _授权_ 或者他们在系统中的访问权限由用户的角色决定。Rancher 提供了内置的角色，允许你你轻松地配置用户对资源的权限，但是 Rancher 还提供了为每个 Kubernetes 资源自定义角色的功能。

 更多关于授权的工作原理以及自定义角色的使用，请参考 [RBAC](manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
-
-## Pod 安全策略
-
-_Pod 安全策略_ (或 PSPs) 是控制 Pod 安全敏感方面规范的对象，例如 root 权限。如果一个 Pod 不满足 PSP 中指定的条件，Kubernetes 将不允许 Pod 启动，同时 Rancher 会显示一条错误信息。
-
-更多关于如何创建和使用 PSPs 的内容，请参考 [Pod 安全策略](create-pod-security-policies.md)。
-
 ## Provisioning Drivers

 Rancher 中的驱动允许你管理哪些程序可以预置[托管的 Kubernetes 集群](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) 或 [云服务器节点](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)，允许 Rancher 部署和管理 Kubernetes。
@@ -1,78 +0,0 @@
---
-title: Pod 安全策略
---
-
-:::caution
-Pod 安全策略仅在 Kubernetes v1.24 之前可用。[Pod 安全标准](pod-security-standards.md) 是内置的替代方案。
-:::
-
-[Pod 安全策略（PSP）](https://kubernetes.io/docs/concepts/security/pod-security-policy/)是用来控制安全敏感相关 Pod 规范（例如 root 特权）的对象。
-
-如果某个 Pod 不满足 PSP 指定的条件，Kubernetes 将不允许它启动，Rancher 中将显示错误消息 `Pod <NAME> is forbidden: unable to validate...`。
-
-
-## PSP 工作原理
-
-你可以在集群或项目级别分配 PSP。
-
-PSP 通过继承的方式工作：
-
- 默认情况下，分配给集群的 PSP 由其项目以及添加到这些项目的任何命名空间继承。
- **例外**：无论 PSP 是分配给集群还是项目，未分配给项目的命名空间不会继承 PSP。因为这些命名空间没有 PSP，所以这些命名空间的工作负载 deployment 将失败，这是 Kubernetes 的默认行为。
- 你可以通过将不同的 PSP 直接分配给项目来覆盖默认 PSP。
-
-在分配 PSP 之前已经在集群或项目中运行的任何工作负载如果符合 PSP，则不会被检查。你需要克隆或升级工作负载以查看它们是否通过 PSP。
-
-在 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)中阅读有关 Pod 安全策略的更多信息。
-
-## 默认 PSP
-
-Rancher 内置了三个默认 Pod 安全策略 (PSP)，分别是 `restricted-noroot`（受限 noroot），`restricted`（受限）和 `unrestricted`（不受限）策略。
-
-### 受限-NoRoot
-
-此策略基于 Kubernetes [示例受限策略](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)。它极大地限制了可以将哪些类型的 Pod 部署到集群或项目中。这项策略：
-
- 阻止 Pod 以特权用户身份运行，并防止特权升级。
- 验证服务器所需的安全机制是否到位，例如限制哪些卷只能挂载到核心卷类型，并防止添加 root 补充组。
-
-### 受限
-
-该策略是宽松版的 `restricted-noroot` 策略，除了允许以特权用户身份运行容器外，几乎所有限制都到位。
-
-### 不受限
-
-该策略等效于在禁用 PSP 控制器的情况下运行 Kubernetes。对于可以将哪些 Pod 部署到集群或项目中，它没有任何限制。
-
-:::note 重要提示：
-
-禁用 PSP 时，默认 PSP **不会**自动从集群中删除。如果不再需要它们，你必须手动删除它们。
-
-:::
-
-## 创建 PSP
-
-使用 Rancher，你可以使用我们的 GUI 创建 Pod 安全策略，而不是创建 YAML 文件。
-
-### 要求
-
-Rancher 只能为[使用 RKE 启动的集群](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)分配 PSP。
-
-你必须先在集群级别启用 PSP，然后才能将它们分配给项目。这可以通过[编辑集群](../../../reference-guides/cluster-configuration/cluster-configuration.md)来配置。
-
-最好的做法是在集群级别设置 PSP。
-
-我们建议在集群和项目创建期间添加 PSP，而不是将其添加到现有的项目或集群中。
-
-### 在 Rancher UI 中创建 PSP
-
-1. 在左上角，单击 **☰ > 集群管理**。
-1. 在左侧导航栏中，单击 **Pod 安全策略**。
-1. 单击**添加策略**。
-1. 为策略命名。
-1. 填写表格的每个部分。请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)，了解每个策略的作用。
-1. 单击**创建**。
-
-## 配置
-
-关于 PSP 的 Kubernetes 文档，请参阅[这里](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)。
@@ -7,54 +7,6 @@ title: Pod 安全标准 (PSS) 和 Pod 安全准入 (PSA)

 PSS 定义了工作负载的安全级别。PSA 描述了 Pod 安全上下文和相关字段的要求。PSA 参考 PSS 级别来定义安全限制。

-## 升级到 Pod 安全标准 (PSS)
-
-确保将所有 PSP 都迁移到了另一个工作负载安全机制，包括将你当前的 PSP 映射到 Pod 安全标准，以便使用 [PSA 控制器](https://kubernetes.io/docs/concepts/security/pod-security-admission/)执行。如果 PSA 控制器不能满足企业的所有需求，建议你使用策略引擎，例如 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)、[Kubewarden](https://www.kubewarden.io/)、[Kyverno](https://kyverno.io/) 或 [NeuVector](https://neuvector.com/)。有关如何迁移 PSP 的更多信息，请参阅你选择的策略引擎的文档。
-
-:::caution
-必须在删除 PodSecurityPolicy 对象_之前_添加新的策略执行机制。否则，你可能会为集群内的特权升级攻击创造机会。
-:::
-
-### 从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies
-
-Rancher v2.7.2 提供了 Rancher 维护的 Helm Chart 的新主要版本。v102.x.y 允许你删除与以前的 Chart 版本一起安装的 PSP。这个新版本使用标准化的 `global.cattle.psp.enabled` 开关（默认关闭）替换了非标准的 PSP 开关。
-
-你必须在_仍使用 Kubernetes v1.24_ 时执行以下步骤：
-1. 根据需要配置 PSA 控制器。你可以使用 Rancher 的内置 [PSA 配置模板](#pod-安全准入配置模板)，或创建自定义模板并将其应用于正在迁移的集群。
-
-1. 将活动的 PSP 映射到 Pod 安全标准：
-   1. 查看集群中哪些 PSP 仍处于活动状态：
-      :::caution
-      此策略可能会错过当前未运行的工作负载，例如 CronJobs、当前缩放为零的工作负载或尚未推出的工作负载。
-      :::
-
-      ```shell
-      kubectl get pods \
-        --all-namespaces \
-        --output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
-        | tr " " "\n" | sort -u
-      ```
-
-   1. 按照[将 PSP 映射到 Pod 安全标准](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/)的 Kubernetes 指南将 PSS 应用于依赖 PSP 的工作负载。有关详细信息，请参阅[从 PodSecurityPolicy 迁移到内置 PodSecurity Admission 控制器](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/)。
-
-1. 要从 Rancher Chart 中删除 PSP，请在升级到 Kubernetes v1.25 _之前_将 Chart 升级到最新的 v102.x.y 版本。确保 **Enable PodSecurityPolicies** 选项**已禁用**。这将删除与以前的 Chart 版本一起安装的所有 PSP。
-
-:::info 重要提示
-如果你想将 Chart 升级到 v102.x.y，但不打算将集群升级到 Kubernetes v1.25 和弃用 PSP，请确保为每个要升级的 Chart 选择 **Enable PodSecurityPolicies** 选项。
-:::
-
-### 在 Kubernetes v1.25 升级后清理版本
-
-如果你在删除 Chart 的 PSP 时遇到问题，或者 Chart 不包含用于删除 PSP 的内置机制，Chart 升级或删除可能会失败并显示如下错误消息：
-```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
-```
-
-Helm 尝试在集群中查询存储在先前版本的数据 blob 中的对象时，就会发生这种情况。要清理这些版本并避免此错误，请使用 `helm-mapkubeapis` Helm 插件。要详细了解 `helm-mapkubeapis`、它的工作原理以及如何针对你的用例进行微调，请参阅 [Helm 官方文档](https://github.com/helm/helm-mapkubeapis#readme)。
-
-请注意，Helm 插件安装在你运行命令的机器本地。因此，请确保从同一台机器运行安装和清理。
-
 #### 安装 `helm-mapkubeapis`

 1. 在打算使用 `helm-mapkubeapis` 的机器上打开你的终端并安装插件：
@@ -106,15 +58,6 @@ Helm 尝试在集群中查询存储在先前版本的数据 blob 中的对象时

 1. 最后，在查看更改后，使用 `helm mapkubeapis <release-name> --namespace <release-namespace>` 执行完整运行。

-#### 将 Chart 升级到支持 Kubernetes v1.25 的版本
-
-清理了具有 PSP 的所有版本后，你就可以继续升级了。对于 Rancher 维护的工作负载，请按照本文档[从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies](#从-rancher-维护的应用程序和市场工作负载中删除-podsecuritypolicies) 部分中的步骤进行操作。
-如果工作负载不是由 Rancher 维护的，请参阅对应的提供商的文档。
-
-:::caution
-不要跳过此步骤。与 Kubernetes v1.25 不兼容的应用程序不能保证在清理后正常工作。
-:::
-
 ## Pod 安全准入配置模板

 Rancher 提供了 PSA 配置模板。它们是可以应用到集群的预定义安全配置。Rancher 管理员（或具有权限的人员）可以[创建、管理和编辑](./psa-config-templates.md) PSA 模板。
@@ -159,8 +159,6 @@ Kubernetes v1.22 是 Rancher 2.6.3 的实验功能，不支持使用 apiVersion

 使用与第一个集群上使用的相同版本的 Helm 来安装 Rancher：

-对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
-
 ```bash
 helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
--- a/Show More
+++ b/Show More