Merge pull request #1410 from LucasSaintarbor/2.7.15-deprecated-features

Update Deprecated Features Table - v2.7.15

.github/pull_request_template.md

@@ -10,7 +10,7 @@ Fixes #[issue_number]
 
 - Verify if changes pertain to other versions of Rancher. If they do, finalize the edits on one version of the page, then apply the edits to the other versions.
 
-- If the pull request is dependent on an upcoming release, make sure to target the release branch instead of `main`.
+- If the pull request is dependent on an upcoming release, remember to add a "MERGE ON RELEASE" label and set the proper milestone.
 
 ## Description
 
@@ -24,4 +24,4 @@ Fixes #[issue_number]
 
 <!--
 Any additional notes a reviewer should know before we review.
--->
+-->

.github/workflows/deploy.yml

@@ -6,14 +6,14 @@ on:
       - main
 
 jobs:
-  deploy:
-    name: Deploy to GitHub Pages
+  build:
+    name: Build Docusaurus
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           fetch-depth: 0
-      - uses: actions/setup-node@v3
+      - uses: actions/setup-node@v4
         with:
           node-version: 18
           cache: yarn
@@ -22,21 +22,28 @@ jobs:
         run: yarn install --frozen-lockfile
       - name: Build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=6144"
+          NODE_OPTIONS: "--max_old_space_size=7168"
         run: yarn build --no-minify
 
-      # Popular action to deploy to GitHub Pages:
-      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
-      - name: Deploy to GitHub Pages
-        uses: peaceiris/actions-gh-pages@v3
+      - name: Upload Build Artifact
+        uses: actions/upload-pages-artifact@v3
         with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          # Build output to publish to the `gh-pages` branch:
-          publish_dir: ./build
-          # The following lines assign commit authorship to the official
-          # GH-Actions bot for deploys to `gh-pages` branch:
-          # https://github.com/actions/checkout/issues/13#issuecomment-724415212
-          # The GH actions bot is used by default if you didn't specify the two fields.
-          # You can swap them out with your own user credentials.
-          user_name: github-actions[bot]
-          user_email: 41898282+github-actions[bot]@users.noreply.github.com
+          path: build
+
+  deploy:
+    name: Deploy to GitHub Pages
+    needs: build
+
+    permissions:
+      pages: write
+      id-token: write
+    
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.github/workflows/test-deploy.yml

@@ -10,8 +10,10 @@ jobs:
     name: Test deployment
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
-      - uses: actions/setup-node@v3
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
         with:
           node-version: 18
           cache: yarn
@@ -24,5 +26,5 @@ jobs:
         run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
       - name: Test build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=6144"
+          NODE_OPTIONS: "--max_old_space_size=7168"
         run: yarn build --no-minify

.github/workflows/vale.yml

