Merge branch 'rancher:main' into update-directories

2026-09-26 04:58:07 +00:00 · 2025-05-19 10:21:23 -07:00
parent 18a2d91c57 3bca8e71ea
commit 988c958747
1870 changed files with 151706 additions and 3561 deletions
@@ -16,6 +16,11 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
+| [2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5) | Apr 24, 2025 |
+| [2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4) | Mar 31, 2025 |
+| [2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3) | Feb 27, 2025 |
+| [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 |
+| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
 | [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |

 ## What can I expect when a feature is marked for deprecation?
@@ -91,11 +91,11 @@ The UI consists of static files, and works based on responses of the API. That m

 ## The IP address of a node changed, how can I recover?

-A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
+A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and add it again. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.

 When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.

-When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
+When the node is removed from the cluster, and the node is cleaned, you can add the node to the cluster.

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

@@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded.

 Having network issues following upgrade?

-See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).

 :::

@@ -142,7 +142,7 @@ helm rollback rancher 3 -n cattle-system

 ## Rolling Back to Rancher v2.2-v2.4+

-To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
+To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.

 For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)

@@ -154,4 +154,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran

 ## Rolling Back to Rancher v2.0-v2.1

-Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
+Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
@@ -35,7 +35,7 @@ The upgrade instructions assume you are using Helm 3.

 <DeprecationHelm2 />

-For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 ### For air-gapped installs: Populate private registry

@@ -203,7 +203,7 @@ Log into Rancher to confirm that the upgrade succeeded.

 Having network issues following upgrade?

-See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).

 :::

@@ -16,8 +16,9 @@ Some feature flags require a restart of the Rancher container. Features that req

 :::

-The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
+The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):

+- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
 - `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
 - `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
 - `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
@@ -37,6 +38,7 @@ The following table shows the availability and default values for some feature f

 | Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
 | ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
+| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
 | `continuous-delivery` | `true` | GA | v2.6.0 | |
 | `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
 | `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
@@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis

 :::note Having network issues in your user clusters following upgrade?

-See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).

 :::

@@ -8,7 +8,7 @@ title: Helm Version Requirements

 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.

-> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 <DeprecationHelm2 />

@@ -6,6 +6,8 @@ title: Upgrading Kubernetes without Upgrading Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
 </head>

+<EOLRKE1Warning />
+
 The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.

 :::note
@@ -87,7 +89,7 @@ After new Kubernetes versions are loaded into the Rancher setup, additional step
 To download the system images for the private registry: 

 1. Click **☰** in the top left corner.
-1. Click **About** at the bottom of the left navigation.
+1. At the bottom of the left navigation, click the Rancher version number.
 1. Download the OS specific image lists for Linux or Windows.
 1. Download `rancher-images.txt`.
 1. Prepare the private registry using the same steps during the [air gap install](other-installation-methods/air-gapped-helm-cli-install/publish-images.md), but instead of using the `rancher-images.txt` from the releases page, use the one obtained from the previous steps.
@@ -27,15 +27,13 @@ This Quick Start Guide is divided into different tasks for easier consumption.

 ## Prerequisites

- An [Equinix Metal account](https://metal.equinix.com/developers/docs/accounts/users/)
- An [Equinix Metal project](https://metal.equinix.com/developers/docs/accounts/projects/)
+- An [Equinix Metal account](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
+- An [Equinix Metal project](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)


 ### 1. Provision a Equinix Metal Host

-Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://metal.equinix.com/developers/docs/deploy/on-demand/). You can find additional documentation on Equinix Metal server types and prices below:
-  - [Equinix Metal Server Types](https://metal.equinix.com/developers/docs/servers/about/)
-  - [Equinix Metal Pricing](https://metal.equinix.com/developers/docs/servers/server-specs/)
+Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://deploy.equinix.com/developers/docs/metal/deploy/on-demand/). You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).

 :::note Notes:

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

 ## Install Rancher with Helm

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

 :::note

@@ -20,12 +20,13 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

-### Note
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
+:::note 

-  `vagrant plugin install vagrant-vboxmanage`
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 

-  `vagrant plugin install vagrant-vbguest`
+:::

 ## Getting Started

@@ -31,6 +31,14 @@ Following project creation, you can add users as project members so that they ca
 1. In the **Members** tab, click **Add**.
 1. Search for the user or group that you want to add to the project.

+    :::note Notes:
+
+    - At least 2 characters must be typed in the search box for results to appear.
+    - Users can be searched based on their username or display name.
+    - Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
+
+    :::
+
    If external authentication is configured:

    -  Rancher returns users from your external authentication source as you type.
@@ -6,6 +6,8 @@ title: About RKE1 Templates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
 RKE templates are designed to allow DevOps and security teams to standardize and simplify the creation of Kubernetes clusters.

 RKE is the [Rancher Kubernetes Engine,](https://rancher.com/docs/rke/latest/en/) which is the tool that Rancher uses to provision Kubernetes clusters.
@@ -6,6 +6,8 @@ title: Creating and Revising RKE Templates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
 This section describes how to manage RKE templates and revisions. You an create, share, update, and delete templates from the **Cluster Management** view under **RKE1 Configuration > RKE Templates**.

 Template updates are handled through a revision system. When template owners want to change or update a template, they create a new revision of the template. Individual revisions cannot be edited. However, if you want to prevent a revision from being used to create a new cluster, you can disable it.
@@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth

 ## Users and Groups

-Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
-
 :::note

-Local authentication does not support creating or managing groups.
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
+
 For more information, see [Users and Groups](manage-users-and-groups.md)

 ## Scope of Rancher Authorization
@@ -3,7 +3,7 @@ title: Configure Keycloak (OIDC)
 description: Create a Keycloak OpenID Connect (OIDC) client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
 ---

-<head> 
+<head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-keycloak-oidc"/>
 </head>

@@ -17,46 +17,88 @@ If you have an existing configuration using the SAML protocol and want to switch

 - On Rancher, Keycloak (SAML) is disabled.
 - You must have a [Keycloak IdP Server](https://www.keycloak.org/guides#getting-started) configured.
- In Keycloak, create a [new OIDC client](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients), with the settings below. See the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients) for help.
+- Follow the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#proc-creating-oidc-client_server_administration_guide) to create a new OIDC client with the settings below.

-     Setting | Value
-     ------------|------------
-     `Client ID` | &lt;CLIENT_ID> (e.g. `rancher`)
-     `Name` | &lt;CLIENT_NAME> (e.g. `rancher`)
-     `Client Protocol` | `openid-connect`
-     `Access Type` | `confidential`
-     `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+    | Setting | Value |
+    | ------------|------------|
+    | `Client ID` | &lt;client-id> (e.g. `rancher`) |
+    | `Name` | &lt;client-name> (e.g. `rancher`) |
+    | `Client type` | `OpenID Connect` |
+    | `Client authentication` | `ON` |
+    | `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth` |

 - In the new OIDC client, create [Mappers](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers) to expose the users fields.
-  - Create a new "Groups Mapper" with the settings below.
+    1. In the navigation menu, click **Clients**.
+    1. Click the **Clients list** tab.
+    1. Find and click the client you created.
+    1. Click the **Client scopes** tab.
+    1. Find and click the link labeled `<client-name>-dedicated`. For example, if you named your client `rancher`, look for the link named `rancher-dedicated`.
+    1. Click the **Mappers** tab.
+    1. Click **Configure a new mapper**. If you already have existing mappers configured, click the arrow next to **Add mapper** and select **By configuration**. Repeat this process and create these mappers:
+        - From the mappings table, select **Group Membership** and configure a new "Groups Mapper" with the settings below. For settings that are not mentioned, use the default value.

-    Setting | Value
-    ------------|------------
-    `Name` | `Groups Mapper`
-    `Mapper Type` | `Group Membership`
-    `Token Claim Name` | `groups`
-    `Add to ID token` | `OFF`
-    `Add to access token` | `OFF`
-    `Add to user info` | `ON`
+          | Setting | Value |
+          | ------------|------------|
+          | `Name` | `Groups Mapper` |
+          | `Mapper Type` | `Group Membership` |
+          | `Token Claim Name` | `groups` |
+          | `Full group path` | `OFF` |
+          | `Add to ID token` | `OFF` |
+          | `Add to access token` | `OFF` |
+          | `Add to user info` | `ON` |

-  - Create a new "Client Audience" with the settings below.
+        - From the mappings table, select **Audience** and configure a new "Client Audience" with the settings below. For settings that are not mentioned, use the default value.

-    Setting | Value
-    ------------|------------
-    `Name` | `Client Audience`
-    `Mapper Type` | `Audience`
-    `Included Client Audience` | &lt;CLIENT_NAME>
-    `Add to access token` | `ON`
+          | Setting | Value |
+          | ------------|------------|
+          | `Name` | `Client Audience` |
+          | `Mapper Type` | `Audience` |
+          | `Included Client Audience` | &lt;client-name> |
+          | `Add to ID token` | `OFF` |
+          | `Add to access token` | `ON` |

-  - Create a new "Groups Path" with the settings below.
+        - From the mappings table, select **Group Membership** and configure a new "Groups Path" with the settings below. For settings that are not mentioned, use the default value.

-    Setting | Value
-    ------------|------------
-    `Name` | `Group Path`
-    `Mapper Type` | `Group Membership`
-    `Token Claim Name` | `full_group_path`
-    `Full group path` | `ON`
-    `Add to user info` | `ON`
+          | Setting | Value |
+          | ------------|------------|
+          | `Name` | `Group Path` |
+          | `Mapper Type` | `Group Membership` |
+          | `Token Claim Name` | `full_group_path` |
+          | `Full group path` | `ON` |
+          | `Add to ID token` | `ON` |
+          | `Add to access token` | `ON` |
+          | `Add to user info` | `ON` |
+
+- Add the following role mappings to all users or groups that need to query the Keycloak users.
+
+<Tabs>
+<TabItem value="Users">
+
+1. In the navigation menu, click **Users**.
+1. Click the user you want to add role mappings to.
+1. Click the **Role mapping** tab.
+1. Click **Assign role**.
+1. Select the following roles:
+    - query-users
+    - query-groups
+    - view-users
+1. Click **Assign**.
+
+</TabItem>
+<TabItem value="Groups">
+
+1. In the navigation menu, click **Groups**.
+1. Click the group  you want to add role mappings to.
+1. Click the **Role mapping** tab.
+1. Click **Assign role**.
+1. Select the following roles:
+    - query-users
+    - query-groups
+    - view-users
+1. Click **Assign**.
+
+</TabItem>
+</Tabs>

 ## Configuring Keycloak in Rancher

@@ -64,6 +106,13 @@ If you have an existing configuration using the SAML protocol and want to switch
 1. In the left navigation bar, click **Auth Provider**.
 1. Select **Keycloak (OIDC)**.
 1. Complete the **Configure a Keycloak OIDC account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
