Merge remote-tracking branch 'upstream/main' into discourage_third_party_sw

2026-09-27 13:38:07 +00:00 · 2025-07-04 17:09:39 -07:00
parent 2a9af4d13a 1b4338a1cb
commit aa47c1b163
2923 changed files with 147744 additions and 11192 deletions
@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api" />
+<ApiDocMdx id="rancher-api-v2-10" />
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
+| [2.10.7](https://github.com/rancher/rancher/releases/tag/v2.10.7) | June 25, 2025 |
 | [2.10.6](https://github.com/rancher/rancher/releases/tag/v2.10.6) | May 22, 2025 |
 | [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 |
@@ -213,10 +213,11 @@ If you are using a Private CA signed certificate (or if `agent-tls-mode` is set

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

-### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

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

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
@@ -224,6 +225,22 @@ ingress:
    use-forwarded-headers: 'true'
 ```

+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
 ### Required Headers

 - `Host`
@@ -120,6 +120,7 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
 - `cert-manager`
 - `cis-operator-system`
 - `fleet-default`
+- `fleet-local`
 - `ingress-nginx`
 - `istio-system`
 - `kube-node-lease`
@@ -42,26 +42,6 @@ To display prerelease versions:
 1. Click **Preferences**.
 1. Under **Helm Charts**, select **Include Prerelease Versions**.

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

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

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

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

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

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

  For example, suppose you install `cert-manager` v1.13.0 from repository A, where v1.14.0 is now the most recent version available. In this case, you expect **Upgradable** to display v1.14.0. However, if the cluster also has access to repository B where v1.15.0 of `cert-manager` is available, then **Upgradable** displays v1.15.0 even though the original installation used repository A.
-  
+
@@ -18,7 +18,7 @@ Listed below are the primary RKE2 features for Windows cluster provisioning:

 - Windows Containers with RKE2 powered by containerd
 - Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
- Calico CNI for Windows RKE2 custom clusters
+- Calico and Flannel CNI for Windows RKE2 custom clusters
 - SAC releases of Windows Server (2004 and 20H2) are included in the technical preview

 :::note
@@ -57,7 +57,7 @@ Rancher will not provision the node if the node does not meet these requirements

 Before provisioning a new cluster, be sure that you have already installed Rancher on a device that accepts inbound network traffic. This is required in order for the cluster nodes to communicate with Rancher. If you have not already installed Rancher, please refer to the [installation documentation](../../../../getting-started/installation-and-upgrade/installation-and-upgrade.md) before proceeding with this guide.

-Rancher supports Windows using Calico as the network provider.
+Rancher supports Windows using Calico and Flannel as network providers.

 If you are configuring DHCP options sets for an AWS virtual private cloud, note that in the `domain-name` option field, only one domain name can be specified. According to the DHCP options [documentation:](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)

@@ -163,7 +163,7 @@ The instructions for creating a Windows cluster on existing nodes are very simil
 1. Click **Custom**.
 1. Enter a name for your cluster in the **Cluster Name** field.
 1. In the **Kubernetes Version** dropdown menu, select a supported Kubernetes version.
-1. In the **Container Network** field, select **Calico**.
+1. In the **Container Network** field, select either **Calico** or **Flannel**.
 1. Click **Next**.

 ### 3. Add Nodes to the Cluster
@@ -65,7 +65,7 @@ RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.
 Windows features for RKE2 include:

 - Windows supports the vSphere node driver
- Calico CNI for Windows RKE2 custom clusters
+- Calico and Flannel CNI for Windows RKE2 custom clusters
 - Project Network Isolation (PNI) for Calico
 - Windows Containers with RKE2 powered by containerd
 - Provisioning of Windows RKE2 clusters through Terraform
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
+| v2.10.7         | v105.0.0+up5.0.1 |
 | v2.10.6         | v105.0.0+up5.0.1 |
 | v2.10.5         | v105.0.0+up5.0.1 |
 | v2.10.4         | v105.0.0+up5.0.1 |
@@ -23,7 +23,7 @@ Users can leverage continuous delivery to deploy their applications to the Kuber

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

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

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

@@ -55,6 +55,37 @@ For help with configuring `Flows` and `ClusterFlows`, see [this page.](custom-re

 For help with configuring `Outputs` and `ClusterOutputs`, see [this page.](custom-resource-configuration/outputs-and-clusteroutputs.md)

+## Using a custom HostTailer image
+
+To use a custom image for the `HostTailer` resource, you need to specify the image in the `containerOverrides` section of each `fileTailer` of the `HostTailer` resource.
+
+```yaml
+apiVersion: logging-extensions.banzaicloud.io/v1alpha1
+kind: HostTailer
+metadata:
+  name: cluster-system-log
+spec:
+  workloadMetaOverrides:
+    annotations: {}
+    labels: {}
+  fileTailers:
+    - disabled: false
+      name: kubelet-log
+      path: /var/lib/rancher/rke2/agent/logs/*.log
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+    - disabled: false
+      name: containerd-log
+      path: /var/lib/rancher/rke2/agent/containerd/*.log
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+    - name: kube-audit
+      path: /var/log/kube-audit/audit-log.json
+      disabled: false
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+```
+
 ## Configuring the Logging Helm Chart

 For a list of options that can be configured when the logging application is installed or upgraded, see [this page.](logging-helm-chart-options.md)
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.10.7         |     v0.6.8      | &check;               | &cross;                   |
 | v2.10.6         |     v0.6.7      | &check;               | &cross;                   |
 | v2.10.5         |     v0.6.6      | &check;               | &cross;                   |
 | v2.10.4         |     v0.6.5      | &check;               | &cross;                   |
@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api" />
+<ApiDocMdx id="rancher-api-v2-11" />
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
+| [2.11.3](https://github.com/rancher/rancher/releases/tag/v2.11.3) | June 25, 2025 |
 | [2.11.2](https://github.com/rancher/rancher/releases/tag/v2.11.2) | May 22, 2025 |
 | [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | Apr 24, 2025 |
 | [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | Mar 31, 2025 |
@@ -212,10 +212,11 @@ If you are using a Private CA signed certificate (or if `agent-tls-mode` is set

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

-### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

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

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
@@ -223,6 +224,22 @@ ingress:
    use-forwarded-headers: 'true'
 ```

+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
 ### Required Headers

 - `Host`
@@ -7,7 +7,7 @@ title: ClusterRole Aggregation
 </head>

 :::caution
-ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11. It is expected to be available as a beta for users in v2.12 with a prospective GA in Rancher v2.13.
+ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11 and v2.12. It is expected to be available as a beta for users in v2.13.
 :::

 ClusterRole aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
@@ -100,6 +100,12 @@ For details on which Kubernetes resources correspond to each global permission,

 :::

+:::danger
+
+The built-in GlobalRole `Manage Users` allows users to create, modify and delete other users within the Rancher environment. While this permission may be necessary for administrative workflows in trusted environments, granting it to non-trusted or lower-privileged users, such as standard users, poses a serious security risk and may result in privilege escalation.
+
+:::
+
 ### Custom GlobalRoles

 You can create custom GlobalRoles to satisfy use cases not directly addressed by built-in GlobalRoles. 
@@ -120,6 +120,7 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
 - `cert-manager`
 - `cis-operator-system`
 - `fleet-default`
+- `fleet-local`
 - `ingress-nginx`
 - `istio-system`
 - `kube-node-lease`
@@ -42,26 +42,6 @@ To display prerelease versions:
 1. Click **Preferences**.
 1. Under **Helm Charts**, select **Include Prerelease Versions**.

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

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

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

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

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

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

  For example, suppose you install `cert-manager` v1.13.0 from repository A, where v1.14.0 is now the most recent version available. In this case, you expect **Upgradable** to display v1.14.0. However, if the cluster also has access to repository B where v1.15.0 of `cert-manager` is available, then **Upgradable** displays v1.15.0 even though the original installation used repository A.
-  
+
@@ -18,7 +18,7 @@ Listed below are the primary RKE2 features for Windows cluster provisioning:

 - Windows Containers with RKE2 powered by containerd
 - Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
- Calico CNI for Windows RKE2 custom clusters
+- Calico and Flannel CNI for Windows RKE2 custom clusters
 - SAC releases of Windows Server (2004 and 20H2) are included in the technical preview

 :::note
@@ -57,7 +57,7 @@ Rancher will not provision the node if the node does not meet these requirements

 Before provisioning a new cluster, be sure that you have already installed Rancher on a device that accepts inbound network traffic. This is required in order for the cluster nodes to communicate with Rancher. If you have not already installed Rancher, please refer to the [installation documentation](../../../../getting-started/installation-and-upgrade/installation-and-upgrade.md) before proceeding with this guide.

-Rancher supports Windows using Calico as the network provider.
+Rancher supports Windows using Calico and Flannel as network providers.

 If you are configuring DHCP options sets for an AWS virtual private cloud, note that in the `domain-name` option field, only one domain name can be specified. According to the DHCP options [documentation:](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)

@@ -163,7 +163,7 @@ The instructions for creating a Windows cluster on existing nodes are very simil
 1. Click **Custom**.
 1. Enter a name for your cluster in the **Cluster Name** field.
 1. In the **Kubernetes Version** dropdown menu, select a supported Kubernetes version.
-1. In the **Container Network** field, select **Calico**.
+1. In the **Container Network** field, select either **Calico** or **Flannel**.
 1. Click **Next**.

 ### 3. Add Nodes to the Cluster
@@ -65,7 +65,7 @@ RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.
 Windows features for RKE2 include:

 - Windows supports the vSphere node driver
- Calico CNI for Windows RKE2 custom clusters
+- Calico and Flannel CNI for Windows RKE2 custom clusters
 - Project Network Isolation (PNI) for Calico
 - Windows Containers with RKE2 powered by containerd
 - Provisioning of Windows RKE2 clusters through Terraform
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
+| v2.11.3         | v106.0.0+up6.0.0 |
 | v2.11.2         | v106.0.0+up6.0.0 |
 | v2.11.1         | v106.0.0+up6.0.0 |
 | v2.11.0         | v106.0.0+up6.0.0 |
@@ -26,7 +26,7 @@ Users can leverage continuous delivery to deploy their applications to the Kuber

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

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

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

@@ -55,6 +55,37 @@ For help with configuring `Flows` and `ClusterFlows`, see [this page.](custom-re

 For help with configuring `Outputs` and `ClusterOutputs`, see [this page.](custom-resource-configuration/outputs-and-clusteroutputs.md)

+## Using a custom HostTailer image
+
+To use a custom image for the `HostTailer` resource, you need to specify the image in the `containerOverrides` section of each `fileTailer` of the `HostTailer` resource.
+
+```yaml
+apiVersion: logging-extensions.banzaicloud.io/v1alpha1
+kind: HostTailer
+metadata:
+  name: cluster-system-log
+spec:
+  workloadMetaOverrides:
+    annotations: {}
+    labels: {}
+  fileTailers:
+    - disabled: false
+      name: kubelet-log
+      path: /var/lib/rancher/rke2/agent/logs/*.log
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+    - disabled: false
+      name: containerd-log
+      path: /var/lib/rancher/rke2/agent/containerd/*.log
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+    - name: kube-audit
+      path: /var/log/kube-audit/audit-log.json
+      disabled: false
+      containerOverrides:
+        image: <your_registry>/<your_image>:<your_tag>
+```
+
 ## Configuring the Logging Helm Chart

 For a list of options that can be configured when the logging application is installed or upgraded, see [this page.](logging-helm-chart-options.md)
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.11.3         |     v0.7.3      | &check;               | &check;                   |
 | v2.11.2         |     v0.7.2      | &check;               | &check;                   |
 | v2.11.1         |     v0.7.1      | &check;               | &check;                   |
 | v2.11.0         |     v0.7.0      | &cross;               | &check;                   |
@@ -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-v2-11" />
@@ -1,11 +1,13 @@
 ---
-title: API Tokens
+title: Using API Tokens
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-tokens"/>
+  <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.
@@ -24,18 +26,15 @@ The following is a complete list of tokens generated with `ttl=0`:

 | Token             | Description                                                                            |
 | ----------------- | -------------------------------------------------------------------------------------- |
-| `kubeconfig-*`    | Kubeconfig token                                                                       |
 | `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                                                        |
-| `telemetry-*`     | Telemetry token                                                                        |
-| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API) |
+| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API). |

+## Setting TTL on Kubeconfig Tokens

-### 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. The default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is `0`, which means that tokens never expire.
+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

@@ -45,15 +44,11 @@ This setting is used by all kubeconfig tokens except those created by the CLI to

 ## Disable Tokens in Generated Kubeconfigs

-1. 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](../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.
-
-2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is `960` (16 hours).
+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

-Users can enable token hashing, where tokens undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process: once enabled, this feature cannot be disabled. It is advisable to take backups prior to enabling and/or evaluating in a test environment first.
-
-To enable token hashing, refer to [this section](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md).
+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:

@@ -68,9 +63,8 @@ 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 those [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). **Introduced in version 2.6.6.**                                                   |
-| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes)                 | TTL used for tokens generated via the CLI.  **Deprecated since version 2.6.6, and removed in 2.8.0.** Rancher v2.8 and later instead use `kubeconfig-default-token-ttl-minutes` for all kubeconfig tokens. |
-| [`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). May override `kubeconfig-default-token-ttl-minutes`.                                                                                                          |
+| [`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
@@ -79,19 +73,12 @@ Time to live (TTL) duration in minutes, used to determine when a user auth sessi

 ### 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). The default value is `0`, which means that tokens never expire.
-**Introduced in version 2.6.6**.
-
-### kubeconfig-token-ttl-minutes
-
-Time to live (TTL) duration in minutes used to determine when a kubeconfig token that was generated by the CLI expires. Tokens are generated by the CLI when [`kubeconfig-generate-token`](#kubeconfig-generate-token) is false. 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).
-**Deprecated since Rancher v2.6.6.**
+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. The default value is `0`, which means that tokens never expire.
-**Rancher v2.6.5 and earlier: Applies only to tokens created for authenticating API requests.**
+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](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
+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.
@@ -0,0 +1,25 @@
+---
+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.2](https://github.com/rancher/rancher/releases/tag/v2.11.2) | May 22, 2025 |
+| [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | Apr 24, 2025 |
+| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | Mar 31, 2025 |
+
+## 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.
@@ -24,7 +24,7 @@ Yes. Rancher supports [Istio](../integrations-in-rancher/istio/istio.md).

 ## Will Rancher v2.x support Hashicorp's Vault for storing secrets?

-Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
+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?

@@ -31,7 +31,7 @@ The previously recommended [System Tools](../reference-guides/system-tools.md) h

 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.

-As of Rancher v2.5.8, uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:
+Uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:

 - fleet
 - fleet-agent
@@ -1,6 +1,5 @@
 ---
 title: Security FAQ
-
 ---

 <head>
@@ -44,6 +44,7 @@ $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig
 New password for default administrator (user-xxxxx):
 <new_password>
 ```
+
 ## How can I enable debug logging?

 See [Troubleshooting: Logging](../troubleshooting/other-troubleshooting-tips/logging.md)
@@ -90,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?

@@ -40,7 +40,7 @@ helm upgrade rancher ./rancher-<VERSION>.tgz \

 #### 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:
+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 . \
@@ -107,15 +107,15 @@ The Rancher management server is designed to be secure by default and requires S

 :::note

-If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../installation-references/helm-chart-options.md#external-tls-termination).
+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                 |
@@ -242,6 +242,12 @@ In the following command,
 - Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
 - For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.

+:::warning
+
+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 \
@@ -190,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).
+
@@ -12,6 +12,7 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa

 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
@@ -30,10 +31,10 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 ### Helm Version

-<DeprecationHelm2 />
-
 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-gapped installs: Populate private registry
@@ -56,7 +57,7 @@ You'll use the backup as a restore point if something goes wrong during upgrade.

 ### 2. Update the Helm chart repository

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

    ```
    helm repo update
@@ -132,6 +133,7 @@ There will be more values that are listed with this command. This is just an exa
 :::

 :::tip 
+
 Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
 Thus: 
 ```
@@ -139,6 +141,7 @@ 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.
@@ -164,6 +167,7 @@ The above is an example, there may be more values from the previous step that ne
 :::

 :::tip 
+
 If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
 Thus: 
 ```
@@ -171,6 +175,7 @@ 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:
@@ -18,8 +18,6 @@ In this section,
 - **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.

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

 Rancher can be installed on these main architectures:
@@ -18,27 +18,40 @@ 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](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.
- `external-rules`: This flag is disabled by default. Only admin users can enable/disable the flag, and note that `escalate` permissions on `RoleTemplates` are required to create external `RoleTemplates` with `ExternalRules`. Restricted admin users can only enable the flag. If enabled, external `RoleTemplates` can be created only if the backing `ClusterRole` exists in the local cluster or the `ExternalRules` is set. For context, the backing `ClusterRole` holds cluster rules and privileges, and shares the same `metadata.name` used in the `RoleTemplate` in your respective cluster referenced by the `ClusterRoleTemplateBinding/ProjectRoleTemplateBinding`. Previous external `RoleTemplates` that don’t have a backing `ClusterRole` won’t be granted or modifiable unless a backing `ClusterRole` is created or the `ExternalRules` field is set. If disabled, external `RoleTemplates` with `.context=project` or `.context=””` can be created even if the backing `ClusterRole` does not exist.
- `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-gitops-at-scale/fleet-gitops-at-scale.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](../../../integrations-in-rancher/harvester.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](../../../reference-guides/about-the-api/api-tokens.md#token-hashing) for more information.
+- `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 |
-| ----------------------------- | ------------- | ------------ | --------------- |
-| `continuous-delivery` | `true` | GA | v2.6.0 |
-| `fleet`  | `true` | Can no longer be disabled | v2.6.0 |
-| `fleet`  | `true` | GA | v2.5.0 |
-| `harvester` | `true` | Experimental | v2.6.1 |
-| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.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 |
+| 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 | |
@@ -31,7 +31,8 @@ For information on enabling experimental features, refer to [this page.](../../.
 | 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`)                                           |
@@ -58,7 +59,6 @@ For information on enabling experimental features, refer to [this page.](../../.
 | `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
 | `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` | `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/new-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 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.  |
@@ -206,16 +206,17 @@ You may terminate the SSL/TLS on a L7 load balancer external to the Rancher clus

 :::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.
+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.

-### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

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

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
@@ -223,6 +224,22 @@ ingress:
    use-forwarded-headers: 'true'
 ```

+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
 ### Required Headers

 - `Host`
@@ -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
+```
@@ -18,7 +18,7 @@ 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-7-9/) 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:

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

 To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](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).
@@ -196,7 +196,7 @@ If security isn't a large concern and you're okay with opening a few additional

 ### Ports for Harvester Clusters

-Refer [here](../../../integrations-in-rancher/harvester.md#port-requirements) for more information on Harvester port requirements.
+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
@@ -142,10 +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.
-
-:::
-
@@ -8,7 +8,7 @@ title: 4. Install Rancher

 This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.

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

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

@@ -92,7 +92,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher

 :::

-##### 1. Add the cert-manager repo
+##### 1. Add the cert-manager Repo

 From a system connected to the internet, add the cert-manager repo to Helm:

@@ -101,7 +101,7 @@ helm repo add jetstack https://charts.jetstack.io
 helm repo update
 ```

-##### 2. Fetch the cert-manager chart
+##### 2. Fetch the cert-manager Chart

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

@@ -109,7 +109,7 @@ Fetch the latest cert-manager chart available from the [Helm chart repository](h
 helm fetch jetstack/cert-manager --version v1.11.0
 ```

-##### 3. Retrieve the Cert-Manager CRDs
+##### 3. Retrieve the cert-manager CRDs

 Download the required CRD file for cert-manager:
   ```plain
@@ -120,7 +120,7 @@ Download the required CRD file for cert-manager:

 Copy the fetched charts to a system that has access to the Rancher server cluster to complete installation.

-##### 1. Install Cert-Manager
+#### 1. Install cert-manager

 Install cert-manager with the same options you would use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry.

@@ -160,7 +160,8 @@ If you are using self-signed certificates, install cert-manager:

 </details>

-##### 2. Install Rancher
+#### 2. Install Rancher
+
 First, refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.

 Then, create the namespace for Rancher using kubectl:
@@ -194,7 +195,7 @@ Placeholder | Description

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

-##### 1. Create secrets
+##### 1. Create Secrets

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

@@ -233,18 +234,13 @@ 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

 These resources could be helpful when installing Rancher:

+- [Importing and installing extensions in an air-gapped environment](../../../../integrations-in-rancher/rancher-extensions.md#importing-and-installing-extensions-in-an-air-gapped-environment)
 - [Rancher Helm chart options](../../installation-references/helm-chart-options.md)
 - [Adding TLS secrets](../../resources/add-tls-secrets.md)
 - [Troubleshooting Rancher Kubernetes Installations](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
@@ -95,12 +95,6 @@ kubectl rollout status deployment -n cattle-system rancher

 You can now navigate to `https://rancher.example.com` and start using Rancher.

-:::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

 These resources could be helpful when installing Rancher:
@@ -6,10 +6,10 @@ title: Upgrading Rancher Installed with Docker
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher"/>
 </head>

-The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
-
 <DockerSupportWarning />

+The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
+
 ## Prerequisites

 - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues)** section in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete 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). Note that upgrades to or from any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren’t supported.
@@ -46,4 +46,4 @@ The configured `tls-ca` secret is retrieved when Rancher starts. On a running Ra

 ## Updating a Private CA Certificate

-Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
+Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -65,4 +65,4 @@ docker logs container-id  2>&1 | grep "Bootstrap Password:"
 ```

 </TabItem>
-</Tabs>
+</Tabs>
@@ -39,7 +39,7 @@ All charts in the `rancher-stable` repository will correspond with any Rancher v

 ### Helm Chart Versions

-Rancher Helm chart versions match the Rancher version (i.e `appVersion`).  Once you've added the repo you can search it to show available versions with the following command:<br/>
+Rancher Helm chart versions match the Rancher version (i.e `appVersion`). Once you've added the repo you can search it to show available versions with the following command:
 &nbsp;&nbsp;&nbsp;&nbsp;`helm search repo --versions`

 If you have several repos you can specify the repo name, ie. `helm search repo rancher-stable/rancher --versions` <br/>
@@ -180,7 +180,7 @@ Repeat the below steps for each downstream cluster:

 ### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher

-Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
+Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet/overview.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

 #### Why is this step required?

@@ -260,7 +260,7 @@ As a private CA is no longer being used, the `CATTLE_CA_CHECKSUM` environment va

 ### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher

-Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
+Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet/overview.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.

 #### Why is this step required?

@@ -89,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.
@@ -42,7 +42,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 - **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) on existing nodes, or perform [Kubernetes upgrades.](installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
 - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) that make it easy to repeatedly deploy applications.
 - **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration](../how-to-guides/advanced-user-guides/manage-projects/manage-projects.md) and for [managing applications within projects.](../how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-resources-setup.md)
- **Fleet Continuous Delivery:** Within Rancher, you can leverage [Fleet Continuous Delivery](../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md) to deploy applications from git repositories, without any manual operation, to targeted downstream Kubernetes clusters.
+- **Fleet Continuous Delivery:** Within Rancher, you can leverage [Fleet Continuous Delivery](../integrations-in-rancher/fleet/fleet.md) to deploy applications from git repositories, without any manual operation, to targeted downstream Kubernetes clusters.
 - **Istio:** Our [integration with Istio](../integrations-in-rancher/istio/istio.md) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.

 ### Working with Cloud Infrastructure
@@ -8,3 +8,4 @@ description: Deploy SUSE Rancher from the AWS Marketplace listing.
 </head>

 You can quickly deploy Rancher Prime on Amazon Elastic Kubernetes Service (EKS.) To learn more, see the [instructions](https://suse-enceladus.github.io/marketplace-docs/rancher-prime/aws/?repository=rancher-payg-billing-adapter-llc-prd) under Usage Information in the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c). 
+
@@ -44,6 +44,7 @@ Deploying to Microsoft Azure will incur charges.
    - `azure_client_secret` - Microsoft Azure Client Secret
    - `azure_tenant_id` - Microsoft Azure Tenant ID
    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
+
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
   - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
@@ -37,18 +37,18 @@ Deploying to Linode will incur charges.
 3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.

 4. Edit `terraform.tfvars` and customize the following variables:
-  - `linode_token` - The Linode Personal Access Token mentioned above.
+    - `linode_token` - The Linode Personal Access Token mentioned above.
    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
-    
+
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
-   See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
-  - `linode_region` - The target Linode region to provision the server and cluster in.
-    - Default: `eu-central`
-    - For a complete list of regions, see the [official Region Availability page](https://www.linode.com/global-infrastructure/availability/).
-  - `prefix` - The prefix for all created infrastructure.
-  - `linode_type` - The type/plan that all infrastructure Linodes should use.
-    - Default: `g6-standard-2`
-    - For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
+   - `linode_region` - The target Linode region to provision the server and cluster in.
+     - Default: `eu-central`
+     - For a complete list of regions, see the [official Region Availability page](https://www.linode.com/global-infrastructure/availability/).
+   - `prefix` - The prefix for all created infrastructure.
+   - `linode_type` - The type/plan that all infrastructure Linodes should use.
+     - Default: `g6-standard-2` 
+     - For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).

 6. Run `terraform init`.

@@ -40,7 +40,7 @@ Deploying to Outscale will incur charges.
    - `access_key_id` - Outscale access key
    - `secret_key_id` - Outscale secret key
    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirements.
-    
+
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) for more information.
 Suggestions include:
--- a/Show More
+++ b/Show More