@@ -0,0 +1,58 @@
+# This action gets all changed markdown files in /docs and /versioned_docs using tj-actions/changed-files@v42
+# It compares new commits in the PR with the base commit (github.event.pull_request.base.sha)
+# It checks if no markdown files are changed 
+# It shows a count of markdown files and lists all changed markdown files
+# It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
+
+name: Style check
+on: [pull_request]
+
+jobs:
+  vale-lint:
+    name: runner / vale
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        continue-on-error: true
+        with:
+          fetch-depth: 0  # OR "2" -> To retrieve the preceding commit.
+          submodules: true
+      - name: Get all changed markdown files
+        continue-on-error: true
+        id: changed-markdown-files
+        uses: tj-actions/changed-files@v42
+        with:
+            # Avoid using single or double quotes for multiline patterns
+            files: |
+               docs/**
+               versioned_docs/**
+            separator: ","
+            base_sha: ${{ github.event.pull_request.base.sha }}
+        env:
+            ALL_CHANGED_FILES: ${{ 0 }}
+      - name: No files changed?
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'false'
+        run: |
+              echo "No files changed"
+              echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
+      - name: List all changed files markdown files
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'true'
+        env:
+            ALL_CHANGED_FILES: ${{ steps.changed-markdown-files.outputs.all_changed_files }}
+            ALL_CHANGED_FILES_COUNT: ${{ steps.changed-markdown-files.outputs.all_changed_files_count }}
+            SHA: ${{ github.head_ref }}
+            HEAD: ${{ github.base_ref }}
+        run: |
+            echo "Total Files Changed:" ${ALL_CHANGED_FILES_COUNT}
+            echo ${ALL_CHANGED_FILES}
+            echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
+      - uses: errata-ai/vale-action@v2.1.0
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          separator: ", "
+          files: ${{ env.ALL_CHANGED_FILES }}

.gitmodules

@@ -0,0 +1,3 @@
+[submodule ".github/styles/suse-vale-styleguide"]
+	path = .github/styles/suse-vale-styleguide
+	url = https://github.com/openSUSE/suse-vale-styleguide

.vale.ini

@@ -0,0 +1,7 @@
+StylesPath = .github/styles
+
+[formtats]
+mdx = md
+
+[*.md]
+BasedOnStyles = suse-vale-styleguide

CODEOWNERS

@@ -0,0 +1 @@
+* @btat @LucasSaintarbor @martyav @sunilarjun

README.md

@@ -23,11 +23,21 @@ If a file is moved or renamed, you'll also need to edit the `sidebars.js` files
 
 ### Navigate the Repo
 
-The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. Most index pages are found within the `/pages-for-subheaders` directory in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
+The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
 
 ### Style & Formatting
 
-The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We refer to the Microsoft [style guide](https://learn.microsoft.com/en-us/style-guide/welcome/) and use standard American English. Many pages are also available in Simplified Chinese.
+The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We use standard American English and many pages are also available in Simplified Chinese.
+
+Moving forward, we are referring to the SUSE [style guide](https://documentation.suse.com/style/current/pdf/style-guide_en.pdf). The **Style check / runner / vale (pull_request)** check used [Vale](https://vale.sh/) to make style and grammar suggestions for new or updated documentation based on the SUSE style guide. To review these suggestions when working on a PR:
+
+1. Select the details of the **Style check / runner / vale (pull_request)** check.
+1. In the logs, go to **Run errata-ai/vale-action@v2.1.0** and select **Running vale with reviewdog 🐶 ...** to view the suggestions.
+1. New or updated files are checked against the SUSE style guide. Suggestions have the following format: '{"message": "[suse-vale-styleguide.Rule] Rule description", "location": {"path": "file-path", "range": {"start": {"line": , "column": }}}, "severity": " "}'
+
+    For example: '{"message": "[suse-vale-styleguide.Usage] Use 'certain' instead of 'some'", "location": {"path": "docs/contribute-to-rancher.md", "range": {"start": {"line": 3, "column": 132}}}, "severity": "WARNING"}'
+
+1. Incorporate the suggestions when possible and appropriate.
 
 Every docs page contain metadata in the first few lines:
 

dev-resources/algolia-search/config.json

@@ -8,7 +8,8 @@
     "lvl2": "article h2",
     "lvl3": "article h3",
     "lvl4": "article h4",
-    "lvl5": "article h5"
+    "lvl5": "article h5",
+    "lvl6": "article h6"
   },
   "custom_settings": {
     "attributesForFaceting": [

docs/api/api-reference.mdx

@@ -2,6 +2,10 @@
 title: API Reference
 ---
 
+<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.

docs/api/api-tokens.md

@@ -0,0 +1,85 @@
+---
+title: Using API Tokens
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
+</head>
+
+Rancher v2.8.0 introduced the [Rancher Kubernetes API](./api-reference.mdx) which can be used to manage Rancher resources through `kubectl`. This page covers information on API tokens used with the [Rancher CLI](../reference-guides/cli-with-rancher), [kubeconfig files](../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md#about-the-kubeconfig-file), Terraform and the [v3 API browser](./v3-rancher-api-guide.md#enable-view-in-api).
+
+By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
+
+You can deactivate API tokens by deleting them or by deactivating the user account.
+
+## Deleting Tokens
+
+To delete a token:
+
+1. Go to the list of all tokens in the Rancher API view at `https://<Rancher-Server-IP>/v3/tokens`.
+
+1. Access the token you want to delete by its ID. For example, `https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`
+
+1. Click **Delete**.
+
+The following is a complete list of tokens generated with `ttl=0`:
+
+| Token             | Description                                                                            |
+| ----------------- | -------------------------------------------------------------------------------------- |
+| `kubectl-shell-*` | Access to `kubectl` shell in the browser                                               |
+| `agent-*`         | Token for agent deployment                                                             |
+| `compose-token-*` | Token for compose                                                                      |
+| `helm-token-*`    | Token for Helm chart deployment                                                        |
+| `telemetry-*`     | Telemetry token                                                                        |
+| `drain-node-*`    | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API). |
+
+## Setting TTL on Kubeconfig Tokens
+
+Admins can set a global time-to-live (TTL) on Kubeconfig tokens. Changing the default kubeconfig TTL can be done by navigating to global settings and setting [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) to the desired duration in minutes. As of Rancher v2.8, the default value of [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) is `43200`, which means that tokens expire in 30 days.
+
+:::note
+
+This setting is used by all kubeconfig tokens except those created by the CLI to [generate kubeconfig tokens](#disable-tokens-in-generated-kubeconfigs).
+
+:::
+
+## Disable Tokens in Generated Kubeconfigs
+
+Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. When this setting is deactivated, a generated kubeconfig references the [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.
+
+## Token Hashing
+
+You can [enable token hashing](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md), where tokens undergo a one-way hash using the SHA256 algorithm. This is a non-reversible process: once enabled, this feature cannot be disabled. You should first evaluate this setting in a test environment, and/or take backups before enabling.
+
+This feature affects all tokens which include, but are not limited to, the following:
+
+- Kubeconfig tokens
+- Bearer tokens API keys/calls
+- Tokens used by internal operations
+
+## Token Settings
+
+These global settings affect Rancher token behavior.
+
+| Setting                                                                         | Description                                                                                                                                                                                                                    |
+| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).                                                 |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |
+
+### auth-user-session-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
+
+### kubeconfig-default-token-ttl-minutes
+
+Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). As of Rancher v2.8, the default duration is `43200`, which means that tokens expire in 30 days.
+
+### auth-token-max-ttl-minutes
+
+Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempts to create a token with a TTL greater than `auth-token-max-ttl-minutes`, Rancher sets the token TTL to the value of `auth-token-max-ttl-minutes`. Applies to all kubeconfig tokens and API tokens. As of Rancher v2.8, the default duration is `129600`, which means that tokens expire in 90 days.
+
+### kubeconfig-generate-token
+
+When true, kubeconfigs requested through the UI contain a valid token. When false, kubeconfigs contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then retrieves and caches a token for the user](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).

docs/api/quickstart.md

@@ -1,12 +1,12 @@
 ---
-title: API Quick Start Guide
+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 will help you get started on using this API as a Rancher user.
+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.
@@ -129,7 +129,7 @@ To ensure that your tools can recognize Rancher's CA certificates, most setups r
   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 will convert `rancher.crt` to base64 output, trim all new-lines, and update the cluster in the kubeconfig with the certificate, then finishing by removing the `rancher.crt` file:
+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

docs/api/v3-rancher-api-guide.md

@@ -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](./v3-rancher-api-guide.md#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.

docs/api/workflows/projects.md

@@ -29,6 +29,26 @@ Use `metadata.generateName` to ensure a unique project ID, but note that `kubect
 
 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.
+
 ### Creating a Project With a Resource Quota
 
 Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
@@ -111,3 +131,5 @@ 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. 

docs/cluster-provisioning/rke-clusters/options/options.md

@@ -1,9 +0,0 @@
----
-title: RKE Cluster Configuration
----
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
-</head>
-
-This page has moved [here.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)

docs/faq/container-network-interface-providers.md

@@ -86,6 +86,8 @@ For more information, see the [Flannel GitHub Page](https://github.com/flannel-i
 
 #### Weave
 
+<DeprecationWeave />
+
 ![Weave Logo](/img/weave-logo.png)
 
 Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
@@ -94,7 +96,7 @@ Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` a
 
 For more information, see the following pages:
 
-- [Weave Net Official Site](https://www.weave.works/)
+- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
 
 ### RKE2 Kubernetes clusters
 
@@ -184,8 +186,6 @@ The following table summarizes the different features available for each CNI net
 
 ## CNI Community Popularity
 
-import CNIPopularityTable from '/shared-files/_cni-popularity.md';
-
 <CNIPopularityTable />
 
 ## Which CNI Provider Should I Use?

docs/faq/deprecated-features.md

@@ -3,10 +3,10 @@ title: Deprecated Features in Rancher
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features-in-v2.5"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>
 
-### What is Rancher's Deprecation policy?
+### 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).
 
@@ -16,14 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
 
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) |  Aug 31, 2021  |
-| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) |  Oct 11, 2021  |
-| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) |  Oct 19, 2021  |
-| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) |  Dec 21, 2021  |
-| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |  Mar 31, 2022  |
-| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) |  May 12, 2022  |
-| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) |  Jun 30, 2022  |
-
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
 
 ### What can I expect when a feature is marked for deprecation?
 

docs/faq/dockershim.md

@@ -1,5 +1,5 @@
 ---
-title: Dockershim
+title: Dockershim FAQ
 ---
 
 <head>

docs/faq/general-faq.md

@@ -10,10 +10,6 @@ This FAQ is a work in progress designed to answer the questions most frequently
 
 See the [Technical FAQ](technical-items.md) for frequently asked technical questions.
 
-## Does Rancher v2.x support Docker Swarm and Mesos as environment types?
-
-Swarm and Mesos are no longer selectable options when you create a new environment in Rancher v2.x. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 were running Swarm.
-
 ## Is it possible to manage Azure Kubernetes Services with Rancher v2.x?
 
 Yes. See our [Cluster Administration](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md) guide for what Rancher features are available on AKS, as well as our [documentation on AKS](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md).

docs/faq/security.md

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

docs/faq/technical-items.md

@@ -1,5 +1,5 @@
 ---
-title: Technical
+title: Technical FAQ
 ---
 
 <head>

docs/faq/telemetry.md

@@ -1,5 +1,5 @@
 ---
-title: Telemetry
+title: Telemetry FAQ
 ---
 
 <head>

docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md

@@ -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                 |
@@ -160,7 +160,8 @@ helm repo update
 # Install the cert-manager Helm chart
 helm install cert-manager jetstack/cert-manager \
   --namespace cert-manager \
-  --create-namespace
+  --create-namespace \
+  --set installCRDs=true
 ```
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -241,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 \

docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md

@@ -78,7 +78,7 @@ A restore is performed by creating a Restore custom resource.
 1. In the left navigation bar, click **Rancher Backups > Restore**.
     :::note
 
-    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
+    If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.
 
     :::
 

docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/troubleshooting.md

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

docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md

@@ -28,10 +28,13 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
 Review the list of known issues for each Rancher version, which 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.
+
 ### Helm Version
 
 The upgrade instructions assume you are using Helm 3.
 
+<DeprecationHelm2 />
+
 For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
 
 ### For air-gapped installs: Populate private registry

docs/getting-started/installation-and-upgrade/installation-references/feature-flags.md

@@ -19,25 +19,31 @@ Some feature flags require a restart of the Rancher container. Features that req
 The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
 
 - `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
-- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.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.
 - `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.
 - `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 |
+| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
+| `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 | |
+| `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 | |
+| `uiextension` | `true` | GA | v2.9.0 |
+| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 |

docs/getting-started/installation-and-upgrade/installation-references/helm-chart-options.md

@@ -17,7 +17,7 @@ For information on enabling experimental features, refer to [this page.](../../.
 
 | Option                    | Default Value | Description                                                                        |
 | ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
-| `bootstrapPassword`       | " "           | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin will need to reset their password. A randomly generated bootstrap password is used if this value is not set.
+| `bootstrapPassword`       | " "           | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin should reset their password. A randomly generated bootstrap password is used if this value is not set.
 | `hostname`                | " "           | `string` - the Fully Qualified Domain Name for your Rancher Server                 |
 | `ingress.tls.source`      | "rancher"     | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
 | `letsEncrypt.email`       | " "           | `string` - Your email address                                                      |
@@ -32,6 +32,7 @@ For information on enabling experimental features, refer to [this page.](../../.
 | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
 | `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`)                                           |
@@ -67,19 +68,9 @@ For information on enabling experimental features, refer to [this page.](../../.
 
 ### Bootstrap Password
 
-When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
+You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.
 
-If you want to use a specific bootstrap password instead of a randomly generated one, provide the password.
-
-```plain
---set bootstrapPassword="rancher"
-```
-
-The password, whether provided or generated, will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
-
-```
-kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
-```
+When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.
 
 ### API Audit Log
 
@@ -163,7 +154,7 @@ Rancher supports CIDR notation ranges in this list.
 
 When not including sensitive data, the `proxy` or `extraEnv` chart options can be used. When using `extraEnv` the `noProxy` Helm option is ignored. Therefore, the `NO_PROXY` environment variable must also be set with `extraEnv`.
 
-The following is an example of setting proxy using the `extraEnv` chart option:
+The following is an example of setting proxy using the `proxy` chart option:
 
 ```plain
 --set proxy="http://<proxy_url:proxy_port>/"
@@ -216,7 +207,7 @@ 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. 
 
 :::
 

docs/getting-started/installation-and-upgrade/installation-references/tls-settings.md

@@ -23,3 +23,82 @@ The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites.
 |-----|-----|-----|-----|
 | `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
+```

docs/getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md

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

docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher.md

@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu
 
 ### Install the Helm CLI
 
+<DeprecationHelm2 />
+
 Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
 
 ```

docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md

@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
 </head>
 
-### How Do I Know if My Certificates are in PEM Format?
+<DockerSupportWarning />
+
+## How Do I Know if My Certificates are in PEM Format?
 
 You can recognize the PEM format by the following traits:
 
@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
 -----END PRIVATE KEY-----
 ```
 
-### Converting a Certificate Key From PKCS8 to PKCS1
+## Converting a Certificate Key From PKCS8 to PKCS1
 
 If you are using a PKCS8 certificate key file, Rancher will log the following line:
 
@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem
 
 You can now use `convertedkey.pem` as certificate key file for Rancher.
 
-### What is the Order of Certificates if I Want to Add My Intermediate(s)?
+## What is the Order of Certificates if I Want to Add My Intermediate(s)?
 
 The order of adding certificates is as follows:
 
@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
 -----END CERTIFICATE-----
 ```
 
-### How Do I Validate My Certificate Chain?
+## How Do I Validate My Certificate Chain?
 
 You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.
 

docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md

@@ -7,6 +7,8 @@ description: For development and testing environments only, use a Docker install
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>
 
+<DockerSupportWarning />
+
 Rancher can be installed by running a single Docker container.
 
 In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.

docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md

@@ -6,6 +6,8 @@ title: Rolling Back 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/roll-back-docker-installed-rancher"/>
 </head>
 
+<DockerSupportWarning />
+
 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:
 
 - Your previous version of Rancher.

docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md

@@ -6,14 +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>
 
+<DockerSupportWarning />
+
 The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
 
-:::caution
-
-**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
-
-:::
-
 ## 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.

docs/getting-started/installation-and-upgrade/resources/bootstrap-password.md

@@ -6,26 +6,63 @@ title: Setting up the Bootstrap Password
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/bootstrap-password"/>
 </head>
 
-When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
+When you install Rancher, you can set a bootstrap password for the first admin account.
 
-The bootstrap password is randomly generated if it is not set during installation with a variable. For details on how to set the bootstrap password using a variable, see below.
+If you choose not to set a bootstrap password, Rancher randomly generates a bootstrap password for the first admin account.
 
-### Specifying the Bootstrap Password in Helm Installs
+For details on how to set the bootstrap password, see below.
 
-For a Helm install, users can specify the bootstrap password variable by configuring it in the Helm chart values with `.Values.bootstrapPassword`.
+## Password Requirements
 
-The password will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
+The bootstrap password can be any length.
 
+When you reset the first admin account's password after first login, the new password must be at least 12 characters long.
+
+You can [customize the minimum password length](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length) for user accounts, within limitations.
+
+Minimum password length can be any positive integer value between 2 and 256. Decimal values and leading zeroes are not allowed.
+
+## Specifying the Bootstrap Password
+
+<Tabs>
+<TabItem value="Helm">
+
+During [Rancher installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md), set `bootstrapPassword` alongside any other flags for the Rancher Helm chart. For example:
+
+```bash
+helm install rancher rancher-<chart-repo>/rancher \
+  --set bootstrapPassword=<password>
 ```
+
+</TabItem>
+<TabItem value="Docker">
+
+Pass the following value to the [Docker install command](../other-installation-methods/air-gapped-helm-cli-install/docker-install-commands.md):
+
+```bash
+-e CATTLE_BOOTSTRAP_PASSWORD=<password>
+```
+
+</TabItem>
+</Tabs>
+
+## Retrieving the Bootstrap Password
+
+The bootstrap password is stored in the Docker container logs. After Rancher is installed, the UI shows instructions for how to retrieve the password based on your installation method. 
+
+<Tabs>
+<TabItem value="Helm">
+
+```bash
 kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
 ```
 
-### Specifying the Bootstrap Password in Docker Installs
-
-For a Docker install, you can specify the bootstrap password by passing `-e CATTLE_BOOTSTRAP_PASSWORD=password` to the Docker install command.
-
-The password will be stored in the Docker container logs. After Rancher is installed, the UI will show instructions for how to retrieve the password using the Docker container ID:
+</TabItem>
+<TabItem value="Docker">
 
+```bash
+docker logs container-id  2>&1 | grep "Bootstrap Password:"
 ```
-docker logs  container-id  2>&1 | grep "Bootstrap Password:"
-```
+
+</TabItem>
+</Tabs>

docs/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md

@@ -109,7 +109,7 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
 | -------------------------- | ------ |
 | `rancher/rancher:latest`   | Our latest development release. These builds are validated through our CI automation framework. These releases are not recommended for production environments. |
 | `rancher/rancher:stable`   | Our newest stable release. This tag is recommended for production.                                                                                              |
-| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at DockerHub.                                       |
+| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at Docker Hub.                                       |
 
 :::note
 

docs/getting-started/installation-and-upgrade/resources/helm-version-requirements.md

@@ -8,7 +8,9 @@ title: Helm Version Requirements
 
 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
 
-> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+<DeprecationHelm2 />
 
 - Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
 - Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.

docs/getting-started/installation-and-upgrade/resources/update-rancher-certificate.md

@@ -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](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
+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](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
+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?
 

docs/getting-started/installation-and-upgrade/resources/upgrade-cert-manager.md

@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
     ```
 
+    <DeprecationHelm2 />
+    
     The Helm 2 command is as follows:
 
     ```plain

docs/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md

@@ -102,8 +102,6 @@ There is a [known issue](https://github.com/rancher/rancher/issues/25478) in whi
 
 ### Maintaining Availability for Applications During Upgrades
 
-_Available as of RKE v1.1.0_
-
 In [this section of the RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/) you'll learn the requirements to prevent downtime for your applications when upgrading the cluster.
 
 ### Configuring the Upgrade Strategy in the cluster.yml

docs/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace.md

@@ -7,8 +7,5 @@ description: Deploy SUSE Rancher from the AWS Marketplace listing.
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
 </head>
 
-import YouTube from '@site/src/components/YouTube'
-
 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). 
 
-# <YouTube id="9dznJ7Ons0M"/> 

docs/getting-started/quick-start-guides/deploy-rancher-manager/aws.md

@@ -57,7 +57,7 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst
 
     - `aws_access_key` - Amazon AWS Access Key
     - `aws_secret_key` - Amazon AWS Secret Key
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
 Suggestions include:

docs/getting-started/quick-start-guides/deploy-rancher-manager/azure.md

@@ -43,7 +43,7 @@ Deploying to Microsoft Azure will incur charges.
     - `azure_client_id` - Microsoft Azure Client ID
     - `azure_client_secret` - Microsoft Azure Client Secret
     - `azure_tenant_id` - Microsoft Azure Tenant ID
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 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:

docs/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md

@@ -38,7 +38,7 @@ Deploying to DigitalOcean will incur charges.
 
 4. Edit `terraform.tfvars` and customize the following variables:
     - `do_token` - DigitalOcean access key
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:

docs/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md

@@ -39,7 +39,7 @@ Deploying to Google GCP will incur charges.
 
 4. Edit `terraform.tfvars` and customize the following variables:
     - `gcp_account_json` - GCP service account file path and file name
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.

docs/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md

@@ -130,7 +130,7 @@ To install a specific Rancher version, use the `--version` flag (e.g., `--versio
 
 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.
 
-Note the password requires a minimum of 12 characters.
+See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
 
 ```
 helm install rancher rancher-latest/rancher \

docs/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md

@@ -38,7 +38,7 @@ Deploying to Hetzner Cloud will incur charges.
 
 4. Edit `terraform.tfvars` and customize the following variables:
     - `hcloud_token` - Hetzner API access key
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.

docs/getting-started/quick-start-guides/deploy-rancher-manager/linode.md

@@ -38,7 +38,7 @@ Deploying to Linode will incur charges.
 
 4. Edit `terraform.tfvars` and customize the following variables:
     - `linode_token` - The Linode Personal Access Token mentioned above.
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters).
+    - `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 requirments.
 
 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:

docs/getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs.md

@@ -39,7 +39,7 @@ Deploying to Outscale will incur charges.
 4. Edit `terraform.tfvars` and customize the following variables:
     - `access_key_id` - Outscale access key
     - `secret_key_id` - Outscale secret key
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters)
+    - `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 requirments.
 
 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.

docs/getting-started/quick-start-guides/deploy-rancher-manager/prime.md

@@ -6,6 +6,6 @@ title: Rancher Prime
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/prime"/>
 </head>
 
-Rancher v2.7 introduces Rancher Prime, an evolution of the Rancher enterprise offering. Rancher Prime is a new edition of the commercial, enterprise offering built on the the same source code. Rancher’s product will therefore continue to be 100% open source with additional value coming in from security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
+SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from version v2.7. Rancher Prime is the new commercially available enterprise offering of Rancher, built on the same open source code. The Rancher project will continue to be 100% open source. Prime introduces additional value with greater security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
 
 To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.

docs/glossary.md

@@ -0,0 +1,17 @@
+---
+title: Glossary
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/glossary"/>
+</head>
+
+This page covers Rancher-specific terminology and symbols which might be unfamiliar, or which differ between Rancher versions.
+
+```mdx-code-block
+import Glossary, {toc as GlossaryTOC} from "/shared-files/_glossary.md"
+
+<Glossary />
+
+export const toc = GlossaryTOC;
+```

docs/how-to-guides/advanced-user-guides/enable-api-audit-log-in-downstream-clusters.md

@@ -28,14 +28,14 @@ spec:
   rkeConfig:
     machineGlobalConfig:
       audit-policy-file: |
-        apiVersion: audit.k8s.io/v1 
-        kind: Policy 
-        rules: 
-        - level: RequestResponse
-          resources:
-          - group: ""
-            resources: 
-            - pods
+        apiVersion: audit.k8s.io/v1
+        kind: Policy
+        rules:
+          - level: RequestResponse
+            resources:
+              - group: ""
+                resources:
+                  - pods
 ```
 
 ### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`

docs/how-to-guides/advanced-user-guides/enable-api-audit-log.md

@@ -36,12 +36,12 @@ The usage below defines rules about what the audit log should record and what da
 
 The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.
 
-| `AUDIT_LEVEL` Setting | Request Metadata | Request Body | Response Metadata | Response Body |
-| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
-| `0`                   |                  |              |                   |               |
-| `1`                   | ✓                |              |                   |               |
-| `2`                   | ✓                | ✓            |                   |               |
-| `3`                   | ✓                | ✓            | ✓                 | ✓             |
+| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
+| --------------------- | -------- | ------------ | ------------- |
+| `0`                   |          |              |               |
+| `1`                   | ✓        |              |               |
+| `2`                   | ✓        | ✓            |               |
+| `3`                   | ✓        | ✓            | ✓             |
 
 ## Viewing API Audit Logs
 

docs/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md

@@ -6,7 +6,7 @@ title: Continuous Delivery
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery"/>
 </head>
 
-[Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) comes preinstalled in Rancher can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
+[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) comes preinstalled in Rancher and can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
 
 To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](enable-experimental-features.md)
 

docs/how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md

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

docs/how-to-guides/advanced-user-guides/enable-user-retention.md

@@ -0,0 +1,62 @@
+---
+title: Enabling User Retention
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention"/>
+</head>
+
+In Rancher v2.8.5 and later, you can enable user retention to automatically disable or delete inactive user accounts after a configurable time period.
+
+The user retention feature is off by default.
+
+## Enabling User Retention with kubectl
+
+To enable user retention, you must set `user-retention-cron`. You must also set at least one of  `disable-inactive-user-after` or `delete-inactive-user-after`. You can use `kubectl edit setting <name-of-setting>` to open your editor of choice and set these values.
+
+## Configuring Rancher to Delete Users, Disable Users, or Combine Operations
+
+Rancher uses two global user retention settings to determine if and when users are disabled or deleted after a certain period of inactivity. Disabled accounts must be re-enabled before users can log in again. If an account is deleted without being disabled, users may be able to log in through external authentication and the deleted account will be recreated.
+
+The global settings, `disable-inactive-user-after` and  `delete-inactive-user-after`, do not block one another from running. 
+
+For example, you can set both operations to run. If you give `disable-inactive-user-after` a shorter duration than `delete-inactive-user-after`, the user retention process disables inactive accounts before deleting them.
+
+You can also edit some user retention settings on a specific user's `UserAttribute`. Setting these values overrides the global settings. See [User-specific User Retention Overrides](#user-specific-user-retention-overrides) for more details.
+
+### Required User Retention Settings
+
+The following are global settings:
+
+- `user-retention-cron`: Describes how often the user retention process runs. The value is a cron expression (for example, `0 * * * *` for every hour).
+ - `disable-inactive-user-after`: The amount of time that a user account can be inactive before the process disables an account. Disabling an account forces the user to request that an administrator re-enable the account before they can log in to use it. Values are expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) (for example, `720h` for 720 hours or 30 days). The value must be greater than `auth-user-session-ttl-minutes`, which is `16h` by default. If the value is not set, set to the empty string, or is equal to 0, the process does not disable any inactive accounts.
+- `delete-inactive-user-after`: The amount of time that a user account can be inactive before the process deletes the account. Values are expressed in time.Duration units (for example, `720h` for 720 hours or 30 days). The value must be greater than `auth-user-session-ttl-minutes`, which is `16h` by default. The value should be greater than `336h` (14 days), otherwise it is rejected by the Rancher webhook. If you need the value to be lower than 14 days, you can [bypass the webhook](../../reference-guides/rancher-webhook.md#bypassing-the-webhook). If the value is not set, set to the empty string, or is equal to 0, the process does not delete any inactive accounts.
+
+### Optional User Retention Settings
+
+The following are global settings:
+
+- `user-retention-dry-run`: If set to `true`, the user retention process runs without actually deleting or disabling any user accounts. This can help test user retention behavior before allowing the process to disable or delete user accounts in a production environment.
+- `user-last-login-default`: If a user does not have `UserAttribute.LastLogin` set on their account, this setting is used instead. The value is expressed as an [RFC 3339 date-time](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) truncated to the last second; for example, `2023-03-01T00:00:00Z`. If the value is set to the empty string or is equal to 0, this setting is not used.
+
+#### User-specific User Retention Overrides
+
+The following are user-specific overrides to the global settings for special cases. These settings are applied by editing the `UserAttribute` associated with a given account:
+
+```
+kubectl edit userattribute <user-name>
+```
+
+- `disableAfter`: The user-specific override for `disable-inactive-user-after`. The value is expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) and truncated to the second. If the value is set to `0s` then the account won't be subject to disabling. 
+- `deleteAfter`: The user-specific override for `delete-inactive-user-after`. The value is expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) and truncated to the second. If the value is set to `0s` then the account won't be subject to deletion.
+
+## Viewing User Retention Settings in the Rancher UI
+
+You can see which user retention settings are applied to which users. 
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, select **Users**. 
+
+The **Disable After** and **Delete After** columns for each user account indicate how long the account can be inactive before it is disabled or deleted from Rancher. There is also a **Last Login** column roughly indicating when the account was last active. 
+
+The same information is available if you click a user's name in the **Users** table and select the **Detail** tab.

docs/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic.md

@@ -6,19 +6,21 @@ title: Generate and View Traffic from Istio
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic"/>
 </head>
 
-This section describes how to view the traffic that is being managed by Istio.
-
 ## The Kiali Traffic Graph
 
-The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
+The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you can view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
 
-:::note Prerequisites:
+## Prerequisites
 
-To enable traffic to show up in the graph, ensure you have prometheus installed in the cluster. Rancher-istio installs Kiali configured by default to work with the rancher-monitoring chart. You can use rancher-monitoring or install your own monitoring solution. Optional: you can change configuration on how data scraping occurs by setting the [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) options.
+To enable traffic to show up in the graph, ensure that you have Prometheus installed in the cluster. `Rancher-istio` installs Kiali, and configures it by default to work with the `rancher-monitoring` chart. You can use `rancher-monitoring` or install your own monitoring solution.
 
-:::
+Additionally, for Istio installations version `103.1.0+up1.19.6` and later, Kiali uses a token value for its authentication strategy. If you are trying to generate or retrieve the token (e.g. for login), note that the name of the Kiali service account in Rancher is `kiali`. For more information, refer to the [Kiali token authentication FAQ](https://kiali.io/docs/faq/authentication/).
 
-To see the traffic graph,
+Optional: You can configure which namespaces data scraping occurs in by setting the Helm chart options described in [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md).
+
+## Traffic Visualization
+
+To see the traffic graph follow the steps below:
 
 1. In the cluster where Istio is installed, click **Istio** in the left navigation bar.
 1. Click the **Kiali** link.

docs/how-to-guides/advanced-user-guides/istio-setup-guide/istio-setup-guide.md

@@ -1,5 +1,5 @@
 ---
-title: Setup Guide
+title: Istio Setup Guides
 ---
 
 <head>

docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md

@@ -42,7 +42,7 @@ For more information about the default limits, see [this page.](../../../referen
 
 ### Enable Monitoring for use without SSL
 
-1.  Click **☰ > Cluster Management**.
+1. Click **☰ > Cluster Management**.
 1. Go to the cluster that you created and click **Explore**.
 1. Click **Cluster Tools** (bottom left corner).
 1. Click **Install** by Monitoring.
@@ -77,3 +77,79 @@ key.pfx=`base64-content`
 ```
 
 Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
+
+## Rancher Performance Dashboard
+
+When monitoring is installed on the upstream (local) cluster, you are given basic health metrics about the Rancher pods, such as CPU and memory data. To get advanced metrics for your local Rancher server, you must additionally enable the Rancher Performance Dashboard for Grafana.
+
+This dashboard provides access to the following advanced metrics:
+
+- Handler Average Execution Times Over Last 5 Minutes
+- Rancher API Average Request Times Over Last 5 Minutes
+- Subscribe Average Request Times Over Last 5 Minutes
+- Lasso Controller Work Queue Depth (Top 20)
+- Number of Rancher Requests (Top 20)
+- Number of Failed Rancher API Requests (Top 20)
+- K8s Proxy Store Average Request Times Over Last 5 Minutes (Top 20)
+- K8s Proxy Client Average Request Times Over Last 5 Minutes (Top 20)
+- Cached Objects by GroupVersionKind (Top 20)
+- Lasso Handler Executions (Top 20)
+- Handler Executions Over Last 2 Minutes (Top 20)
+- Total Handler Executions with Error (Top 20)
+- Data Transmitted by Remote Dialer Sessions (Top 20)
+- Errors for Remote Dialer Sessions (Top 20)
+- Remote Dialer Connections Removed (Top 20)
+- Remote Dialer Connections Added by Client (Top 20)
+
+:::note
+
+Profiling data (such as advanced memory or CPU analysis) is not present as it is a very context-dependent technique that's meant for debugging and not intended for normal observation.
+
+:::
+
+### Enabling the Rancher Performance Dashboard
+
+To enable the Rancher Performance Dashboard:
+
+<Tabs groupId="UIorCLI">
+<TabItem value="Helm">
+
+Use the following options with the Helm CLI:
+
+```bash
+--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
+```
+
+You can also include the following snippet in your Rancher Helm chart's values.yaml file:
+
+```yaml
+extraEnv:
+  - name: "CATTLE_PROMETHEUS_METRICS"
+    value: "true"
+```
+
+</TabItem>
+<TabItem value="UI">
+
+1. Click **☰ > Cluster Management**.
+1. Go to the row of the `local` cluster and click **Explore**.
+1. Click **Workloads > Deployments**.
+1. Use the dropdown menu at the top to filter for **All Namespaces**.
+1. Under the `cattle-system` namespace, go to the `rancher` row and click **⋮ > Edit Config**
+1. Under **Environment Variables**, click **Add Variable**.
+1. For **Type**, select `Key/Value Pair`.
+1. For **Variable Name**, enter `CATTLE_PROMETHEUS_METRICS`.
+1. For **Value**, enter `true`.
+1. Click **Save** to apply the change.
+
+</TabItem>
+</Tabs>
+
+### Accessing the Rancher Performance Dashboard
+
+1. Click **☰ > Cluster Management**.
+1. Go to the row of the `local` cluster and click **Explore**.
+1. Click **Monitoring**
+1. Select the **Grafana** dashboard.
+1. From the sidebar, click **Search dashboards**.
+1. Enter `Rancher Performance Debugging` and select it.

docs/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/monitoring-v2-configuration-guides.md

@@ -1,5 +1,5 @@
 ---
-title: Configuration
+title: Monitoring Configuration Guides
 ---
 
 <head>

docs/how-to-guides/advanced-user-guides/open-ports-with-firewalld.md

@@ -6,7 +6,17 @@ title: Opening Ports with firewalld
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/open-ports-with-firewalld"/>
 </head>
 
-> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
+:::danger
+
+Enabling firewalld can cause serious network communication problems. 
+
+For proper network function, firewalld must be disabled on systems running RKE2. [Firewalld conflicts with Canal](https://docs.rke2.io/known_issues#firewalld-conflicts-with-default-networking), RKE2's default networking stack.
+
+Firewalld must also be disabled on systems running Kubernetes 1.19 and later.
+
+If you enable firewalld on systems running Kubernetes 1.18 or earlier, understand that this may cause networking issues. CNIs in Kubernetes dynamically update iptables and networking rules independently of any external firewalls, such as firewalld. This can cause unexpected behavior when the CNI and the external firewall conflict.
+
+:::
 
 Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
 

docs/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md

@@ -8,7 +8,7 @@ title: Tuning etcd for Large Installations
 
 When Rancher is used to manage [a large infrastructure](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) it is recommended to increase the default keyspace for etcd from the default 2 GB. The maximum setting is 8 GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
 
-The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) setting on the etcd servers.
+The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.
 
 ### Example: This snippet of the RKE cluster.yml file increases the keyspace size to 5GB
 
@@ -23,7 +23,7 @@ services:
 
 ## Scaling etcd disk performance
 
-You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
+You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.5/tuning/#disk) on how to tune the disk priority on the host.
 
 Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
 

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md

@@ -6,11 +6,11 @@ title: Node Drivers
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers"/>
 </head>
 
-Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
+A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. By default, Rancher is packaged with many node drivers, but you can also create and add custom node drivers to Rancher.
 
-If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
+Only `Active` node drivers are displayed in the Rancher UI when you create node templates. If there are specific node drivers that you don't want to show your users, you must deactivate these node drivers.
 
-#### Managing Node Drivers
+## Managing Node Drivers
 
 :::note Prerequisites:
 
@@ -21,17 +21,31 @@ To create, edit, or delete drivers, you need _one_ of the following permissions:
 
 :::
 
-## Activating/Deactivating Node Drivers
+### Activating/Deactivating Node Drivers
 
-By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
+By default, Rancher only activates drivers for the most popular cloud providers, such as Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
 
 1. In the upper left corner, click **☰ > Cluster Management**.
+1.  In the left navigation menu, click **Drivers**.
+1.	On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.
 
-2.  In the left navigation menu, click **Drivers**.
+:::danger 
 
-2.	On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.
+You can lose access to clusters after deactivating a node driver.
 
-## Adding Custom Node Drivers
+Deactivating a node driver doesn't just affect its visibility in the Rancher UI. When you deactivate or delete a node driver, any nodes deployed with that driver become inaccessible. 
+
+For example, if you deactivate a vSphere node driver to hide it in the UI, and you have a vSphere cluster that was deployed with that driver, the initial node in the cluster will fail, and the entire cluster will become inaccessible. Attempts to delete the vSphere nodes will fail, with nodes stuck in an extended `Removing` state.
+
+Before you deactivate a node driver, make sure that it has no associated clusters. One way to check is to see if the respective platform for a driver is listed among your clusters:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Select **Clusters**.
+1. Check the **Provider** column of the table for instances of the node driver you are deactivating.
+
+:::
+
+### Adding Custom Node Drivers
 
 If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add that provider's driver in order to start using them to create node templates and eventually node pools for your Kubernetes cluster.
 
@@ -40,6 +54,8 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
 1. On **Node Drivers** tab, click **Add Node Driver**.
 1.	Complete the **Add Node Driver** form. Then click **Create**.
 
-### Developing your own node driver
+### Developing Your Own Node Drivers
 
-Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
+Node drivers are implemented with [Rancher Machine](https://github.com/rancher/machine), a fork of [Docker Machine](https://github.com/docker/machine). Docker Machine is no longer under active development.
+
+Refer to the original [Docker Machine documentation](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) for details on how to develop your own node drivers.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/about-rke1-templates.md

@@ -1,5 +1,5 @@
 ---
-title: RKE Templates
+title: About RKE1 Templates
 ---
 
 <head>

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/creator-permissions.md

@@ -40,8 +40,8 @@ An administrator can individually grant the role **Create RKE Templates** to any
 Alternatively, the administrator can give all new users the default permission to create RKE templates by following the following steps. This will not affect the permissions of existing users.
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
-1. Go to the role named **Create new RKE Cluster Templates and click **⋮ > Edit Config**.
+1. In the left navigation bar, click **Role Templates**.
+1. Select **Create new RKE Cluster Templates** and click **⋮ > Edit Config**.
 1. Select the option **Yes: Default role for new users**.
 1. Click **Save**.
 1. If you would like new users to also be able to create RKE template revisions, enable that role as default as well.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md

@@ -25,7 +25,6 @@ This section focuses on how to use Terraform with the [Rancher 2 Terraform provi
 Terraform allows you to:
 
 - Define almost any kind of infrastructure-as-code, including servers, databases, load balancers, monitoring, firewall settings, and SSL certificates
-- Leverage catalog apps and multi-cluster apps
 - Codify infrastructure across many platforms, including Rancher and major cloud providers
 - Commit infrastructure-as-code to version control
 - Easily repeat configuration and setup of infrastructure
@@ -52,8 +51,6 @@ When you need to make changes to your infrastructure, instead of manually updati
 
 - You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.
 
-- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
-
 ## Tip for Creating CIS Benchmark Compliant Clusters
 
 This section describes one way that you can make security and compliance-related config files standard in your clusters.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md

@@ -11,24 +11,31 @@ One of the key features that Rancher adds to Kubernetes is centralized user auth
 
 This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account.
 
+:::warning
+
+The account used to enable the external provider will be granted admin permissions. If you use a test account or non-admin account, that account will still be granted admin-level permissions. See [External Authentication Configuration and Principal Users](#external-authentication-configuration-and-principal-users) to understand why.
+
+:::
+
 ## External vs. Local Authentication
 
 The Rancher authentication proxy integrates with the following external authentication services.
 
-| Auth Service                                                                                     |
-| ------------------------------------------------------------------------------------------------ |
-| [Microsoft Active Directory](configure-active-directory.md)  |
-| [GitHub](configure-github.md)                  |
-| [Microsoft Azure AD](configure-azure-ad.md)    |
-| [FreeIPA](configure-freeipa.md)                |
-| [OpenLDAP](../configure-openldap/configure-openldap.md)              |
+| Auth Service                                                                                                           |
+|------------------------------------------------------------------------------------------------------------------------|
+| [Microsoft Active Directory](configure-active-directory.md)                                                            |
+| [GitHub](configure-github.md)                                                                                          |
+| [Microsoft Azure AD](configure-azure-ad.md)                                                                            |
+| [FreeIPA](configure-freeipa.md)                                                                                        |
+| [OpenLDAP](../configure-openldap/configure-openldap.md)                                                                |
 | [Microsoft AD FS](../configure-microsoft-ad-federation-service-saml/configure-microsoft-ad-federation-service-saml.md) |
-| [PingIdentity](configure-pingidentity.md)     |
-| [Keycloak (OIDC)](configure-keycloak-oidc.md)  |
-| [Keycloak (SAML)](configure-keycloak-saml.md)  |
-| [Okta](configure-okta-saml.md)                      |
-| [Google OAuth](configure-google-oauth.md)            |
-| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.md)           |
+| [PingIdentity](configure-pingidentity.md)                                                                              |
+| [Keycloak (OIDC)](configure-keycloak-oidc.md)                                                                          |
+| [Keycloak (SAML)](configure-keycloak-saml.md)                                                                          |
+| [Okta](configure-okta-saml.md)                                                                                         |
+| [Google OAuth](configure-google-oauth.md)                                                                              |
+| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.md)                                                |
+| [Generic (OIDC)](configure-generic-oidc.md)                                                                            |
 
 However, Rancher also provides [local authentication](create-local-users.md).
 
@@ -36,7 +43,7 @@ In most cases, you should use an external authentication service over local auth
 
 ## Users and Groups
 
-Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
+Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
 
 :::note
 
@@ -56,6 +63,12 @@ After you configure Rancher to allow sign on using an external authentication se
 | Allow members of Clusters, Projects, plus Authorized Users and Organizations | Any user in the authorization service and any group added as a **Cluster Member** or **Project Member** can log in to Rancher. Additionally, any user in the authentication service or group you add to the **Authorized Users and Organizations** list may log in to Rancher. |
 | Restrict access to only Authorized Users and Organizations | Only users in the authentication service or groups added to the Authorized Users and Organizations can log in to Rancher. |
 
+:::warning 
+
+Only trusted admin-level users should have access to the local cluster, which manages all of the other clusters in a Rancher instance. Rancher is directly installed on the local cluster, and Rancher's management features allow admins on the local cluster to provision, modify, connect to, and view details about downstream clusters. Since the local cluster is key to a Rancher instance's architecture, inappropriate access carries security risks.
+
+:::
+
 To set the Rancher access level for users in the authorization service, follow these steps:
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
@@ -77,12 +90,14 @@ To set the Rancher access level for users in the authorization service, follow t
 
 ## External Authentication Configuration and Principal Users
 
-Configuration of external authentication requires:
+Configuring external authentication requires:
 
 - A local user assigned the administrator role, called hereafter the _local principal_.
 - An external user that can authenticate with your external authentication service, called hereafter the _external principal_.
 
-Configuration of external authentication affects how principal users are managed within Rancher. Follow the list below to better understand these effects.
+The configuration of external authentication also affects how principal users are managed within Rancher. Specifically, when a user account enables an external provider, it is granted admin-level permissions. This is because the local principal and external principal share the same user ID and access rights.
+
+The following instructions demonstrate these effects:
 
 1. Sign into Rancher as the local principal and complete configuration of external authentication.
 

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-azure-ad.md

@@ -133,7 +133,17 @@ Here are a few examples of permission combinations that satisfy Rancher's needs:
 
 :::
 
-#### 4. Copy Azure Application Data
+#### 4. Allow Public Client Flows
+
+To login from Rancher CLI you must allow public client flows:
+
+1. From the left navigation menu, select **Authentication**.
+
+1. Under **Advanced Settings**, select **Yes** on the toggle next to **Allow public client flows**.
+
+    ![Allow Public Client Flows](/img/azure-public-client-flows.png)
+
+#### 5. Copy Azure Application Data
 
 ![Application ID](/img/app-configuration.png)
 
@@ -167,7 +177,7 @@ Custom Endpoints are not tested or fully supported by Rancher.
 
 You'll also need to manually enter the Graph, Token, and Auth Endpoints.
 
-- From <b>App registrations</b>, click <b>Endpoints</b>:
+- From **App registrations**, click **Endpoints**:
 
 ![Click Endpoints](/img/endpoints.png)
 
@@ -176,7 +186,7 @@ You'll also need to manually enter the Graph, Token, and Auth Endpoints.
   - **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
   - **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
 
-#### 5. Configure Azure AD in Rancher
+#### 6. Configure Azure AD in Rancher
 
 To complete configuration, enter information about your AD instance in the Rancher UI.
 
@@ -188,7 +198,7 @@ To complete configuration, enter information about your AD instance in the Ranch
 
 1. Click **AzureAD**.
 
-1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
+1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
 
     :::caution
 
@@ -221,10 +231,15 @@ To complete configuration, enter information about your AD instance in the Ranch
 
     <code>http<span>s://g</span>raph.microsoft.com<del>/abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
 
+1. (Optional) In Rancher v2.9.0 and later, you can filter users' group memberships in Azure AD to reduce the amount of log data generated. See steps 4–5 of [Filtering Users by Azure AD Auth Group Memberships](#filtering-users-by-azure-ad-auth-group-memberships) for full instructions.
+
 1. Click **Enable**.
 
 **Result:** Azure Active Directory authentication is configured.
 
+#### (Optional) Configure Authentication with Multiple Rancher Domains
+
+If you have multiple Rancher domains, it's not possible to configure multiple redirect URIs through the Rancher UI. The Azure AD configuration file, `azuread`, only allows one redirect URI by default. You must manually edit `azuread` to set the redirect URI as needed for any other domains. If you don't manually edit `azuread`, then upon a successful login attempt to any domain, Rancher automatically redirects the user to the **Redirect URI** value you set when you registered the app in [Step 1. Register Rancher with Azure](#1-register-rancher-with-azure).
 
 ### Migrating from Azure AD Graph API to Microsoft Graph API
 
@@ -311,6 +326,29 @@ Endpoint         | https://login.partner.microsoftonline.cn/
 Graph Endpoint   | https://microsoftgraph.chinacloudapi.cn
 Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/token
 
+## Filtering Users by Azure AD Auth Group Memberships
+
+In Rancher v2.9.0 and later, you can filter users' group memberships from Azure AD to reduce the amount of log data generated. If you did not filter group memberships during initial setup, you can still add filters on an existing Azure AD configuration.
+
+:::warning
+    
+Filtering out a user group membership affects more than just logging. 
+
+Since the filter prevents Rancher from seeing that the user belongs to an excluded group, it also does not see any permissions from that group. This means that excluding a group from the filter can have the side effect of denying users permissions they should have.
+
+:::
+
+1. In Rancher, in the top left corner, click **☰ > Users & Authentication**.
+
+1. In the left navigation menu, click **Auth Provider**.
+
+1. Click **AzureAD**.
+
+1. Click the checkbox next to **Limit users by group membership**.
+    
+1. Enter an [OData filter clause](https://learn.microsoft.com/en-us/odata/concepts/queryoptions-overview#filter) into the **Group Membership Filter** field. For example, if you want to limit logging to group memberships whose name starts with `test`, click the checkbox and enter `startswith(displayName,'test')`.
+
+![Adding a group membership filter to Azure AD](/img/auth-setup-azure-ad-filter.png)
 
 ## Deprecated Azure AD Graph API
 
@@ -325,4 +363,3 @@ Token Endpoint   | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
     - Use the built-in Rancher auth or
     - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
-

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc.md

@@ -0,0 +1,110 @@
+---
+title: Configure Generic OIDC
+description: Create an OpenID Connect (OIDC) client and configure Rancher to work with your authentication provider. Your users can then sign into Rancher using their login from the authentication provider.
+---
+
+<head> 
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc"/>
+</head>
+
+If your organization uses an OIDC provider for user authentication, you can configure Rancher to allow login using Identity Provider (IdP) credentials. Rancher supports integration with the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to configure Rancher to work using the OIDC protocol.
+
+## Prerequisites
+
+- In Rancher:
+  - Generic OIDC is disabled.
+
+:::note
+Consult the documentation for your specific IdP to complete the listed prerequisites.
+:::
+
+- In your IdP:
+  - Create a new client with the settings below:
+
+    Setting | Value
+    ------------|------------
+    `Client ID` | <CLIENT_ID> (e.g. `rancher`)
+    `Name` | <CLIENT_NAME> (e.g. `rancher`)
+    `Client Protocol` | `openid-connect`
+    `Access Type` | `confidential`
+    `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+
+  - In the new OIDC client, create mappers to expose the users fields.
+    - Create a new Groups Mapper with the settings below:
+
+      Setting | Value
+      ------------|------------
+      `Name` | `Groups Mapper`
+      `Mapper Type` | `Group Membership`
+      `Token Claim Name` | `groups`
+      `Add to ID token` | `OFF`
+      `Add to access token` | `OFF`
+      `Add to user info` | `ON`
+
+    - Create a new Client Audience with the settings below:
+
+      Setting | Value
+      ------------|------------
+      `Name` | `Client Audience`
+      `Mapper Type` | `Audience`
+      `Included Client Audience` | <CLIENT_NAME>
+      `Add to access token` | `ON`
+
+    - Create a new "Groups Path" with the settings below.
+
+      Setting | Value
+      ------------|------------
+      `Name` | `Group Path`
+      `Mapper Type` | `Group Membership`
+      `Token Claim Name` | `full_group_path`
+      `Full group path` | `ON`
+      `Add to user info` | `ON`
+
+- Important:  Rancher will use the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that will be unique and immutable.
+
+## Configuring Generic OIDC in Rancher
+
+1. In the upper left corner of the Rancher UI, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Auth Provider**.
+1. Select **Generic OIDC**.
+1. Complete the **Configure an OIDC account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
+1. Click **Enable**.
+
+   Rancher will redirect you to the IdP login page. Enter your IdP credentials to validate your Rancher Keycloak configuration.
+
+   :::note
+
+   You may need to disable your popup blocker to see the IdP login page.
+
+   :::
+
+**Result:** Rancher is configured to work with your provider using the OIDC protocol. Your users can now sign into Rancher using their IdP logins.
+
+## Configuration Reference
+
+| Field                     | Description                                                                                                                                        |
+| ------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------|
+| Client ID                 | The Client ID of your OIDC client.                                                                                                               |
+| Client Secret             | The generated Secret of your OIDC client.                                                                                                        |
+| Private Key/Certificate | A key/certificate pair to create a secure shell between Rancher and your IdP. Required if HTTPS/SSL is enabled on your OIDC server.                |
+| Endpoints                 | Choose whether to use the generated values for the Rancher URL, Issue, and Auth Endpoint fields or to provide manual overrides if incorrect. |
+| Rancher URL               | The URL for your Rancher Server.                                                                                                                   |
+| Issuer                    | The URL of your IdP.  If your provider has discovery enabled, Rancher uses the Issuer URL to fetch all of the required URLs.                   |
+| Auth Endpoint             | The URL where users are redirected to authenticate.                                                                                                |
+## Troubleshooting
+
+If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
+
+All Generic OIDC related log entries are prepended with either `[generic oidc]` or `[oidc]`.
+
+### You are not redirected to your authentication provider
+
+If you fill out the **Configure a Generic OIDC account** form and click on **Enable**, and you are not redirected to your IdP, verify your OIDC client configuration.
+
+### The generated `Issuer` and `Auth Endpoint` are incorrect
+
+If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Configure an OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` value.
+
+### Error: "Invalid grant_type"
+
+In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-okta-saml.md

@@ -51,7 +51,6 @@ You can integrate Okta with Rancher, so that authenticated users can access Ranc
 
     :::
 
-
 1. After you complete the **Configure Okta Account** form, click **Enable**.
 
     Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md

@@ -8,7 +8,7 @@ title: Users and Groups
 
 Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When you configure an external authentication provider, users from that provider will be able to log in to your Rancher server. When a user logs in, the authentication provider will supply your Rancher server with a list of groups to which the user belongs.
 
-Access to clusters, projects, multi-cluster apps, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
+Access to clusters, projects, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
 
 ## Managing Members
 
@@ -70,6 +70,14 @@ Since SAML does not support user lookup, SAML-based authentication providers do
 
 :::
 
+## Minimum Password Length
+
+By default, user passwords must be at least 12 characters long. However, you can customize the password length requirement:
+
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to **`password-min-length`** and click **⋮ > Edit Setting**.
+1. Enter an integer value between 2 and 256, and click **Save**.
+
 ## Session Length
 
 The default length (TTL) of each user session is adjustable. The default session length is 16 hours.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md

@@ -30,6 +30,14 @@ Within Rancher, each person authenticates as a _user_, which is a login that gra
 
 For more information how authorization works and how to customize roles, see [Roles Based Access Control (RBAC)](manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
 
+## User Retention
+
+In Rancher v2.8.5 and later, you can enable user retention. This feature automatically removes inactive users after a configurable period of time.
+
+The user retention feature is disabled by default.
+
+For more information, see [Enabling User Retention](../../advanced-user-guides/enable-user-retention.md).
+
 ## Pod Security Policies
 
 _Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
@@ -82,4 +90,4 @@ The following features are available under **Global Configuration**:
 - **Global DNS Entries**
 - **Global DNS Providers**
 
-As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
+As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/custom-branding.md

@@ -23,7 +23,7 @@ This option replaces "Rancher" with the value you provide in most places. Files
 
 ### Support Links
 
-Use a url address to send new "File an Issue" reports instead of sending users to the Github issues page. Optionally show Rancher community support links.
+Use a url address to send new "File an Issue" reports instead of sending users to the GitHub issues page. Optionally show Rancher community support links.
 
 ### Logo
 

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication.md

@@ -0,0 +1,17 @@
+---
+title: JSON Web Token (JWT) Authentication
+---
+<head> 
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication"/>
+</head>
+
+Many 3rd party integrations available for Kubernetes, such as GitLab and HashiCorp Vault, involve giving an external process access to the Kubernetes API using a native Kubernetes Service Account token for authentication.
+
+In Rancher v2.9.0 and later, service accounts on downstream clusters can now authenticate through a JSON web token (JWT) using the Rancher authentication proxy. In Rancher versions earlier than  v2.9.0, only Rancher-issued tokens were supported.
+
+To enable this feature, follow these steps:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Click **Advanced** to open the dropdown menu.
+1. Select **JWT Authentication**.
+1. Click the checkbox for the cluster you want to enable JWT authentication for, and click **Enable**. Alternatively, you can click **⋮** > **Enable**.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md

@@ -11,7 +11,7 @@ Cluster and project roles define user authorization inside a cluster or project.
 To manage these roles,
 
 1. Click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles** and go to the **Cluster** or **Project/Namespaces** tab.
+1. In the left navigation bar, click **Role Templates** and go to the **Cluster** or **Project/Namespaces** tab.
 
 ### Membership and Role Assignment
 
@@ -73,7 +73,7 @@ The following table lists the permissions available for the `Manage Nodes` role
 For details on how each cluster role can access Kubernetes resources, you can look them up in the Rancher UI:
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1. Click the **Cluster** tab.
 1. Click the name of an individual role. The table shows all of the operations and resources that are permitted by the role.
 
@@ -220,7 +220,7 @@ There are two methods for changing default cluster/project roles:
 You can change the cluster or project role(s) that are automatically assigned to the creating user.
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1. Click the **Cluster** or **Project/Namespaces** tab.
 1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **⋮ > Edit Config**.
 1. In the **Cluster Creator Default** or **Project Creator Default** section, enable the role as the default.
@@ -238,3 +238,9 @@ When you revoke the cluster membership for a standard user that's explicitly ass
 - Exercise any [individual project roles](#project-role-reference) they are assigned.
 
 If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
+
+### External `RoleTemplate` Behavior
+
+In Rancher v2.9.0 and later, external `RoleTemplate` objects can only be created if the backing `ClusterRole` exists in the local cluster or the `ExternalRules` is set in your configuration.
+
+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`. Additionally, note that `escalate` permissions on `RoleTemplates` are required to create external `RoleTemplates` with `ExternalRules`.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md

@@ -31,7 +31,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
 The steps to add custom roles differ depending on the version of Rancher.
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1.  Select a tab to determine the scope of the role you're adding. The tabs are:
 
   - **Global:** The role is valid for allowing members to manage global scoped resources.
@@ -65,7 +65,7 @@ The custom role can then be assigned to a user or group so that the role takes e
 To create a custom role based on an existing role,
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1. Click the **Cluster** or **Project/Namespaces** tab. Click **Create Cluster Role** or **Create Project/Namespaces Role** depending on the scope. Note: Only cluster roles and project/namespace roles can inherit from another role.
 1. Enter a name for the role.
 1. In the **Inherit From** tab, select the role(s) that the custom role will inherit permissions from.
@@ -86,7 +86,7 @@ Custom roles can be deleted, but built-in roles cannot be deleted.
 To delete a custom role,
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 2. Go to the custom global role that should be deleted and click **⋮ (…) > Delete**.
 3. Click **Delete**.
 

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md

@@ -12,7 +12,7 @@ Global Permissions define user authorization outside the scope of any particular
 
 - **Administrator:** These users have full control over the entire Rancher system and all clusters within it.
 
-- **Restricted Admin:** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
+- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
 
 - **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
 
@@ -20,9 +20,282 @@ Global Permissions define user authorization outside the scope of any particular
 
 You cannot update or delete the built-in Global Permissions.
 
+## Global Permission Assignment
+
+Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
+
+### Global Permissions for New Local Users
+
+When you create a new local user, you assign them a global permission as you complete the **Add User** form.
+
+To see the default permissions for new users,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Role Templates**.
+1. The **Role Templates** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **Global** tab, in the **New User Default** column, the permissions given to new users by default are indicated with a checkmark.
+
+You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
+
+### Global Permissions for Users with External Authentication
+
+When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the  **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.
+
+To see the default permissions for new users,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Role Templates**.
+1. The **Role Templates** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **New User Default** column on each page, the permissions given to new users by default are indicated with a checkmark.
+
+You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)
+
+Permissions can be [assigned](#configuring-global-permissions-for-individual-users) to an individual user.
+
+You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
+
+## Custom Global Permissions
+
+Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.
+
+When a user from an [external authentication source](../authentication-config/authentication-config.md) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters.
+
+However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions.
+
+The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role.
+
+Administrators can enforce custom global permissions in multiple ways:
+
+- [Creating custom global roles](#custom-globalroles).
+- [Changing the default permissions for new users](#configuring-default-global-permissions).
+- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users).
+- [Configuring global permissions for groups](#configuring-global-permissions-for-groups).
+
+### Combining Built-in GlobalRoles
+
+Rancher provides several GlobalRoles which grant granular permissions for certain common use cases.
+The following table lists each built-in global permission and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
+
+| Custom Global Permission           | Administrator | Standard User | User-Base |
+| ---------------------------------- | ------------- | ------------- |-----------|
+| Create Clusters                    | ✓             | ✓             |           |
+| Create RKE Templates               | ✓             | ✓             |           |
+| Manage Authentication              | ✓             |               |           |
+| Manage Catalogs                    | ✓             |               |           |
+| Manage Cluster Drivers             | ✓             |               |           |
+| Manage Node Drivers                | ✓             |               |           |
+| Manage PodSecurityPolicy Templates | ✓             |               |           |
+| Manage Roles                       | ✓             |               |           |
+| Manage Settings                    | ✓             |               |           |
+| Manage Users                       | ✓             |               |           |
+| Use Catalog Templates              | ✓             | ✓             |           |
+| User-Base (Basic log-in access)  | ✓             | ✓             |           |
+
+For details on which Kubernetes resources correspond to each global permission,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Role Templates**.
+1.  If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.
+
+:::note Notes:
+
+- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
+- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
+
+:::
+
+### Custom GlobalRoles
+
+You can create custom GlobalRoles to satisfy use cases not directly addressed by built-in GlobalRoles. 
+
+Create custom GlobalRoles through the UI or through automation (such as the Rancher Kubernetes API). You can specify the same type of rules as the rules for upstream roles and clusterRoles. 
+
+#### Escalate and Bind verbs
+
+When giving permissions on GlobalRoles, keep in mind that Rancher respects the `escalate` and `bind` verbs, in a similar fashion to [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
+
+Both of these verbs, which are given on the GlobalRoles resource, can grant users the permission to bypass Rancher's privilege escalation checks. This potentially allows users to become admins. Since this represents a serious security risk, `bind` and `escalate` should be distributed to users with great caution. 
+
+The `escalate` verb allows users to change a GlobalRole and add any permission, even if the users doesn't have the permissions in the current GlobalRole or the new version of the GlobalRole. 
+
+The `bind` verb allows users to create a GlobalRoleBinding to the specified GlobalRole, even if they do not have the permissions in the GlobalRole. 
+
+:::danger
+
+The wildcard verb `*` also includes the `bind` and `escalate` verbs. This means that giving `*` on GlobalRoles to a user also gives them both `escalate` and `bind`.
+
+:::
+
+##### Custom GlobalRole Examples
+
+To grant permission to escalate only the `test-gr` GlobalRole:
+
+```yaml
+rules:
+- apiGroups:
+  - 'management.cattle.io'
+  resources:
+  - 'globalroles'
+  resourceNames:
+  - 'test-gr'
+  verbs:
+  - 'escalate'
+```
+
+To grant permission to escalate all GlobalRoles:
+
+```yaml
+rules:
+- apiGroups:
+  - 'management.cattle.io'
+  resources:
+  - 'globalroles'
+  verbs:
+  - 'escalate'
+```
+
+To grant permission to create bindings (which bypass escalation checks) to only the `test-gr` GlobalRole:
+
+```yaml
+rules:
+- apiGroups:
+  - 'management.cattle.io'
+  resources:
+  - 'globalroles'
+  resourceNames:
+  - 'test-gr'
+  verbs:
+  - 'bind'
+- apiGroups:
+  - 'management.cattle.io'
+  resources:
+  - 'globalrolebindings'
+  verbs:
+  - 'create'
+```
+
+Granting `*` permissions (which includes both `escalate` and `bind`):
+
+```yaml
+rules:
+- apiGroups:
+  - 'management.cattle.io'
+  resources:
+  - 'globalroles'
+  verbs:
+  - '*'
+```
+
+#### GlobalRole Permissions on Downstream Clusters
+
+GlobalRoles can grant one or more RoleTemplates on every downstream cluster through the `inheritedClusterRoles` field. Values in this field must refer to a RoleTemplate which exists and has a `context` of Cluster.
+
+With this field, users gain the specified permissions on all current or future downstream clusters. For example, consider the following GlobalRole:
+
+```yaml
+apiVersion: management.cattle.io/v3
+kind: GlobalRole
+displayName: All Downstream Owner 
+metadata:
+  name: all-downstream-owner
+inheritedClusterRoles:
+- cluster-owner
+```
+
+Any user with this permission will be a cluster-owner on all downstream clusters. If a new cluster is added, regardless of type, the user will be an owner on that cluster as well.
+
+:::danger
+
+Using this field on [default GlobalRoles](#configuring-default-global-permissions) may result in users gaining excessive permissions.
+
+:::
+
+### Configuring Default Global Permissions
+
+If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
+
+:::note
+
+Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
+
+:::
+
+To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Role Templates**. On the **Role Templates** page, make sure the **Global** tab is selected.
+1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit Config**.
+1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**. If you want to remove a default permission, edit the permission and select **No**.
+
+**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
+
+### Configuring Global Permissions for Individual Users
+
+To configure permission for a user,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Go to the user whose access level you want to change and click **⋮ > Edit Config**.
+1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Role Templates** page, they will appear in the **Custom** section and you can choose from them as well.
+1. Click **Save**.
+
+**Result:** The user's global permissions have been updated.
+
+### Configuring Global Permissions for Groups
+
+If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher.
+
+After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher.
+
+For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships)
+
+For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)
+
+If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
+
+:::note Prerequisites:
+
+You can only assign a global role to a group if:
+
+* You have set up an [external authentication provider](../authentication-config/authentication-config.md#external-vs-local-authentication)
+* The external authentication provider supports [user groups](../authentication-config/manage-users-and-groups.md)
+* You have already set up at least one user group with the authentication provider
+
+:::
+
+To assign a custom global role to a group, follow these steps:
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Groups**.
+1. Go to the group you want to assign a custom global role to and click **⋮ > Edit Config**.
+1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
+1. Click **Create**.
+
+**Result:** The custom global role will take effect when the users in the group log into Rancher.
+
+### Refreshing Group Memberships
+
+When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again.
+
+To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships.
+
+An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group.
+
+To refresh group memberships,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Click **Refresh Group Memberships**.
+
+**Result:** Any changes to the group members' permissions will take effect.
+
 ## Restricted Admin
 
-A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
+:::warning Deprecated
+
+The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
+
+:::
+
+A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
 
 The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
 
@@ -82,170 +355,10 @@ The following table lists the permissions and actions that a `restricted-admin`
 | | Deploy GKE cluster | Yes | Yes | Yes | |
 | | Deploy AKS cluster | Yes | Yes | Yes | |
 
-
 ### Changing Global Administrators to Restricted Admins
 
-If Rancher already has a global administrator, they should change all global administrators over to the new `restricted-admin` role.
+In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach. 
 
 This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
 
 Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
-
-## Global Permission Assignment
-
-Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
-
-### Global Permissions for New Local Users
-
-When you create a new local user, you assign them a global permission as you complete the **Add User** form.
-
-To see the default permissions for new users,
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
-1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **Global** tab, in the **New User Default** column, the permissions given to new users by default are indicated with a checkmark.
-
-You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
-
-### Global Permissions for Users with External Authentication
-
-When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the  **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.
-
-To see the default permissions for new users,
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
-1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **New User Default** column on each page, the permissions given to new users by default are indicated with a checkmark.
-
-You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)
-
-Permissions can be [assigned](#configuring-global-permissions-for-individual-users) to an individual user.
-
-You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
-
-## Custom Global Permissions
-
-Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.
-
-When a user from an [external authentication source](../authentication-config/authentication-config.md) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters.
-
-However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions.
-
-The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role.
-
-Administrators can enforce custom global permissions in multiple ways:
-
-- [Changing the default permissions for new users](#configuring-default-global-permissions)
-- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users)
-- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
-
-### Custom Global Permissions Reference
-
-The following table lists each custom global permission available and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
-
-| Custom Global Permission           | Administrator | Standard User | User-Base |
-| ---------------------------------- | ------------- | ------------- |-----------|
-| Create Clusters                    | ✓             | ✓             |           |
-| Create RKE Templates               | ✓             | ✓             |           |
-| Manage Authentication              | ✓             |               |           |
-| Manage Catalogs                    | ✓             |               |           |
-| Manage Cluster Drivers             | ✓             |               |           |
-| Manage Node Drivers                | ✓             |               |           |
-| Manage PodSecurityPolicy Templates | ✓             |               |           |
-| Manage Roles                       | ✓             |               |           |
-| Manage Settings                    | ✓             |               |           |
-| Manage Users                       | ✓             |               |           |
-| Use Catalog Templates              | ✓             | ✓             |           |
-| User-Base (Basic log-in access)  | ✓             | ✓             |           |
-
-For details on which Kubernetes resources correspond to each global permission,
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
-1.  If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.
-
-:::note Notes:
-
-- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
-- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
-
-:::
-
-### Configuring Default Global Permissions
-
-If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
-
-:::note
-
-Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
-
-:::
-
-To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**. On the **Roles** page, make sure the **Global** tab is selected.
-1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit Config**.
-1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**. If you want to remove a default permission, edit the permission and select **No**.
-
-**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
-
-### Configuring Global Permissions for Individual Users
-
-To configure permission for a user,
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Users**.
-1. Go to the user whose access level you want to change and click **⋮ > Edit Config**.
-1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Roles** page, they will appear in the **Custom** section and you can choose from them as well.
-1. Click **Save**.
-
-**Result:** The user's global permissions have been updated.
-
-### Configuring Global Permissions for Groups
-
-If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher.
-
-After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher.
-
-For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships)
-
-For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)
-
-If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
-
-:::note Prerequisites:
-
-You can only assign a global role to a group if:
-
-* You have set up an [external authentication provider](../authentication-config/authentication-config.md#external-vs-local-authentication)
-* The external authentication provider supports [user groups](../authentication-config/manage-users-and-groups.md)
-* You have already set up at least one user group with the authentication provider
-
-:::
-
-To assign a custom global role to a group, follow these steps:
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Groups**.
-1. Go to the group you want to assign a custom global role to and click **⋮ > Edit Config**.
-1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
-1. Click **Create**.
-
-**Result:** The custom global role will take effect when the users in the group log into Rancher.
-
-### Refreshing Group Memberships
-
-When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again.
-
-To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships.
-
-An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group.
-
-To refresh group memberships,
-
-1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Users**.
-1. Click **Refresh Group Memberships**.
-
-**Result:** Any changes to the group members' permissions will take effect.

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/locked-roles.md

@@ -36,7 +36,7 @@ You can lock roles in two contexts:
 Cluster roles and project/namespace roles can be locked, but global roles cannot.
 
 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1. Go to the **Cluster** tab or the **Project/Namespaces** tab.
 1. From the role that you want to lock (or unlock), select **⋮ > Edit Config**.
 1. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.

docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md

@@ -40,7 +40,7 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
 
 :::note
 
-There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../deploy-apps-across-clusters/fleet.md#troubleshooting) for a workaround.
+There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../../../integrations-in-rancher/fleet/overview.md#troubleshooting) for a workaround.
 
 :::
 

docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md

@@ -1,5 +1,5 @@
 ---
-title: Backups and Disaster Recovery
+title: Backup, Restore, and Disaster Recovery
 keywords: [rancher backup restore, rancher backup and restore, backup restore rancher, rancher backup and restore rancher]
 ---
 

docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md

@@ -8,14 +8,13 @@ title: Migrating Rancher to a New Cluster
 
 If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.
 
-
 ### Prerequisites
 
 These instructions assume that you have [created a backup](back-up-rancher.md) and  already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
 
 :::caution
 
-It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
+You must use the same hostname that was set as the server URL in the original cluster. If you don't, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's **Explore** button.
 
 :::
 
@@ -25,9 +24,9 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
 
 Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.
 
-
 ### 1. Install the rancher-backup Helm chart
-Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
+
+Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
 
   1. Add the Helm repository:
 
@@ -36,13 +35,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
      helm repo update
      ```
 
-  1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
+  1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
+
      ```bash
-     helm search repo --versions rancher-charts/rancher-backup
-     CHART_VERSION=<2.x.x>
+     CHART_VERSION=<chart-version>
      ```
 
   1. Install the charts:
+   
      ```bash
      helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
      helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
@@ -50,33 +50,18 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
 
      :::note
 
-     The above assumes an environment with outbound connectivity to Docker Hub
+     The above assumes an environment with outbound connectivity to Docker Hub.
 
-     For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
+     For an **air-gapped environment**, use the following Helm value to pull the `backup-restore-operator` image from your private registry when you install the rancher-backup Helm chart.
 
      ```bash
-     --set image.repository $REGISTRY/rancher/backup-restore-operator
+     --set image.repository <registry>/rancher/backup-restore-operator
      ```
 
      :::
 
 ### 2. Restore from backup using a Restore custom resource
 
-:::note Important:
-
-Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
-
-1. Update the default `resourceSet` to collect the CRDs with the apiVersion v1.
-1. Update the default `resourceSet` and the client to use the new APIs internally, with `apiextensions.k8s.io/v1` as the replacement.
-
-    :::note
-
-    When making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
-
-    :::
-
-:::
-
 1. When using S3 object storage as the backup source for a restore that requires credentials, create a `Secret` object in this cluster to add the S3 credentials. The secret data must have two keys - `accessKey`, and `secretKey`, that contain the S3 credentials.
 
    The secret can be created in any namespace, this example uses the default namespace.
@@ -187,3 +172,9 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
 ```
 
 :::
+
+### 5. Redirect Traffic to the New Cluster
+
+After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.
+
+Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.

docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md

@@ -79,15 +79,20 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
     1. In the **Clusters** page, go to the cluster where you want to remove nodes.
     1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.
 
-1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
+1. After all etcd nodes are removed, add the new etcd node that you are planning to restore from. Assign the new node the role of `all` (etcd, controlplane, and worker).
 
-    - For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - If the node was previously in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
     - For node driver clusters, a new node is provisioned automatically.
 
     At this point, Rancher will indicate that restoration from etcd snapshot is required.
 
 1. Restore from an etcd snapshot.
 
+    :::note
+    As the etcd node is a clean node, you may need to manually create the `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` path.
+    :::
+
     - For S3 snapshots, restore using the UI.
       1. Click the **Snapshots** tab to view the list of saved snapshots.
       1. Go to the snapshot you want to restore and click **⋮ > Restore**.
@@ -95,7 +100,15 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
       1. Click **Restore**.
     - For local snapshots, restore using the UI is **not** available.
       1. In the upper right corner, click **⋮ > Edit YAML**.
-      1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
+      1. The example YAML below can be added under your `rkeConfig` to configure the etcd restore:
+
+      ```yaml
+        ...
+        rkeConfig:
+          etcdSnapshotRestore:
+            name: <string> # This field is required. Refers to the filename of the associated etcdsnapshot object.
+        ...
+      ```
 
 1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.
 

docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/deploy-apps-across-clusters.md

@@ -1,21 +0,0 @@
----
-title: Deploying Applications across Clusters
----
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
-</head>
-
-Rancher offers several ways to deploy applications across clusters, depending on version.
-
-## Fleet
-
-Rancher v2.5 and later uses Fleet to deploy applications across clusters.
-
-Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section](fleet.md).
-
-## Multi-cluster Apps
-
-In Rancher before v2.5, the multi-cluster apps feature was used to deploy applications across clusters. The multi-cluster apps feature is deprecated, but still available as a legacy feature.
-
-See the [multi-cluster app documentation](multi-cluster-apps.md) for more details.

docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md

@@ -1,71 +0,0 @@
----
-title: Continuous Delivery with Fleet
----
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
-</head>
-
-Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/installation#configuration-for-multi-cluster) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
-
-Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
-
-
-## Architecture
-
-For information about how Fleet works, see [this page.](../../../integrations-in-rancher/fleet/architecture.md)
-
-## Accessing Fleet in the Rancher UI
-
-Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
-
-Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
-
-Follow the steps below to access Continuous Delivery in the Rancher UI:
-
-1. Click **☰ > Continuous Delivery**.
-
-1. Select your namespace at the top of the menu, noting the following:
-    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
-    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
-    - You can then manage clusters by clicking on **Clusters** on the left navigation bar.
-
-1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
-
-1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
-
-1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
-
-## Windows Support
-
-For details on support for clusters with Windows nodes, see [this page.](../../../integrations-in-rancher/fleet/windows-support.md)
-
-
-## GitHub Repository
-
-The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest)
-
-
-## Using Fleet Behind a Proxy
-
-For details on using Fleet behind a proxy, see [this page.](../../../integrations-in-rancher/fleet/use-fleet-behind-a-proxy.md)
-
-## Helm Chart Dependencies
-
-In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.
-
-The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` or run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters.
-
-## Troubleshooting
-
----
-* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
-
-* **Temporary Workaround:** <br/>
-By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
-
----
-
-## Documentation
-
-The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)

docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md

@@ -1,179 +0,0 @@
----
-title: Multi-cluster Apps
----
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps"/>
-</head>
-
-Typically, most applications are deployed on a single Kubernetes cluster, but there will be times you might want to deploy multiple copies of the same application across different clusters and/or projects. In Rancher, a _multi-cluster application_,  is an application deployed using a Helm chart across multiple clusters. With the ability to deploy the same application across multiple clusters, it avoids the repetition of the same action on each cluster, which could introduce user error during application configuration. With multi-cluster applications, you can customize to have the same configuration across all projects/clusters as well as have the ability to change the configuration based on your target project. Since multi-cluster application is considered a single application, it's easy to manage and maintain this application.
-
-Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
-
-After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application.
-
-## Prerequisites
-
-### Permissions
-
-To create a multi-cluster app in Rancher, you must have at least one of the following permissions:
-
-- A [project-member role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) in the target cluster(s), which gives you the ability to create, read, update, and delete the workloads
-- A [cluster owner role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) for the clusters(s) that include the target project(s)
-
-### Enable Legacy Features
-
-Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2.5, you will need to enable multi-cluster apps with a feature flag.
-
-1. In the upper left corner, click **☰ > Global Settings**.
-1. Click **Feature Flags**.
-1. Go to the `legacy` feature flag and click **Activate**.
-
-## Launching a Multi-Cluster App
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-1. Click **Launch**.
-1. Find the application that you want to launch.
-1.  (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
-1. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `<MULTI-CLUSTER_APPLICATION_NAME>-<PROJECT_ID>`.
-1. Select a **Template Version**.
-1. Complete the [multi-cluster applications specific configuration options](#multi-cluster-app-configuration-options) as well as the [application configuration options](#application-configuration-options).
-1. Select the **Members** who can [interact with the multi-cluster application](#members).
-1. Add any [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects) that would change the configuration for specific project(s) from the default application configuration answers.
-1. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
-
-**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
-
-## Multi-cluster App Configuration Options
-
-Rancher has divided the configuration option for the multi-cluster application into several sections.
-
-### Targets
-
-In the **Targets** section, select the projects that you want the application to be deployed in. The list of projects is based on what projects you have access to. For each project that you select, it will be added to the list, which shows the cluster name and project name that were selected. To remove a target project, click on **-**.
-
-### Upgrades
-
-In the **Upgrades** section, select the upgrade strategy to use, when you decide to upgrade your application.
-
-* **Rolling Update (batched):** When selecting this upgrade strategy, the number of applications upgraded at a time is based on the selected **Batch size** and the **Interval** specifies how many seconds to wait before starting the next batch of updates.
-
-* **Upgrade all apps simultaneously:** When selecting this upgrade strategy, all applications across all projects will be upgraded at the same time.
-
-### Roles
-
-In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications](../helm-charts-in-rancher/helm-charts-in-rancher.md), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
-
-For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
-
-Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions.
-
-- **Project** - This is the equivalent of a [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or a [project owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles), then the user is considered to have the appropriate level of permissions.
-
-- **Cluster** - This is the equivalent of a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), then the user is considered to have the appropriate level of permissions.
-
-When launching the application, Rancher will confirm if you have these permissions in the target projects before launching the application.
-
-:::note
-
-There are some applications like _Grafana_ or _Datadog_ that require access to specific cluster-scoped resources. These applications will require the _Cluster_ role. If you find out later that the application requires cluster roles, the multi-cluster application can be upgraded to update the roles.
-
-:::
-
-## Application Configuration Options
-
-For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
-
-:::note Example
-
-When entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
-
-:::
-
-### Using a questions.yml file
-
-If the Helm chart that you are deploying contains a `questions.yml` file, Rancher's UI will translate this file to display an easy to use UI to collect the answers for the questions.
-
-### Key Value Pairs for Native Helm Charts
-
-For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a custom Helm chart repository, answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
-
-### Members
-
-By default, multi-cluster applications can only be managed by the user who created it. In the **Members** section, other users can be added so that they can also help manage or view the multi-cluster application.
-
-1. Find the user that you want to add by typing in the member's name in the **Member** search box.
-
-2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean.
-
-    - **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#Multi-cluster App Configuration Options), the [application specific configuration options](#application-configuration-options), the members who can interact with the multi-cluster application and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type.
-
-    - **Member**: This access type can only modify the template version, the [application specific configuration options](#application-configuration-options) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _member_ of the multi-cluster application can modify the application without explicitly having access to these project(s). Only trusted users should be provided with this access type.
-
-    - **Read-only**: This access type cannot modify any configuration option for the multi-cluster application. Users can only view these applications.
-
-    :::caution
-
-    Please ensure only trusted users are given _Owner_ or _Member_ access as they will automatically be able to manage applications created for this multi-cluster application in target projects they might not have direct access to.
-
-    :::
-
-### Overriding Application Configuration Options for Specific Projects
-
-The ability to use the same configuration to deploy the same application across multiple clusters/projects is one of the main benefits of multi-cluster applications. There might be a specific project that requires a slightly different configuration option, but you want to manage that application with all the other matching applications. Instead of creating a brand new application, you can override specific [application specific configuration options](#application-configuration-options) for specific projects.
-
-1. In the **Answer Overrides** section, click **Add Override**.
-
-2. For each override, you can select the following:
-
-    - **Scope**: Select which target projects you want to override the answer in the configuration option.
-
-    - **Question**: Select which question you want to override.
-
-    - **Answer**: Enter the answer that you want to be used instead.
-
-## Upgrading Multi-Cluster App Roles and Projects
-
-- **Changing Roles on an existing Multi-Cluster app**
-The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`.
-
-- **Adding/Removing target projects**
-1. The creator and any users added with access-type "owner" to a multi-cluster app, can add or remove its target projects. When adding a new project, we check if the caller of this request has all Roles defined on multi-cluster app, in the new projects they want to add. The roles checks are again relaxed for global admins, cluster-owners and project-owners.
-2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list.
-
-
-## Multi-Cluster Application Management
-
-One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.
-
-:::note Prerequisite:
-
-The `legacy` feature flag needs to be enabled.
-
-:::
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-
-2. Choose the multi-cluster application you want to take one of these actions on and click the **⋮**. Select one of the following options:
-
-   * **Clone**: Creates another multi-cluster application with the same configuration. By using this option, you can easily duplicate a multi-cluster application.
-   * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members).
-   * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue.
-
-## Deleting a Multi-Cluster Application
-
-:::note Prerequisite:
-
-The `legacy` feature flag needs to be enabled.
-
-:::
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-
-2. Choose the multi-cluster application you want to delete and click the **⋮ > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
-
-   :::note
-
-   The applications in the target projects, that are created for a multi-cluster application, cannot be deleted individually. The applications can only be deleted when the multi-cluster application is deleted.
-
-   :::

docs/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md

@@ -1,20 +1,48 @@
 ---
-title: Helm Charts in Rancher
+title: Helm Charts and Apps
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
 </head>
 
-In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps**. It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+In this section, you'll learn how to manage Helm chart repositories and apps in Rancher. 
+
+## How Helm Charts Work in Rancher
+
+Helm chart repositories in Rancher are managed using **Apps**.
+
+Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
+
+### Catalogs, Apps, and the Rancher UI
+
+[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. 
+
+Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature. 
+
+Since Rancher v2.6.5, the **Apps & Marketplace** feature is named **Apps** in the UI.
 
 ### Versioning Scheme
 
 The Rancher feature charts versioning scheme is centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.
 
-**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps** charts are also upgraded to the correct release line for the chart.
+**Major Version:** The major versions of feature charts are tied to particular minor versions of Rancher. When you upgrade to a new Rancher minor version, you should ensure that all of your feature charts are also upgraded to the correct release line for the chart.
 
-**Feature Charts:**
+**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
+
+When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+
+#### Prerelease Versions
+
+Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
+
+To display prerelease versions:
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Preferences**.
+1. Under **Helm Charts**, select **Include Prerelease Versions**.
+
+### Feature Charts
 
 | **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
 | ---------------- | ------------ | ------------ |
@@ -30,56 +58,87 @@ The Rancher feature charts versioning scheme is centered around the major versio
 | 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 (experimental) | 100.0.0+up0.1.0 | 100.0.3+up0.1.0 |
+| 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 |
 
-<br/>
-**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
+## Access Charts
 
-- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
+The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:
 
-- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
+* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
+* Partner charts are under the **Partners** label.
+* Custom charts are listed under the name of their respective repository.
 
-### Prerelease Versions
-
-Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
-
-To display prerelease versions:
-
-1. Click on your user avatar in the upper right corner.
-1. Click **Preferences**.
-1. Under **Helm Charts**, select **Include Prerelease Versions**.
-
-### Charts
-
-From the top-left menu select _"Apps"_ and you will be taken to the Charts page.
-
-The charts page contains all Rancher, Partner, and Custom Charts.
-
-* Rancher tools such as Logging or Monitoring are included under the Rancher label
-* Partner charts reside under the Partners label
-* Custom charts will show up under the name of the repository
-
-All three types are deployed and managed in the same way.
+All three types of charts are deployed and managed in the same way.
 
 :::note
 
-Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps</b> in the new UI must be managed only by <b>Apps</b>.
+Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) continue to be managed only by the Cluster Manager, and apps managed with **Apps** in the new UI must be managed only by **Apps**.
 
 :::
 
-### Repositories
+To access the **Charts** page:
 
-From the left sidebar select _"Repositories"_.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
 
-These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+## Manage Repositories
 
-To add a private CA for Helm Chart repositories:
+The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.
 
-- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
+To access the **Repositories** page:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+
+### Add Custom Git Repositories
+
+To add a custom Git repository that contains your Helm charts or cluster template definitions:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Click **Create**.
+1. Select the target, **Git repository containing Helm chart...**.
+1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
+1. Click **Create** to add the repository. 
+
+After you add a chart repository to Rancher, it becomes available immediately.
+
+### Add Custom Helm Chart Repositories
+
+You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.
+
+For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).
+
+To add a custom Helm chart repository to Rancher:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Click **Create**.
+1. Select the target, **http(s) URL to an index generated by Helm**.
+1. Enter a repo name and the index URL address of the chart repository.
+1. Click **Create** to add the repository. 
+
+### Add Private Git/Helm Chart Repositories
+
+You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.
+
+### Add a Private CA to Repositories
+
+To add a private CA to Helm chart repositories, you must add a base64 encoded copy of the CA certificate in DER format to the `spec.caBundle field` of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Instructions are the same for both Git-based and HTTP-based repositories:
+
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Find the row associated with the Git-based or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
+1. Set the `caBundle` value, as in the following example:
+
+  ```yaml
     [...]
     spec:
       caBundle:
@@ -87,25 +146,13 @@ To add a private CA for Helm Chart repositories:
     ...
     nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
     [...]
-    ```
-
-
-- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
-    ```
-    [...]
-    spec:
-      caBundle:
-    MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
-    ...
-    nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
-    [...]
-    ```
+  ```
 
 :::note Helm chart repositories with authentication
 
-The Repo.Spec contains a `disableSameOriginCheck` value that allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
+The Repo.Spec contains a `disableSameOriginCheck` value. This value allows you to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories, such as those that have redirects to a different origin URL.
 
-To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+To use this feature for an existing Helm chart repository, follow previous steps up to edit the YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
 
 ```yaml
 [...]
@@ -116,41 +163,107 @@ spec:
 
 :::
 
+### Add Custom OCI Chart Repositories
+
+:::caution
+
+This feature is currently experimental and is not officially supported in Rancher.
+
+:::
+
+Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means you can deploy apps that are stored as OCI artifacts. For more information, see [Using OCI Helm Chart Repositories](./oci-repositories.md).
+
 ### Helm Compatibility
 
 Only Helm 3 compatible charts are supported.
 
+### Refresh Chart Repositories
 
-### Deployment and Upgrades
+The **Refresh** button can be used to sync changes from selected Helm chart repositories on the **Repositories** page.
 
-From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
+To refresh a chart repository:
 
-To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Use the toggle next to the **State** field to select all repositories, or toggle specified chart repositories to sync changes.
+1. Click **Refresh**.
+1. The **⋮** at the end of each chart repository row also includes a **Refresh** option, which can be clicked to refresh the respective repository.
 
-After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
+Non-Airgap Rancher installations upon refresh will reflect any chart repository changes immediately and you will see the **State** field for updated repositories move from `In Progress` to `Active` once the action is completed.
 
-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.
+Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
+
+## Deploy and Upgrade Charts
+
+To install and deploy a chart:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
+1. Select a chart, and click **Install**. 
+
+Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
+
+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. 
+
+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.
 
 :::caution
 
-If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
+If you are upgrading your chart using **Customize Helm options before upgrade**, and your chart contains immutable fields, using the `--force` option may result in errors. This is because some objects in Kubernetes can't be changed after they're created. To prevent this error:
 
-  * use the default upgrade option ( i.e do not use _"--force"_ option )
-  * uninstall the existing chart and install the upgraded chart
-  * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
+  * Use the default upgrade option (i.e don't use `--force`).
+  * Uninstall the existing chart and install the upgraded chart.
+  * Delete the resources with immutable fields from the cluster before performing a forced upgrade.
 
 :::
 
-#### Legacy Apps
+### Legacy Apps
 
-The upgrade button has been removed for legacy apps from the **Apps > Installed Apps** page.
+The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.
 
-If you have a legacy app installed and want to upgrade it:
+If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.
 
-- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
-- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
-- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
+1. Enable the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md), if it isn't enabled already.
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose apps you want to access. Click **Explore** at the end of the cluster's row.
+1. Click **Legacy > Project > Apps**.
 
-### Limitations
+If you don't see **Apps** listed under **Legacy > Project**, click the project/namespace search bar in the top navigation and select the relevant project from the dropdown menu.
 
-Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
+To upgrade legacy multi-cluster apps:
+
+1. Click **☰**. 
+1. Under **Legacy Apps**, click **Multi-cluster Apps**.
+
+### Chart-Specific Information
+
+#### sriov Chart Deprecation and Migration
+
+The `sriov` (SR-IOV network operator) chart from the Rancher Charts repository is deprecated and will be removed in Rancher v2.10. Please migrate to the `sriov-network-operator` chart from the SUSE Edge repository (https://github.com/suse-edge/charts) instead.
+
+To migrate, follow these steps:
+
+1. Add the SUSE Edge repository to your cluster by following the steps in [Add Custom Git Repositories](#add-custom-git-repositories).
+1. For the **Git Repo URL** field, enter `https://github.com/suse-edge/charts`.
+1. Click **Create**.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
+1. Find the `sriov-network-operator` chart and click on it.
+1. Click **Install**.
+1. In the **Name** field, enter the same name you used for your existing `sriov` chart installation.
+1. Click **Next**.
+1. Click **Install**.
+
+**Result:** Rancher redirects to the **Installed Apps** page where your existing installation enters the **Updating** state. The migration is complete when it enters the **Deployed** state.
+
+## Limitations
+
+- Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
+
+- 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.
+  

docs/how-to-guides/new-user-guides/helm-charts-in-rancher/oci-repositories.md

@@ -0,0 +1,115 @@
+---
+title: Using OCI-Based Helm Chart Repositories
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/oci-registries"/>
+</head>
+
+:::caution
+
+This feature is currently experimental and is not officially supported in Rancher.
+
+:::
+
+Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means that you can deploy apps that are stored as OCI artifacts.
+
+## Add an OCI-Based Helm Chart Repository
+
+To add an OCI-based Helm chart repository through the Rancher UI:
+
+1. Click **☰ > Cluster Management**.
+2. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+3. In the left navigation bar, select **Apps > Repositories**.
+4. Click **Create**.
+5. Enter a **Name** for the registry. Select **OCI Repository** as the target.
+6. Enter the **OCI Repository Host URL** for the registry. The registry endpoint must not contain anything besides OCI Helm Chart artifacts. The artifacts should all have unique names. If you attempt to add an endpoint that contains any other kinds of files or artifacts, the OCI repository will not be added. 
+  
+  :::note
+  
+  You can use the **OCI URL** field to fine-tune how many charts from the registry are available for installation on Rancher. More generic endpoints target more charts, as the following examples demonstrate:
+
+    - `oci://<registry-host>`: Every chart in the registry becomes available for installation, regardless of namespace or tag.
+    - `oci://<registry-host>/<namespace>`: Every chart in the specified namespace within the registry becomes available for installation.
+    - `oci://<registry-host>/<namespace>/<chart-name>`: Only the specified chart and any associated tags or versions of that chart become available for installation.
+    - `oci://<registry-host>/<namespace>/<chart-name>:<tag>`: Only the chart with the specified tag becomes available for installation.
+  
+  :::
+
+7. Set up authentication. Select **Basicauth** from the authentication field and enter a username and password as required. Otherwise, create or select an **Authentication** secret. See [Authentication](#authentication-for-oci-based-helm-chart-repositories) for a full description.
+8. (optional) Enter a base64 encoded DER certificate in the **CA Cert Bundle** field. This field is for cases where you have a private OCI-based Helm chart repository and need Rancher to trust its certificates.   
+9. (optional) To allow insecure connections without performing an SSL check, select **Skip TLS Verification**. To force Rancher to use HTTP instead of HTTPS to send requests to the repository, select **Insecure Plain Http**.
+10. (optional) If your repository has a rate limiting policy and may respond with status code `429 Too Many Requests`, you may want to fill out the fields under **Exponential Back Off**:
+    - **Min Wait**: The minimum duration in seconds that Rancher should wait before retrying. The default is 1 second.
+    - **Max Wait**: The maximum duration in seconds that Rancher should wait before retrying. The default is 5 second.
+    - **Max Number of Retries**: The default is 5 retries.
+
+    Once these values are set, Rancher responds to the `429` status code by staggering requests based on the minimum and maximum wait values. The wait time between retries increases exponentially, until Rancher has sent the maximum number of retries set. See [Rate Limiting](#rate-limiting-of-oci-based-helm-chart-repositories) for more details.
+11. Add any labels and annotations.
+12. Click **Create**.
+
+It may take some time for the OCI repository to activate. This is particularly true if the OCI endpoint contains multiple namespaces. 
+
+## Authentication for OCI-Based Helm Chart Repositories
+
+Rancher supports BasicAuth for OCI registries. You must create a [**BasicAuth** Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret). You can also [create the secret through the Rancher UI](../kubernetes-resources-setup/secrets.md). 
+
+
+The CRD that is linked to the OCI-based Helm repository is `ClusterRepo`.
+
+## View Helm Charts in OCI-Based Helm Chart Repositories
+
+To view Helm charts in the OCI-based Helm chart repository after it achieves an `Active` state:
+
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
+1. Click **Apps > Charts**.
+1. Select the OCI-based Helm chart repository from the dropdown.
+
+## Refresh an OCI-Based Helm Chart Repository
+
+Rancher automatically refreshes the OCI-based Helm chart repository every 6 hours. 
+
+If you need to update immediately, you can [perform a manual refresh](../helm-charts-in-rancher/helm-charts-in-rancher.md#refresh-chart-repositories).
+
+## Update an OCI-Based Helm Chart Repository Configuration
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation bar, select **Apps > Repositories**.
+1. Find the row associated with the OCI-based Helm chart repository, and click **⋮**.
+1. From the submenu, select **Edit Config**.
+
+## Delete an OCI-Based Helm Chart Repository
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation bar, select **Apps > Repositories**.
+1. Select the row associated with the OCI-based Helm chart repository, and click **Delete**.
+
+## Size Limitations of OCI-Based Helm Chart Repositories in Rancher
+
+Due to security concerns, there are limitations on how large of a Helm chart you can deploy through an OCI-based repository, and how much metadata you can use to describe the Helm charts within a single OCI endpoint.
+
+Rancher can deploy OCI Helm charts up to 20 MB in size.
+
+## Rate Limiting of OCI-Based Helm Chart Repositories
+
+Different OCI registries implement rate limiting in different ways. 
+
+Most servers return a `Retry-After` header, indicating how long to wait before rate limiting is lifted. 
+
+Docker Hub returns a `429` status code when it completes all allocated requests. It also returns a `RateLimit-Remaining` header which describes the rate limiting policy. 
+
+Rancher currently checks for the `Retry-After` header. It also handles Docker Hub-style responses (status code `429` and the `RateLimit-Remaining` header) and automatically waits before making a new request. When handling `Retry-After` or Docker Hub-style responses, Rancher ignores `ExponentialBackOff` values. 
+
+If you have an OCI-based Helm chart repository which doesn't implement the `Retry-After` or `RateLimit-Remaining` headers, and think you may be rate-limited at some point, fill out the fields under **Exponential Back Off** when you add the repository. 
+
+For example, if you have an OCI-based Helm chart repository that doesn't return a `Retry-After` header, but you know that the server allows 50 requests in 24 hours, you can provide Rancher a **Min Wait** value of **86400** seconds, a **Max Wait** value of **90000** seconds, and a **Max Number of Retries** value of **1**. Then, if Rancher gets rate limited by the server, Rancher will wait for 24 hours before trying again. The request should succeed as Rancher hasn't sent any other requests in the previous 24 hours.
+
+## Troubleshooting OCI-based Helm Registries
+
+- To enhance logging information, [enable the debug option](../../../troubleshooting/other-troubleshooting-tips/logging.md#kubernetes-install) while deploying Rancher.
+
+- If there is any discrepancy between the repository contents and Rancher, you should refresh the cluster repository as a first resort. If the discrepancy persists, delete the OCI-based Helm chart repository from Rancher and add it again. Deleting the repository won't delete any Helm charts that are already installed.
+
+- Apps installed through OCI-based Helm chart repositories are subject to a known issue with how Rancher displays upgradeable version information. See the [Limitations](./helm-charts-in-rancher.md#limitations) section of **Helm Charts and Apps** for more details.

docs/how-to-guides/new-user-guides/infrastructure-setup/infrastructure-setup.md

@@ -1,12 +1,13 @@
 ---
-title: Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.
+title: Infrastructure Setup
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup"/>
 </head>
 
-To set up infrastructure for a high-availability K3s Kubernetes cluster with an external DB, refer to [this page.](ha-k3s-kubernetes-cluster.md)
+Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.
 
+To set up infrastructure for a high-availability K3s Kubernetes cluster with an external database, refer to [this page.](ha-k3s-kubernetes-cluster.md)
 
 To set up infrastructure for a high-availability RKE Kubernetes cluster, refer to [this page.](ha-rke1-kubernetes-cluster.md)

docs/how-to-guides/new-user-guides/kubernetes-cluster-setup/kubernetes-cluster-setup.md

@@ -1,11 +1,13 @@
 ---
-title: "Don't have a Kubernetes cluster? Try one of these tutorials."
+title: Setting up a Kubernetes Cluster for Rancher Server
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup"/>
 </head>
 
+Don't have a Kubernetes cluster? Try one of these tutorials.
+
 This section contains information on how to install a Kubernetes cluster that the Rancher server can be installed on.
 
 Rancher can run on any Kubernetes cluster.

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md

@@ -49,5 +49,5 @@ number of nodes for each Kubernetes role, refer to the section on [recommended a
 
 ### Networking
 
-* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://coreos.com/etcd/docs/latest/tuning.html) allow etcd to run in most networks (except really high latency networks).
+* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://etcd.io/docs/v3.5/tuning/) allow etcd to run in most networks (except really high latency networks).
 * Cluster nodes should be located within a single region. Most cloud providers provide multiple availability zones within a region, which can be used to create higher availability for your cluster. Using multiple availability zones is fine for nodes with any role. If you are using [Kubernetes Cloud Provider](../set-up-cloud-providers/set-up-cloud-providers.md) resources, consult the documentation for any restrictions (i.e. zone storage restrictions).

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md

@@ -57,7 +57,7 @@ The number of nodes that you can lose at once while maintaining cluster availabi
 
 References:
 
-* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
+* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance)
 * [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
 
 ### Number of Worker Nodes

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md

@@ -1,5 +1,5 @@
 ---
-title: Setting up Kubernetes Clusters in Rancher
+title: Kubernetes Clusters in Rancher Setup
 description: Provisioning Kubernetes Clusters
 ---
 

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon.md

@@ -6,13 +6,13 @@ title: Migrating Amazon In-tree to Out-of-tree
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon"/>
 </head>
 
-Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed.
+Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes v1.27 and later, the in-tree cloud providers have been removed. The Rancher UI allows you to upgrade to Kubernetes v1.27 when you migrate from an in-tree to out-of-tree provider. 
 
-You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
+However, if you're performing a manual migration, existing clusters must upgrade to Kubernetes v1.27 after you migrate in order to remain functional.
 
 To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.
 
-If it's acceptable to have some downtime, you can [switch to an external cloud provider](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider), which removes in-tree components and then deploy charts to install the AWS cloud controller manager.
+If it's acceptable to have some downtime during migration, follow the instructions to [set up an external cloud provider](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). These instructions outline how to configure the out-of-tree cloud provider for a newly provisioned cluster. During set up, there will be some downtime, as there is a time gap between when the old cloud provider stops running and when the new cloud provider starts to run.
 
 If your setup can't tolerate any control plane downtime, you must enable leader migration. This facilitates a smooth transition from the controllers in the kube controller manager to their counterparts in the cloud controller manager. Refer to the official AWS documentation on [Using leader migration](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for more details.
 
@@ -52,7 +52,7 @@ spec:
 2. Cordon control plane nodes so that AWS cloud controller pods run on nodes only after upgrading to the external cloud provider:
 
 ```shell
-kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
+kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
 ```
 
 3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure.md

@@ -0,0 +1,211 @@
+---
+title: Migrating Azure In-tree to Out-of-tree
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure"/>
+</head>
+
+Kubernetes is moving away from maintaining cloud providers in-tree.
+
+Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider or migrate from in-tree cloud provider to out-of-tree provider. You can disable the required feature gates by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
+
+In Kubernetes v1.30 and later, the in-tree cloud providers have been removed. Rancher allows you to upgrade to Kubernetes v1.30 when you migrate from an in-tree to out-of-tree provider.
+
+To migrate from the in-tree cloud provider to the out-of-tree Azure cloud provider, you must stop the existing cluster's kube controller manager and install the Azure cloud controller manager.
+
+If it's acceptable to have some downtime during migration, follow the instructions to [set up an external cloud provider](../set-up-cloud-providers/azure.md#using-the-out-of-tree-azure-cloud-provider). These instructions outline how to configure the out-of-tree cloud provider for a newly provisioned cluster. During set up, there will be some downtime, as there is a time gap between when the old cloud provider stops running and when the new cloud provider starts to run.
+
+If your setup can't tolerate any control plane downtime, you must enable leader migration. This facilitates a smooth transition from the controllers in the kube controller manager to their counterparts in the cloud controller manager.
+
+:::note Important:
+The Kubernetes [cloud controller migration documentation](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#before-you-begin) states that it's possible to migrate with the same Kubernetes version, but assumes that the migration is part of a Kubernetes upgrade. Refer to the Kubernetes documentation on [migrating to use the cloud controller manager](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/) to see if you need to customize your setup before migrating. Confirm your [migration configuration values](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#default-configuration). If your cloud provider provides an implementation of the Node IPAM controller, you also need to [migrate the IPAM controller](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/#node-ipam-controller-migration).
+
+Starting with Kubernetes v1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and no longer supported. There are no plans to remove these drivers following their deprecation, however you should migrate to the corresponding CSI drivers, `disk.csi.azure.com` and `file.csi.azure.com`. To review the migration options for your storage classes and upgrade your cluster to use Azure Disks and Azure Files CSI drivers, see [Migrate from in-tree to CSI drivers](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
+:::
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+1. Update the cluster config to enable leader migration:
+
+```yaml
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          kube-controller-manager-arg:
+            - enable-leader-migration
+        machineLabelSelector:
+          matchExpressions:
+            - key: rke.cattle.io/control-plane-role
+              operator: In
+              values:
+                - 'true'
+```
+
+Note that the cloud provider is still `azure` at this step:
+
+```yaml
+spec:
+  rkeConfig:
+    machineGlobalConfig:
+      cloud-provider-name: azure
+```
+
+2. Cordon control plane nodes so that Azure cloud controller pods run on nodes only after upgrading to the external cloud provider:
+
+```shell
+kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
+```
+
+3. To deploy the Azure cloud controller manager, use any of the available options: 
+- UI: Follow steps 1-10 of [Helm chart installation from UI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-ui) to install the cloud controller manager chart.
+- CLI: Follow steps 1-4 of [Helm chart installation from CLI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-cli).
+- Update the cluster's additional manifest: Follow steps 2-3 to [install the cloud controller manager chart](../set-up-cloud-providers/azure.md#using-the-out-of-tree-azure-cloud-provider).
+
+Confirm that the chart is installed but that the new pods aren't running yet due to cordoned controlplane nodes.
+
+4. To enable leader migration, add `--enable-leader-migration` to the container arguments of `cloud-controller-manager`:
+
+```shell 
+kubectl -n kube-system patch deployment cloud-controller-manager \
+--type=json \
+-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
+```
+
+5. Update the provisioning cluster to change the cloud provider and remove leader migration args from the kube controller manager.
+   If upgrading the Kubernetes version, set the Kubernetes version as well in the `spec.kubernetesVersion` section of the cluster YAML file.
+
+```yaml
+spec:
+  rkeConfig:
+    machineGlobalConfig:
+      cloud-provider-name: external
+```
+
+Remove `enable-leader-migration` from the kube controller manager:
+
+```yaml
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          kube-controller-manager-arg:
+            - enable-leader-migration
+        machineLabelSelector:
+          matchExpressions:
+            - key: rke.cattle.io/control-plane-role
+              operator: In
+              values:
+                - 'true'
+```
+
+6. Uncordon control plane nodes so that Azure cloud controller pods now run on nodes:
+
+```shell
+kubectl uncordon -l "node-role.kubernetes.io/control-plane=true"
+```
+
+7. Update the cluster. The `cloud-controller-manager` pods should now be running.
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+8. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+9. (Optional) You can also disable leader migration after the upgrade, as leader migration is not required with only one cloud-controller-manager.
+    Update the `cloud-controller-manager` deployment to remove leader migration from the container arguments:
+
+```yaml
+- --enable-leader-migration=true 
+```
+
+</TabItem>
+
+<TabItem value="RKE">
+
+1. Update the cluster config to enable leader migration in `cluster.yml`:
+
+```yaml
+services:
+  kube-controller:
+    extra_args:
+      enable-leader-migration: "true"
+```
+
+Note that the cloud provider is still `azure` at this step:
+
+```yaml
+cloud_provider:
+  name: azure
+```
+
+2. Cordon the control plane nodes, so that Azure cloud controller pods run on nodes only after upgrading to the external cloud provider:
+
+```shell
+kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
+```
+
+3. To install the Azure cloud controller manager, follow the same steps as when installing Azure cloud provider on a new cluster:
+- UI: Follow steps 1-10 of [Helm chart installation from UI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-ui) to install the cloud controller manager chart.
+- CLI: Follow steps 1-4 of [Helm chart installation from CLI](../set-up-cloud-providers/azure.md#helm-chart-installation-from-cli) to install the cloud controller manager chart.
+
+4. Confirm that the chart is installed but that the new pods aren't running yet due to cordoned controlplane nodes. After updating the cluster in the next step, RKE will upgrade and uncordon each node, and schedule `cloud-controller-manager` pods.
+
+5. To enable leader migration, add `--enable-leader-migration` to the container arguments of `cloud-controller-manager`:
+
+```shell 
+kubectl -n kube-system patch deployment cloud-controller-manager \
+--type=json \
+-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
+```
+
+6. Update `cluster.yml` to change the cloud provider to `external` and remove the leader migration arguments from the kube-controller.
+
+```yaml
+rancher_kubernetes_engine_config:
+  cloud_provider:
+    name: external
+```
+
+Remove `enable-leader-migration` if you don't want it enabled in your cluster:
+
+```yaml
+services:
+  kube-controller:
+    extra_args:
+      enable-leader-migration: "true"
+```
+
+7. If you're upgrading the cluster's Kubernetes version, set the Kubernetes version as well.
+
+8. Update the cluster. The `cloud-controller-manager` pods should now be running. 
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+9. The cloud provider is responsible for setting the ProviderID of the node. Verify that all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+10. (Optional) You can also disable leader migration after the upgrade, as leader migration is not required with only one cloud-controller-manager.
+    Update the `cloud-controller-manager` deployment to remove leader migration from the container arguments:
+
+```yaml
+- --enable-leader-migration=true 
+```
+
+</TabItem>
+</Tabs>
+

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-vsphere.md

@@ -1,12 +1,12 @@
 ---
-title: Migrating vSphere In-tree to Out-of-tree
+title: Migrating VMware vSphere In-tree to Out-of-tree
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-vsphere"/>
 </head>
 
-Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
+Kubernetes is moving away from maintaining cloud providers in-tree. VMware vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
 
 This page covers how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration.
 

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md

@@ -108,7 +108,7 @@ Regarding CPU and memory, it is recommended that the different planes of Kuberne
 
 For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
 
-For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/)
+For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.5/op-guide/hardware/)
 
 ## Networking Requirements
 

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md

@@ -184,9 +184,7 @@ To prevent issues when upgrading, the [Kubernetes upgrade best practices](https:
 
 ## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
 
-_Available as of v2.6.3_
-
-Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
+Rancher supports Authorized Cluster Endpoints (ACE) for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
 
 :::note Notes:
 

docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/amazon.md

@@ -332,7 +332,7 @@ Refer to the offical AWS upstream documentation for the [cloud controller manage
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2">
 
-Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
 
 1. Add the Helm repository:
 
@@ -352,9 +352,9 @@ tolerations:
     value: 'true'
   - effect: NoSchedule
     value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 args:
   - --configure-cloud-routes=false
   - --use-service-account-credentials=true
@@ -465,7 +465,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
 
 <TabItem value="RKE">
 
-Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
 
 1. Add the Helm repository:
 
@@ -639,7 +639,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
       - get
 ```
 
-9. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+9. Rancher-provisioned RKE2 nodes are tainted `node-role.kubernetes.io/control-plane`. Update tolerations and the nodeSelector:
 
 ```yaml
 tolerations:
@@ -648,13 +648,13 @@ tolerations:
     value: 'true'
   - effect: NoSchedule
     value: 'true'
-    key: node-role.kubernetes.io/controlplane
+    key: node-role.kubernetes.io/control-plane
 
 ```
 
 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```
 
 :::note
@@ -663,7 +663,7 @@ There's currently a [known issue](https://github.com/rancher/dashboard/issues/92
 
 ```yaml
 nodeSelector:
-  node-role.kubernetes.io/controlplane: 'true'
+  node-role.kubernetes.io/control-plane: 'true'
 ```
 
 :::
@@ -737,7 +737,7 @@ nodeSelector:
 10. Install the chart and confirm that the Daemonset `aws-cloud-controller-manager` deploys successfully:
 
 ```shell
-kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
+kubectl rollout status deployment -n kube-system aws-cloud-controller-manager
 ```
 
 </TabItem>