+
+    :::note
+
+    When configuring the **Endpoints** section using the **Generate** option, Rancher includes `/auth` as part of the context path in the **Issuer** and **Auth Endpoint** fields, which is only valid for Keycloak 16 or older. You must configure endpoints using the **Specify** option for [Keycloak 17](https://www.keycloak.org/docs/latest/release_notes/index.html#keycloak-17-0-0) and newer, which have [migrated to Quarkus](https://www.keycloak.org/migration/migrating-to-quarkus).  
+
+    :::
+
 1. After you complete the **Configure a Keycloak OIDC account** form, click **Enable**.

    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
@@ -74,7 +123,7 @@ If you have an existing configuration using the SAML protocol and want to switch

    :::

-**Result:** Rancher is configured to work with Keycloak using the OIDC protocol. Your users can now sign into Rancher using their Keycloak logins.
+**Result:** Rancher is configured to work with Keycloak using the OIDC protocol. Your users can now sign in to Rancher using their Keycloak logins.

 ## Configuration Reference

@@ -94,37 +143,19 @@ If you have an existing configuration using the SAML protocol and want to switch

 This section describes the process to transition from using Rancher with Keycloak (SAML) to Keycloak (OIDC).

-### Reconfigure Keycloak
+1. Reconfigure Keycloak.
+    1. Configure a new `OpenID Connect` client according to the [Prerequisites](#prerequisites). Ensure the same `Valid Redirect URIs` are set.
+    1. Configure mappers for the new client according to the [Prerequisites](#prerequisites).
+1. Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled.
+    1. In the Rancher UI, click **☰ > Users & Authentication**.
+    1. In the left navigation bar, click **Auth Provider**.
+    1. Select **Keycloak (SAML)**.
+    1. Click **Disable**.
+1. Follow the steps in [Configuring Keycloak in Rancher](#configuring-keycloak-in-rancher).

-1. Change the existing client to use the OIDC protocol. In the Keycloak console, select **Clients**, select the SAML client to migrate, select the **Settings** tab, change `Client Protocol` from `saml` to `openid-connect`, and click **Save**
+:::caution

-1. Verify the `Valid Redirect URIs` are still valid.
-
-1. Select the **Mappers** tab and create a new Mapper with the settings below.
-
-    Setting | Value
-    ------------|------------
-    `Name` | `Groups Mapper`
-    `Mapper Type` | `Group Membership`
-    `Token Claim Name` | `groups`
-    `Add to ID token` | `ON`
-    `Add to access token` | `ON`
-    `Add to user info` | `ON`
-
-### Reconfigure Rancher
-
-Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled.
-
-1. In the Rancher UI, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Auth Provider**.
-1. Select **Keycloak (SAML)**.
-1. Click **Disable**.
-
-Configure Rancher to use Keycloak (OIDC) by following the steps in [this section](#configuring-keycloak-in-rancher).
-
-:::note
-
-After configuration is completed, Rancher user permissions will need to be reapplied as they are not automatically migrated.
+After configuration is completed, Rancher user permissions need to be reapplied as they are not automatically migrated.

 :::

@@ -132,18 +163,34 @@ After configuration is completed, Rancher user permissions will need to be reapp

 If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration options of your OIDC client. You may also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.

-All Keycloak related log entries will be prepended with either `[generic oidc]` or `[keycloak oidc]`.
+All Keycloak related log entries are prepended with either `[generic oidc]` or `[keycloak oidc]`.

 ### You are not redirected to Keycloak

-When you fill the **Configure a Keycloak OIDC account** form and click on **Enable**, you are not redirected to your IdP.
+When you fill the **Configure a Keycloak OIDC account** form and click **Enable**, you are not redirected to your IdP.

-  * Verify your Keycloak client configuration.
+Verify your Keycloak client configuration.

 ### The generated `Issuer` and `Auth Endpoint` are incorrect

-  * On the **Configure a Keycloak OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` and `Auth Endpoint` values. To find the values, go to the Keycloak console and select **Realm Settings**, select the **General** tab, and click **OpenID Endpoint Configuration**. The JSON output will display values for `issuer` and `authorization_endpoint`.
+On the **Configure a Keycloak OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` and `Auth Endpoint` values. To find the values, go to the Keycloak console and select **Realm Settings**, select the **General** tab, and click **OpenID Endpoint Configuration**. The JSON output displays values for `issuer` and `authorization_endpoint`.

 ### Keycloak Error: "Invalid grant_type"

-  * In some cases, this error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
+In some cases, this error message may be misleading and is caused by setting the `Valid Redirect URI` incorrectly.
+
+### Unable to See Groups When Assigning Global Roles
+
+If you use a user that is not part of any groups for initial setup, then you cannot search for groups when trying to assign a global role. 
+To resolve this, you can either:
+
+1. Manually edit the `authconfig/keycloakoidc` object to enable group search.
+  
+    1. On the Rancher server:
+     ```bash
+     kubectl edit authconfigs.management.cattle.io keycloakoidc
+     ```
+    2. Set `groupSearchEnabled: true`.
+    3. Save your changes.
+ 
+2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
@@ -168,7 +168,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
 When you click on **Authenticate with Keycloak**, you are not redirected to your IdP.

  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` set to `OFF`.
+  * Make sure `Force Post Binding` is set to `OFF`.


 ### Forbidden message displayed after IdP login
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-

 ## First Log In

-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.

 :::danger

@@ -90,4 +90,4 @@ The following features are available under **Global Configuration**:
 - **Global DNS Entries**
 - **Global DNS Providers**

-As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
+As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
@@ -8,6 +8,10 @@ title: Pod Security Admission (PSA) Configuration Templates

 [Pod Security admission (PSA)](./pod-security-standards.md) configuration templates are a Rancher custom-defined resource (CRD), available in Rancher v2.7.2 and above. The templates provide pre-defined security configurations that you can apply to a cluster:

+:::info important
+The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#exempting-required-rancher-namespaces) that won't be used within your environments.
+:::
+
 - `rancher-privileged`: The most permissive configuration. It doesn't restrict the behavior of any pods. This allows for known privilege escalations. This policy has no exemptions.
 - `rancher-restricted`: A heavily restricted configuration that follows current best practices for hardening pods. You must make [namespace-level exemptions](./pod-security-standards.md#rancher-on-psa-restricted-clusters) for Rancher components.

@@ -82,7 +82,7 @@ This section outlines the guidelines for the proper usage of the Rancher Backups
 ### Restores

 - A restore refers to restoring a backup to the same cluster it was taken from. This can be with Rancher installed (**prune must be enabled**) or with it not installed (no special instructions).
- One thing to note when restoring is that you may find yourself needing to “wipe” the cluster of any Rancher resources. This can be done by deploying the [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) script as a job to the cluster. This allows you to install Rancher Backups again and restore to a completely fresh cluster.
+- One thing to note when restoring is that you may find yourself needing to “wipe” the cluster of any Rancher resources. This can be done by deploying the [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) as a job to the cluster. This allows you to install Rancher Backups again and restore to a completely fresh cluster.
  - Make sure to use kubectl to deploy the scripts.

 ### Migrations
@@ -52,10 +52,10 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o

     The above assumes an environment with outbound connectivity to Docker Hub.

-     For an **air-gapped environment**, use the following Helm value to pull the `backup-restore-operator` image from your private registry when you install the rancher-backup Helm chart.
+     For an **air-gapped environment**, use the following Helm values to pull the `backup-restore-operator` and `kubectl` images from your private registry when you install the rancher-backup Helm chart.

     ```bash
-     --set image.repository <registry>/rancher/backup-restore-operator
+     --set image.repository <registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
     ```

     :::
@@ -140,6 +140,26 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o

   1. Once the Restore resource has the status `Completed`, you can continue the cert-manager and Rancher installation.

+:::note Important:
+
+When migrating Rancher between any two different Kubernetes distributions (e.g. from K3s to RKE2), the object representing the local cluster has to be modified to allow Rancher to detect the new distribution. After the restoration is completed, and **before** bringing up Rancher on the new cluster, edit the local cluster object:
+
+```bash
+kubectl edit clusters.management.cattle.io local
+```
+
+1. Change the value of `status.driver` to `imported`.
+1. Remove `status.provider`.
+1. Remove the entire `status.version` map.
+1. Remove the label with the key `provider.cattle.io` in `metadata.labels`.
+1. Remove the annotation with the key `management.cattle.io/current-cluster-controllers-version` in `metadata.annotations`.
+1. Remove the entire `spec.rke2Config` or `spec.k3sConfig` map, if present.
+1. Save the changes.
+
+Note that removing `spec.rke2Config` or `spec.k3sConfig` will erase your distribution-specific upgrade configuration for the local cluster. It can be [reconfigured](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) if the new distribution is configurable for the local cluster.
+
+:::
+
 ### 3. Install cert-manager

 Follow the steps to [install cert-manager](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
@@ -18,7 +18,7 @@ Rancher supports two different types of charts: Helm charts and Rancher charts.

 ### Helm Charts

-Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you' can provide the chart's parameter values in a YAML editor.
+Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you can provide the chart's parameter values in a YAML editor.

 ### Rancher Charts

@@ -16,7 +16,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories

 ### Catalogs, Apps, and the Rancher UI

-[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. 
+[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. 

 Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature. 

@@ -6,6 +6,8 @@ title: Setting up Infrastructure for a High Availability RKE Kubernetes Cluster
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster"/>
 </head>

+<EOLRKE1Warning />
+
 This tutorial is intended to help you create a high-availability RKE cluster that can be used to install a Rancher server.

 :::note Important:
@@ -6,6 +6,8 @@ title: Setting up a High-availability RKE Kubernetes Cluster
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher"/>
 </head>

+<EOLRKE1Warning />
+
 This section describes how to install a Kubernetes cluster. This cluster should be dedicated to run only the Rancher server.

 :::note
@@ -35,6 +35,8 @@ Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-adm

 To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group. 

+AKS clusters can be imported only if local accounts are enabled. If a cluster is configured to use Microsoft Entra ID for authentication, then Rancher will not be able to import it and report an error.
+
 EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher. 

 GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison) for more information about the differences between GKE modes.
@@ -286,3 +288,20 @@ To annotate a registered cluster,
 6. Click **Save**.

 **Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.
+
+## Troubleshooting
+
+This section lists some of the most common errors that may occur when importing a cluster, along with steps to troubleshoot them.
+
+### AKS
+
+- The following error may occur if local accounts are disabled in your cluster.
+  ```sh
+  Error: Getting static credential is not allowed because this cluster is set to disable local accounts.
+  ```
+
+  To resolve this issue, enable local accounts before attempting to [import the cluster](#registering-a-cluster) again.
+
+  ```sh
+  az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts
+  ```
@@ -175,34 +175,7 @@ stringData:
      "loadBalancerSku": "standard",
      "excludeMasterFromStandardLB": false,
    }
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-rules:
-  - apiGroups: [""]
-resources: ["secrets"]
-resourceNames: ["azure-cloud-config"]
-verbs:
-  - get
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: system:azure-cloud-provider-secret-getter
-  subjects:
-    - kind: ServiceAccount
-      name: azure-cloud-config
-      namespace: kube-system
+
   ``` 

 ## Using the Out-of-tree Azure Cloud Provider
@@ -212,109 +185,85 @@ roleRef:

 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.

-2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
-  - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.

-3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. 
+3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.

-Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+    Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+
+4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
+Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+
+  Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).

  ```yaml
-apiVersion: helm.cattle.io/v1
-kind: HelmChart
-metadata:
-  name: azure-cloud-controller-manager
-  namespace: kube-system
-spec:
-  chart: cloud-provider-azure
-  repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
-  targetNamespace: kube-system
-  bootstrap: true
-  valuesContent: |-
-    infra:
-      clusterName: <cluster-name>
-    cloudControllerManager:
-      cloudConfigSecretName: azure-cloud-config
-      cloudConfig: null
-      clusterCIDR: null
-      enableDynamicReloading: 'true'
-      nodeSelector: 
-        node-role.kubernetes.io/control-plane: 'true'
-      allocateNodeCidrs: 'false' 
-      hostNetworking: true
-      caCertDir: /etc/ssl
-      configureCloudRoutes: 'false'
-      enabled: true
-      tolerations:
-        - effect: NoSchedule
-          key: node-role.kubernetes.io/master
-        - effect: NoSchedule
-          key: node-role.kubernetes.io/control-plane
-          value: 'true'
-        - effect: NoSchedule
-          key: node.cloudprovider.kubernetes.io/uninitialized
-          value: 'true'
---
-apiVersion: v1
-kind: Secret
-metadata:
-  name: azure-cloud-config
-  namespace: kube-system
-type: Opaque
-stringData:
-  cloud-config: |-
-    {
-      "cloud": "AzurePublicCloud",
-      "tenantId": "<tenant-id>",
-      "subscriptionId": "<subscription-id>",
-      "aadClientId": "<client-id>",
-      "aadClientSecret": "<tenant-id>",
-      "resourceGroup": "docker-machine",
-      "location": "westus",
-      "subnetName": "docker-machine",
-      "securityGroupName": "rancher-managed-kqmtsjgJ",
-      "securityGroupResourceGroup": "docker-machine",
-      "vnetName": "docker-machine-vnet",
-      "vnetResourceGroup": "docker-machine",
-      "primaryAvailabilitySetName": "docker-machine",  
-      "routeTableResourceGroup": "docker-machine",
-      "cloudProviderBackoff": false,
-      "useManagedIdentityExtension": false,
-      "useInstanceMetadata": true,
-      "loadBalancerSku": "standard",
-      "excludeMasterFromStandardLB": false,
-    }
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-rules:
-  - apiGroups: [""]
-resources: ["secrets"]
-resourceNames: ["azure-cloud-config"]
-verbs:
-  - get
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: system:azure-cloud-provider-secret-getter
-  subjects:
-    - kind: ServiceAccount
-      name: azure-cloud-config
-      namespace: kube-system
+  apiVersion: helm.cattle.io/v1
+  kind: HelmChart
+  metadata:
+    name: azure-cloud-controller-manager
+    namespace: kube-system
+  spec:
+    chart: cloud-provider-azure
+    repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+    targetNamespace: kube-system
+    bootstrap: true
+    valuesContent: |-
+      infra:
+        clusterName: <cluster-name>
+      cloudControllerManager:
+        cloudConfigSecretName: azure-cloud-config
+        cloudConfig: null
+        clusterCIDR: null
+        enableDynamicReloading: 'true'
+        nodeSelector: 
+          node-role.kubernetes.io/control-plane: 'true'
+        allocateNodeCidrs: 'false' 
+        hostNetworking: true
+        caCertDir: /etc/ssl
+        configureCloudRoutes: 'false'
+        enabled: true
+        tolerations:
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/master
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/control-plane
+            value: 'true'
+          - effect: NoSchedule
+            key: node.cloudprovider.kubernetes.io/uninitialized
+            value: 'true'
+  ---
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: azure-cloud-config
+    namespace: kube-system
+  type: Opaque
+  stringData:
+    cloud-config: |-
+      {
+        "cloud": "AzurePublicCloud",
+        "tenantId": "<tenant-id>",
+        "subscriptionId": "<subscription-id>",
+        "aadClientId": "<client-id>",
+        "aadClientSecret": "<tenant-id>",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-kqmtsjgJ",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",  
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true,
+        "loadBalancerSku": "standard",
+        "excludeMasterFromStandardLB": false,
+      }
  ```

-4. Click **Create** to submit the form and create the cluster.
+5. Click **Create** to submit the form and create the cluster.

 </TabItem>

@@ -11,7 +11,7 @@ description: Configuring an Ingress

 For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.

-Because of this change to the controller, the default RKE1 behavior no longer sets `hostNetwork` to `true`. However, you must set `hostNetwork` to `true` for TCP- and UDP-based Services to work. To do so, [edit](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#editing-clusters-with-yaml) the cluster's YAML and follow the steps in the [official RKE1 doccumention](https://rke.docs.rancher.com/config-options/add-ons/ingress-controllers#configuring-network-options).
+Because of this change to the controller, the default RKE1 behavior no longer sets `hostNetwork` to `true`. However, you must set `hostNetwork` to `true` for TCP- and UDP-based Services to work. To do so, [edit](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#editing-clusters-with-yaml) the cluster's YAML and follow the steps in the [official RKE1 documentation](https://rke.docs.rancher.com/config-options/add-ons/ingress-controllers#configuring-network-options).

 :::

@@ -6,6 +6,8 @@ title: Behavior Differences Between RKE1 and RKE2
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/rke1-vs-rke2-differences"/>
 </head>

+<EOLRKE1Warning />
+
 RKE2, also known as RKE Government, is a Kubernetes distribution that focuses on security and compliance for U.S. Federal Government entities. It is considered the next iteration of the Rancher Kubernetes Engine, now known as RKE1.

 RKE1 and RKE2 have several slight behavioral differences to note, and this page will highlight some of these at a high level.
@@ -35,7 +35,7 @@ The packages that need to be installed on the template are listed below. These w
 * cloud-init
 * cloud-guest-utils
 * cloud-image-utils
-* growpart
+* growpart (part of cloud-guest-utils)
 * cloud-initramfs-growroot
 * open-iscsi
 * openssh-server
@@ -131,7 +131,7 @@ cloud-init clean -s -l

 ### Windows Preparation

-Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:
+Windows has a utility called [sysprep](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation?view=windows-11) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:

 ```PowerShell
 sysprep.exe /generalize /shutdown /oobe
@@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https:

 ## Creating a VMware vSphere Cluster

+:::note
+
+User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines.
+
+:::
+
 1. [Create your cloud credentials](#1-create-your-cloud-credentials)
 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
@@ -6,7 +6,7 @@ title: Adding Users to Clusters
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters"/>
 </head>

-If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
+To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.

 :::tip

@@ -33,6 +33,14 @@ Cluster administrators can edit the membership for a cluster, controlling which
 1. In the **Member Roles** tab, click **Add Member**.
 1. Search for the user or group that you want to add to the cluster.

+    :::note Notes:
+
+    - At least 2 characters must be typed in the search box for results to appear.
+    - Users can be searched based on their username or display name.
+    - Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
+
+    :::
+
    If external authentication is configured:

    - Rancher returns users from your [external authentication](../../authentication-permissions-and-global-configuration/authentication-config/authentication-config.md) source as you type.
@@ -42,7 +42,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl

 ### About the kube-api-auth Authentication Webhook

-The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
+The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.

 During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.

@@ -184,6 +184,12 @@ for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }'
 </TabItem>
 <TabItem value="RKE2">

+:::note
+
+For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Rancher, see the [official RKE2 documentation](https://docs.rke2.io/install/uninstall) on uninstalling clusters.
+
+:::
+  
 You need to remove the following components from Rancher-provisioned RKE2 nodes:

 * The rancher-system-agent, which connects to Rancher and installs and manages RKE2.
@@ -168,7 +168,15 @@ By default, your user is added as the project `Owner`.
 To add members:

 1. In the **Members** tab, click **Add**.
-1. From the **Select Member** field, search for a user or group that you want to assign project access. Note: You can only search for groups if external authentication is enabled.
+1. From the **Select Member** field, search for a user or group that you want to assign project access. You can only search for groups if external authentication is enabled.
+
+    :::note Notes:
+
+    - At least 2 characters must be typed in the search box for results to appear.
+    - Users can be searched based on their username or display name.
+    - Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
+
+    :::
 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
@@ -19,6 +19,11 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
+| v2.10.5         | v105.0.0+up5.0.1 |
+| v2.10.4         | v105.0.0+up5.0.1 |
+| v2.10.3         | v105.0.0+up5.0.1 |
+| v2.10.2         | v105.0.0+up5.0.1 |
+| v2.10.1         | v105.0.0+up5.0.1 |
 | v2.10.0         | v105.0.0+up5.0.1 |

 ### 1. Gain Access to the Local Cluster
@@ -9,6 +9,6 @@ title: Cluster API (CAPI) with Rancher Turtles
 [Rancher Turtles](https://turtles.docs.rancher.com/) is a [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/#operators-in-kubernetes) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:

 - Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
- Configure the [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values).
+- Configure the [CAPI Operator](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html#cluster-api-operator-values).

 The [Overview](./overview.md) section outlines installation options, Rancher Turtles architecture, and a brief demo. For more details, see the [Rancher Turtles documentation](https://turtles.docs.rancher.com/).
@@ -16,7 +16,7 @@ Below is a visual representation of the key components of Rancher Turtles and th

 As defined by [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/spec/v1.0/about), SLSA is a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. The specification set by SLSA is useful for both software producers and consumers: producers can follow SLSA’s guidelines to make their software supply chain more secure, and consumers can use SLSA to make decisions about whether to trust a software package.

-Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/security/slsa) document.
+Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/turtles/next/en/security/slsa.html) document.

 ## Prerequisites

@@ -92,7 +92,7 @@ By adding the Turtles repository via the Rancher UI, Rancher can process the ins
 1. Click **Rancher Turtles - the Cluster API Extension**.
 1. Click **Install > Next > Install**.

-This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values).
+This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html).

 The installation may take a few minutes and after completing you can see the following new deployments in the cluster:

@@ -115,7 +115,7 @@ There are two ways to install Rancher Turtles with Helm, depending on whether yo

 The CAPI Operator is required for installing Rancher Turtles. You can choose whether you want to take care of this dependency yourself or let the Rancher Turtles Helm chart manage it for you. [Installing Turtles as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency) is simpler, but your best option depends on your specific configuration.

-The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/tasks/capi-operator/installing_core_provider) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).
+The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/turtles/next/en/tasks/capi-operator/installing_core_provider) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).

 #### Installing Rancher Turtles with `Cluster API (CAPI) Operator` as a Helm dependency

@@ -177,7 +177,7 @@ stringData:

 :::info

-For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
+For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html)

 :::

@@ -185,7 +185,7 @@ For detailed information on the values supported by the chart and their usage, r

 :::note

-Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/contributing/install_capi_operator) in the Rancher Turtles documentation for assistance.
+Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/turtles/next/en/contributing/install_capi_operator.html) in the Rancher Turtles documentation for assistance.

 :::

@@ -15,4 +15,4 @@ To learn more and get started with Rancher Prime, please visit [this page](https
 import DocCardList from '@theme/DocCardList';
 import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';

-<DocCardList items={useCurrentSidebarCategory().items.slice(0,9)} />
+<DocCardList items={useCurrentSidebarCategory().items.slice(0,10)} />
@@ -55,7 +55,7 @@ For Istio installations `103.1.0+up1.19.6` and later, Kiali uses a token value f

 Our Istio installer includes a quick-start, all-in-one installation of [Jaeger,](https://www.jaegertracing.io/) a tool used for tracing distributed systems.

-Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/latest/operator/#production-strategy)
+Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/1.65/operator/#production-strategy)

 ## Prerequisites

@@ -118,4 +118,4 @@ For more information on configuring PrometheusRules in Rancher, see [this page.]

 ## Legacy UI

-For information on the dashboards available in v2.2 to v2.4 of Rancher, before the introduction of the `rancher-monitoring` application, see the [Rancher v2.0—v2.4 docs](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
+For information on the dashboards available in v2.2 to v2.4 of Rancher, before the introduction of the `rancher-monitoring` application, see the [Rancher v2.0—v2.4 docs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
@@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni

 Introduced in Rancher v2.5, the application is powered by [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/grafana/),  [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), and the [Prometheus adapter.](https://github.com/DirectXMan12/k8s-prometheus-adapter) 

-For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
+For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).

 Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.

@@ -66,7 +66,7 @@ In general, you want to scrape data from all the workloads running in your clust

 ### About Prometheus Exporters

-Many 3rd party workloads, such as databases, queues, and web-servers, already support exposing metrics in a Prometheus format, or offer exporters that translate between the tool's metrics and a format that Prometheus understands. You can usually add these exporters as additional sidecar containers to the workload's Pods. Many Helm charts already include options to deploy the correct exporter. You can find a curated list of exports by SysDig on [promcat.io](https://promcat.io/) and on [ExporterHub](https://exporterhub.io/).
+Many 3rd party workloads, such as databases, queues, and web-servers, already support exposing metrics in a Prometheus format, or offer exporters that translate between the tool's metrics and a format that Prometheus understands. You can usually add these exporters as additional sidecar containers to the workload's Pods. Many Helm charts already include options to deploy the correct exporter. You can find a curated list of exports on [ExporterHub](https://exporterhub.io/).

 ### Prometheus support in Programming Languages and Frameworks

@@ -14,7 +14,7 @@ The Rancher CLI (Command Line Interface) is a unified tool that you can use to i
 The binary can be downloaded directly from the UI.

 1. In the upper left corner, click **☰**.
-1. At the bottom of the navigation sidebar menu, click **About**.
+1. At the bottom of the navigation sidebar menu, click the Rancher version number.
 1. Under the **CLI Downloads section**, there are links to download the binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.

 ## Requirements
@@ -8,7 +8,7 @@ title: AKS Cluster Configuration Reference

 ## Role-based Access Control

-When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher.
+When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher. In practice, this means that local accounts must be enabled in order to register an AKS cluster.

 Rancher can configure member roles for AKS clusters in the same way as any other cluster. For more information, see the section on [role-based 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)

@@ -198,7 +198,7 @@ The node operating system image. For more information for the node image options

 :::note

-The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
+The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.

 :::

@@ -6,6 +6,8 @@ title: RKE Cluster Configuration Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
 </head>

+<EOLRKE1Warning />
+
 When Rancher installs Kubernetes, it uses [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) or [RKE2](https://docs.rke2.io/) as the Kubernetes distribution.

 This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.
@@ -12,7 +12,7 @@ See the official prometheus-operator GitHub repo for an example [ServiceMonitor]

 ## PodMonitor

-See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.
+See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/developer/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.

 ## PrometheusRule

@@ -20,7 +20,7 @@ A PrometheusRule contains the alerting and recording rules that you would usuall

 For a more fine-grained approach, the `ruleSelector` field on a Prometheus resource can select which PrometheusRules should be loaded onto Prometheus, based on the labels attached to the PrometheusRules resources.

-See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/alerting/) for an example PrometheusRule.
+See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/developer/alerting/) for an example PrometheusRule.

 ## Alertmanager Config

@@ -24,7 +24,7 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio

 When a ServiceMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the ServiceMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the ServiceMonitor.

-Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) provided by Prometheus Operator.
+Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#servicemonitor) provided by Prometheus Operator.

 For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)

@@ -34,4 +34,4 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio

 When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the PodMonitor.

-Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec) provided by Prometheus Operator.
+Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#podmonitor) provided by Prometheus Operator.
@@ -2,6 +2,8 @@
 title: RKE Hardening Guides
 ---

+<EOLRKE1Warning />
+
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
 </head>
@@ -6,6 +6,8 @@ title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
 </head>

+<EOLRKE1Warning />
+
 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

 This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
@@ -1,10 +1,12 @@
 ---
 title: RKE Self-Assessment Guide - CIS Benchmark v1.24 - K8s v1.24
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
-</head>
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
+</head>
+
+<EOLRKE1Warning />

 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

@@ -1,10 +1,12 @@
 ---
 title: RKE Self-Assessment Guide - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
-</head>
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
+</head>
+
+<EOLRKE1Warning />

 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

@@ -10,7 +10,19 @@ Rancher is committed to informing the community of security issues in our produc

 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
-[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
+| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li>  <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
+| [CVE-2025-22031](https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m) | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the `BackingNampespace`, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. <br/><br/> The field is populated automatically during project creation and is formatted as `<clusterID>-<project.Name>`. For example, if your project is named `project-abc123` in a cluster with ID `cluster-xyz789`, then the project will have the `BackingNampespace`: `cluster-xyz789-project-abc123`. <br/><br/> If the `BackingNampespace` field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via `kubectl` the `BackingNampespace` will also be listed as a column. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
+| [CVE-2025-32198](https://github.com/rancher/steve/security/advisories/GHSA-95fc-g4gj-mqmx) | A vulnerability was found where users with permission to create a service in the Kubernetes cluster where Rancher is deployed can take over the Rancher UI, display their own UI, and gather sensitive information. This is only possible when the setting `ui-offline-preferred` is set to `remote`. This release introduces a patch, and the malicious user can no longer serve their own UI. If users can't upgrade, please make sure that only trustable users have access to create a service in the local cluster. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) and [v2.8.15](https://github.com/rancher/rancher/releases/tag/v2.8.15) |
+| [CVE-2025-23391](https://github.com/rancher/rancher/security/advisories/GHSA-8p83-cpfg-fj3g) | A vulnerability has been identified within Rancher where a Restricted Administrator can change the password of Administrators and take over their accounts. A Restricted Administrator should not be allowed to change the password of more privileged users unless it contains the Manage Users permissions. A new validation has been added to block a user from editing or deleting another user with more permissions than themselves. Rancher deployments where the Restricted Administrator role is not being used are not affected by this CVE. | 31 Mar 2025 | Rancher [v2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0), [v2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4), [v2.9.8](https://github.com/rancher/rancher/releases/tag/v2.9.8) and [v2.8.14](https://github.com/rancher/rancher/releases/tag/v2.8.14) |
+| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login. <br/><br/> The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
+| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue. <br/><br/> This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
+| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig). <br/><br/> Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
+| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) |
+| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
+| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
+| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**.  | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
+| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
+| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
 | [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
 | [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
 | [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
@@ -20,6 +20,11 @@ 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.10.5         |     v0.6.6      | &check;               | N/A                       |
+| v2.10.4         |     v0.6.5      | &check;               | N/A                       |
+| v2.10.3         |     v0.6.4      | &check;               | &check;                   |
+| v2.10.2         |     v0.6.3      | &check;               | &check;                   |
+| v2.10.1         |     v0.6.2      | &check;               | &check;                   |
 | v2.10.0         |     v0.6.1      | &cross;               | &check;                   |

 ## Why Do We Need It?
@@ -6,6 +6,8 @@ title: RKE1 Example YAML
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rke1-template-example-yaml"/>
 </head>

+<EOLRKE1Warning />
+
 Below is an example RKE template configuration file for reference.

 The YAML in the RKE template uses the same customization that is used when you create an RKE cluster. However, since the YAML is within the context of a Rancher provisioned RKE cluster, the customization from the RKE docs needs to be nested under the `rancher_kubernetes_engine` directive.
@@ -100,7 +100,7 @@ If you want to check resolving of domain names on all of the hosts, execute the
          - image: busybox:1.28
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -49,7 +49,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
          - image: rancherlabs/swiss-army-knife
            imagePullPolicy: Always
            name: overlaytest
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log

    ```
@@ -0,0 +1,18 @@
+---
+title: API Reference
+hide_table_of_contents: true
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
+</head>
+
+:::note
+
+At this time, not all Rancher resources are available through the Rancher Kubernetes API.
+
+:::
+
+import ApiDocMdx from '@theme/ApiDocMdx';
+
+<ApiDocMdx id="rancher-api" />
@@ -0,0 +1,84 @@
+---
+title: Using API Tokens
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
+</head>
+
+Rancher v2.8.0 introduced the [Rancher Kubernetes API](./api-reference.mdx) which can be used to manage Rancher resources through `kubectl`. This page covers information on API tokens used with the [Rancher CLI](../reference-guides/cli-with-rancher/cli-with-rancher.md), [kubeconfig files](../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md#about-the-kubeconfig-file), Terraform and the [v3 API browser](./v3-rancher-api-guide.md#enable-view-in-api).
+
+By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
+
+You can deactivate API tokens by deleting them or by deactivating the user account.
+
+## Deleting Tokens
+
+To delete a token:
+
+1. Go to the list of all tokens in the Rancher API view at `https://<Rancher-Server-IP>/v3/tokens`.
+
+1. Access the token you want to delete by its ID. For example, `https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`
+
+1. Click **Delete**.
+
+The following is a complete list of tokens generated with `ttl=0`:
+
+| Token             | Description                                                                            |
+| ----------------- | -------------------------------------------------------------------------------------- |
+| `kubectl-shell-*` | Access to `kubectl` shell in the browser                                               |
+| `agent-*`         | Token for agent deployment                                                             |
+| `compose-token-*` | Token for compose                                                                      |
+| `helm-token-*`    | Token for Helm chart deployment                                                        |
+| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API). |
+
+## Setting TTL on Kubeconfig Tokens
+
+Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. As of Rancher v2.8, the default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is `43200`, which means that tokens expire in 30 days.
+
+:::note
+
+This setting is used by all kubeconfig tokens except those created by the CLI to [generate kubeconfig tokens](#disable-tokens-in-generated-kubeconfigs).
+
+:::
+
+## Disable Tokens in Generated Kubeconfigs
+
+Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. When this setting is deactivated, a generated kubeconfig references the [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.
+
+## Token Hashing
+
+You can [enable token hashing](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md), where tokens undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process: once enabled, this feature cannot be disabled. You should first evaluate this setting in a test environment, and/or take backups before enabling.
+
+This feature affects all tokens which include, but are not limited to, the following:
+
+- Kubeconfig tokens
+- Bearer tokens API keys/calls
+- Tokens used by internal operations
+
+## Token Settings
+
+These global settings affect Rancher token behavior.
+
+| Setting                                                                         | Description                                                                                                                                                                                                                    |
+| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).                                                 |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |
+
+### auth-user-session-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+
+### kubeconfig-default-token-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). As of Rancher v2.8, the default duration is `43200`, which means that tokens expire in 30 days.
+
+### auth-token-max-ttl-minutes
+
+Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher sets the token TTL to the value of `auth-token-max-ttl-minutes`. Applies to all kubeconfig tokens and API tokens. As of Rancher v2.8, the default duration is `129600`, which means that tokens expire in 90 days.
+
+### kubeconfig-generate-token
+
+When true, kubeconfigs requested through the UI contain a valid token. When false, kubeconfigs contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then retrieves and caches a token for the user](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
@@ -0,0 +1,15 @@
+---
+title: Extension API Server
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/extension-apiserver"/>
+</head>
+
+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
+
+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).
+
+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.
@@ -0,0 +1,152 @@
+---
+title: RK-API Quick Start Guide
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/quickstart"/>
+</head>
+
+You can access Rancher's resources through the Kubernetes API. This guide helps you get started on using this API as a Rancher user.
+
+1. In the upper left corner, click **☰ > Global Settings**.
+2. Find and copy the address in the `server-url` field.
+3. [Create](../reference-guides/user-settings/api-keys.md#creating-an-api-key) a Rancher API key with no scope.
+
+  :::danger
+
+  A Rancher API key with no scope grants unrestricted access to all resources that the user can access. To prevent unauthorized use, this key should be stored securely and rotated frequently.
+
+  :::
+
+4. Create a `kubeconfig.yaml` file. Replace `$SERVER_URL` with the server url and `$API_KEY` with your Rancher API key:
+
+    ```yaml
+    apiVersion: v1
+    kind: Config
+    clusters:
+    - name: "rancher"
+      cluster:
+        server: "$SERVER_URL"
+    
+    users:
+    - name: "rancher"
+      user:
+        token: "$API_KEY"
+
+    contexts:
+    - name: "rancher"
+      context:
+        user: "rancher"
+        cluster: "rancher"
+
+    current-context: "rancher"
+    ```
+
+You can use this file with any compatible tool, such as kubectl or [client-go](https://github.com/kubernetes/client-go). For a quick demo, see the [kubectl example](#api-kubectl-example).
+
+For more information on handling more complex certificate setups, see [Specifying CA Certs](#specifying-ca-certs).
+
+For more information on available kubeconfig options, see the [upstream documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+
+## API kubectl Example
+
+In this example, we'll show how to use kubectl to create a project, followed by deleting it. For a list of other Rancher resources available, refer to the [API Reference](./api-reference.mdx) page.
+
+:::note
+
+At this time, not all Rancher resources are available through the Rancher Kubernetes API.
+
+:::
+
+1. Set your KUBECONFIG environment variable to the kubeconfig file you just created:
+
+  ```bash
+  export KUBECONFIG=$(pwd)/kubeconfig.yaml
+  ```
+
+2. Use `kubectl explain` to view the available fields for projects, or complex sub-fields of resources:
+
+  ```bash
+  kubectl explain projects
+  kubectl explain projects.spec
+  ```
+  
+Not all resources may have detailed output.
+
+3. Add the following content to a file named `project.yaml`:
+
+  ```yaml
+  apiVersion: management.cattle.io/v3
+  kind: Project
+  metadata:
+    # name should be unique across all projects in every cluster
+    name: p-abc123
+    # generateName can be used instead of `name` to randomly generate a name.
+    # generateName: p-
+    # namespace should match spec.ClusterName.
+    namespace: local
+  spec:
+    # clusterName should match `metadata.Name` of the target cluster.
+    clusterName: local
+    description: Example Project 
+    # displayName is the human-readable name and is visible from the UI.
+    displayName: Example
+  ```
+
+4. Create the project:
+
+  ```bash
+  kubectl create -f project.yaml
+  ```
+
+5. Delete the project:
+
+  How you delete the project depends on how you created the project name.
+
+  **A. If you used `name` when creating the project**:
+
+    ```bash
+    kubectl delete -f project.yaml
+    ```
+
+  **B. If you used `generateName`**:
+
+    Replace `$PROJECT_NAME` with the randomly generated name of the project displayed by Kubectl after you created the project.
+
+    ```bash
+    kubectl delete project $PROJECT_NAME -n local
+    ```
+
+## Specifying CA Certs
+
+To ensure that your tools can recognize Rancher's CA certificates, most setups require additional modifications to the above template.
+
+1. In the upper left corner, click **☰ > Global Settings**.
+2. Find and copy the value in the `ca-certs` field.
+3. Save the value in a file named `rancher.crt`.
+
+  :::note
+  If your Rancher instance is proxied by another service, you must extract the certificate that the service is using, and add it to the kubeconfig file, as demonstrated in step 5.
+  :::
+
+4. The following commands convert `rancher.crt` to base64 output, trim all new-lines, and update the cluster in the kubeconfig with the certificate, then finish by removing the `rancher.crt` file:
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.certificate-authority-data $(cat rancher.crt | base64 -i - | tr -d '\n')
+  rm rancher.crt
+  ```
+5. (Optional) If you use self-signed certificatess that aren't trusted by your system, you can set the insecure option in your kubeconfig with kubectl:
+
+  :::danger
+
+  This option shouldn't be used in production as it is a security risk.
+
+  :::
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.insecure-skip-tls-verify true
+  ```
+
+  If your Rancher instance is proxied by another service, you must extract the certificate that the service is using, and add it to the kubeconfig file, as demonstrated above.
@@ -0,0 +1,94 @@
+---
+title: Previous v3 Rancher API Guide
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/v3-rancher-api-guide"/>
+</head>
+
+Rancher v2.8.0 introduced the Rancher Kubernetes API (RK-API). The previous v3 Rancher API is still available. This page describes the v3 API. For more information on RK-API, see the [RK-API quickstart](./quickstart.md) and [reference guide](./api-reference.mdx).
+
+## How to Use the API
+
+The previous v3 API has its own user interface accessible from a [web browser](#enable-view-in-api). This is an easy way to see resources, perform actions, and see the equivalent `curl` or HTTP request & response. To access it:
+
+<Tabs>
+<TabItem value="Rancher v2.6.4+">
+
+1. Click your user avatar in the upper right corner.
+1. Click **Account & API Keys**.
+1. Under the **API Keys** section, find the **API Endpoint** field and click the link. The link looks something like `https://<RANCHER_FQDN>/v3`, where `<RANCHER_FQDN>` is the fully qualified domain name of your Rancher deployment.
+
+</TabItem>
+<TabItem value="Rancher before v2.6.4">
+
+Go to the URL endpoint at `https://<RANCHER_FQDN>/v3`, where `<RANCHER_FQDN>` is the fully qualified domain name of your Rancher deployment.
+
+</TabItem>
+</Tabs>
+
+## Authentication
+
+API requests must include authentication information. Authentication is done with HTTP basic authentication using [API keys](../reference-guides/user-settings/api-keys.md). API keys can create new clusters and have access to multiple clusters via `/v3/clusters/`. [Cluster and project roles](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md) apply to these keys and restrict what clusters and projects the account can see and what actions they can take.
+
+By default, certain cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. For details on how to invalidate them, refer to the [API tokens page](api-tokens.md).
+
+## Making Requests
+
+The API is generally RESTful but has several features to make the definition of everything discoverable by a client so that generic clients can be written instead of having to write specific code for every type of resource. For detailed info about the generic API spec, [see further documentation](https://github.com/rancher/api-spec/blob/master/specification.md).
+
+- Every type has a Schema which describes:
+  - The URL to get to the collection of this type of resource.
+  - Every field the resource can have, along with their type, basic validation rules, whether they are required or optional, etc.
+  - Every action that is possible on this type of resource, with their inputs and outputs (also as schemas).
+  - Every field that allows filtering.
+  - What HTTP verb methods are available for the collection itself, or for individual resources in the collection.
+
+The design allows you to load just the list of schemas and access everything about the API. The UI for the API contains no code specific to Rancher itself. The URL to get Schemas is sent in every HTTP response as a `X-Api-Schemas` header. From there you can follow the `collection` link on each schema to know where to list resources, and follow other `links` inside of the returned resources to get any other information.
+
+In practice, you may just want to construct URL strings. We highly suggest limiting this to the top-level to list a collection (`/v3/<type>`) or get a specific resource (`/v3/<type>/<id>`). Anything deeper than that is subject to change in future releases.
+
+Resources have relationships between each other called links. Each resource includes a map of `links` with the name of the link and the URL where you can retrieve that information. Again, you should `GET` the resource and then follow the URL in the `links` map, not construct these strings yourself.
+
+Most resources have actions, which do something or change the state of the resource. To use them, send a HTTP `POST` to the URL in the `actions` map of the action you want. Certain actions require input or produce output. See the individual documentation for each type or the schemas for specific information.
+
+To edit a resource, send a HTTP `PUT` to the `links.update` link on the resource with the fields that you want to change. If the link is missing then you don't have permission to update the resource. Unknown fields and ones that are not editable are ignored.
+
+To delete a resource, send a HTTP `DELETE` to the `links.remove` link on the resource. If the link is missing then you don't have permission to update the resource.
+
+To create a new resource, HTTP `POST` to the collection URL in the schema (which is `/v3/<type>`).
+
+## Filtering
+
+Most collections can be filtered on the server-side by common fields using HTTP query parameters. The `filters` map shows you what fields can be filtered on and what the filtered values were for the request you made. The API UI has controls to setup filtering and show you the appropriate request. For simple "equals" matches it's just `field=value`. Modifiers can be added to the field name, for example, `field_gt=42` for "field is greater than 42." See the [API spec](https://github.com/rancher/api-spec/blob/master/specification.md#filtering) for full details.
+
+## Sorting
+
+Most collections can be sorted on the server-side by common fields using HTTP query parameters. The `sortLinks` map shows you what sorts are available, along with the URL to get the collection sorted by that. It also includes info about what the current response was sorted by, if specified.
+
+## Pagination
+
+API responses are paginated with a limit of 100 resources per page by default. This can be changed with the `limit` query parameter, up to a maximum of 1000, for example, `/v3/pods?limit=1000`. The `pagination` map in collection responses tells you whether or not you have the full result set and has a link to the next page if you do not.
+
+## Capturing v3 API Calls
+
+You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster:
+
+1. In the Rancher UI, go to **Cluster Management** and click **Create.**
+1. Click one of the cluster types. This example uses Digital Ocean.
+1. Fill out the form with a cluster name and node template, but don't click **Create**.
+1. You need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click the Rancher UI and click **Inspect.**
+1. In the developer tools, click the **Network** tab.
+1. On the **Network** tab, make sure **Fetch/XHR** is selected.
+1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`.
+1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.**
+1. Paste the result into any text editor. You can see the POST request, including the URL it was sent to, all headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: the request should be stored in a safe place because it contains credentials.
+
+### Enable View in API
+
+You can also view captured v3 API calls for your respective clusters and resources. This feature is not enabled by default. To enable it:
+
+1. Click your **User Tile** in the top right corner of the UI and select **Preferences** from the drop-down menu.
+2. Under the **Advanced Features** section, click **Enable "View in API"**
+
+Once checked, the **View in API** link is displayed under the **⋮** sub-menu on resource pages in the UI.
@@ -0,0 +1,210 @@
+---
+title: Projects
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/projects"/>
+</head>
+
+## Creating a Project
+
+Project resources may only be created on the management cluster. See below for [creating namespaces under projects in a managed cluster](#creating-a-namespace-in-a-project).
+
+### Creating a Basic Project
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+Use `metadata.generateName` to ensure a unique project ID, but note that `kubectl apply` does not work with `metadata.generateName`, so `kubectl create` must be used instead.
+
+Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
+
+If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  annotations: 
+  field.cattle.io/creatorId:
+    user-id
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+
+Setting the  `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
+
+If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
+
+### Creating a Project With a Resource Quota
+
+Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  resourceQuota:
+    limit:
+      limitsCpu: 1000m
+  namespaceDefaultResourceQuota:
+    limit:
+      limitsCpu: 50m
+EOF
+```
+
+### Creating a Project With Container Limit Ranges
+
+Refer to [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/).
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  containerDefaultResourceLimit:
+    limitsCpu:    100m
+    limitsMemory: 100Mi
+    requestsCpu:  50m
+    requestsMemory: 50Mi
+EOF
+```
+
+## Adding a Member to a Project
+
+Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
+
+```bash
+kubectl get roletemplates
+```
+
+When adding a user member specify the `userPrincipalName` field:
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: ProjectRoleTemplateBinding
+metadata:
+  generateName: prtb-
+  namespace: p-vwxyz
+projectName: c-m-abcde:p-vwxyz
+roleTemplateName: project-member
+userPrincipalName: keycloak_user://user
+EOF
+```
+
+When adding a group member specify the `groupPrincipalName` field instead:
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: ProjectRoleTemplateBinding
+metadata:
+  generateName: prtb-
+  namespace: p-vwxyz
+projectName: c-m-abcde:p-vwxyz
+roleTemplateName: project-member
+groupPrincipalName: keycloak_group://group
+EOF
+```
+
+Create a projectroletemplatebinding for each role you want to assign to the project member.
+
+## Listing Project Members
+
+Look up the project ID:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+to list projectroletemplatebindings in the project's namespace:
+
+```bash
+kubectl --namespace p-vwxyz get projectroletemplatebindings
+```
+
+## Deleting a Member From a Project
+
+Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
+
+Delete the projectroletemplatebinding from the project's namespace:
+
+```bash
+kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
+```
+
+## Creating a Namespace in a Project
+
+The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.
+
+On the management cluster, look up the project ID for the cluster you are administrating since it generated using `metadata.generateName`:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+On the managed cluster, create a namespace with a project annotation:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: mynamespace
+  annotations:
+    field.cattle.io/projectId: c-m-abcde:p-vwxyz
+EOF
+```
+
+Note the format, `<cluster ID>:<project ID>`.
+
+## Deleting a Project
+
+Look up the project to delete in the cluster namespace:
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+Delete the project under the cluster namespace:
+
+```bash
+kubectl --namespace c-m-abcde delete project p-vwxyz
+```
+
+Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
@@ -20,11 +20,11 @@ On the Rancher Users Slack, the channel for developers is **#developer**.

 ## Rancher Docs

-If you have suggestions for the documentation on this website, [open](https://github.com/rancher/rancher-docs/issues/new/choose) an issue in the main [Rancher docs](https://github.com/rancher/rancher-docs) repository. This repo contains documentation for Rancher v2.0 and later. 
+If you have suggestions for the documentation on this website, [open](https://github.com/rancher/rancher-docs/issues/new/choose) an issue in the main [Rancher docs](https://github.com/rancher/rancher-docs) repository. This repo contains documentation for Rancher v2.0 and later.

 See the [Rancher docs README](https://github.com/rancher/rancher-docs#readme) for more details on contributing to and building the Rancher v2.x docs repo.

-For documentation describing Rancher v1.6 and earlier, see the [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) repo, which contains source files for https://rancher.com/docs/rancher/v1.6/en/. 
+For documentation describing Rancher v1.6 and earlier, see the [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) repo, which contains source files for https://rancher.com/docs/rancher/v1.6/en/.

 ## Rancher Repositories

@@ -42,7 +42,6 @@ kontainer-engine | https://github.com/rancher/kontainer-engine | This repository
 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.
-Telemetry repository | https://github.com/rancher/telemetry | This repository is the source for the Telemetry binary.
 loglevel repository | https://github.com/rancher/loglevel | This repository is the source of the loglevel binary, used to dynamically change log levels.

 To see all libraries/projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
@@ -17,11 +17,11 @@ Kubernetes uses CNI as an interface between network providers and Kubernetes pod

 For more information visit [CNI GitHub project](https://github.com/containernetworking/cni).

-### What Network Models are Used in CNI?
+## What Network Models are Used in CNI?

-CNI network providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
+CNI network providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).

-#### What is an Encapsulated Network?
+### What is an Encapsulated Network?

 This network model provides a logical Layer 2 (L2) network encapsulated over the existing Layer 3 (L3) network topology that spans the Kubernetes cluster nodes. With this model you have an isolated L2 network for containers without needing routing distribution, all at the cost of minimal overhead in terms of processing and increased IP package size, which comes from an IP header generated by overlay encapsulation. Encapsulation information is distributed by UDP ports between Kubernetes workers, interchanging network control plane information about how MAC addresses can be reached. Common encapsulation used in this kind of network model is VXLAN, Internet Protocol Security (IPSec), and IP-in-IP.

@@ -29,11 +29,11 @@ In simple terms, this network model generates a kind of network bridge extended

 This network model is used when an extended L2 bridge is preferred. This network model is sensitive to L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.

-CNI network providers using this network model include Flannel, Canal, and Weave.
+CNI network providers using this network model include Flannel, Canal, Weave, and Cilium. By default, Calico is not using this model, but it can be configured to do so.

 ![Encapsulated Network](/img/encapsulated-network.png)

-#### What is an Unencapsulated Network?
+### What is an Unencapsulated Network?

 This network model provides an L3 network to route packets between containers. This model doesn't generate an isolated l2 network, nor generates overhead. These benefits come at the cost of Kubernetes workers having to manage any route distribution that's needed. Instead of using IP headers for encapsulation, this network model uses a network protocol between Kubernetes workers to distribute routing information to reach pods, such as [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol).

@@ -41,13 +41,17 @@ In simple terms, this network model generates a kind of network router extended

 This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensitive to latency.

-CNI network providers using this network model include Calico and Romana.
+CNI network providers using this network model include Calico and Cilium. Cilium may be configured with this model although it is not the default mode.

 ![Unencapsulated Network](/img/unencapsulated-network.png)

-### What CNI Providers are Provided by Rancher?
+## What CNI Providers are Provided by Rancher?

-Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico, and Weave. You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
+### RKE Kubernetes clusters
+
+Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, Calico, and Weave.
+
+You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.

 #### Canal

@@ -57,7 +61,7 @@ Canal is a CNI network provider that gives you the best of Flannel and Calico. I

 In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.

-Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). For details, refer to [the port requirements for user clusters.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (health checks). If using Wireguard, you should open UDP ports `51820` and `51821`. For more details, refer to [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).

 ![](/img/canal-diagram.png)

@@ -67,36 +71,23 @@ For more information, see the [Canal GitHub Page.](https://github.com/projectcal

 ![Flannel Logo](/img/flannel-logo.png)

-Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
+Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan).

-Encapsulated traffic is unencrypted by default. Therefore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers.
+Encapsulated traffic is unencrypted by default. Flannel provides two solutions for encryption:

-Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. It is an experimental backend for encryption.
+* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard), which is a more faster-performing alternative to strongSwan.
+
+Kubernetes workers should open UDP port `8472` (VXLAN). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.

 ![Flannel Diagram](/img/flannel-diagram.png)

-For more information, see the [Flannel GitHub Page](https://github.com/coreos/flannel).
-
-#### Calico
-
-![Calico Logo](/img/calico-logo.png)
-
-Calico enables networking and network policy in Kubernetes clusters across the cloud. Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-prem using BGP.
-
-Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
-
-Kubernetes workers should open TCP port `179` (BGP). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
-
-![Calico Diagram](/img/calico-diagram.svg)
-
-For more information, see the following pages:
-
- [Project Calico Official Site](https://www.projectcalico.org/)
- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
-
+For more information, see the [Flannel GitHub Page](https://github.com/flannel-io/flannel).

 #### Weave

+<DeprecationWeave />
+
 ![Weave Logo](/img/weave-logo.png)

 Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
@@ -107,16 +98,77 @@ For more information, see the following pages:

 - [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)

-### CNI Features by Provider
+### RKE2 Kubernetes clusters
+
+Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
+
+You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico enables networking and network policy in Kubernetes clusters across the cloud. By default, Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-prem using BGP.
+
+Calico also provides a stateless IP-in-IP or VXLAN encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
+
+Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if using VXLAN encapsulation. In addition, TCP port `5473` is needed when using Typha. See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+:::note Important:
+
+In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.</b>
+
+- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
+
+- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
+
+:::
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+For more information, see the following pages:
+
+- [Project Calico Official Site](https://www.projectcalico.org/)
+- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
+
+#### Cilium
+
+![Cilium Logo](/img/cilium-logo.png)
+
+Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured.
+
+Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
+
+##### Ingress Routing Across Nodes in Cilium
+<br/>
+By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`.
+
+After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows:
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {}
+  ingress:
+    - fromEntities:
+      - remote-node
+```
+
+## CNI Features by Provider

 The following table summarizes the different features available for each CNI network provider provided by Rancher.

 | Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies |
 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
-| Canal | Encapsulated (VXLAN) | No | Yes | No | K8S API | No | Yes |
-| Flannel | Encapsulated (VXLAN) | No | No | No | K8S API | No | No |
-| Calico | Encapsulated (VXLAN,IPIP) OR Unencapsulated | Yes | Yes | Yes | Etcd and K8S API | No | Yes |
+| Canal | Encapsulated (VXLAN) | No | Yes | No | K8s API | Yes | Yes |
+| Flannel | Encapsulated (VXLAN) | No | No | No | K8s API | Yes | No |
+| Calico | Encapsulated (VXLAN,IPIP) OR Unencapsulated | Yes | Yes | Yes | Etcd and K8s API | Yes | Yes |
 | Weave | Encapsulated | Yes | Yes | Yes | No | Yes | Yes |
+| Cilium | Encapsulated (VXLAN) | Yes | Yes | Yes | Etcd and K8s API | Yes | Yes |

 - Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni)

@@ -132,16 +184,16 @@ The following table summarizes the different features available for each CNI net

 - Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications.

-### CNI Community Popularity
+## CNI Community Popularity

 <CNIPopularityTable />

-### Which CNI Provider Should I Use?
+## Which CNI Provider Should I Use?

 It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs.

 Canal is the default CNI network provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.

-### How can I configure a CNI network provider?
+## How can I configure a CNI network provider?

-Please see [Cluster Options](cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File](cluster-provisioning/rke-clusters/options/#cluster-config-file) and the options for [Network Plug-ins](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/).
+Please see [Cluster Options](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) and the options for [Network Plug-ins](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/).
@@ -0,0 +1,24 @@
+---
+title: Deprecated Features in Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
+</head>
+
+## What is Rancher's deprecation policy?
+
+We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
+
+## Where can I find out which features have been deprecated in Rancher?
+
+Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
+
+| Patch Version |  Release Date |
+|---------------|---------------|
+| [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 |
+
+## What can I expect when a feature is marked for deprecation?
+
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -0,0 +1,49 @@
+---
+title: Dockershim FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/dockershim"/>
+</head>
+
+The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Removal is currently scheduled for Kubernetes 1.24. For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+RKE clusters, starting with Kubernetes 1.21, now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
+
+To enable the external Dockershim, configure the following option.
+
+```
+enable_cri_dockerd: true
+```
+
+For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.
+
+## FAQ
+
+<br/>
+
+Q: Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
+
+The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.
+
+<br/>
+
+Q: I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
+
+A: The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
+
+For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+<br/>
+
+Q: What are my other options if I don’t want to depend on the Dockershim?
+
+A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
+
+<br/>
+
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
+
+A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl.
+
+<br/>
@@ -0,0 +1,47 @@
+---
+title: General FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/general-faq"/>
+</head>
+
+This FAQ is a work in progress designed to answer the questions most frequently asked about Rancher v2.x.
+
+See the [Technical FAQ](technical-items.md) for frequently asked technical questions.
+
+## Is it possible to manage Azure Kubernetes Services with Rancher v2.x?
+
+Yes. See our [Cluster Administration](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md) guide for what Rancher features are available on AKS, as well as our [documentation on AKS](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md).
+
+## Does Rancher support Windows?
+
+Yes. Rancher supports Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)
+
+## Does Rancher support Istio?
+
+Yes. Rancher supports [Istio](../integrations-in-rancher/istio/istio.md).
+
+## Will Rancher v2.x support Hashicorp's Vault for storing secrets?
+
+As of Rancher v2.9, Rancher [supports authentication with service account tokens](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication.md), which is used by Vault and other integrations.
+
+## Does Rancher v2.x support RKT containers as well?
+
+At this time, we only support Docker.
+
+## Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and registered Kubernetes?
+
+Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave.  Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported.
+
+## Are you planning on supporting Traefik for existing setups?
+
+We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches.
+
+## Can I import OpenShift Kubernetes clusters into v2.x?
+
+Our goal is to run any Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet.
+
+## Is Longhorn integrated with Rancher?
+
+Yes. Longhorn is integrated with Rancher v2.5 and later.
@@ -16,7 +16,7 @@ See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubect

 When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.

-You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`.
+You can copy this file as `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`.

 ```
 export KUBECONFIG=$(pwd)/kube_config_cluster.yml
@@ -19,13 +19,19 @@ The capability to access a downstream cluster without Rancher depends on the typ

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

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

-If you [installed Rancher on a Kubernetes cluster,](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) remove Rancher by using the [System Tools](../reference-guides/system-tools.md) with the `remove` subcommand.
+:::note

-As of Rancher v2.5.8, uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:
+The previously recommended [System Tools](../reference-guides/system-tools.md) has been deprecated since June 2022.
+
+:::
+
+If you [installed Rancher on a Kubernetes cluster,](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) remove Rancher by using the [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) tool.
+
+Uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:

 - fleet
 - fleet-agent
@@ -44,9 +50,9 @@ If a registered cluster is deleted from the Rancher UI, the cluster is detached

 To detach the cluster,

-1. From the **Global** view in Rancher, go to the **Clusters** tab.
-2. Go to the registered cluster that should be detached from Rancher and click **&#8942; > Delete.**
-3. Click **Delete.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+2. Go to the registered cluster that should be detached from Rancher and click **⋮ > Delete**.
+3. Click **Delete**.

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

@@ -0,0 +1,21 @@
+---
+title: Security FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
+</head>
+
+## Is there a Hardening Guide?
+
+The Hardening Guide is located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
+
+## Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
+
+We have run the CIS Kubernetes benchmark against a hardened Rancher Kubernetes cluster.  The results of that assessment can be found in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
+
+## How does Rancher verify communication with downstream clusters, and what are some associated security concerns?
+
+Communication between the Rancher server and downstream clusters is performed through agents. Rancher uses either a registered certificate authority (CA) bundle or the local trust store to verify communication between Rancher agents and the Rancher server. Using a CA bundle for verification is more strict, as only the certificates based on that bundle are trusted. If TLS verification for a explicit CA bundle fails, Rancher may fall back to using the local trust store for verifying future communication. Any CA within the local trust store can then be used to generate a valid certificate.
+
+As described in [Rancher Security Update CVE-2024-22030](https://www.suse.com/c/rancher-security-update/), under a narrow set of circumstances, malicious actors can take over Rancher nodes by exploiting the behavior of Rancher CAs. For the attack to succeed, the malicious actor must generate a valid certificate from either a valid CA in the targeted Rancher server, or from a valid registered CA. The attacker also needs to either hijack or spoof the Rancher server-url as a preliminary step. Rancher is currently evaluating Rancher CA behavior to mitigate against this and any similar avenues of attack. 
@@ -20,7 +20,7 @@ Kubernetes install (Helm):

 ```
 $ KUBECONFIG=./kube_config_cluster.yml
-$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password
+$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
 New password for default administrator (user-xxxxx):
 <new_password>
 ```
@@ -59,7 +59,7 @@ Node Templates can be accessed by opening your account menu (top right) and sele

 ## Why is my Layer-4 Load Balancer in `Pending` state?

-The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
+The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)

 ## Where is the state of Rancher stored?

@@ -72,7 +72,7 @@ We follow the validated Docker versions for upstream Kubernetes releases. The va

 ## How can I access nodes created by Rancher?

-SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical &#8942; button at the end of the row, and choose **Download Keys** as shown in the picture below.
+SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ⋮ button at the end of the row, and choose **Download Keys** as shown in the picture below.

 ![Download Keys](/img/downloadsshkeys.png)

@@ -91,22 +91,24 @@ The UI consists of static files, and works based on responses of the API. That m

 ## The IP address of a node changed, how can I recover?

-A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
+A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and add it again. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.

-When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/advanced-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.
+When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.

-When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
+When the node is removed from the cluster, and the node is cleaned, you can add the node to the cluster.

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

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

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

 Use the `openssl verify` command to validate your certificate chain:

 :::tip
-Configure `SSL_CERT_DIR` and `SSL_CERT_FILE` to a dummy location to make sure the OS installed certificates are not used when verifying manually.
+
+Configure `SSL_CERT_DIR` and `SSL_CERT_FILE` to a dummy location to make sure the OS-installed certificates are not used when verifying manually.
+
 :::

 ```
@@ -180,7 +182,3 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se
 ## Can I use keyboard shortcuts in the UI?

 Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.
-
-## What does `Unknown schema for type:` errors followed by something like `catalog.cattle.io.operation` mean when trying to modify an App?
-
-This error occurs when Kubernetes can not find the CRD mentioned.  The vast majority of the time these are a result of missing RBAC permissions.  Try with an admin user and if this works, add permissions for the resource mentioned by the error (ie. `Get`, `List`, `Patch` as needed).
@@ -0,0 +1,101 @@
+---
+title: Upgrading in an Air-Gapped Environment
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades"/>
+</head>
+
+:::note
+
+These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,](upgrades.md) including the prerequisites, up until step 3. Upgrade Rancher.
+
+:::
+
+## Rancher Helm Upgrade Options
+
+To upgrade with Helm, apply the same options that you used when installing Rancher. Refer to 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.
+
+Based on the choice you made during installation, complete one of the procedures below.
+
+Placeholder | Description
+------------|-------------
+`<VERSION>` | The version number of the output tarball.
+`<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer.
+`<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
+`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
+
+
+### Option A: Default Self-signed Certificate
+
+```
+helm upgrade rancher ./rancher-<VERSION>.tgz \
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set certmanager.version=<CERTMANAGER_VERSION> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+#### Resolving UPGRADE FAILED Error
+
+If you encounter the error message, `Error: UPGRADE FAILED: "rancher" has no deployed releases`, Rancher might have been  installed via the `helm template` command. To successfully upgrade Rancher, use the following command instead:
+
+```
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+    --no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set certmanager.version=<CERTMANAGER_VERSION> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+After you run the Helm command, apply the rendered template:
+
+```
+kubectl -n cattle-system apply -R -f ./rancher
+```
+
+### Option B: Certificates from Files using Kubernetes Secrets
+
+```plain
+helm upgrade rancher ./rancher-<VERSION>.tgz \
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set ingress.tls.source=secret \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
+
+```plain
+helm upgrade rancher ./rancher-<VERSION>.tgz \
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set ingress.tls.source=secret \
+	--set privateCA=true \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+## Verify the Upgrade
+
+Log into Rancher to confirm that the upgrade succeeded.
+
+:::tip
+
+Having network issues following upgrade?
+
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+
+:::
+
+## Known Upgrade Issues
+
+A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -9,11 +9,12 @@ description: Learn how to install Rancher in development and production environm

 In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.

+
 ## Prerequisites

 - [Kubernetes Cluster](#kubernetes-cluster)
+- [Ingress Controller](#ingress-controller)
 - [CLI Tools](#cli-tools)
- [Ingress Controller (Only for Hosted Kubernetes)](#ingress-controller-for-hosted-kubernetes)

 ### Kubernetes Cluster

@@ -26,9 +27,20 @@ For help setting up a Kubernetes cluster, we provide these tutorials:
 - **RKE:** For the tutorial to install an RKE Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md) For help setting up the infrastructure for a high-availability RKE cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster.md)
 - **K3s:** For the tutorial to install a K3s Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)
 - **RKE2:** For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher.md) For help setting up the infrastructure for a high-availability RKE2 cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md)
- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](rancher-on-amazon-eks.md)
- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](rancher-on-aks.md)
- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](rancher-on-gke.md)
+- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-amazon-eks.md)
+- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-aks.md)
+- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an Ingress controller so that the Rancher server can be accessed, refer to [this page.](rancher-on-gke.md) GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode.
+
+
+### Ingress Controller
+
+The Rancher UI and API are exposed through an Ingress. This means the Kubernetes cluster that you install Rancher in must contain an Ingress controller.
+
+For RKE, RKE2, and K3s installations, you don't have to install the Ingress controller manually because one is installed by default.
+
+For distributions that do not include an Ingress Controller by default, like a hosted Kubernetes cluster such as EKS, GKE, or AKS, you have to deploy an Ingress controller first. Note that the Rancher Helm chart does not set an `ingressClassName` on the ingress by default. Because of this, you have to configure the Ingress controller to also watch ingresses without an `ingressClassName`.
+
+Examples are included in the **Amazon EKS**, **AKS**, and **GKE** tutorials above.

 ### CLI Tools

@@ -37,17 +49,9 @@ The following CLI tools are required for setting up the Kubernetes cluster. Plea
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
 - [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements](../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher. Refer to the [instructions provided by the Helm project](https://helm.sh/docs/intro/install/) for your specific platform.

-### Ingress Controller (For Hosted Kubernetes)
-
-To deploy Rancher v2.5 on a hosted Kubernetes cluster such as EKS, GKE, or AKS, you should deploy a compatible Ingress controller first to configure [SSL termination on Rancher.](#3-choose-your-ssl-configuration)
-
-For an example of how to deploy an ingress on EKS, refer to [this section.](rancher-on-amazon-eks.md#5-install-an-ingress)
-
 ## Install the Rancher Helm Chart

-Rancher is installed using the Helm package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents.
-
-With Helm, we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at https://helm.sh/.
+Rancher is installed using the [Helm](https://helm.sh/) package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, we can create configurable deployments instead of just using static files.

 For systems without direct internet access, see [Air Gap: Kubernetes install](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md).

@@ -55,7 +59,11 @@ To choose a Rancher version to install, refer to [Choosing a Rancher Version.](.

 To choose a version of Helm to install Rancher with, refer to the [Helm version requirements](../resources/helm-version-requirements.md)

-> **Note:** The installation instructions assume you are using Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) This [section](../resources/helm-version-requirements.md) provides a copy of the older installation instructions for Rancher installed on an RKE Kubernetes cluster with Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+:::note
+
+The installation instructions assume you are using Helm 3.
+
+:::

 To set up Rancher,

@@ -81,7 +89,7 @@ Use `helm repo add` command to add the Helm chart repository that contains chart
    ```
 - Alpha: Experimental preview of upcoming releases.
    ```
-    helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+    helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
    ```
    Note: Upgrades are not supported to, from, or between Alphas.

@@ -97,13 +105,17 @@ kubectl create namespace cattle-system

 The Rancher management server is designed to be secure by default and requires SSL/TLS configuration.

-> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
+:::note
+
+If you want to externally terminate SSL/TLS, see [TLS termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination). As outlined on that page, this option does have additional requirements for TLS verification.
+
+:::

 There are three recommended options for the source of the certificate used for TLS termination at the Rancher server:

- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate.
- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet.
- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher.
+- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate. No extra action is needed when `agent-tls-mode` is set to strict. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
+- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet. When setting `agent-tls-mode` to `strict`, you must also specify `--privateCA=true` and upload the Let's Encrypt CA as described in [Adding TLS Secrets](../resources/add-tls-secrets.md). More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).
+- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher. If `agent-tls-mode` is set to `strict`, the CA must be uploaded, so that downstream clusters can successfully connect. More information can be found on this setting in [Agent TLS Enforcement](../installation-references/tls-settings.md#agent-tls-enforcement).


 | Configuration                  | Helm Chart Option           | Requires cert-manager                 |
@@ -114,20 +126,30 @@ There are three recommended options for the source of the certificate used for T

 ### 4. Install cert-manager

-> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
+> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer](../installation-references/helm-chart-options.md#external-tls-termination).

 This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).

 <details id="cert-manager">
  <summary>Click to Expand</summary>

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

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

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

 # Add the Jetstack Helm repository
 helm repo add jetstack https://charts.jetstack.io
@@ -139,8 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true \
-  --version v1.5.1
+  --set crds.enabled=true
 ```

 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -162,23 +183,35 @@ The exact command to install Rancher differs depending on the certificate config

 However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.

+:::tip Testing and Development:
+
+This final command to install Rancher requires a domain name that forwards traffic to Rancher. If you are using the Helm CLI to set up a proof-of-concept, you can use a fake domain name when passing the `hostname` option. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`, which would expose Rancher on an IP where it is running. Production installs would require a real domain name.
+
+:::
+
 <Tabs>
 <TabItem value="Rancher-generated Certificates">

-The default is for Rancher to generate a self-signed CA, and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
+The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.

 Because `rancher` is the default option for `ingress.tls.source`, we are not specifying `ingress.tls.source` when running the `helm install` command.

- Set `hostname` to the DNS record that resolves to your load balancer.
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- 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 \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
-  --set replicas=3
+  --set bootstrapPassword=admin
+```
+
+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
 ```

 Wait for Rancher to be rolled out:
@@ -194,28 +227,43 @@ deployment "rancher" successfully rolled out

 This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.

->**Note:** You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+:::note
+
+You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+
+:::

 In the following command,

- Set `hostname` to the public DNS record that resolves to your load balancer.
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
- Set `ingress.tls.source` to `letsEncrypt`.
- Set `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices).
+- `hostname` is set to the public DNS record,
+- Set the `bootstrapPassword` to something unique for the `admin` user.
+- `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.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- 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
+
+When `agent-tls-mode` is set to `strict` (the default value for new installs of Rancher starting from v2.9.0), you must supply the `privateCA=true` chart value (e.x. through `--set privateCA=true`) and upload the Let's Encrypt Certificate Authority as outlined in [Adding TLS Secrets](../resources/add-tls-secrets.md). Information on identifying the Let's Encrypt Root CA can be found in the Let's Encrypt [docs](https://letsencrypt.org/certificates/). If you don't upload the CA, then Rancher may fail to connect to new or existing downstream clusters.
+
+:::

 ```
 helm install rancher rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
-  --set replicas=3 \
+  --set bootstrapPassword=admin \
  --set ingress.tls.source=letsEncrypt \
  --set letsEncrypt.email=me@example.org \
  --set letsEncrypt.ingress.class=nginx
 ```

+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
 Wait for Rancher to be rolled out:

 ```
@@ -228,25 +276,33 @@ deployment "rancher" successfully rolled out
 <TabItem value="Certificates from Files">
 In this option, Kubernetes secrets are created from your own certificates for Rancher to use.

-When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate, or the Ingress controller will fail to configure correctly.
+When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.

 Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers and applications.

-> If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../../../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
+:::note

- Set `hostname` as appropriate for your certificate, as described above.
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
+If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../../../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
+
+:::
+
+- Set the `hostname`.
+- Set the `bootstrapPassword` to something unique for the `admin` user.
 - Set `ingress.tls.source` to `secret`.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- 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 \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
-  --set replicas=3 \
+  --set bootstrapPassword=admin \
  --set ingress.tls.source=secret
 ```
+If you are installing an alpha version, Helm requires adding the `--devel` option to the install command:
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```

 If you are using a Private CA signed certificate , add `--set privateCA=true` to the command:

@@ -254,6 +310,7 @@ If you are using a Private CA signed certificate , add `--set privateCA=true` to
 helm install rancher rancher-<CHART_REPO>/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
  --set ingress.tls.source=secret \
  --set privateCA=true
 ```
@@ -265,11 +322,11 @@ Now that Rancher is deployed, see [Adding TLS Secrets](../resources/add-tls-secr

 The Rancher chart configuration has many options for customizing the installation to suit your specific environment. Here are some common advanced scenarios.

- [HTTP Proxy](../../../reference-guides/installation-references/helm-chart-options.md#http-proxy)
- [Private Docker Image Registry](../../../reference-guides/installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
- [TLS Termination on an External Load Balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
+- [HTTP Proxy](../installation-references/helm-chart-options.md#http-proxy)
+- [Private Container Image Registry](../installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
+- [TLS Termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination)

-See the [Chart Options](../../../reference-guides/installation-references/helm-chart-options.md) for the full list of options.
+See the [Chart Options](../installation-references/helm-chart-options.md) for the full list of options.


 ### 6. Verify that the Rancher Server is Successfully Deployed
@@ -303,8 +360,3 @@ That's it. You should have a functional Rancher server.
 In a web browser, go to the DNS name that forwards traffic to your load balancer. Then you should be greeted by the colorful login page.

 Doesn't work? Take a look at the [Troubleshooting](troubleshooting.md) Page
-
-
-### Optional Next Steps
-
-Enable the Enterprise Cluster Manager.
@@ -14,13 +14,16 @@ If you already have an AKS Kubernetes cluster, skip to the step about [installin

 ## Prerequisites

->**Note**
->Deploying to Microsoft Azure will incur charges.
+:::caution
+
+Deploying to Microsoft Azure will incur charges.
+
+:::

 - [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
 - [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
 - [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../installation-requirements/installation-requirements.md#rke-and-hosted-kubernetes)
+- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../installation-requirements/installation-requirements.md)
 - When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).

 ## 1. Prepare your Workstation
@@ -49,11 +52,17 @@ az group create --name rancher-rg --location eastus

 To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.

+:::note
+
+If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
+
+:::
+
 ```
 az aks create \
  --resource-group rancher-rg \
  --name rancher-server \
-  --kubernetes-version 1.20.5 \
+  --kubernetes-version <VERSION> \
  --node-count 3 \
  --node-vm-size Standard_D2_v3
 ```
@@ -74,7 +83,7 @@ This command merges your cluster's credentials into the existing kubeconfig and

 The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription.

-To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table). 
+To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table).

 Then, list the Helm charts available to you by running the following command:

@@ -84,16 +93,19 @@ helm repo update
 helm search repo ingress-nginx -l
 ```

-The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.20, you can select the v4.2.5 Helm chart, since Ingress-NGINX v1.3.1 comes bundled with that chart, and v1.3.1 is compatible with Kubernetes v1.20. When in doubt, select the most recent compatible version.
+The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.24, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.24. When in doubt, select the most recent compatible version.

 Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:

 ```
+helm search repo ingress-nginx -l
 helm upgrade --install \
  ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.service.type=LoadBalancer \
-  --version 4.2.5 \
+  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
+  --set controller.service.externalTrafficPolicy=Local \
+  --version 4.6.0 \
  --create-namespace
 ```

@@ -129,3 +141,11 @@ There are many valid ways to set up the DNS. For help, refer to the [Azure DNS d
 Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.

 Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -6,7 +6,7 @@ title: Installing Rancher on Amazon EKS
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks"/>
 </head>

-This page covers installing Rancher on an Amazon EKS cluster.
+This page covers installing Rancher on an Amazon EKS cluster.  You can also [install Rancher through the AWS Marketplace](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md).

 If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)

@@ -14,11 +14,13 @@ If you already have an EKS Kubernetes cluster, skip to the step about [installin

 In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS.

-> **Prerequisites:**
->
-> - You should already have an AWS account.
-> - It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
-> - The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
+:::note Prerequisites:
+
+- You should already have an AWS account.
+- It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
+- The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
+
+:::

 ### 1. Prepare your Workstation

@@ -50,10 +52,12 @@ Then enter the following values:

 To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.

+**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
+
 ```
 eksctl create cluster \
  --name rancher-server \
-  --version 1.20 \
+  --version <VERSION> \
  --region us-west-2 \
  --nodegroup-name ranchernodes \
  --nodes 3 \
@@ -96,7 +100,7 @@ helm repo update
 helm search repo ingress-nginx -l
 ```

-The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.20, you can select the v4.2.5 Helm chart, since Ingress-NGINX v1.3.1 comes bundled with that chart, and v1.3.1 is compatible with Kubernetes v1.20. When in doubt, select the most recent compatible version.
+The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.23, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.23. When in doubt, select the most recent compatible version.

 Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:

@@ -105,7 +109,7 @@ helm upgrade --install \
  ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.service.type=LoadBalancer \
-  --version 4.2.5 \
+  --version 4.6.0 \
  --create-namespace
 ```

@@ -141,3 +145,11 @@ There are many valid ways to set up the DNS. For help, refer to the AWS document
 Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.

 Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
@@ -14,7 +14,7 @@ If you already have a GKE Kubernetes cluster, skip to the step about [installing

 - You will need a Google account.
 - You will need a Google Cloud billing account. You can manage your Cloud Billing accounts using the Google Cloud Console. For more information about the Cloud Console, visit [General guide to the console.](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)
- You will need a cloud quota for at least one in-use IP address and at least 2 CPUs. For more details about hardware requirements for the Rancher server, refer to [this section.](../installation-requirements/installation-requirements.md#rke-and-hosted-kubernetes)
+- You will need a cloud quota for at least one in-use IP address and at least 2 CPUs. For more details about hardware requirements for the Rancher server, refer to [this section.](../installation-requirements/installation-requirements.md)

 ## 1. Enable the Kubernetes Engine API

@@ -33,7 +33,7 @@ The following sections describe how to launch the cloud shell from the Google Cl

 ### Cloud Shell

-To launch the shell from the [Google Cloud Console,](https://console.cloud.google.com) go to the upper-right corner of the console and click the terminal button. When hovering over the button, it is labeled **Activate Cloud Shell.**
+To launch the shell from the [Google Cloud Console,](https://console.cloud.google.com) go to the upper-right corner of the console and click the terminal button. When hovering over the button, it is labeled **Activate Cloud Shell**.

 ### Local Shell

@@ -72,23 +72,23 @@ To install `gcloud` and `kubectl`, perform the following steps:
 - Using gcloud config, to individually set your project ID, zone, and region.

 <Tabs>
-<TabItem value="Using gloud init">
+<TabItem value="Using gcloud init">

-1. Run gcloud init and follow the directions:
+  1. Run gcloud init and follow the directions:

-    ```
-    gcloud init
-    ```
-    If you are using SSH on a remote server, use the --console-only flag to prevent the command from launching a browser:
+      ```
+      gcloud init
+      ```
+      If you are using SSH on a remote server, use the --console-only flag to prevent the command from launching a browser:
+
+      ```
+      gcloud init --console-only
+      ```
+  2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.

-    ```
-    gcloud init --console-only
-    ```
-2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.

 </TabItem>
 <TabItem value="Using gcloud config">
-
 </TabItem>
 </Tabs>

@@ -122,8 +122,12 @@ Replace `cluster-name` with the name of your new cluster.

 When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.

+To successfully create a GKE cluster with Rancher, your GKE must be in Standard mode. GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode. For more information about the difference between GKE Autopilot mode and Standard mode, visit [Compare GKE Autopilot and Standard.](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)
+
+**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
+
 ```
-gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=1.20.10-gke.301
+gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
 ```

 ## 6. Get Authentication Credentials
@@ -149,7 +153,7 @@ helm upgrade --install \
  ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.service.type=LoadBalancer \
-  --version 3.12.0 \
+  --version 4.0.18 \
  --create-namespace
 ```

@@ -183,3 +187,19 @@ There are many valid ways to set up the DNS. For help, refer to the Google Cloud
 Next, install the Rancher Helm chart by following the instructions on [this page.](install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.

 Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
+
+When installing Rancher on top of this setup, you will also need to set the name of the ingress controller to be used with Rancher's ingress resource:
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+Refer [here for the Helm install command](install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
+
+In Rancher v2.7.5, if you intend to use the default GKE ingress on your cluster without enabling VPC-native cluster mode, you need to set the following flag:
+
+```
+--set service.type=NodePort
+```
+
+This is necessary because of compatibility issues between this setup and ClusterIP, the default type for `cattle-system/rancher`.
@@ -0,0 +1,39 @@
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+- configuration:
+    apiVersion: pod-security.admission.config.k8s.io/v1
+    defaults:
+      audit: restricted
+      audit-version: latest
+      enforce: restricted
+      enforce-version: latest
+      warn: restricted
+      warn-version: latest
+    exemptions:
+      namespaces:
+      - ingress-nginx
+      - kube-system
+      - cattle-system
+      - cattle-epinio-system
+      - cattle-fleet-system
+      - cattle-fleet-local-system
+      - longhorn-system
+      - cattle-neuvector-system
+      - cattle-monitoring-system
+      - rancher-alerting-drivers
+      - cis-operator-system
+      - cattle-csp-adapter-system
+      - cattle-externalip-system
+      - cattle-gatekeeper-system
+      - istio-system
+      - cattle-istio-system
+      - cattle-logging-system
+      - cattle-windows-gmsa-system
+      - cattle-sriov-system
+      - cattle-ui-plugin-system
+      - tigera-operator
+      - cattle-provisioning-capi-system
+    kind: PodSecurityConfiguration
+  name: PodSecurity
+  path: ""
@@ -0,0 +1,157 @@
+---
+title: Rollbacks
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
+</head>
+
+This page outlines how to rollback Rancher to a previous version after an upgrade.
+
+Follow the instructions from this page when:
+- The running Rancher instance has been upgraded to a newer version after the backup was made.
+- The upstream (local) cluster is the same as where the backup was made.
+
+:::tip
+
+* Follow these steps to [migrate Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md).
+* If you need to restore Rancher to its previous state at the same Rancher version, see the [restore documentation](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md).
+
+:::
+
+## Alternative Steps for Special Scenarios
+
+Alternative steps need to be performed for rollbacks in the following scenarios:
+- Rolling back from v2.6.4 and later to an earlier version of v2.6.x.
+- Rolling back from v2.7.7 and later to an earlier version of v2.7.x.
+
+In Rancher v2.6.4, the cluster-api module is upgraded from v0.4.4 to v1.0.2. The cluster-api v1.0.2, in turn, upgrades the apiVersions of its Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. Custom Resources (CRs) that use the older apiVersion (v1alpha4) are incompatible with v1beta1, which  causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x.
+
+In Rancher v2.7.7, the app `rancher-provisioning-capi` is installed on the upstream (local) cluster automatically as a replacement for the embedded cluster-api controllers. Conflicts and unexpected errors will occur if the upstream cluster contains both the app, and Rancher v2.7.6 and earlier. Therefore, alternative steps are needed if you attempt to move from Rancher v2.7.7 to any previous version of Rancher v2.7.x.
+
+### Step 1: Clean Up the Upstream (Local) Cluster
+
+To avoid rollback failure, follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts **before** you attempt a restore operation or rollback:
+
+* `cleanup.sh`: Cleans up the cluster.
+* `verify.sh`:  Checks for any Rancher-related resources in the cluster.
+
+:::caution
+
+There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
+
+:::
+
+**Result:** all Rancher-related resources should be cleaned up on the upstream (local) cluster.
+
+See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
+
+### Step 2: Restore the Backup and Bring Up Rancher
+
+At this point, there should be no Rancher-related resources on the upstream cluster. Therefore, the next step will be the same as if you were migrating Rancher to a new cluster that contains no Rancher resources.
+
+Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the Rancher-Backup Helm chart and restore Rancher to its previous state.
+Please keep in mind that:
+1. Step 3 can be skipped, because the Cert-Manager app should still exist on the upstream (local) cluster if it was installed before.
+2. At Step 4, install the Rancher version you intend to roll back to.
+
+## Rolling Back to Rancher v2.5.0+
+
+To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup.
+
+Rancher has to be started with the lower/previous version after a rollback.
+
+A restore is performed by creating a Restore custom resource.
+
+:::note Important:
+
+* Follow the instructions from this page for restoring Rancher on the same cluster where it was backed up from. In order to migrate Rancher to a new cluster, follow the steps to [migrate Rancher.](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)
+
+* While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. As a result, Rancher and its UI will be unavailable until the restore is complete. While the UI is unavailable, use the original cluster kubeconfig with the restore YAML file: `kubectl create -f restore.yaml`.
+
+:::
+
+### Step 1: Create the Restore Custom Resource
+
+1. Click **☰ > Cluster Management**.
+1. Go to the local cluster and click **Explore**.
+1. In the left navigation bar, click **Rancher Backups > Restore**.
+    :::note
+
+    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.
+
+    :::
+
+1. Click **Create**.
+1. Create the Restore with the form or with YAML. For help creating the Restore resource using the online form, refer to the [configuration reference](../../../reference-guides/backup-restore-configuration/restore-configuration.md) and to the [examples.](../../../reference-guides/backup-restore-configuration/examples.md)
+1. To use the YAML editor, you can click **Create > Create from YAML.** Enter the Restore YAML. The following is an example Restore custom resource:
+
+    ```yaml
+    apiVersion: resources.cattle.io/v1
+    kind: Restore
+    metadata:
+      name: restore-migration
+    spec:
+      backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
+      encryptionConfigSecretName: encryptionconfig
+      storageLocation:
+        s3:
+          credentialSecretName: s3-creds
+          credentialSecretNamespace: default
+          bucketName: rancher-backups
+          folder: rancher
+          region: us-west-2
+          endpoint: s3.us-west-2.amazonaws.com
+    ```
+    For help configuring the Restore, refer to the [configuration reference](../../../reference-guides/backup-restore-configuration/restore-configuration.md) and to the [examples.](../../../reference-guides/backup-restore-configuration/examples.md)
+
+1. Click **Create**.
+
+**Result:** The backup file is created and updated to the target storage location. The resources are restored in this order:
+
+1. Custom Resource Definitions (CRDs)
+2. Cluster-scoped resources
+3. Namespaced resources
+
+To check how the restore is progressing, you can check the logs of the operator. Follow these steps to get the logs:
+
+```yaml
+kubectl get pods -n cattle-resources-system
+kubectl logs -n cattle-resources-system -f
+```
+
+### Step 2: Roll Back to a Previous Rancher Version
+
+Rancher can be rolled back using the Helm CLI. To roll back to the previous version:
+
+```yaml
+helm rollback rancher -n cattle-system
+```
+
+If the previous revision is not the intended target, you can specify a revision to roll back to. To see the deployment history:
+
+```yaml
+helm history rancher -n cattle-system
+```
+
+When the target revision is determined, perform the rollback. This example will roll back to revision `3`:
+
+```yaml
+helm rollback rancher 3 -n cattle-system
+```
+
+## Rolling Back to Rancher v2.2-v2.4+
+
+To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
+
+For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
+
+:::note
+
+Managed clusters are authoritative for their state. This means restoring the Rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
+
+:::
+
+## Rolling Back to Rancher v2.0-v2.1
+
+Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
@@ -74,7 +74,11 @@ kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh

 Use your browser to check the certificate details. If it says the Common Name is "Kubernetes Ingress Controller Fake Certificate", something may have gone wrong with reading or issuing your SSL cert.

-> **Note:** if you are using LetsEncrypt to issue certs it can sometimes take a few minutes to issue the cert.
+:::note
+
+If you are using LetsEncrypt to issue certs, it can sometimes take a few minutes to issue the cert.
+
+:::

 ### Checking for issues with cert-manager issued certs (Rancher Generated or LetsEncrypt)

@@ -186,3 +190,19 @@ If you want to use encrypted private keys, you should use `ssh-agent` to load yo
 ### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

 The node is not reachable on the configured `address` and `port`.
+
+### Agent reports TLS errors 
+
+When using Rancher, you may encounter error messages from the `fleet-agent`, `system-agent`, or `cluster-agent`, such as the message below:
+```
+tls: failed to verify certificate: x509: failed to load system roots and no roots provided; readdirent /dev/null: not a directory
+```
+
+This occurs when Rancher was configured with `agent-tls-mode` set to `strict`, but couldn't find cacerts in the `cacert` setting. To resolve the issue, set the `agent-tls-mode` to `system-store`, or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
+
+### New Cluster Deployment is stuck in "Waiting for Agent to check in"
+
+When Rancher has `agent-tls-mode` set to `strict`, new clusters may fail to provision and report a generic "Waiting for Agent to check in" error message. The root cause of this is similar to the above case of TLS errors - Rancher's agent can't determine which CA Rancher is using (or can't verify that Rancher's cert is actually signed by the specified certificate authority).  
+
+To resolve the issue, set the `agent-tls-mode` to `system-store` or upload the CA for Rancher as described in [Adding TLS Secrets](../resources/add-tls-secrets.md).
+
@@ -0,0 +1,72 @@
+---
+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>
@@ -6,14 +6,13 @@ title: Upgrades
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
 </head>

-The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air gap installs with Helm.
-
-For the instructions to upgrade Rancher installed on Kubernetes with RancherD, refer to [this page.](../other-installation-methods/install-rancher-on-linux/upgrade-rancherd.md)
+The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air-gapped installs with Helm.

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

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

+
 ## Prerequisites

 ### Access to kubeconfig
@@ -34,15 +33,13 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 The upgrade instructions assume you are using Helm 3.

+<DeprecationHelm2 />
+
 For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

-### For air gap installs: Populate private registry
+### For air-gapped installs: Populate private registry

-For [air gap installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
-
-### For upgrades from a Rancher server with a hidden local cluster
-
-If you are upgrading to Rancher v2.5 from a Rancher server that was started with the Helm chart option `--add-local=false`, you will need to drop that flag when upgrading. Otherwise, the Rancher server will not start. The `restricted-admin` role can be used to continue restricting access to the local cluster. For more information, see [this section.](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#upgrading-from-rancher-with-a-hidden-local-cluster)
+For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.

 ### For upgrades with cert-manager older than 0.8.0

@@ -52,20 +49,15 @@ If you are upgrading to Rancher v2.5 from a Rancher server that was started with

 Follow the steps to upgrade Rancher server:

- [1. Back up your Kubernetes cluster that is running Rancher server](#1-back-up-your-kubernetes-cluster-that-is-running-rancher-server)
- [2. Update the Helm chart repository](#2-update-the-helm-chart-repository)
- [3. Upgrade Rancher](#3-upgrade-rancher)
- [4. Verify the Upgrade](#4-verify-the-upgrade)
-
-## 1. Back up Your Kubernetes Cluster that is Running Rancher Server
+### 1. Back up Your Kubernetes Cluster that is Running Rancher Server

 Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.

-You'll use the backup as a restoration point if something goes wrong during upgrade.
+You'll use the backup as a restore point if something goes wrong during upgrade.

-## 2. Update the Helm chart repository
+### 2. Update the Helm chart repository

-1. Update your local Helm repo cache:
+1. Update your local Helm repo cache.

    ```
    helm repo update
@@ -85,7 +77,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
        ```
    - Alpha: Experimental preview of upcoming releases.
        ```
-        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
        ```
        Note: Upgrades are not supported to, from, or between Alphas.

@@ -97,8 +89,11 @@ You'll use the backup as a restoration point if something goes wrong during upgr
    rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
    ```

-    > **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+    :::note

+    If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+
+    :::

 1. Fetch the latest chart to install Rancher from the Helm chart repository.

@@ -110,15 +105,18 @@ You'll use the backup as a restoration point if something goes wrong during upgr
    You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag.  For example:

    ```plain
-    helm fetch rancher-<CHART_REPO>/rancher --version=2.5.16
+    helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
    ```

-## 3. Upgrade Rancher
+### 3. Upgrade Rancher

-This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
+This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm.

-> **Air Gap Instructions:** If you are installing Rancher in an air gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](air-gapped-upgrades.md)
+:::note Air Gap Instructions:

+If you are installing Rancher in an air-gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](air-gapped-upgrades.md)
+
+:::

 Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.

@@ -128,17 +126,33 @@ helm get values rancher -n cattle-system
 hostname: rancher.my.org
 ```

-> **Note:** There will be more values that are listed with this command. This is just an example of one of the values.
+:::note

-If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow [Option B: Reinstalling Rancher and cert-manager.](#option-b-reinstalling-rancher-and-cert-manager)
+There will be more values that are listed with this command. This is just an example of one of the values.

-Otherwise, follow [Option A: Upgrading Rancher.](#option-a-upgrading-rancher)
+:::

-### Option A: Upgrading Rancher
+:::tip 
+
+Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
+```
+helm get values rancher-stable -n cattle-system
+
+hostname: rancher.my.org
+```
+
+::: 
+
+If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-15-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
+
+#### Steps to Upgrade Rancher

 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`:
+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 \
@@ -146,46 +160,52 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
  --set hostname=rancher.my.org
 ```

-> **Note:** The above is an example, there may be more values from the previous step that need to be appended.
+:::note
+
+The above is an example, there may be more values from the previous step that need to be appended.
+
+:::
+
+:::tip 
+
+If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
+```
+helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+::: 

 Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:

-```
-helm get values rancher -n cattle-system -o yaml > values.yaml
+1. Export the current values to a file:
+    ```
+    helm get values rancher -n cattle-system -o yaml > values.yaml
+    ```
+1. Update only the Rancher version:

-helm upgrade rancher rancher-<CHART_REPO>/rancher \
-  --namespace cattle-system \
-  -f values.yaml \
-  --version=2.5.16
-```
-
-### Option B: Reinstalling Rancher and cert-manager
-
-If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
-
-1. Uninstall Rancher
+    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 delete rancher -n cattle-system
+    helm upgrade rancher rancher-<CHART_REPO>/rancher \
+      --namespace cattle-system \
+      -f values.yaml \
+      --version=2.6.8
    ```

-2. Uninstall and reinstall `cert-manager` according to the instructions on the [Upgrading Cert-Manager](../resources/upgrade-cert-manager.md) page.
-
-3. Reinstall Rancher to the latest version with all your settings. Take all the values from the step 1 and append them to the command using `--set key=value`. Note: There will be many more options from the step 1 that need to be appended.
-
-    ```
-    helm install rancher rancher-<CHART_REPO>/rancher \
-    --namespace cattle-system \
-    --set hostname=rancher.my.org
-    ```
-
-## 4. Verify the Upgrade
+### 4. Verify the Upgrade

 Log into Rancher to confirm that the upgrade succeeded.

->**Having network issues following upgrade?**
->
-> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+:::tip
+
+Having network issues following upgrade?
+
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+
+:::

 ## Known Upgrade Issues

@@ -13,19 +13,10 @@ This section provides an overview of the architecture options of installing Ranc

 In this section,

- **The Rancher server** manages and provisions Kubernetes clusters. You can interact with downstream Kubernetes clusters through the Rancher server's user interface.
+- **The Rancher server** manages and provisions Kubernetes clusters. You can interact with downstream Kubernetes clusters through the Rancher server's user interface. The Rancher management server can be installed on any Kubernetes cluster, including hosted clusters, such as Amazon EKS clusters.
 - **RKE (Rancher Kubernetes Engine)** is a certified Kubernetes distribution and CLI/library which creates and manages a Kubernetes cluster.
 - **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
 - **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- **RancherD** was an experimental tool for installing Rancher; a single binary that first launched an RKE2 Kubernetes cluster, then installed the Rancher server Helm chart on the cluster. It was available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
-
-## Changes to Installation in Rancher v2.5
-
-In Rancher v2.5, the Rancher management server can be installed on any Kubernetes cluster, including hosted clusters, such as Amazon EKS clusters.
-
-For Docker installations, a local Kubernetes cluster is installed in the single Docker container, and Rancher is installed on the local cluster.
-
-The `restrictedAdmin` Helm chart option was added. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)

 ## Overview of Installation Options

@@ -35,15 +26,9 @@ Rancher can be installed on these main architectures:

 We recommend using Helm, a Kubernetes package manager, to install Rancher on multiple nodes on a dedicated Kubernetes cluster. For RKE clusters, three nodes are required to achieve a high-availability cluster. For K3s clusters, only two nodes are required.

-### High-availability Kubernetes Install with RancherD
+### Rancher on EKS Install with the AWS Marketplace

-> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
-
-RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.
-
-In both the RancherD install and the Helm CLI install, Rancher is installed as a Helm chart on a Kubernetes cluster.
-
-Configuration and upgrading are also simplified with RancherD. When you upgrade the RancherD binary, both the Kubernetes cluster and the Rancher Helm chart are upgraded.
+Rancher can be installed on to Amazon Elastic Kubernetes Service (EKS) [through the AWS Marketplace](../quick-start-guides/deploy-rancher-manager/aws-marketplace.md). The EKS cluster deployed is production-ready and follows AWS best practices. 

 ### Single-node Kubernetes Install

@@ -53,7 +38,7 @@ However, this option is useful if you want to save resources by using a single n

 ### Docker Install

-For test and demonstration purposes, Rancher can be installed with Docker on a single node.
+For test and demonstration purposes, Rancher can be installed with Docker on a single node. A local Kubernetes cluster is installed in the single Docker container, and Rancher is installed on the local cluster.

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

@@ -91,11 +76,11 @@ For more architecture recommendations, refer to [this page.](../../reference-gui

 ### More Options for Installations on a Kubernetes Cluster

-Refer to the [Helm chart options](../../reference-guides/installation-references/helm-chart-options.md) for details on installing Rancher on a Kubernetes cluster with other configurations, including:
+Refer to the [Helm chart options](installation-references/helm-chart-options.md) for details on installing Rancher on a Kubernetes cluster with other configurations, including:

- With [API auditing to record all transactions](../../reference-guides/installation-references/helm-chart-options.md#api-audit-log)
- With [TLS termination on a load balancer](../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
- With a [custom Ingress](../../reference-guides/installation-references/helm-chart-options.md#customizing-your-ingress)
+- With [API auditing to record all transactions](installation-references/helm-chart-options.md#api-audit-log)
+- With [TLS termination on a load balancer](installation-references/helm-chart-options.md#external-tls-termination)
+- With a [custom Ingress](installation-references/helm-chart-options.md#customizing-your-ingress)

 In the Rancher installation instructions, we recommend using K3s or RKE to set up a Kubernetes cluster before installing Rancher on the cluster. Both K3s and RKE have many configuration options for customizing the Kubernetes cluster to suit your specific environment. For the full list of their capabilities, refer to their documentation:

@@ -107,5 +92,5 @@ In the Rancher installation instructions, we recommend using K3s or RKE to set u
 Refer to the [docs about options for Docker installs](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) for details about other configurations including:

 - With [API auditing to record all transactions](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log)
- With an [external load balancer](advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md/)
+- With an [external load balancer](../../how-to-guides/advanced-user-guides/configure-layer-7-nginx-load-balancer.md)
 - With a [persistent data store](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#persistent-data)
@@ -0,0 +1,57 @@
+---
+title: Feature Flags
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/feature-flags"/>
+</head>
+
+With feature flags, you can try out optional or experimental features, and enable legacy features that are being phased out.
+
+To learn more about feature values and how to enable them, see [Enabling Experimental Features](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md).
+
+:::note
+
+Some feature flags require a restart of the Rancher container. Features that require a restart are marked in the Rancher UI.
+
+:::
+
+The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):
+
+- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [Cluster Role Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md) for more information.
+- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
+- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
+- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
+- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
+- `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.
+- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
+- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
+- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
+- `token-hashing`: Enables token hashing. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically with the SHA256 algorithm. Once a token is hashed it can't be undone. This flag can't be disabled after its enabled. See [API Tokens](../../../api/api-tokens.md#token-hashing) for more information.
+- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
+- `unsupported-storage-drivers`: Enables types for storage providers and provisioners that aren't enabled by default. See [Allow Unsupported Storage Drivers](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md) for more information.
+- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
+
+
+The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:
+
+| Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
+| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
+| `aggregated-roletemplates` | `false` | Highly experimentatl | v2.11.0 | This flag value is locked on install and can't be changed. |
+| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
+| `continuous-delivery` | `true` | GA | v2.6.0 | |
+| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
+| `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
+| `fleet`  | `true` | GA | v2.5.0 | |
+| `harvester` | `true` | Experimental | v2.6.1 | |
+| `imperative-api-extension` | `true` | GA | v2.11.0 | |
+| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
+| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
+| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
+| `rke2` | `true` | Experimental | v2.6.0 | |
+| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
+| `uiextension` | `true` | GA | v2.9.0 | |
+| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
@@ -1,6 +1,6 @@
 ---
 title: Rancher Helm Chart Options
-keywords: [rancher v2.5 helm chart, rancher v2.5 helm options, rancher v2.5 helm chart options, helm chart rancher v2.5 helm options rancher v2.5 helm chart options rancher v2.5]
+keywords: [rancher helm chart, rancher helm options, rancher helm chart options, helm chart rancher, helm options rancher, helm chart options rancher]
 ---

 <head>
@@ -9,15 +9,15 @@ keywords: [rancher v2.5 helm chart, rancher v2.5 helm options, rancher v2.5 helm

 This page is a configuration reference for the Rancher Helm chart.

-For help choosing a Helm chart version, refer to [this page.](../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)
-
-For information on enabling experimental features, refer to [this page.](../../getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/enable-experimental-features.md)
+For help choosing a Helm chart version, refer to [this page.](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)

+For information on enabling experimental features, refer to [this page.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)

 ## Common Options

 | Option                    | Default Value | Description                                                                        |
 | ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
+| `bootstrapPassword`       | " "           | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin should reset their password. A randomly generated bootstrap password is used if this value is not set.
 | `hostname`                | " "           | `string` - the Fully Qualified Domain Name for your Rancher Server                 |
 | `ingress.tls.source`      | "rancher"     | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
 | `letsEncrypt.email`       | " "           | `string` - Your email address                                                      |
@@ -31,60 +31,75 @@ For information on enabling experimental features, refer to [this page.](../../g
 | Option                         | Default Value                                         | Description                                                                                                                                       |
 | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
-| `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._ |
+| `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" (upstream) Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._              |
+| `agentTLSMode`                 | ""                                                    | `string` - either `system-store` or `strict`. See [Agent TLS Enforcement](./tls-settings.md#agent-tls-enforcement) |
 | `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
 | `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
 | `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
-| `auditLog.level`               | 0                                                     | `int` - set the [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) level. 0 is off. [0-3]                                   |
+| `auditLog.level`               | 0                                                     | `int` - set the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level. 0 is off. [0-3]                                   |
 | `auditLog.maxAge`              | 1                                                     | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`)                      |
 | `auditLog.maxBackup`           | 1                                                     | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`)                               |
 | `auditLog.maxSize`             | 100                                                   | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`)    |
-| `busyboxImage`                 | "busybox"                                             | `string` - Image location for busybox image used to collect audit logs                |
+| `auditLog.image.repository`    | "registry.suse.com/bci/bci-micro"                     | `string` - Location for the image used to collect audit logs.                                                                                     |
+| `auditLog.image.tag`           | "15.4.14.3"                                           | `string` - Tag for the image used to collect audit logs.                                                                                          |
+| `auditLog.image.pullPolicy`    | "IfNotPresent"                                        | `string` - Override imagePullPolicy for auditLog images - "Always", "Never", "IfNotPresent".                                                   |
+| `busyboxImage`                 | ""                                             | `string` - Image location for busybox image used to collect audit logs. _Note: This option is deprecated use `auditLog.image.repository` to control auditing sidecar image._        |
 | `certmanager.version`          | ""                                                    | `string` - set cert-manager compatibility                                                                                                         |
 | `debug`                        | false                                                 | `bool` - set debug flag on rancher server                                                                                                         |
 | `extraEnv`                     | []                                                    | `list` - set additional environment variables for Rancher                                                          |
 | `imagePullSecrets`             | []                                                    | `list` - list of names of Secret resource containing private registry credentials                                                                 |
 | `ingress.configurationSnippet` | ""                                                    | `string` - additional Nginx configuration. Can be used for proxy configuration.   |
 | `ingress.extraAnnotations`     | {}                                                    | `map` - additional annotations to customize the ingress                                                                                           |
-|  `ingress.enabled` |  true   |    When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress. _Available as of v2.5.6_  |
+|  `ingress.enabled` |  true   |    When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress.   |
 | `letsEncrypt.ingress.class`    | ""                                                    | `string` - optional ingress class for the cert-manager acmesolver ingress that responds to the Let's Encrypt ACME challenges. Options: traefik, nginx.       |                      |
 | `noProxy`                      | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - comma separated list of hostnames or ip address not to use the proxy                              |                                     |
 | `proxy`                        | ""                                                    | `string` - HTTP[S] proxy server for Rancher                                                                                                       |
 | `rancherImage`                 | "rancher/rancher"                                     | `string` - rancher image source                                                                                                                   |
 | `rancherImagePullPolicy`       | "IfNotPresent"                                        | `string` - Override imagePullPolicy for rancher server images - "Always", "Never", "IfNotPresent"                                                 |
 | `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
-| `replicas`                     | 3                                                     | `int` - Number of replicas of Rancher pods                                                                                                        |
+| `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.                                                                                                        |
 | `resources`                    | {}                                                    | `map` - rancher pod resource requests & limits                                                                                                    |
-| `restrictedAdmin` | `false` | _Available in Rancher v2.5_ `bool` - When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) |
-| `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system Docker images, e.g., registry.example.com                       |
+| `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
+
+You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.
+
+When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.

 ### API Audit Log

-Enabling the [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md).
+Enabling the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md).

-You can collect this log as you would any container log. Enable [logging](../../explanations/integrations-in-rancher/logging/logging.md) for the `System` Project on the Rancher server cluster.
+You can collect this log as you would any container log. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the `System` Project on the Rancher server cluster.

 ```plain
 --set auditLog.level=1
 ```

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

 Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.

 ### Setting Extra Environment Variables

-You can set extra environment variables for Rancher server using `extraEnv`. This list uses the same `name` and `value` keys as the container manifest definitions. Remember to quote the values.
+You can set extra environment variables for Rancher server using `extraEnv`. This list is passed to the Rancher deployment in its YAML format. It is embedded under `env` for the Rancher container. Refer to the Kubernetes documentation for setting container environment variables, `extraEnv` can use any of the keys referenced in [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
+Consider an example that uses the `name` and `value` keys:

 ```plain
 --set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
 --set 'extraEnv[0].value=1.0'
 ```

+If passing sensitive data as the value for an environment variable, such as proxy authentication credentials, it is strongly recommended that a secret reference is used. This will prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+Consider an example that uses the `name`, `valueFrom.secretKeyRef.name`, and `valueFrom.secretKeyRef.key` keys. See example in [HTTP Proxy](#http-proxy)
+
 ### TLS Settings

 When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
@@ -95,7 +110,11 @@ See [TLS settings](tls-settings.md) for more information and options.

 By default Rancher server will detect and import the `local` cluster it's running on. User with access to the `local` cluster will essentially have "root" access to all the clusters managed by Rancher server.

-> **Important:**  If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
+:::caution
+
+If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
+
+:::

 If this is a concern in your environment you can set this option to "false" on your initial install.

@@ -123,15 +142,44 @@ Example on setting a static proxy header with `ingress.configurationSnippet`. Th

 ### HTTP Proxy

-Rancher requires internet access for some functionality, such as reaching remote Helm charts. Use `proxy` to set your proxy server.
+Rancher requires internet access for some functionality (Helm charts). Use `proxy` to set your proxy server or use `extraEnv` to set the `HTTPS_PROXY` environment variable to point to your proxy server.

-Add your IP exceptions to the `noProxy` list. Make sure you add the Pod cluster IP range (default: `10.42.0.0/16`), Service cluster IP range (default: `10.43.0.0/16`), the internal cluster domains (default: `.svc,.cluster.local`) and any worker cluster `controlplane` nodes. Rancher supports CIDR notation ranges in this list.
+Add your IP exceptions to the `noProxy` chart value as a comma separated list. Make sure you add the following values:
+- Pod cluster IP range (default: `10.42.0.0/16`).
+- Service cluster IP range (default: `10.43.0.0/16`).
+- Internal cluster domains (default: `.svc,.cluster.local`).
+- Any worker cluster `controlplane` nodes.
+Rancher supports CIDR notation ranges in this list.
+
+When not including sensitive data, the `proxy` or `extraEnv` chart options can be used. When using `extraEnv` the `noProxy` Helm option is ignored. Therefore, the `NO_PROXY` environment variable must also be set with `extraEnv`.
+
+The following is an example of setting proxy using the `proxy` chart option:

 ```plain
--set proxy="http://<username>:<password>@<proxy_url>:<proxy_port>/"
--set noProxy="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+--set proxy="http://<proxy_url:proxy_port>/"
 ```

+Example of setting proxy using the `extraEnv` chart option:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+When including sensitive data, such as proxy authentication credentials, use the `extraEnv` option with `valueFrom.secretRef` to prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+The following is an example of using `extraEnv` to configure proxy. This example secret would contain the value `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` in the secret's `"https-proxy-url"` key:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
+--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+To learn more about how to configure environment variables, refer to [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
 ### Additional Trusted CAs

 If you have private registries, catalogs or a proxy that intercepts certificates, you may need to add more trusted CAs to Rancher.
@@ -148,7 +196,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-

 ### Private Registry and Air Gap Installs

-For details on installing Rancher with a private registry, see [Air Gapped Helm CLI Install](../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md).
+For details on installing Rancher with a private registry, see the [air gap installation docs.](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)

 ## External TLS Termination

@@ -156,7 +204,11 @@ We recommend configuring your load balancer as a Layer 4 balancer, forwarding pl

 You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.

-> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher.
+:::note
+
+If you are using a Private CA signed certificate (or if `agent-tls-mode` is set to `strict`), add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher. 
+
+:::

 Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.

@@ -192,7 +244,11 @@ Rancher will respond `200` to health checks on the `/healthz` endpoint.

 This NGINX configuration is tested on NGINX 1.14.

-> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+:::caution
+
+This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+
+:::

 - Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
 - Replace both occurrences of `FQDN` to the DNS name for Rancher.
@@ -3,7 +3,7 @@ title: Installation References
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-references"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
 </head>

 Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
@@ -0,0 +1,104 @@
+---
+title: TLS Settings
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/tls-settings"/>
+</head>
+
+Changing the default TLS settings depends on the chosen installation method.
+
+## Running Rancher in a highly available Kubernetes cluster
+
+When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller:
+
+* nginx-ingress-controller (default for RKE1 and RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
+* traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).
+
+## Running Rancher in a single Docker container
+
+The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. You can change this by setting the following environment variables:
+
+| Parameter | Description | Default | Available options |
+|-----|-----|-----|-----|
+| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
+| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
+
+## Agent TLS Enforcement
+
+The `agent-tls-mode` setting controls how Rancher's agents (`cluster-agent`, `fleet-agent`, and `system-agent`) validate Rancher's certificate.
+
+When the value is set to `strict`, Rancher's agents only trust certificates generated by the Certificate Authority contained in the `cacerts` setting. 
+When the value is set to `system-store`, Rancher's agents trust any certificate generated by a public Certificate Authority contained in the operating system's trust store including those signed by authorities such as Let's Encrypt. This can be a security risk, since any certificate generated by these external authorities, which are outside the user's control, are considered valid in this state.
+
+While the `strict` option enables a higher level of security, it requires Rancher to have access to the CA which generated the certificate visible to the agents. In the case of certain certificate configurations (notably, external certificates), this is not automatic, and extra configuration is needed. See the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) for more information on which scenarios require extra configuration.
+
+In Rancher v2.9.0 and later, this setting defaults to `strict` on new installs. For users installing or upgrading from a prior Rancher version, it is set to `system-store`.
+
+### Preparing for the Setting Change
+
+Each cluster contains a condition in the status field called `AgentTlsStrictCheck`. If `AgentTlsStrictCheck` is set to `"True"`, this indicates that the agents for the cluster are ready to operate in `strict` mode. You can manually inspect each cluster to see if they are ready using the Rancher UI or a kubectl command such as the following:
+
+```bash
+## the below command skips ouputs $CLUSTER_NAME,$STATUS for all non-local clusters
+kubectl get cluster.management.cattle.io -o jsonpath='{range .items[?(@.metadata.name!="local")]}{.metadata.name},{.status.conditions[?(@.type=="AgentTlsStrictCheck")].status}{"\n"}{end}'
+```
+
+### Changing the Setting
+
+You can change the setting using the Rancher UI or the `agentTLSMode` [helm chart option](./helm-chart-options.md).
+
+:::note
+
+If you specify the value through the Helm chart, you may only modify the value with Helm.
+
+:::
+
+:::warning
+
+Depending on your cert setup, additional action may be required, such as uploading the Certificate Authority which signed your certs. Review the [installation guide](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#3-choose-your-ssl-configuration) before changing the setting to see if any additional requirements apply to your setup.
+
+:::
+
+To change the setting's value through the UI, navigate to the **Global Settings** page, and find the `agent-tls-mode` setting near the bottom of the page. When you change the setting through the UI, Rancher first checks that all downstream clusters have the condition `AgentTlsStrictCheck` set to `"True"` before allowing the request. This prevents outages from a certificate mismatch.
+
+
+#### Overriding the Setting Validation Checks
+
+In some cases, you may want to override the check ensuring all agents can accept the new TLS configuration:
+
+:::warning
+
+Rancher checks the status of all downstream clusters to prevent outages. Overriding this check is not recommended, and should be done with great caution.
+
+:::
+
+1. As an admin, generate a kubeconfig for the local cluster. In the below examples, this was saved to the `local_kubeconfig.yaml` file.
+2. Retrieve the current setting and save it to `setting.yaml`:
+```bash
+kubectl get setting agent-tls-mode -o yaml --kubeconfig=local_kubeconfig.yaml > setting.yaml
+```
+3. Update the `setting.yaml` file, replacing `value` with `strict`. Adding the `cattle.io/force: "true"` annotation overrides the cluster condition check, and should only be done with great care:
+
+:::warning
+
+Including the `cattle.io/force` annotation with any value (including, for example `"false"`) overrides the cluster condition check.
+
+:::
+
+```yaml
+apiVersion: management.cattle.io/v3
+customized: false
+default: strict
+kind: Setting
+metadata:
+  name: agent-tls-mode
+  annotations:
+    cattle.io/force: "true"
+source: ""
+value: strict
+```
+4. Apply the new version of the setting:
+```bash
+kubectl apply -f setting.yaml --kubeconfig=local_kubeconfig.yaml
+```
@@ -0,0 +1,51 @@
+---
+title: Dockershim
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements/dockershim"/>
+</head>
+
+The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
+
+RKE clusters now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community external Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
+
+RKE2 and K3s clusters use an embedded containerd as a container runtime and are not affected.
+
+To enable the external Dockershim in versions of RKE before 1.24, configure the following option.
+
+```
+enable_cri_dockerd: true
+```
+
+Starting with version 1.24, the above defaults to true.
+
+For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.
+
+## FAQ
+
+<br/>
+
+Q: Do I have to upgrade Rancher to get Rancher’s support of the upstream external Dockershim replacement?
+
+A: The upstream support of the Dockershim replacement `cri_dockerd` begins for RKE in Kubernetes 1.21. You will need to be on a version of Rancher that supports RKE 1.21. See our support matrix for details.
+
+<br/>
+
+Q: I am currently on RKE with Kubernetes 1.23. What happens when upstream finally removes Dockershim in 1.24?
+
+A: The version of Dockershim in RKE with Kubernetes will continue to work until 1.23. For information on the timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). After this, starting in 1.24, RKE will default to enabling `cri_dockerd` by default and will continue to do for versions afterwards.
+
+<br/>
+
+Q: What are my other options if I don’t want to depend on the Dockershim or cri_dockerd?
+
+A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
+
+<br/>
+
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
+
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
+
+<br/>
@@ -6,7 +6,7 @@ title: Installing Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements/install-docker"/>
 </head>

-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm on an RKE cluster or with Docker. Docker is not required for RKE2 or K3s clusters.

 There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.

@@ -18,4 +18,10 @@ For example, this command could be used to install on one of the main Linux dist
 curl https://releases.rancher.com/install-docker/<version-number>.sh | sh
 ```

-Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-5-16/) to match a validated Docker version with your operating system and version of Rancher. Although the support matrix lists validated Docker versions down to the patch version, only the major and minor version of the release are relevant for the Docker installation scripts.
+Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix) to match a validated Docker version with your operating system and version of Rancher. Although the support matrix lists validated Docker versions down to the patch version, only the major and minor version of the release are relevant for the Docker installation scripts.
+
+Note that the following sysctl setting must be applied:
+
+```bash
+net.bridge.bridge-nf-call-iptables=1
+```
@@ -0,0 +1,229 @@
+---
+title: Installation Requirements
+description: Learn the node requirements for each node running Rancher server when you’re configuring  Rancher to run either in a Docker or Kubernetes setup
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements"/>
+</head>
+
+This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
+
+:::note Important:
+
+If you install Rancher on a Kubernetes cluster, requirements are different from the [node requirements for downstream user clusters,](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) which will run your apps and services.
+
+:::
+
+The Rancher UI works best in Firefox or Chromium based browsers (Chrome, Edge, Opera, Brave, etc).
+
+See our page on [best practices](../../../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md) for a list of recommendations for running a Rancher server in production.
+
+## Kubernetes Compatibility with Rancher
+
+Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to ensure that your intended version of Kubernetes is supported.
+
+### Install Rancher on a Hardened Kubernetes cluster
+
+If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.
+
+## Operating Systems and Container Runtime Requirements
+
+All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
+
+The [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) lists which OS and Docker versions were tested for each Rancher version.
+
+Docker is required for nodes that will run RKE clusters. It is not required for RKE2 or K3s clusters.
+
+The `ntp` (Network Time Protocol) package should be installed. This prevents errors with certificate validation that can occur when the time is not synchronized between the client and server.
+
+Some distributions of Linux may have default firewall rules that block communication within the Kubernetes cluster. Since Kubernetes v1.19, firewalld must be turned off, because it conflicts with the Kubernetes networking plugins.
+
+If you don't feel comfortable doing so, you might check suggestions in the [respective issue](https://github.com/rancher/rancher/issues/28840). Some users were successful [creating a separate firewalld zone with a policy of ACCEPT for the Pod CIDR](https://github.com/rancher/rancher/issues/28840#issuecomment-787404822).
+
+If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).](../../../how-to-guides/advanced-user-guides/enable-experimental-features/rancher-on-arm64.md)
+
+### RKE2 Specific Requirements
+
+RKE2 bundles its own container runtime, containerd. Docker is not required for RKE2 installs.
+
+For details on which OS versions were tested with RKE2, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions).
+
+### K3s Specific Requirements
+
+For the container runtime, K3s bundles its own containerd by default. Alternatively, you can configure K3s to use an already installed Docker runtime. For more information on using K3s with Docker see the [K3s documentation.](https://docs.k3s.io/advanced#using-docker-as-the-container-runtime)
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions). To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
+
+If you are installing Rancher on a K3s cluster with **Raspbian Buster**, follow [these steps](https://rancher.com/docs/k3s/latest/en/advanced/#enabling-legacy-iptables-on-raspbian-buster) to switch to legacy iptables.
+
+If you are installing Rancher on a K3s cluster with Alpine Linux, follow [these steps](https://rancher.com/docs/k3s/latest/en/advanced/#additional-preparation-for-alpine-linux-setup) for additional setup.
+
+### RKE Specific Requirements
+
+RKE requires a Docker container runtime. Supported Docker versions are specified in the [Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) page.
+
+For more information, see [Installing Docker](install-docker.md).
+
+## Hardware Requirements
+
+The following sections describe the CPU, memory, and I/O requirements for nodes where Rancher is installed. Requirements vary based on the size of the infrastructure.
+
+### Practical Considerations
+
+Rancher's hardware footprint depends on a number of factors, including:
+
+ - Size of the managed infrastructure (e.g., node count, cluster count).
+ - Complexity of the desired access control rules (e.g., `RoleBinding` object count).
+ - Number of workloads (e.g., Kubernetes deployments, Fleet deployments).
+ - Usage patterns (e.g., subset of functionality actively used, frequency of use, number of concurrent users).
+
+Since there are a high number of influencing factors that may vary over time, the requirements listed here should be understood as reasonable starting points that work well for most use cases. Nevertheless, your use case may have different requirements. For inquiries about a specific scenario please [contact Rancher](https://rancher.com/contact/) for further guidance.
+
+In particular, requirements on this page are subject to typical use assumptions, which include:
+ - Under 60,000 total Kubernetes resources, per type.
+ - Up to 120 pods per node.
+ - Up to 200 CRDs in the upstream (local) cluster.
+ - Up to 100 CRDs in downstream clusters.
+ - Up to 50 Fleet deployments.
+
+Higher numbers are possible but requirements might be higher. If you have more than 20,000 resources of the same type, loading time of the whole list through the Rancher UI might take several seconds.
+
+:::note Evolution:
+
+Rancher's codebase evolves, use cases change, and the body of accumulated Rancher experience grows every day.
+
+Hardware requirement recommendations are subject to change over time, as guidelines improve in accuracy and become more concrete.
+
+If you find that your Rancher deployment no longer complies with the listed recommendations, [contact Rancher](https://rancher.com/contact/) for a re-evaluation.
+
+:::
+
+
+### RKE2 Kubernetes
+
+The following table lists minimum CPU and memory requirements for each node in the [upstream cluster](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+
+Please note that a highly available setup with at least three nodes is required for production.
+
+| Managed Infrastructure Size | Maximum Number of Clusters | Maximum Number of Nodes | vCPUs | RAM   |
+|-----------------------------|----------------------------|-------------------------|-------|-------|
+| Small                       | 150                        | 1500                    | 4     | 16 GB |
+| Medium                      | 300                        | 3000                    | 8     | 32 GB |
+| Large (*)                   | 500                        | 5000                    | 16    | 64 GB |
+| Larger (†)                  | (†)                        | (†)                     | (†)   | (†)   |
+
+(*): Large deployments require that you [follow best practices](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md) for adequate performance.
+
+(†): Larger deployment sizes are generally possible with ad-hoc hardware recommendations and tuning. You can [contact Rancher](https://rancher.com/contact/) for a custom evaluation.
+
+Refer to RKE2 documentation for more detailed information on [RKE2 general requirements](https://docs.rke2.io/install/requirements).
+
+### K3s Kubernetes
+
+The following table lists minimum CPU and memory requirements for each node in the [upstream cluster](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+
+Please note that a highly available setup with at least three nodes is required for production.
+
+| Managed Infrastructure Size | Maximum Number of Clusters | Maximum Number of Nodes | vCPUs | RAM   | External Database Host (*) |
+|-----------------------------|----------------------------|-------------------------|-------|-------|----------------------------|
+| Small                       | 150                        | 1500                    | 4     | 16 GB | 2 vCPUs, 8 GB + 1000 IOPS  |
+| Medium                      | 300                        | 3000                    | 8     | 32 GB | 4 vCPUs, 16 GB + 2000 IOPS |
+| Large (†)                   | 500                        | 5000                    | 16    | 64 GB | 8 vCPUs, 32 GB + 4000 IOPS |
+
+(*): External Database Host refers to hosting the K3s cluster data store on an [dedicated external host](https://docs.k3s.io/datastore). This is optional. Exact requirements depend on the external data store.
+
+(†): Large deployments require that you [follow best practices](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md) for adequate performance.
+
+Refer to the K3s documentation for more detailed information on [general requirements](https://docs.k3s.io/installation/requirements).
+
+### Hosted Kubernetes
+
+The following table lists minimum CPU and memory requirements for each node in the [upstream cluster](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+
+Please note that a highly available setup with at least three nodes is required for production.
+
+These requirements apply to hosted Kubernetes clusters such as Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE). They don't apply to Rancher SaaS solutions such as [Rancher Prime Hosted](https://www.rancher.com/products/rancher).
+
+| Managed Infrastructure Size | Maximum Number of Clusters | Maximum Number of Nodes | vCPUs | RAM   |
+|-----------------------------|----------------------------|-------------------------|-------|-------|
+| Small                       | 150                        | 1500                    | 4     | 16 GB |
+| Medium                      | 300                        | 3000                    | 8     | 32 GB |
+| Large (*)                   | 500                        | 5000                    | 16    | 64 GB |
+
+(*): Large deployments require that you [follow best practices](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md) for adequate performance.
+
+### RKE
+
+The following table lists minimum CPU and memory requirements for each node in the [upstream cluster](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+
+Please note that a highly available setup with at least three nodes is required for production.
+
+| Managed Infrastructure Size | Maximum Number of Clusters | Maximum Number of Nodes | vCPUs | RAM   |
+|-----------------------------|----------------------------|-------------------------|-------|-------|
+| Small                       | 150                        | 1500                    | 4     | 16 GB |
+| Medium                      | 300                        | 3000                    | 8     | 32 GB |
+| Large (*)                   | 500                        | 5000                    | 16    | 64 GB |
+
+(*): Large deployments require that you [follow best practices](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md) for adequate performance.
+
+Refer to the RKE documentation for more detailed information on [general requirements](https://rke.docs.rancher.com/os).
+
+### Docker
+
+The following table lists minimum CPU and memory requirements for a [single Docker node installation of Rancher](../other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md).
+
+Please note that a Docker installation is only suitable for development or testing purposes and is not meant to be used in production environments.
+
+| Managed Infrastructure Size | Maximum Number of Clusters | Maximum Number of Nodes | vCPUs | RAM  |
+|-----------------------------|----------------------------|-------------------------|-------|------|
+| Small                       | 5                          | 50                      | 1     | 4 GB |
+| Medium                      | 15                         | 200                     | 2     | 8 GB |
+
+## Ingress
+
+Each node in the Kubernetes cluster that Rancher is installed on should run an Ingress.
+
+The Ingress should be deployed as DaemonSet to ensure your load balancer can successfully route traffic to all nodes.
+
+For RKE, RKE2 and K3s installations, you don't have to install the Ingress manually because it is installed by default.
+
+For hosted Kubernetes clusters (EKS, GKE, AKS), you will need to set up the ingress.
+
+- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](../install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)
+- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](../install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
+- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.](../install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md)
+
+## Disks
+
+Rancher performance depends on etcd in the cluster performance. To ensure optimal speed, we recommend always using SSD disks to back your Rancher management Kubernetes cluster. On cloud providers, you will also want to use the minimum size that allows the maximum IOPS. In larger clusters, consider using dedicated storage devices for etcd data and wal directories.
+
+## Networking Requirements
+
+This section describes the networking requirements for the node(s) where the Rancher server is installed.
+
+:::caution
+
+If a server containing Rancher has the `X-Frame-Options=DENY` header, some pages in the new Rancher UI will not be able to render after upgrading from the legacy UI. This is because some legacy pages are embedded as iFrames in the new UI.
+
+:::
+
+### Node IP Addresses
+
+Each node used should have a static IP configured, regardless of whether you are installing Rancher on a single node or on an HA cluster. In case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated.
+
+### Port Requirements
+
+To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](port-requirements.md) lists all the necessary ports for Rancher and Downstream Clusters for the different cluster types.
+
+### Load Balancer Requirements
+
+If you use a load balancer, it should be be HTTP/2 compatible. 
+
+To receive help from SUSE Support, Rancher Prime customers who use load balancers (or any other middleboxes such as firewalls), must use one that is HTTP/2 compatible.
+
+When HTTP/2 is not available, Rancher falls back to HTTP/1.1. However, since HTTP/2 offers improved web application performance, using HTTP/1.1 can create performance issues. 
+
+## Dockershim Support
+
+For more information on Dockershim support, refer to [this page](dockershim.md).
@@ -19,13 +19,16 @@ The following table lists the ports that need to be open to and from nodes that

 The port requirements differ based on the Rancher server architecture.

-As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3s, RKE, or RKE2 Kubernetes cluster, refer to the tabs below. For other Kubernetes distributions, refer to the distribution's documentation for the port requirements for cluster nodes.
+Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3s, RKE, or RKE2 Kubernetes cluster, refer to the tabs below. For other Kubernetes distributions, refer to the distribution's documentation for the port requirements for cluster nodes.

-> **Notes:**
->
-> - Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
-> - Kubernetes recommends TCP 30000-32767 for node port services.
-> - For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
+:::note Notes:
+
+- Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
+- Kubernetes recommends TCP 30000-32767 for node port services.
+- For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
+- Rancher nodes may also need outbound access to an external S3 location which is used for storing cluster backups (Minio for example).
+
+:::

 ### Ports for Rancher Server Nodes on K3s

@@ -38,7 +41,11 @@ The nodes need to be able to reach other nodes over UDP port 8472 when Flannel V

 If you wish to utilize the metrics server, you will need to open port 10250 on each node.

-> **Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+:::note Important:
+
+The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+
+:::

 The following tables break down the port requirements for inbound and outbound traffic:

@@ -80,6 +87,7 @@ The following tables break down the port requirements for traffic between the Ra
 | TCP | 2379 | etcd client requests |
 | TCP | 2380 | etcd peer communication |
 | TCP | 6443 | Kubernetes apiserver |
+| TCP | 8443 | Nginx Ingress's Validating Webhook |
 | UDP | 8472 | Canal/Flannel VXLAN overlay networking |
 | TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
 | TCP | 10250 | Metrics server communication with all nodes |
@@ -100,7 +108,7 @@ The following tables break down the port requirements for inbound and outbound t

 | Protocol | Port | Destination | Description |
 |-----|-----|----------------|---|
-| TCP | 443 | `35.160.43.145`,`35.167.242.46`,`52.33.59.17` | Rancher catalog (git.rancher.io) |
+| TCP | 443 | git.rancher.io | Rancher catalog |
 | TCP | 22 | Any node created using a node driver | SSH provisioning of node by node driver |
 | TCP | 2376 | Any node created using a node driver | Docker daemon TLS port used by node driver |
 | TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
@@ -108,34 +116,37 @@ The following tables break down the port requirements for inbound and outbound t

 </details>

-### Ports for Rancher Server Nodes on RancherD or RKE2
-
-> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
+### Ports for Rancher Server Nodes on RKE2

 <details>
  <summary>Click to expand</summary>

-The RancherD (or RKE2) server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
+The RKE2 server needs port 6443 and 9345 to be accessible by other nodes in the cluster.

 All nodes need to be able to reach other nodes over UDP port 8472 when Flannel VXLAN is used.

 If you wish to utilize the metrics server, you will need to open port 10250 on each node.

-**Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+:::note Important:

-<figcaption>Inbound Rules for RancherD or RKE2 Server Nodes</figcaption>
+The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+
+:::
+
+<figcaption>Inbound Rules for RKE2 Server Nodes</figcaption>

 | Protocol | Port | Source | Description
 |-----|-----|----------------|---|
-| TCP | 9345 | RancherD/RKE2 agent nodes | Kubernetes API
-| TCP | 6443 | RancherD/RKE2 agent nodes | Kubernetes API
-| UDP | 8472 | RancherD/RKE2 server and agent nodes | Required only for Flannel VXLAN
-| TCP | 10250 | RancherD/RKE2 server and agent nodes | kubelet
-| TCP | 2379 | RancherD/RKE2 server nodes | etcd client port
-| TCP | 2380 | RancherD/RKE2 server nodes | etcd peer port
-| TCP | 30000-32767 | RancherD/RKE2 server and agent nodes | NodePort port range
-| HTTP | 8080 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used |
-| HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
+| TCP | 9345 | RKE2 server and agent nodes | Node registration. Port should be open on all server nodes to all other nodes in the cluster.
+| TCP | 6443 | RKE2 agent nodes | Kubernetes API
+| UDP | 8472 | RKE2 server and agent nodes | Required only for Flannel VXLAN
+| TCP | 10250 | RKE2 server and agent nodes | kubelet
+| TCP | 2379 | RKE2 server nodes | etcd client port
+| TCP | 2380 | RKE2 server nodes | etcd peer port
+| TCP | 30000-32767 | RKE2 server and agent nodes | NodePort port range. Can use TCP or UDP.
+| TCP | 5473 | Calico-node pod connecting to typha pod | Required when deploying with Calico
+| HTTP | 80 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used |
+| HTTPS | 443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have a load balancer doing TLS termination. |

 Typically all outbound traffic is allowed.
 </details>
@@ -177,21 +188,31 @@ The following diagram depicts the ports that are opened for each [cluster type](

 ![Basic Port Requirements](/img/port-communications.svg)

->**Tip:**
->
->If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
+:::tip
+
+If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
+
+:::
+
+### Ports for Harvester Clusters
+
+Refer to the [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md#port-requirements) for more information on Harvester port requirements.
+

 ### Ports for Rancher Launched Kubernetes Clusters using Node Pools

 <details>
  <summary>Click to expand</summary>

-The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with nodes created in an [Infrastructure Provider](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
+The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with nodes created in an [Infrastructure Provider](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).

->**Note:**
->The required ports are automatically opened by Rancher during creation of clusters in cloud providers like Amazon EC2 or DigitalOcean.
+:::note

-<PortsIaasNodes/>
+The required ports are automatically opened by Rancher during creation of clusters in cloud providers like Amazon EC2 or DigitalOcean.
+
+:::
+
+ <PortsIaasNodes/>

 </details>

@@ -200,7 +221,7 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
 <details>
  <summary>Click to expand</summary>

-The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with [Custom Nodes](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).
+The following table depicts the port requirements for [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) with [Custom Nodes](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).

 <PortsCustomNodes/>

@@ -219,7 +240,11 @@ The following table depicts the port requirements for [hosted clusters](../../..

 ### Ports for Registered Clusters

-Note: Registered clusters were called imported clusters before Rancher v2.5.
+:::note
+
+Registered clusters were called imported clusters before Rancher v2.5.
+
+:::

 <details>
  <summary>Click to expand</summary>
@@ -257,7 +282,7 @@ In these cases, you have to explicitly allow this traffic in your host firewall,

 ### Rancher AWS EC2 Security Group

-When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) to provision cluster nodes in Rancher, you can choose to let Rancher create a security group called `rancher-nodes`. The following rules are automatically added to this security group.
+When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) to provision cluster nodes in Rancher, you can choose to let Rancher create a security group called `rancher-nodes`. The following rules are automatically added to this security group.

 |       Type      | Protocol |  Port Range | Source/Destination     | Rule Type |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
@@ -299,7 +324,6 @@ SUSE Linux may have a firewall that blocks all ports by default. To open the por

 1. When all required ports are enter, select **Accept**.

-
 </TabItem>
 <TabItem value="SLES 12 / openSUSE Leap 42">

@@ -1,5 +1,5 @@
 ---
-title: Air Gapped Helm CLI Install
+title: Air-Gapped Helm CLI Install
 ---

 <head>
@@ -14,7 +14,11 @@ For more information on each installation option, refer to [this page.](../../in

 Throughout the installation instructions, there will be _tabs_ for each installation option.

-> **Important:** If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker Installation to a Kubernetes Installation.
+:::note Important:
+
+If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker Installation to a Kubernetes Installation.
+
+:::

 ## Installation Outline

@@ -10,7 +10,7 @@ The Docker installation is for Rancher users who want to test out Rancher.

 Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.

-For Rancher v2.5+, the backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)
+The backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)

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

@@ -19,10 +19,12 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 | `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `CATTLE_SYSTEM_CATALOG`          | `bundled`                        | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |

-> **Do you want to...**
->
-> - Configure custom CA root certificate to access your services? See [Custom CA root certificate](../../resources/custom-ca-root-certificates.md/).
-> - Record all transactions with the Rancher API? See [API Auditing](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log).
+:::note Do you want to..
+
+- Configure custom CA root certificate to access your services? See [Custom CA root certificate](../../resources/custom-ca-root-certificates.md).
+- Record all transactions with the Rancher API? See [API Auditing](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log).
+
+:::

 Choose from the following options:

@@ -38,9 +40,9 @@ Log into your Linux host, and then run the installation command below. When ente
 | Placeholder                      | Description                                                                                                                   |
 | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
 | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
-| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../installation-references/helm-chart-options.md) that you want to install. |

-As of Rancher v2.5, privileged access is [required.](../rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
+Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)

 ```
 docker run -d --restart=unless-stopped \
@@ -60,11 +62,14 @@ docker run -d --restart=unless-stopped \

 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.

-> **Prerequisites:**
-> From a computer with an internet connection, create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice.
->
-> - The certificate files must be in PEM format.
-> - In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+:::note Prerequisites:
+
+From a computer with an internet connection, create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice.
+
+- The certificate files must be in PEM format.
+- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+:::

 After creating your certificate, log into your Linux host, and then run the installation command below. When entering the command, use the table below to replace each placeholder. Use the `-v` flag and provide the path to your certificates to mount them in your container.

@@ -75,9 +80,9 @@ After creating your certificate, log into your Linux host, and then run the inst
 | `<PRIVATE_KEY.pem>`              | The path to the private key for your certificate.                                                                             |
 | `<CA_CERTS.pem>`                     | The path to the certificate authority's certificate.                                                                          |
 | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
-| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../installation-references/helm-chart-options.md) that you want to install. |

-As of Rancher v2.5, privileged access is [required.](../rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
+Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)

 ```
 docker run -d --restart=unless-stopped \
@@ -100,7 +105,11 @@ docker run -d --restart=unless-stopped \

 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.

-> **Prerequisite:** The certificate files must be in PEM format.
+:::note Prerequisite:
+
+The certificate files must be in PEM format.
+
+:::

 After obtaining your certificate, log into your Linux host, and then run the installation command below. When entering the command, use the table below to replace each placeholder. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary.

@@ -110,11 +119,15 @@ After obtaining your certificate, log into your Linux host, and then run the ins
 | `<FULL_CHAIN.pem>`               | The path to your full certificate chain.                                                                                      |
 | `<PRIVATE_KEY.pem>`              | The path to the private key for your certificate.                                                                             |
 | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
-| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../installation-references/helm-chart-options.md) that you want to install. |

-> **Note:** Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
+:::note

-As of Rancher v2.5, privileged access is [required.](../rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
+Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
+
+:::
+
+Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)

 ```
 docker run -d --restart=unless-stopped \
@@ -129,9 +142,3 @@ docker run -d --restart=unless-stopped \
 ```

 </details>
-
-:::note
-
-If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.
-
-:::
@@ -6,13 +6,13 @@ title: '1. Set up Infrastructure and Private Registry'
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry"/>
 </head>

-In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).
+In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private container image registry that must be available to your Rancher node(s).

 An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.

 The infrastructure depends on whether you are installing Rancher on a K3s Kubernetes cluster, an RKE Kubernetes cluster, or a single Docker container. For more information on each installation option, refer to [this page.](../../installation-and-upgrade.md)

-As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. The RKE and K3s Kubernetes infrastructure tutorials below are still included for convenience.
+Rancher can be installed on any Kubernetes cluster. The RKE and K3s Kubernetes infrastructure tutorials below are still included for convenience.

 <Tabs>
 <TabItem value="K3s">
@@ -23,7 +23,7 @@ We recommend setting up the following infrastructure for a high-availability ins
 - **An external database** to store the cluster data. PostgreSQL, MySQL, and etcd are supported.
 - **A load balancer** to direct traffic to the two nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
- **A private Docker registry** to distribute Docker images to your machines.
+- **A private image registry** to distribute container images to your machines.

 ## 1. Set up Linux Nodes

@@ -60,14 +60,17 @@ When Rancher is installed (also in a later step), the Rancher system creates an
 For your implementation, consider if you want or need to use a Layer-4 or Layer-7 load balancer:

 - **A layer-4 load balancer** is the simpler of the two choices, in which you are forwarding TCP traffic to your nodes. We recommend configuring your load balancer as a Layer 4 balancer, forwarding traffic to ports TCP/80 and TCP/443 to the Rancher management cluster nodes. The Ingress controller on the cluster will redirect HTTP traffic to HTTPS and terminate SSL/TLS on port TCP/443. The Ingress controller will forward traffic to port TCP/80 to the Ingress pod in the Rancher deployment.
- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.](../../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
+- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.](../../installation-references/helm-chart-options.md#external-tls-termination)

 For an example showing how to set up an NGINX load balancer, refer to [this page.](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)

 For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)

-> **Important:**
-> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
+:::note Important:
+
+Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
+
+:::

 ## 4. Set up the DNS Record

@@ -79,13 +82,17 @@ You will need to specify this hostname in a later step when you install Rancher,

 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)

-## 5. Set up a Private Docker Registry
+## 5. Set up a Private Image Registry

-Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing Docker images to your machines.
+Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing container images to your machines.

 In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) with details from this registry.

-If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
+If you need to create a private registry, refer to the documentation pages for your respective runtime:
+
+* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
+  * [Nerdctl commands and managed registry services](https://github.com/containerd/nerdctl/blob/main/docs/registry.md). 
+* [Docker](https://docs.docker.com/registry/deploying/).

 </TabItem>
 <TabItem value="RKE">
@@ -95,7 +102,7 @@ To install the Rancher management server on a high-availability RKE cluster, we
 - **Three Linux nodes,** typically virtual machines, in an infrastructure provider such as Amazon's EC2, Google Compute Engine, or vSphere.
 - **A load balancer** to direct front-end traffic to the three nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
- **A private Docker registry** to distribute Docker images to your machines.
+- **A private image registry** to distribute container images to your machines.

 These nodes must be in the same region/data center. You may place these servers in separate availability zones.

@@ -124,14 +131,17 @@ When Rancher is installed (also in a later step), the Rancher system creates an
 For your implementation, consider if you want or need to use a Layer-4 or Layer-7 load balancer:

 - **A layer-4 load balancer** is the simpler of the two choices, in which you are forwarding TCP traffic to your nodes. We recommend configuring your load balancer as a Layer 4 balancer, forwarding traffic to ports TCP/80 and TCP/443 to the Rancher management cluster nodes. The Ingress controller on the cluster will redirect HTTP traffic to HTTPS and terminate SSL/TLS on port TCP/443. The Ingress controller will forward traffic to port TCP/80 to the Ingress pod in the Rancher deployment.
- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.](../../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
+- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.](../../installation-references/helm-chart-options.md#external-tls-termination)

 For an example showing how to set up an NGINX load balancer, refer to [this page.](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)

 For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)

-> **Important:**
-> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
+:::caution
+
+Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
+
+:::

 ## 3. Set up the DNS Record

@@ -143,35 +153,42 @@ You will need to specify this hostname in a later step when you install Rancher,

 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)

-## 4. Set up a Private Docker Registry
+## 4. Set up a Private Image Registry

-Rancher supports air gap installs using a secure Docker private registry. You must have your own private registry or other means of distributing Docker images to your machines.
+Rancher supports air gap installs using a secure private registry. You must have your own private registry or other means of distributing container images to your machines.

 In a later step, when you set up your RKE Kubernetes cluster, you will create a [private registries configuration file](https://rancher.com/docs/rke/latest/en/config-options/private-registries/) with details from this registry.

-If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
+If you need to create a private registry, refer to the documentation pages for your respective runtime:

+* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
+  * [Nerdctl commands and managed registry services](https://github.com/containerd/nerdctl/blob/main/docs/registry.md). 
+* [Docker](https://docs.docker.com/registry/deploying/).

 </TabItem>
 <TabItem value="Docker">

-> The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
->
-> As of Rancher v2.5, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)
+:::note Notes:
+
+- The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
+
+- The Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)
+
+:::

 ## 1. Set up a Linux Node

 This host will be disconnected from the Internet, but needs to be able to connect to your private registry.

-Make sure that your node fulfills the general installation requirements for [OS, Docker, hardware, and networking.](../../installation-requirements/installation-requirements.md)
+Make sure that your node fulfills the general installation requirements for [OS, containers, hardware, and networking.](../../installation-requirements/installation-requirements.md)

 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.

 ## 2. Set up a Private Docker Registry

-Rancher supports air gap installs using a Docker private registry on your bastion server. You must have your own private registry or other means of distributing Docker images to your machines.
+Rancher supports air gap installs using a private registry on your bastion server. You must have your own private registry or other means of distributing container images to your machines.

-If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/)
+If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/).

 </TabItem>
 </Tabs>
@@ -6,13 +6,17 @@ title: '3. Install Kubernetes (Skip for Docker Installs)'
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes"/>
 </head>

-> Skip this section if you are installing Rancher on a single node with Docker.
+:::note
+
+Skip this section if you are installing Rancher on a single node with Docker.
+
+:::

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

-As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes providers.
+Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes providers.

-The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
+The steps to set up an air-gapped Kubernetes cluster on RKE, RKE2, or K3s are shown below.

 <Tabs>
 <TabItem value="K3s">
@@ -28,7 +32,7 @@ In this guide, we are assuming you have created your nodes in your air gapped en

 ## 1. Prepare Images Directory

-Obtain the images tar file for your architecture from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be running.
+Obtain the images tar file for your architecture from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be running.

 Place the tar file in the `images` directory before starting K3s on each node, for example:

@@ -43,7 +47,7 @@ Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will

 The registries.yaml file should look like this before plugging in the necessary information:

-```
+```yaml
 ---
 mirrors:
  customreg:
@@ -66,11 +70,11 @@ For more information on private registries configuration file for K3s, refer to

 ## 3. Install K3s

-Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).

-To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
+To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.

-Obtain the K3s binary from the [releases](https://github.com/rancher/k3s/releases) page, matching the same version used to get the airgap images tar.
+Obtain the K3s binary from the [releases](https://github.com/k3s-io/k3s/releases) page, matching the same version used to get the airgap images tar.
 Also obtain the K3s install script at https://get.k3s.io

 Place the binary in `/usr/local/bin` on each node.
@@ -79,19 +83,22 @@ Place the install script anywhere on each node, and name it `install.sh`.
 Install K3s on each server:

 ```
-INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
+INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> ./install.sh
 ```

 Install K3s on each agent:

 ```
-INSTALL_K3S_SKIP_DOWNLOAD=true K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken ./install.sh
+INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> K3S_URL=https://<SERVER>:6443 K3S_TOKEN=<TOKEN> ./install.sh
 ```

-Note, take care to ensure you replace `myserver` with the IP or valid DNS of the server and replace `mynodetoken` with the node-token from the server.
-The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`
+Where `<SERVER>` is the IP or valid DNS of the server and `<TOKEN>` is the node-token from the server found at `/var/lib/rancher/k3s/server/node-token`.

->**Note:** K3s additionally provides a `--resolv-conf` flag for kubelets, which may help with configuring DNS in air-gap networks.
+:::note
+
+K3s additionally provides a `--resolv-conf` flag for kubelets, which may help with configuring DNS in air-gapped networks.
+
+:::

 ## 4. Save and Start Using the kubeconfig File

@@ -103,7 +110,7 @@ To use this `kubeconfig` file,
 2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
 3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `k3s.yaml`:

-```
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -137,19 +144,167 @@ For more information about the `kubeconfig` file, refer to the [K3s documentatio

 Upgrading an air-gap environment can be accomplished in the following manner:

-1. Download the new air-gap images (tar file) from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
+1. Download the new air-gap images (tar file) from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
 2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
 3. Restart the K3s service (if not restarted automatically by installer).

 </TabItem>
-<TabItem value="RKE">
+<TabItem value="RKE2">

+In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.
+
+## Installation Outline
+
+1. [Create RKE2 configuration](#1-create-rke2-configuration)
+2. [Create Registry YAML](#2-create-registry-yaml)
+3. [Install RKE2](#3-install-rke2)
+4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
+
+## 1. Create RKE2 configuration
+
+Create the config.yaml file at `/etc/rancher/rke2/config.yaml`. This will contain all the configuration options necessary to create a highly available RKE2 cluster.
+
+On the first server the minimum config is:
+
+```
+token: my-shared-secret
+tls-san:
+  - loadbalancer-dns-domain.com
+```
+
+On each other server the config file should contain the same token and tell RKE2 to connect to the existing first server:
+
+```
+server: https://ip-of-first-server:9345
+token: my-shared-secret
+tls-san:
+  - loadbalancer-dns-domain.com
+```
+
+For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha).
+
+:::note
+
+RKE2 additionally provides a `resolv-conf` option for kubelets, which may help with configuring DNS in air-gap networks.
+
+:::
+
+## 2. Create Registry YAML
+
+Create the registries.yaml file at `/etc/rancher/rke2/registries.yaml`. This will tell RKE2 the necessary details to connect to your private registry.
+
+The registries.yaml file should look like this before plugging in the necessary information:
+
+```
+---
+mirrors:
+  customreg:
+    endpoint:
+      - "https://ip-to-server:5000"
+configs:
+  customreg:
+    auth:
+      username: xxxxxx # this is the registry username
+      password: xxxxxx # this is the registry password
+    tls:
+      cert_file: <path to the cert file used in the registry>
+      key_file:  <path to the key file used in the registry>
+      ca_file: <path to the ca file used in the registry>
+```
+
+For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
+
+## 3. Install RKE2
+
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
+
+Download the install script, rke2, rke2-images, and sha256sum archives from the release and upload them into a directory on each server:
+
+```
+mkdir /tmp/rke2-artifacts && cd /tmp/rke2-artifacts/
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2-images.linux-amd64.tar.zst
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2.linux-amd64.tar.gz
+wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/sha256sum-amd64.txt
+curl -sfL https://get.rke2.io --output install.sh
+```
+
+Next, run install.sh using the directory on each server, as in the example below:
+
+```
+INSTALL_RKE2_ARTIFACT_PATH=/tmp/rke2-artifacts sh install.sh
+```
+
+Then enable and start the service on all servers:
+
+``
+systemctl enable rke2-server.service
+systemctl start rke2-server.service
+``
+
+For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
+
+## 4. Save and Start Using the kubeconfig File
+
+When you installed RKE2 on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/rke2/rke2.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
+
+To use this `kubeconfig` file,
+
+1. Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl), a Kubernetes command-line tool.
+2. Copy the file at `/etc/rancher/rke2/rke2.yaml` and save it to the directory `~/.kube/config` on your local machine.
+3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `rke2.yaml`:
+
+```
+apiVersion: v1
+clusters:
+- cluster:
+    certificate-authority-data: [CERTIFICATE-DATA]
+    server: [LOAD-BALANCER-DNS]:6443 # Edit this line
+  name: default
+contexts:
+- context:
+    cluster: default
+    user: default
+  name: default
+current-context: default
+kind: Config
+preferences: {}
+users:
+- name: default
+  user:
+    password: [PASSWORD]
+    username: admin
+```
+
+**Result:** You can now use `kubectl` to manage your RKE2 cluster. If you have more than one kubeconfig file, you can specify which one you want to use by passing in the path to the file when using `kubectl`:
+
+```
+kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
+```
+
+For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
+
+## Note on Upgrading
+
+Upgrading an air-gap environment can be accomplished in the following manner:
+
+1. Download the new air-gap artifacts and install script from the [releases](https://github.com/rancher/rke2/releases) page for the version of RKE2 you will be upgrading to.
+2. Run the script again just as you had done in the past with the same environment variables.
+3. Restart the RKE2 service.
+
+</TabItem>
+<TabItem value="RKE">
 We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.

 ## 1. Install RKE

 Install RKE by following the instructions in the [RKE documentation.](https://rancher.com/docs/rke/latest/en/installation/)

+:::note
+
+Certified version(s) of RKE based on the Rancher version can be found in the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
+
+:::
+
 ## 2. Create an RKE Config File

 From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s) that you set up in a previous step, use the sample below to create a new file named `rancher-cluster.yml`.
@@ -158,7 +313,11 @@ This file is an RKE configuration file, which is a configuration for the cluster

 Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the three nodes you created.

-> **Tip:** For more details on the options available, see the RKE [Config Options](https://rancher.com/docs/rke/latest/en/config-options/).
+:::tip
+
+For more details on the options available, see the RKE [Config Options](https://rancher.com/docs/rke/latest/en/config-options/).
+
+:::

 <figcaption>RKE Options</figcaption>

@@ -207,8 +366,11 @@ rke up --config ./rancher-cluster.yml

 ## 4. Save Your Files

-> **Important**
-> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+:::note Important:
+
+The files mentioned below are needed to maintain, troubleshoot, and upgrade your cluster.
+
+:::

 Save a copy of the following files in a secure location:

@@ -219,7 +381,11 @@ Save a copy of the following files in a secure location:
 </TabItem>
 </Tabs>

-> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
+:::note
+
+The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
+
+:::

 ## Issues or Errors?

@@ -234,13 +234,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
    --set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```

-
 The installation is complete.
-:::caution
-
-If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
-
-:::

 ## Additional Resources

@@ -8,17 +8,19 @@ title: '2. Collect and Publish Images to your Private Registry'

 This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.

-By default, all images used to [provision Kubernetes clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) or launch any tools in Rancher, e.g. monitoring and logging, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
+By default, all images used to [provision Kubernetes clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) or launch any tools in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.

 Populating the private registry with images is the same process for installing Rancher with Docker and for installing Rancher on a Kubernetes cluster.

-The steps in this section differ depending on whether or not you are planning to use Rancher to provision a downstream cluster with Windows nodes or not. By default, we provide the steps of how to populate your private registry assuming that Rancher will provision downstream Kubernetes clusters with only Linux nodes. But if you plan on provisioning any [downstream Kubernetes clusters using Windows nodes](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md), there are separate instructions to support the images needed.
+The steps in this section differ depending on whether or not you are planning to use Rancher to provision a downstream cluster with Windows nodes or not. By default, we provide the steps of how to populate your private registry assuming that Rancher will provision downstream Kubernetes clusters with only Linux nodes. But if you plan on provisioning any [downstream Kubernetes clusters using Windows nodes](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md), there are separate instructions to support the images needed.

-> **Prerequisites:**
->
-> You must have a [private registry](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry) available to use.
->
-> If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
+:::note Prerequisites:
+
+You must have a [private registry](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry) available to use.
+
+If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
+
+:::

 <Tabs>
 <TabItem value="Linux Only Clusters">
@@ -38,7 +40,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20

 ### 1. Find the required assets for your Rancher version

-1. Go to our [releases page,](https://github.com/rancher/rancher/releases) find the Rancher v2.x.x release that you want to install, and click **Assets.** Note: Don't use releases marked `rc` or `Pre-release`, as they are not stable for production environments.
+1. Go to our [releases page,](https://github.com/rancher/rancher/releases) find the Rancher v2.x.x release that you want to install, and click **Assets**. Note: Don't use releases marked `rc` or `Pre-release`, as they are not stable for production environments.

 2. From the release's **Assets** section, download the following files, which are required to install Rancher in an air gap environment:

@@ -50,18 +52,26 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20

 ### 2. Collect the cert-manager image

-> Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
+:::note

-In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
+Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
+
+:::
+
+In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well.

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

-    > **Note:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../resources/upgrade-cert-manager.md).
+    :::note
+
+    Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../resources/upgrade-cert-manager.md).
+
+    :::

    ```plain
    helm repo add jetstack https://charts.jetstack.io
    helm repo update
-    helm fetch jetstack/cert-manager --version v1.5.1
+    helm fetch jetstack/cert-manager
    helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
    ```

@@ -161,7 +171,7 @@ Your registry must support manifests. As of April 2020, Amazon Elastic Container

 Append your private registry address to the `allow-nondistributable-artifacts` config field in the Docker daemon (`C:\ProgramData\Docker\config\daemon.json`). Since the base image of Windows images are maintained by the `mcr.microsoft.com` registry, this step is required as the layers in the Microsoft registry are missing from Docker Hub and need to be pulled into the private registry.

-   ```
+   ```json
   {
     ...
     "allow-nondistributable-artifacts": [
@@ -211,7 +221,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are

 ### 1. Find the required assets for your Rancher version

-1. Browse to our [releases page](https://github.com/rancher/rancher/releases) and find the Rancher v2.x.x release that you want to install. Don't download releases marked `rc` or `Pre-release`, as they are not stable for production environments. Click **Assets.**
+1. Browse to our [releases page](https://github.com/rancher/rancher/releases) and find the Rancher v2.x.x release that you want to install. Don't download releases marked `rc` or `Pre-release`, as they are not stable for production environments. Click **Assets**.

 2. From the release's **Assets** section, download the following files:

@@ -226,15 +236,22 @@ The workstation must have Docker 18.02+ in order to support manifests, which are

 ### 2. Collect all the required images

-**For Kubernetes Installs using Rancher Generated Self-Signed Certificate:** In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well. You skip this step if you are using you using your own certificates.
+**For Kubernetes Installs using Rancher Generated Self-Signed Certificate:** In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well. You skip this step if you are using you using your own certificates.
+

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

 2. Sort and unique the images list to remove any overlap between the sources:
@@ -20,4 +20,4 @@ The Docker installation is for development and testing environments only.

 Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.

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