Merge release/v2.8.8 into main (#1479)

* 2.8.8 versions table entry

* 2.8.8 webhook table entry

* 2.8.8 csp adapter entry

* 2.8.8 deprecated features entry

.github/dependabot.yml

@@ -0,0 +1,8 @@
+version: 2
+
+updates:
+  - package-ecosystem: gitsubmodule
+    schedule:
+        interval: "daily"
+    directory: /
+    

.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

@@ -4,16 +4,18 @@ on:
   push:
     branches:
       - main
+    paths-ignore:
+      - '**/README.md'
 
 jobs:
-  deploy:
+  build:
-    name: Deploy to GitHub Pages
+    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 +24,28 @@ jobs:
         run: yarn install --frozen-lockfile
       - name: Build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=5120"
+          NODE_OPTIONS: "--max_old_space_size=7168"
         run: yarn build --no-minify
 
-      # Popular action to deploy to GitHub Pages:
+      - name: Upload Build Artifact
-      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
+        uses: actions/upload-pages-artifact@v3
-      - name: Deploy to GitHub Pages
-        uses: peaceiris/actions-gh-pages@v3
         with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
+          path: build
-          # Build output to publish to the `gh-pages` branch:
+
-          publish_dir: ./build
+  deploy:
-          # The following lines assign commit authorship to the official
+    name: Deploy to GitHub Pages
-          # GH-Actions bot for deploys to `gh-pages` branch:
+    needs: build
-          # 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.
+    permissions:
-          # You can swap them out with your own user credentials.
+      pages: write
-          user_name: github-actions[bot]
+      id-token: write
-          user_email: 41898282+github-actions[bot]@users.noreply.github.com
+    
+    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

@@ -2,16 +2,18 @@ name: Test deployment
 
 on:
   pull_request:
-    branches:
+    paths-ignore:
-      - main
+      - '**/README.md'
 
 jobs:
   test-deploy:
     name: Test deployment
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v3
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
         with:
           node-version: 18
           cache: yarn
@@ -19,10 +21,10 @@ jobs:
       - name: Install dependencies
         run: yarn install --frozen-lockfile
       - name: Check Markdown links
-        run: yarn run remark --quiet --use remark-validate-links ./docs
+        run: yarn run remark --quiet --frail --use remark-validate-links ./docs
       - name: Check External links
         run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
       - name: Test build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=5120"
+          NODE_OPTIONS: "--max_old_space_size=7168"
         run: yarn build --no-minify

.github/workflows/vale.yml

@@ -0,0 +1,61 @@
+# 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:
+    paths-ignore:
+      - '**/README.md'
+
+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/suse-vale-styleguide
+
+[formtats]
+mdx = md
+
+[*.md]
+BasedOnStyles = common

CODEOWNERS

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

README.md

@@ -15,19 +15,29 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t
 
 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).
 
-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of December 2023, the most recently released version of Rancher is 2.8.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.
 
-Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.8`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
+Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
 
 If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each affected version, as well as the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).
 
 ### 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

@@ -1,7 +1,12 @@
 ---
 title: API Reference
+hide_table_of_contents: true
 ---
 
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
+</head>
+
 :::note
 
 At this time, not all Rancher resources are available through the Rancher Kubernetes API.

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,8 +1,12 @@
 ---
-title: API Quick Start Guide
+title: RK-API Quick Start Guide
 ---
 
-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.
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/quickstart"/>
+</head>
+
+You can access Rancher's resources through the Kubernetes API. This guide helps you get started on using this API as a Rancher user.
 
 1. In the upper left corner, click **☰ > Global Settings**.
 2. Find and copy the address in the `server-url` field.
@@ -125,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

@@ -2,6 +2,10 @@
 title: Projects
 ---
 
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/projects"/>
+</head>
+
 ## Creating a Project
 
 Project resources may only be created on the management cluster. See below for [creating namespaces under projects in a managed cluster](#creating-a-namespace-in-a-project).
@@ -25,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/).
@@ -107,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,28 +3,23 @@ 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).
 
-### Where can I find out which features have been deprecated in Rancher?
+## Where can I find out which features have been deprecated in Rancher?
 
 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
 
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) |  Aug 31, 2021  |
+| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 2024 |
-| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) |  Oct 11, 2021  |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
-| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) |  Oct 19, 2021  |
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
-| [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  |
 
-
+## What can I expect when a feature is marked for deprecation?
-### What can I expect when a feature is marked for deprecation?
 
 In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.

docs/faq/dockershim.md

@@ -1,5 +1,5 @@
 ---
-title: Dockershim
+title: Dockershim FAQ
 ---
 
 <head>
@@ -18,7 +18,7 @@ enable_cri_dockerd: true
 
 For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.
 
-### FAQ
+## FAQ
 
 <br/>
 

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/install-and-configure-kubectl.md

@@ -8,11 +8,11 @@ title: Installing and Configuring kubectl
 
 `kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
 
-### Installation
+## Installation
 
 See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for installation on your operating system.
 
-### Configuration
+## Configuration
 
 When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.
 

docs/faq/rancher-is-no-longer-needed.md

@@ -9,11 +9,11 @@ title: Rancher is No Longer Needed
 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
 
 
-### If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
+## If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
 
 If Rancher is ever deleted or unrecoverable, all workloads in the downstream Kubernetes clusters managed by Rancher will continue to function as normal.
 
-### If the Rancher server is deleted, how do I access my downstream clusters?
+## If the Rancher server is deleted, how do I access my downstream clusters?
 
 The capability to access a downstream cluster without Rancher depends on the type of cluster and the way that the cluster was created. To summarize:
 
@@ -21,7 +21,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
 - **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
 - **RKE clusters:** To access an [RKE cluster,](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
 
-### What if I don't want Rancher anymore?
+## What if I don't want Rancher anymore?
 
 :::note
 
@@ -44,7 +44,7 @@ If you installed Rancher with Docker, you can uninstall Rancher by removing the
 
 Imported clusters will not be affected by Rancher being removed. For other types of clusters, refer to the section on [accessing downstream clusters when Rancher is removed.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
 
-### What if I don't want my registered cluster managed by Rancher?
+## What if I don't want my registered cluster managed by Rancher?
 
 If a registered cluster is deleted from the Rancher UI, the cluster is detached from Rancher, leaving it intact and accessible by the same methods that were used to access it before it was registered in Rancher.
 
@@ -56,7 +56,7 @@ To detach the cluster,
 
 **Result:** The registered cluster is detached from Rancher and functions normally outside of Rancher.
 
-### What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
+## What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
 
 At this time, there is no functionality to detach these clusters from Rancher. In this context, "detach" is defined as the ability to remove Rancher components from the cluster and manage access to the cluster independently of Rancher.
 

docs/faq/security.md

@@ -1,18 +1,21 @@
 ---
-title: Security
+title: Security FAQ
-
 ---
 
 <head>
   <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/>
+## Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
-
-**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
 
 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,14 +1,15 @@
 ---
-title: Technical
+title: Technical FAQ
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/technical-items"/>
 </head>
 
-### How can I reset the administrator password?
+## How can I reset the administrator password?
+
+Docker install:
 
-Docker Install:
 ```
 $ docker exec -ti <container_id> reset-password
 New password for default administrator (user-xxxxx):
@@ -16,6 +17,7 @@ New password for default administrator (user-xxxxx):
 ```
 
 Kubernetes install (Helm):
+
 ```
 $ KUBECONFIG=./kube_config_cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
@@ -23,10 +25,10 @@ New password for default administrator (user-xxxxx):
 <new_password>
 ```
 
+## I deleted/deactivated the last admin, how can I fix it?
 
+Docker install:
 
-### I deleted/deactivated the last admin, how can I fix it?
-Docker Install:
 ```
 $ docker exec -ti <container_id> ensure-default-admin
 New default administrator (user-xxxxx)
@@ -35,38 +37,40 @@ New password for default administrator (user-xxxxx):
 ```
 
 Kubernetes install (Helm):
+
 ```
 $ KUBECONFIG=./kube_config_cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
 New password for default administrator (user-xxxxx):
 <new_password>
 ```
-### How can I enable debug logging?
+
+## How can I enable debug logging?
 
 See [Troubleshooting: Logging](../troubleshooting/other-troubleshooting-tips/logging.md)
 
-### My ClusterIP does not respond to ping
+## My ClusterIP does not respond to ping
 
 ClusterIP is a virtual IP, which will not respond to ping. Best way to test if the ClusterIP is configured correctly, is by using `curl` to access the IP and port to see if it responds.
 
-### Where can I manage Node Templates?
+## Where can I manage Node Templates?
 
 Node Templates can be accessed by opening your account menu (top right) and selecting `Node Templates`.
 
-### Why is my Layer-4 Load Balancer in `Pending` state?
+## Why is my Layer-4 Load Balancer in `Pending` state?
 
 The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
 
-### Where is the state of Rancher stored?
+## Where is the state of Rancher stored?
 
 - Docker Install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
 - Kubernetes install: in the etcd of the RKE cluster created to run Rancher.
 
-### How are the supported Docker versions determined?
+## How are the supported Docker versions determined?
 
 We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
 
-### How can I access nodes created by Rancher?
+## How can I access nodes created by Rancher?
 
 SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ⋮ button at the end of the row, and choose **Download Keys** as shown in the picture below.
 
@@ -78,14 +82,14 @@ Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host.
 $ ssh -i id_rsa user@ip_of_node
 ```
 
-### How can I automate task X in Rancher?
+## How can I automate task X in Rancher?
 
 The UI consists of static files, and works based on responses of the API. That means every action/task that you can execute in the UI, can be automated via the API. There are 2 ways to do this:
 
 * Visit `https://your_rancher_ip/v3` and browse the API options.
 * Capture the API calls when using the UI (Most commonly used for this is [Chrome Developer Tools](https://developers.google.com/web/tools/chrome-devtools/#network) but you can use anything you like)
 
-### The IP address of a node changed, how can I recover?
+## The IP address of a node changed, how can I recover?
 
 A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
 
@@ -93,11 +97,11 @@ When the IP address of the node changed, Rancher lost connection to the node, so
 
 When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
 
-### How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
+## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
 
 You can add more arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
 
-### How do I check if my certificate chain is valid?
+## How do I check if my certificate chain is valid?
 
 Use the `openssl verify` command to validate your certificate chain:
 
@@ -138,7 +142,7 @@ subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
 issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
 ```
 
-### How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
+## How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
 
 Although technically an entry in `Subject Alternative Names` is required, having the hostname in both `Common Name` and as entry in `Subject Alternative Names` gives you maximum compatibility with older browser/applications.
 
@@ -156,7 +160,7 @@ openssl x509 -noout -in cert.pem -text | grep DNS
                 DNS:rancher.my.org
 ```
 
-### Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
+## Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
 
 This is due to a combination of the following default Kubernetes settings:
 
@@ -175,6 +179,6 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se
   * `default-not-ready-toleration-seconds`: Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
   * `default-unreachable-toleration-seconds`: Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.
 
-### Can I use keyboard shortcuts in the UI?
+## Can I use keyboard shortcuts in the UI?
 
 Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.

docs/faq/telemetry.md

@@ -1,16 +1,16 @@
 ---
-title: Telemetry
+title: Telemetry FAQ
 ---
 
 <head>
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
 </head>
 
-### What is Telemetry?
+## What is Telemetry?
 
 Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used.  This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
 
-### What information is collected?
+## What information is collected?
 
 No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
 
@@ -24,12 +24,12 @@ The primary things collected include:
   - The image name & version of Rancher that is running.
   - A unique randomly-generated identifier for this installation.
 
-### Can I see the information that is being sent?
+## Can I see the information that is being sent?
 
 If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
 
 If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
 
-### How do I turn it on or off?
+## How do I turn it on or off?
 
 After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.

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

@@ -12,7 +12,7 @@ These instructions assume you have already followed the instructions for a Kuber
 
 :::
 
-### Rancher Helm Upgrade Options
+## Rancher Helm Upgrade Options
 
 To upgrade with Helm, apply the same options that you used when installing Rancher. Refer to the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
 
@@ -38,6 +38,27 @@ helm upgrade rancher ./rancher-<VERSION>.tgz \
 	--set useBundledSystemChart=true # Use the packaged Rancher system charts
 ```
 
+#### Resolving UPGRADE FAILED Error
+
+If you encounter the error message, `Error: UPGRADE FAILED: "rancher" has no deployed releases`, Rancher might have been  installed via the `helm template` command. To successfully upgrade Rancher, use the following command instead:
+
+```
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+    --no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set certmanager.version=<CERTMANAGER_VERSION> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+After you run the Helm command, apply the rendered template:
+
+```
+kubectl -n cattle-system apply -R -f ./rancher
+```
+
 ### Option B: Certificates from Files using Kubernetes Secrets
 
 ```plain

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

@@ -4,7 +4,7 @@ description: Learn how to install Rancher in development and production environm
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster"/>
 </head>
 
 In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.
@@ -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.
+- **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.
+- **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.
+- **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                 |
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::
 
 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
 
 # Add the Jetstack Helm repository
@@ -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 crds.enabled=true
 ```
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -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

@@ -49,7 +49,7 @@ See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanu
 ### Step 2: Restore the Backup and Bring Up Rancher
 
 At this point, there should be no Rancher-related resources on the upstream cluster. Therefore, the next step will be the same as if you were migrating Rancher to a new cluster that contains no Rancher resources.
-/home/btat/rancher-docs/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md
+
 Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the Rancher-Backup Helm chart and restore Rancher to its previous state.
 Please keep in mind that:
 1. Step 3 can be skipped, because the Cert-Manager app should still exist on the upstream (local) cluster if it was installed before.
@@ -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
@@ -46,7 +49,6 @@ For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cl
 
 Follow the steps to upgrade Rancher server:
 
-
 ### 1. Back up Your Kubernetes Cluster that is Running Rancher Server
 
 Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
@@ -116,7 +118,6 @@ If you are installing Rancher in an air-gapped environment, skip the rest of thi
 
 :::
 
-
 Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
 
 ```

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

@@ -4,7 +4,7 @@ description: Learn how to install Rancher in development and production environm
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-and-upgrade"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade"/>
 </head>
 
 This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.

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 |
+| Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
-| ----------------------------- | ------------- | ------------ | --------------- |
+| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
-| `continuous-delivery` | `true` | GA | v2.6.0 |
+| `continuous-delivery` | `true` | GA | v2.6.0 | |
-| `fleet`  | `true` | Can no longer be disabled | 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` | GA | v2.5.0 |
+| `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
-| `harvester` | `true` | Experimental | v2.6.1 |
+| `fleet`  | `true` | GA | v2.5.0 | |
-| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 |
+| `harvester` | `true` | Experimental | v2.6.1 | |
-| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 |
+| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
-| `rke2` | `true` | Experimental | v2.6.0 |
+| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
-| `token-hashing` | `false` for new installs, `true` for upgrades | 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.
+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.
-
-```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" }}'
-```
 
 ### 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/installation-references.md

@@ -3,7 +3,7 @@ title: Installation References
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-references"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
 </head>
 
 Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).

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/dockershim.md

@@ -22,7 +22,7 @@ Starting with version 1.24, the above defaults to true.
 
 For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.
 
-### FAQ
+## FAQ
 
 <br/>
 
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
 
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 
 <br/>

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

@@ -4,7 +4,7 @@ description: Learn the node requirements for each node running Rancher server wh
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-requirements"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements"/>
 </head>
 
 This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
@@ -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/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md

@@ -3,7 +3,7 @@ title: Air-Gapped Helm CLI Install
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/air-gapped-helm-cli-install"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install"/>
 </head>
 
 This section is about using the Helm CLI to install the Rancher server in an air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.

docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/docker-install-commands.md

@@ -28,7 +28,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-### Option A: Default Self-Signed Certificate
+## Option A: Default Self-Signed Certificate
 
 <details id="option-a">
   <summary>Click to expand</summary>
@@ -55,7 +55,7 @@ docker run -d --restart=unless-stopped \
 
 </details>
 
-### Option B: Bring Your Own Certificate: Self-Signed
+## Option B: Bring Your Own Certificate: Self-Signed
 
 <details id="option-b">
   <summary>Click to expand</summary>
@@ -98,7 +98,7 @@ docker run -d --restart=unless-stopped \
 
 </details>
 
-### Option C: Bring Your Own Certificate: Signed by Recognized CA
+## Option C: Bring Your Own Certificate: Signed by Recognized CA
 
 <details id="option-c">
   <summary>Click to expand</summary>
@@ -143,8 +143,6 @@ docker run -d --restart=unless-stopped \
 
 </details>
 
-
-
 :::note
 
 If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.

docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md

@@ -25,7 +25,7 @@ We recommend setting up the following infrastructure for a high-availability ins
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 - **A private image registry** to distribute container images to your machines.
 
-### 1. Set up Linux Nodes
+## 1. Set up Linux Nodes
 
 These hosts will be disconnected from the internet, but require being able to connect with your private registry.
 
@@ -33,7 +33,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,
 
 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
 
-### 2. Set up External Datastore
+## 2. Set up External Datastore
 
 The ability to run Kubernetes using a datastore other than etcd sets K3s apart from other Kubernetes distributions. This feature provides flexibility to Kubernetes operators. The available options allow you to select a datastore that best fits your use case.
 
@@ -49,7 +49,7 @@ For an example of one way to set up the database, refer to this [tutorial](../..
 
 For the complete list of options that are available for configuring a K3s cluster datastore, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/datastore/)
 
-### 3. Set up the Load Balancer
+## 3. Set up the Load Balancer
 
 You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.
 
@@ -72,7 +72,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance
 
 :::
 
-### 4. Set up the DNS Record
+## 4. Set up the DNS Record
 
 Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.
 
@@ -82,7 +82,7 @@ You will need to specify this hostname in a later step when you install Rancher,
 
 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
 
-### 5. Set up a Private Image Registry
+## 5. Set up a Private Image Registry
 
 Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing container images to your machines.
 
@@ -106,13 +106,13 @@ To install the Rancher management server on a high-availability RKE cluster, we
 
 These nodes must be in the same region/data center. You may place these servers in separate availability zones.
 
-### Why three nodes?
+## Why Three Nodes?
 
 In an RKE cluster, Rancher server data is stored on etcd. This etcd database runs on all three nodes.
 
 The etcd database requires an odd number of nodes so that it can always elect a leader with a majority of the etcd cluster. If the etcd database cannot elect a leader, etcd can suffer from [split brain](https://www.quora.com/What-is-split-brain-in-distributed-systems), requiring the cluster to be restored from backup. If one of the three etcd nodes fails, the two remaining nodes can elect a leader because they have the majority of the total number of etcd nodes.
 
-### 1. Set up Linux Nodes
+## 1. Set up Linux Nodes
 
 These hosts will be disconnected from the internet, but require being able to connect with your private registry.
 
@@ -120,7 +120,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,
 
 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
 
-### 2. Set up the Load Balancer
+## 2. Set up the Load Balancer
 
 You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.
 
@@ -143,7 +143,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance
 
 :::
 
-### 3. Set up the DNS Record
+## 3. Set up the DNS Record
 
 Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.
 
@@ -153,7 +153,7 @@ You will need to specify this hostname in a later step when you install Rancher,
 
 For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
 
-### 4. Set up a Private Image Registry
+## 4. Set up a Private Image Registry
 
 Rancher supports air gap installs using a secure private registry. You must have your own private registry or other means of distributing container images to your machines.
 
@@ -176,7 +176,7 @@ If you need to create a private registry, refer to the documentation pages for y
 
 :::
 
-### 1. Set up a Linux Node
+## 1. Set up a Linux Node
 
 This host will be disconnected from the Internet, but needs to be able to connect to your private registry.
 
@@ -184,7 +184,7 @@ Make sure that your node fulfills the general installation requirements for [OS,
 
 For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
 
-### 2. Set up a Private Docker Registry
+## 2. Set up a Private Docker Registry
 
 Rancher supports air gap installs using a private registry on your bastion server. You must have your own private registry or other means of distributing container images to your machines.
 
@@ -193,4 +193,4 @@ If you need help with creating a private registry, please refer to the [official
 </TabItem>
 </Tabs>
 
-### [Next: Collect and Publish Images to your Private Registry](publish-images.md)
+## [Next: Collect and Publish Images to your Private Registry](publish-images.md)

docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md

@@ -23,14 +23,15 @@ The steps to set up an air-gapped Kubernetes cluster on RKE, RKE2, or K3s are sh
 
 In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
 
-### Installation Outline
+## Installation Outline
 
 1. [Prepare Images Directory](#1-prepare-images-directory)
 2. [Create Registry YAML](#2-create-registry-yaml)
 3. [Install K3s](#3-install-k3s)
 4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
 
-### 1. Prepare Images Directory
+## 1. Prepare Images Directory
+
 Obtain the images tar file for your architecture from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be running.
 
 Place the tar file in the `images` directory before starting K3s on each node, for example:
@@ -40,7 +41,8 @@ sudo mkdir -p /var/lib/rancher/k3s/agent/images/
 sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
 ```
 
-### 2. Create Registry YAML
+## 2. Create Registry YAML
+
 Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will tell K3s the necessary details to connect to your private registry.
 
 The registries.yaml file should look like this before plugging in the necessary information:
@@ -66,7 +68,7 @@ Note, at this time only secure registries are supported with K3s (SSL with custo
 
 For more information on private registries configuration file for K3s, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)
 
-### 3. Install K3s
+## 3. Install K3s
 
 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
 
@@ -98,7 +100,7 @@ K3s additionally provides a `--resolv-conf` flag for kubelets, which may help wi
 
 :::
 
-### 4. Save and Start Using the kubeconfig File
+## 4. Save and Start Using the kubeconfig File
 
 When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
 
@@ -138,7 +140,7 @@ kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces
 
 For more information about the `kubeconfig` file, refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/cluster-access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
 
-### Note on Upgrading
+## Note on Upgrading
 
 Upgrading an air-gap environment can be accomplished in the following manner:
 
@@ -151,14 +153,15 @@ Upgrading an air-gap environment can be accomplished in the following manner:
 
 In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.
 
-### Installation Outline
+## Installation Outline
 
 1. [Create RKE2 configuration](#1-create-rke2-configuration)
 2. [Create Registry YAML](#2-create-registry-yaml)
 3. [Install RKE2](#3-install-rke2)
 4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
 
-### 1. Create RKE2 configuration
+## 1. Create RKE2 configuration
+
 Create the config.yaml file at `/etc/rancher/rke2/config.yaml`. This will contain all the configuration options necessary to create a highly available RKE2 cluster.
 
 On the first server the minimum config is:
@@ -186,7 +189,8 @@ RKE2 additionally provides a `resolv-conf` option for kubelets, which may help w
 
 :::
 
-### 2. Create Registry YAML
+## 2. Create Registry YAML
+
 Create the registries.yaml file at `/etc/rancher/rke2/registries.yaml`. This will tell RKE2 the necessary details to connect to your private registry.
 
 The registries.yaml file should look like this before plugging in the necessary information:
@@ -210,7 +214,7 @@ configs:
 
 For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
 
-### 3. Install RKE2
+## 3. Install RKE2
 
 Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
 
@@ -239,7 +243,7 @@ systemctl start rke2-server.service
 
 For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
 
-### 4. Save and Start Using the kubeconfig File
+## 4. Save and Start Using the kubeconfig File
 
 When you installed RKE2 on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/rke2/rke2.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
 
@@ -279,7 +283,7 @@ kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
 
 For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
 
-### Note on Upgrading
+## Note on Upgrading
 
 Upgrading an air-gap environment can be accomplished in the following manner:
 
@@ -291,7 +295,7 @@ Upgrading an air-gap environment can be accomplished in the following manner:
 <TabItem value="RKE">
 We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
 
-### 1. Install RKE
+## 1. Install RKE
 
 Install RKE by following the instructions in the [RKE documentation.](https://rancher.com/docs/rke/latest/en/installation/)
 
@@ -301,7 +305,7 @@ Certified version(s) of RKE based on the Rancher version can be found in the [Ra
 
 :::
 
-### 2. Create an RKE Config File
+## 2. Create an RKE Config File
 
 From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s) that you set up in a previous step, use the sample below to create a new file named `rancher-cluster.yml`.
 
@@ -352,7 +356,7 @@ private_registries:
     is_default: true
 ```
 
-### 3. Run RKE
+## 3. Run RKE
 
 After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
 
@@ -360,7 +364,7 @@ After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
 rke up --config ./rancher-cluster.yml
 ```
 
-### 4. Save Your Files
+## 4. Save Your Files
 
 :::note Important:
 
@@ -383,8 +387,8 @@ The "rancher-cluster" parts of the two latter file names are dependent on how yo
 
 :::
 
-### Issues or errors?
+## Issues or Errors?
 
 See the [Troubleshooting](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md) page.
 
-### [Next: Install Rancher](install-rancher-ha.md)
+## [Next: Install Rancher](install-rancher-ha.md)

docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md

@@ -8,7 +8,7 @@ title: 4. Install Rancher
 
 This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
 
-### Privileged Access for Rancher
+## Privileged Access for Rancher
 
 When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.
 
@@ -92,7 +92,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher
 
 :::
 
-##### 1. Add the cert-manager repo
+##### 1. Add the cert-manager Repo
 
 From a system connected to the internet, add the cert-manager repo to Helm:
 
@@ -101,7 +101,7 @@ helm repo add jetstack https://charts.jetstack.io
 helm repo update
 ```
 
-##### 2. Fetch the cert-manager chart
+##### 2. Fetch the cert-manager Chart
 
 Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
 
@@ -109,7 +109,7 @@ Fetch the latest cert-manager chart available from the [Helm chart repository](h
 helm fetch jetstack/cert-manager --version v1.11.0
 ```
 
-##### 3. Retrieve the Cert-Manager CRDs
+##### 3. Retrieve the cert-manager CRDs
 
 Download the required CRD file for cert-manager:
    ```plain
@@ -120,7 +120,7 @@ Download the required CRD file for cert-manager:
 
 Copy the fetched charts to a system that has access to the Rancher server cluster to complete installation.
 
-##### 1. Install Cert-Manager
+#### 1. Install cert-manager
 
 Install cert-manager with the same options you would use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry.
 
@@ -160,7 +160,8 @@ If you are using self-signed certificates, install cert-manager:
 
 </details>
 
-##### 2. Install Rancher
+#### 2. Install Rancher
+
 First, refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
 
 Then, create the namespace for Rancher using kubectl:
@@ -192,9 +193,9 @@ Placeholder | Description
 
 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`
 
-#### Option B: Certificates From Files using Kubernetes Secrets
+#### Option B: Certificates From Files Using Kubernetes Secrets
 
-##### 1. Create secrets
+##### 1. Create Secrets
 
 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
 

docs/getting-started/installation-and-upgrade/other-installation-methods/other-installation-methods.md

@@ -3,7 +3,7 @@ title: Other Installation Methods
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/other-installation-methods"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods"/>
 </head>
 
 ### Air Gapped Installations

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

@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```

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-behind-an-http-proxy/rancher-behind-an-http-proxy.md

@@ -3,7 +3,7 @@ title: Installing Rancher behind an HTTP Proxy
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-behind-an-http-proxy"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy"/>
 </head>
 
 In a lot of enterprise environments, servers or VMs running on premise do not have direct Internet access, but must connect to external services through a HTTP(S) proxy for security reasons. This tutorial shows step by step how to set up a highly available Rancher installation in such an environment.

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

@@ -4,9 +4,11 @@ description: For development and testing environments only, use a Docker install
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-on-a-single-node-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"/>
 </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
+</TabItem>
-
+<TabItem value="Docker">
-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:
 
+```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/resources.md

@@ -3,7 +3,7 @@ title: Resources
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/resources"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources"/>
 </head>
 
 ### Docker Installations

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/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher.md

@@ -36,7 +36,7 @@ Administrators might configure the RKE metadata settings to do the following:
 - Change the metadata URL that Rancher uses to sync the metadata, which is useful for air gap setups if you need to sync Rancher locally instead of with GitHub
 - Prevent Rancher from auto-syncing the metadata, which is one way to prevent new and unsupported Kubernetes versions from being available in Rancher
 
-### Refresh Kubernetes Metadata
+## Refresh Kubernetes Metadata
 
 The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)
 
@@ -74,7 +74,7 @@ If you don't have an air gap setup, you don't need to specify the URL where Ranc
 
 However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
 
-### Air Gap Setups
+## Air Gap Setups
 
 Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)
 

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

@@ -1,14 +1,11 @@
 ---
-title: Rancher AWS Marketplace Quick Start
+title: Rancher Prime AWS Marketplace Quick Start
-description: Use Amazon EKS to deploy Rancher server.
+description: Deploy SUSE Rancher from the AWS Marketplace listing.
 ---
 
 <head>
   <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). 
 
-Amazon Elastic Kubernetes Service (EKS) can quickly [deploy Rancher to Amazon Web Services (AWS)](https://documentation.suse.com/trd/kubernetes/single-html/gs_rancher_aws-marketplace/). To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-go7ent7goo5ae). Watch the demo for a walkthrough of AWS Marketplace SUSE Rancher setup:
-
-<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/deploy-rancher-manager.md

@@ -3,7 +3,7 @@ title: Deploying Rancher Server
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-rancher-manager"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager"/>
 </head>
 
 Use one of the following guides to deploy and provision Rancher and a Kubernetes cluster in the provider of your choice.
@@ -14,6 +14,7 @@ Use one of the following guides to deploy and provision Rancher and a Kubernetes
 - [DigitalOcean](digitalocean.md) (uses Terraform)
 - [GCP](gcp.md) (uses Terraform)
 - [Hetzner Cloud](hetzner-cloud.md) (uses Terraform)
+- [Linode](linode.md) (uses Terraform)
 - [Vagrant](vagrant.md)
 - [Equinix Metal](equinix-metal.md)
 - [Outscale](outscale-qs.md) (uses Terraform)

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

@@ -0,0 +1,82 @@
+---
+title: Rancher Linode Quick Start Guide
+description: Read this step by step guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/linode"/>
+</head>
+
+The following steps will quickly deploy a Rancher server on Linode in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+:::caution
+
+Deploying to Linode will incur charges.
+
+:::
+
+- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
+- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
+- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Linode folder containing the Terraform files by executing `cd quickstart/rancher/linode`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+    - `linode_token` - The Linode Personal Access Token mentioned above.
+    - `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:
+   - `linode_region` - The target Linode region to provision the server and cluster in.
+     - Default: `eu-central`
+     - For a complete list of regions, see the [official Region Availability page](https://www.linode.com/global-infrastructure/availability/).
+   - `prefix` - The prefix for all created infrastructure.
+   - `linode_type` - The type/plan that all infrastructure Linodes should use.
+     - Default: `g6-standard-2` 
+     - For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+    ```
+    Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
+
+    Outputs:
+
+    rancher_node_ip = xx.xx.xx.xx
+    rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+    workload_node_ip = yy.yy.yy.yy
+    ```
+
+8. Paste the `rancher_server_url` from the output above into the browser and log in when prompted. The default username is `admin` and the password is defined in `rancher_server_admin_password`.
+9. `ssh` into the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/linode`.
+
+#### Result
+
+Two Kubernetes clusters are deployed on your Linode account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/linode` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.

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/getting-started/quick-start-guides/deploy-workloads/deploy-workloads.md

@@ -3,7 +3,7 @@ title: Deploying Workloads
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-rancher-workloads"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-workloads"/>
 </head>
 
 These guides walk you through the deployment of an application, including how to expose the application for use outside of the cluster.

docs/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md

@@ -73,4 +73,5 @@ When you're done using your sandbox, destroy the Rancher Server and your cluster
 
 - [Amazon AWS: Destroying the Environment](../deploy-rancher-manager/aws.md#destroying-the-environment)
 - [DigitalOcean: Destroying the Environment](../deploy-rancher-manager/digitalocean.md#destroying-the-environment)
+- [Linode: Destroying the Environment](../deploy-rancher-manager/linode.md#destroying-the-environment)
 - [Vagrant: Destroying the Environment](../deploy-rancher-manager/vagrant.md#destroying-the-environment)

docs/getting-started/quick-start-guides/quick-start-guides.md

@@ -3,7 +3,7 @@ title: Rancher Deployment Quick Start Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/quick-start-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides"/>
 </head>
 
 :::caution

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/advanced-user-guides.md

@@ -3,7 +3,7 @@ title: Advanced User Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/advanced-user-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides"/>
 </head>
 
 Advanced user guides are "problem-oriented" docs in which users learn how to answer questions or solve problems. The major difference between these and the new user guides is that these guides are geared toward more experienced or advanced users who have more technical needs from their documentation. These users already have an understanding of Rancher and its functions. They know what they need to accomplish; they just need additional guidance to complete some more complex task they they have encountered while working.

docs/how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md

@@ -3,7 +3,7 @@ title: CIS Scan Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cis-scan-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides"/>
 </head>
 
 - [Install rancher-cis-benchmark](install-rancher-cis-benchmark.md)

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 
+        apiVersion: audit.k8s.io/v1
-        kind: Policy 
+        kind: Policy
-        rules: 
+        rules:
-        - level: RequestResponse
+          - level: RequestResponse
-          resources:
+            resources:
-          - group: ""
+              - group: ""
-            resources: 
+                resources:
-            - pods
+                  - 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 |
+| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
-| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
+| --------------------- | -------- | ------------ | ------------- |
-| `0`                   |                  |              |                   |               |
+| `0`                   |          |              |               |
-| `1`                   | ✓                |              |                   |               |
+| `1`                   | ✓        |              |               |
-| `2`                   | ✓                | ✓            |                   |               |
+| `2`                   | ✓        | ✓            |               |
-| `3`                   | ✓                | ✓            | ✓                 | ✓             |
+| `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/enable-experimental-features.md

@@ -3,7 +3,7 @@ title: Enabling Experimental Features
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/enable-experimental-features"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features"/>
 </head>
 
 Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type](unsupported-storage-drivers.md) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.

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,9 +1,9 @@
 ---
-title: Setup Guide
+title: Istio Setup Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/istio-setup-guide"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide"/>
 </head>
 
 This section describes how to enable Istio and start using it in your projects.

docs/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md

@@ -3,7 +3,7 @@ title: Project Resource Quotas
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-project-resource-quotas"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas"/>
 </head>
 
 In situations where several teams share a cluster, one team may overconsume the resources available: CPU, memory, storage, services, Kubernetes objects like pods or secrets, and so on.  To prevent this overconsumption, you can apply a _resource quota_, which is a Rancher feature that limits the resources available to a project or namespace.

docs/how-to-guides/advanced-user-guides/manage-projects/manage-projects.md

@@ -3,7 +3,7 @@ title: Project Administration
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-projects"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects"/>
 </head>
 
 _Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.

docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md

@@ -46,7 +46,7 @@ To use your own dashboard:
 
 ### 2. Create a ConfigMap using the Grafana JSON model
 
-Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
+Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. `cattle-dashboards` by default).
 
 The ConfigMap should look like this:
 
@@ -65,19 +65,26 @@ data:
 
 By default, Grafana is configured to watch all ConfigMaps with the `grafana_dashboard` label within the `cattle-dashboards` namespace.
 
-To specify that you would like Grafana to watch for ConfigMaps across all namespaces, refer to [this section.](#configuring-namespaces-for-the-grafana-dashboard-configmap)
+To specify that you would like Grafana to watch for ConfigMaps across all namespaces, refer to [this section](#configuring-namespaces-for-the-grafana-dashboard-configmap). 
 
-To create the ConfigMap in the Rancher UI,
+To create the ConfigMap through the Rancher UI, first make sure that you are currently logged in to the Grafana UI, to ensure that dashboards import without encountering permissions issues. Then, return to the Rancher UI and perform the following steps:
 
 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to see the visualizations and click **Explore**.
 1. Click **More Resources > Core > ConfigMaps**.
 1. Click **Create**.
-1. Set up the key-value pairs similar to the example above. When entering the value for `<dashboard-name>.json`, click **Read from File** to upload the JSON data model as the value.
+1. On the **Data** tab, set up the key-value pairs similar to the example above. When entering the value for `<dashboard-name>.json`, click **Read from File** to upload the JSON data model as the value.
+1. On the **Labels & Annotations** tab, click **Add Label** and enter `grafana_dashboard` as the key, and `1` as the value.
 1. Click **Create**.
 
 **Result:** After the ConfigMap is created, it should show up on the Grafana UI and be persisted even if the Grafana pod is restarted.
 
+:::note
+
+The actual key-value pair may differ if you have modified the Helm chart to watch a different dashboard label and value.
+
+:::
+
 Dashboards that are persisted using ConfigMaps cannot be deleted or edited from the Grafana UI.
 
 If you attempt to delete the dashboard in the Grafana UI, you will see the error message "Dashboard cannot be deleted because it was provisioned." To delete the dashboard, you will need to delete the ConfigMap.

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-alerting-guides/monitoring-alerting-guides.md

@@ -3,7 +3,7 @@ title: Monitoring/Alerting Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/monitoring-alerting-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-alerting-guides"/>
 </head>
 
 - [Enable monitoring](enable-monitoring.md)

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

@@ -3,7 +3,7 @@ title: Prometheus Federator Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/prometheus-federator-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides"/>
 </head>
 
 - [Enable Prometheus Operator](enable-prometheus-federator.md)

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

@@ -3,7 +3,7 @@ title: Advanced Configuration
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/advanced-configuration"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration"/>
 </head>
 
 ### Alertmanager

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

@@ -1,9 +1,9 @@
 ---
-title: Configuration
+title: Monitoring Configuration Guides
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/monitoring-v2-configuration-guides"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides"/>
 </head>
 
 This page captures some of the most important options for configuring Monitoring V2 in the Rancher UI.

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,9 +8,9 @@ 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
+## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB
 
 ```yaml
 # RKE cluster.yml
@@ -21,9 +21,9 @@ services:
       quota-backend-bytes: 5368709120
 ```
 
-## Scaling etcd disk performance
+## 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/about-provisioning-drivers.md

@@ -3,7 +3,7 @@ title: About Provisioning Drivers
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/about-provisioning-drivers"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers"/>
 </head>
 
 Drivers in Rancher allow you to manage which providers can be used to deploy [hosted Kubernetes clusters](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) or [nodes in an infrastructure provider](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) to allow Rancher to deploy and manage Kubernetes.

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 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,9 +1,9 @@
 ---
-title: RKE Templates
+title: About RKE1 Templates
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/about-rke1-templates"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>
 
 RKE templates are designed to allow DevOps and security teams to standardize and simplify the creation of Kubernetes clusters.

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. In the left navigation bar, click **Role Templates**.
-1. Go to the role named **Create new RKE Cluster Templates and click **⋮ > Edit Config**.
+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

@@ -4,31 +4,38 @@ weight: 10
 ---
 
 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config"/>
 </head>
 
 One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters.
 
 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                                                                                     |
+| Auth Service                                                                                                           |
-| ------------------------------------------------------------------------------------------------ |
+|------------------------------------------------------------------------------------------------------------------------|
-| [Microsoft Active Directory](configure-active-directory.md)  |
+| [Microsoft Active Directory](configure-active-directory.md)                                                            |
-| [GitHub](configure-github.md)                  |
+| [GitHub](configure-github.md)                                                                                          |
-| [Microsoft Azure AD](configure-azure-ad.md)    |
+| [Microsoft Azure AD](configure-azure-ad.md)                                                                            |
-| [FreeIPA](configure-freeipa.md)                |
+| [FreeIPA](configure-freeipa.md)                                                                                        |
-| [OpenLDAP](../configure-openldap/configure-openldap.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)     |
+| [PingIdentity](configure-pingidentity.md)                                                                              |
-| [Keycloak (OIDC)](configure-keycloak-oidc.md)  |
+| [Keycloak (OIDC)](configure-keycloak-oidc.md)                                                                          |
-| [Keycloak (SAML)](configure-keycloak-saml.md)  |
+| [Keycloak (SAML)](configure-keycloak-saml.md)                                                                          |
-| [Okta](configure-okta-saml.md)                      |
+| [Okta](configure-okta-saml.md)                                                                                         |
-| [Google OAuth](configure-google-oauth.md)            |
+| [Google OAuth](configure-google-oauth.md)                                                                              |
-| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.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.