User Retention Feature for Security Release (#1343 )

* SURE-8285 Document user retention feature * fixing changes for global-configuration.md * versioning plus the enable user authentication page * Apply suggestions from code review Co-authored-by: Andy Pitcher <andy.pitcher@suse.com> Co-authored-by: Peter Matseykanets <peterm@mail.ru> Co-authored-by: pdellamore <pietro.dellamore@suse.com> * versioning, updates to descriptions of settings * correcting versioning & rm v2.9 file * one more correction * if you can't remove the file, just make sure it's synced... * Update docs/how-to-guides/advanced-user-guides/enable-user-retention.md Co-authored-by: Peter Matseykanets <peterm@mail.ru> * user-last-login-default * more settings, more details about deletion behavior * versioning * more explanation for last-login * revising blurb about disabling * describing deletion behavior less direly * corrected commands * fix overwrite * corrected commands * updated description of zero value * sidebars * canonical link fixed * rm'd parenthetical versioning remark * heading capitalization, log in vs login * more log in * revise command, important box, enabling user retention section * clarifying that some optional settings are also global * rm patch mention from 2.9 * explain how to view settings for individual users * Apply suggestions from code review Co-authored-by: Billy Tat <btat@suse.com> * duplicate word rm'd --------- Co-authored-by: Andy Pitcher <andy.pitcher@suse.com> Co-authored-by: Peter Matseykanets <peterm@mail.ru> Co-authored-by: pdellamore <pietro.dellamore@suse.com> Co-authored-by: Billy Tat <btat@suse.com>
Merge pull request #1345 from sunilarjun/2.8.5-2.7.14-Feature-Addition
2026-09-29 14:38:50 +00:00 · 2024-06-17 18:09:40 -04:00 · 2024-06-17 15:05:58 -07:00 · 2024-06-17 15:05:23 -07:00 · 2024-06-17 15:05:06 -07:00 · 2024-06-17 15:04:32 -07:00
2148 changed files with 237446 additions and 54776 deletions
@@ -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.
-->
+-->
@@ -6,14 +6,14 @@ on:
      - main

 jobs:
-  deploy:
-    name: Deploy to GitHub Pages
+  build:
+    name: Build Docusaurus
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@v3
+      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn
@@ -25,18 +25,25 @@ jobs:
          NODE_OPTIONS: "--max_old_space_size=7168"
        run: yarn build --no-minify

-      # Popular action to deploy to GitHub Pages:
-      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
-      - name: Deploy to GitHub Pages
-        uses: peaceiris/actions-gh-pages@v3
+      - name: Upload Build Artifact
+        uses: actions/upload-pages-artifact@v3
        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          # Build output to publish to the `gh-pages` branch:
-          publish_dir: ./build
-          # The following lines assign commit authorship to the official
-          # GH-Actions bot for deploys to `gh-pages` branch:
-          # https://github.com/actions/checkout/issues/13#issuecomment-724415212
-          # The GH actions bot is used by default if you didn't specify the two fields.
-          # You can swap them out with your own user credentials.
-          user_name: github-actions[bot]
-          user_email: 41898282+github-actions[bot]@users.noreply.github.com
+          path: build
+
+  deploy:
+    name: Deploy to GitHub Pages
+    needs: build
+
+    permissions:
+      pages: write
+      id-token: write
+    
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
@@ -10,8 +10,10 @@ jobs:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v3
-      - uses: actions/setup-node@v3
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn
@@ -0,0 +1,58 @@
+# This action gets all changed markdown files in /docs and /versioned_docs using tj-actions/changed-files@v42
+# It compares new commits in the PR with the base commit (github.event.pull_request.base.sha)
+# It checks if no markdown files are changed 
+# It shows a count of markdown files and lists all changed markdown files
+# It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
+
+name: Style check
+on: [pull_request]
+
+jobs:
+  vale-lint:
+    name: runner / vale
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        continue-on-error: true
+        with:
+          fetch-depth: 0  # OR "2" -> To retrieve the preceding commit.
+          submodules: true
+      - name: Get all changed markdown files
+        continue-on-error: true
+        id: changed-markdown-files
+        uses: tj-actions/changed-files@v42
+        with:
+            # Avoid using single or double quotes for multiline patterns
+            files: |
+               docs/**
+               versioned_docs/**
+            separator: ","
+            base_sha: ${{ github.event.pull_request.base.sha }}
+        env:
+            ALL_CHANGED_FILES: ${{ 0 }}
+      - name: No files changed?
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'false'
+        run: |
+              echo "No files changed"
+              echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
+      - name: List all changed files markdown files
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'true'
+        env:
+            ALL_CHANGED_FILES: ${{ steps.changed-markdown-files.outputs.all_changed_files }}
+            ALL_CHANGED_FILES_COUNT: ${{ steps.changed-markdown-files.outputs.all_changed_files_count }}
+            SHA: ${{ github.head_ref }}
+            HEAD: ${{ github.base_ref }}
+        run: |
+            echo "Total Files Changed:" ${ALL_CHANGED_FILES_COUNT}
+            echo ${ALL_CHANGED_FILES}
+            echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
+      - uses: errata-ai/vale-action@v2.1.0
+        continue-on-error: true
+        if: steps.changed-markdown-files.outputs.any_changed == 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          separator: ", "
+          files: ${{ env.ALL_CHANGED_FILES }}
@@ -0,0 +1,3 @@
+[submodule ".github/styles/suse-vale-styleguide"]
+	path = .github/styles/suse-vale-styleguide
+	url = https://github.com/openSUSE/suse-vale-styleguide
@@ -0,0 +1,7 @@
+StylesPath = .github/styles
+
+[formtats]
+mdx = md
+
+[*.md]
+BasedOnStyles = suse-vale-styleguide
@@ -27,7 +27,17 @@ The file paths in the repo correspond to the URLs for pages on the docs website.

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

@@ -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": [
@@ -1,11 +1,13 @@
 ---
-title: API Tokens
+title: Using API Tokens
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-tokens"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-tokens"/>
 </head>

+Rancher v2.8.0 introduced the [Rancher Kubernetes API](./api-reference.mdx) which can be used to manage Rancher resources through `kubectl`. This page covers information on API tokens used with the [Rancher CLI](../reference-guides/cli-with-rancher), [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.
@@ -43,13 +45,11 @@ This setting is used by all kubeconfig tokens except those created by the CLI to

 ## 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](../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.
+Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. When this setting is deactivated, a generated kubeconfig references the [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) to retrieve a short-lived token for the cluster. When this kubeconfig is used in a client, such as `kubectl`, the Rancher CLI needs to be installed to complete the log in request.

 ## Token Hashing

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

 This feature affects all tokens which include, but are not limited to, the following:

@@ -82,4 +82,4 @@ Maximum Time to Live (TTL) in minutes allowed for auth tokens. If a user attempt

 ### kubeconfig-generate-token

-When true, kubeconfigs requested through the UI contain a valid token. When false, kubeconfigs contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then retrieves and caches a token for the user](../cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
+When true, kubeconfigs requested through the UI contain a valid token. When false, kubeconfigs contain a command that uses the Rancher CLI to prompt the user to log in. [The CLI then retrieves and caches a token for the user](../reference-guides/cli-with-rancher/kubectl-utility.md#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl).
@@ -1,12 +1,12 @@
 ---
-title: API Quick Start Guide
+title: RK-API Quick Start Guide
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/quickstart"/>
 </head>

-You can access Rancher's resources through the Kubernetes API. This guide will help you get started on using this API as a Rancher user.
+You can access Rancher's resources through the Kubernetes API. This guide helps you get started on using this API as a Rancher user.

 1. In the upper left corner, click **☰ > Global Settings**.
 2. Find and copy the address in the `server-url` field.
@@ -129,7 +129,7 @@ To ensure that your tools can recognize Rancher's CA certificates, most setups r
  If your Rancher instance is proxied by another service, you must extract the certificate that the service is using, and add it to the kubeconfig file, as demonstrated in step 5.
  :::

-4. The following commands will convert `rancher.crt` to base64 output, trim all new-lines, and update the cluster in the kubeconfig with the certificate, then finishing by removing the `rancher.crt` file:
+4. The following commands convert `rancher.crt` to base64 output, trim all new-lines, and update the cluster in the kubeconfig with the certificate, then finish by removing the `rancher.crt` file:

  ```bash
  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
@@ -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.
@@ -96,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

@@ -3,10 +3,10 @@ title: Deprecated Features in Rancher
 ---

 <head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features-in-v2.5"/>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>

-### What is Rancher's Deprecation policy?
+### What is Rancher's deprecation policy?

 We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).

@@ -16,14 +16,12 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) |  Aug 31, 2021  |
-| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) |  Oct 11, 2021  |
-| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) |  Oct 19, 2021  |
-| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) |  Dec 21, 2021  |
-| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |  Mar 31, 2022  |
-| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) |  May 12, 2022  |
-| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) |  Jun 30, 2022  |
-
+| [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | June 17, 2024 |
+| [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024  |
+| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024  |
+| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024   |
+| [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | Jan 22, 2024  |
+| [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | Dec 6, 2023   |

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

@@ -1,5 +1,5 @@
 ---
-title: Dockershim
+title: Dockershim FAQ
 ---

 <head>
@@ -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).
@@ -1,5 +1,5 @@
 ---
-title: Security
+title: Security FAQ

 ---

@@ -7,12 +7,16 @@ title: Security
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
 </head>

-**Is there a Hardening Guide?**
+### Is there a Hardening Guide?

-The Hardening Guide is now located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
+The Hardening Guide is located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.

-<br/>
-
-**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
+### Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?

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

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

 <head>
@@ -19,14 +19,15 @@ 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.
+- `external-rules`: This flag is enabled by default. Only admin users can enable/disable the flag, and note that `escalate` permissions on `RoleTemplates` are required to create external `RoleTemplates` with `ExternalRules`. Restricted admin users can only enable the flag. If enabled, external `RoleTemplates` can be created only if the backing `ClusterRole` exists in the local cluster or the `ExternalRules` is set. For context, the backing `ClusterRole` holds cluster rules and privileges, and shares the same `metadata.name` used in the `RoleTemplate` in your respective cluster referenced by the `ClusterRoleTemplateBinding/ProjectRoleTemplateBinding`. Previous external `RoleTemplates` that don’t have a backing `ClusterRole` won’t be granted or modifiable unless a backing `ClusterRole` is created or the `ExternalRules` field is set. If disabled, external `RoleTemplates` with `.context=project` or `.context=””` can be created even if the backing `ClusterRole` does not exist.
+- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/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.
 - `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.

 The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:
@@ -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                                                      |
@@ -67,19 +67,9 @@ For information on enabling experimental features, refer to [this page.](../../.

 ### Bootstrap Password

-When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
+You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.

-If you want to use a specific bootstrap password instead of a randomly generated one, provide the password.
-
-```plain
--set bootstrapPassword="rancher"
-```
-
-The password, whether provided or generated, will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
-
-```
-kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
-```
+When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.

 ### API Audit Log

@@ -163,7 +153,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>/"
@@ -6,26 +6,63 @@ title: Setting up the Bootstrap Password
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/bootstrap-password"/>
 </head>

-When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
+When you install Rancher, you can set a bootstrap password for the first admin account.

-The bootstrap password is randomly generated if it is not set during installation with a variable. For details on how to set the bootstrap password using a variable, see below.
+If you choose not to set a bootstrap password, Rancher randomly generates a bootstrap password for the first admin account.

-### Specifying the Bootstrap Password in Helm Installs
+For details on how to set the bootstrap password, see below.

-For a Helm install, users can specify the bootstrap password variable by configuring it in the Helm chart values with `.Values.bootstrapPassword`.
+## Password Requirements

-The password will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
+The bootstrap password can be any length.

+When you reset the first admin account's password after first login, the new password must be at least 12 characters long.
+
+You can [customize the minimum password length](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length) for user accounts, within limitations.
+
+Minimum password length can be any positive integer value between 2 and 256. Decimal values and leading zeroes are not allowed.
+
+## Specifying the Bootstrap Password
+
+<Tabs>
+<TabItem value="Helm">
+
+During [Rancher installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md), set `bootstrapPassword` alongside any other flags for the Rancher Helm chart. For example:
+
+```bash
+helm install rancher rancher-<chart-repo>/rancher \
+  --set bootstrapPassword=<password>
 ```
+
+</TabItem>
+<TabItem value="Docker">
+
+Pass the following value to the [Docker install command](../other-installation-methods/air-gapped-helm-cli-install/docker-install-commands.md):
+
+```bash
+-e CATTLE_BOOTSTRAP_PASSWORD=<password>
+```
+
+</TabItem>
+</Tabs>
+
+## Retrieving the Bootstrap Password
+
+The bootstrap password is stored in the Docker container logs. After Rancher is installed, the UI shows instructions for how to retrieve the password based on your installation method. 
+
+<Tabs>
+<TabItem value="Helm">
+
+```bash
 kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
 ```

-### Specifying the Bootstrap Password in Docker Installs
-
-For a Docker install, you can specify the bootstrap password by passing `-e CATTLE_BOOTSTRAP_PASSWORD=password` to the Docker install command.
-
-The password will be stored in the Docker container logs. After Rancher is installed, the UI will show instructions for how to retrieve the password using the Docker container ID:
+</TabItem>
+<TabItem value="Docker">

+```bash
+docker logs container-id  2>&1 | grep "Bootstrap Password:"
 ```
-docker logs  container-id  2>&1 | grep "Bootstrap Password:"
-```
+
+</TabItem>
+</Tabs>
@@ -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?

@@ -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:
@@ -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:
@@ -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:
@@ -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.
@@ -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 \
@@ -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.
@@ -38,7 +38,7 @@ Deploying to Linode will incur charges.

 4. Edit `terraform.tfvars` and customize the following variables:
    - `linode_token` - The Linode Personal Access Token mentioned above.
-    - `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters).
+    - `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.

 5. **Optional:** Modify optional variables within `terraform.tfvars`.
 See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
@@ -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.
@@ -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.
@@ -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;
+```
@@ -28,14 +28,14 @@ spec:
  rkeConfig:
    machineGlobalConfig:
      audit-policy-file: |
-        apiVersion: audit.k8s.io/v1 
-        kind: Policy 
-        rules: 
-        - level: RequestResponse
-          resources:
-          - group: ""
-            resources: 
-            - pods
+        apiVersion: audit.k8s.io/v1
+        kind: Policy
+        rules:
+          - level: RequestResponse
+            resources:
+              - group: ""
+                resources:
+                  - pods
 ```

 ### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`
@@ -36,12 +36,12 @@ The usage below defines rules about what the audit log should record and what da

 The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.

-| `AUDIT_LEVEL` Setting | Request Metadata | Request Body | Response Metadata | Response Body |
-| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
-| `0`                   |                  |              |                   |               |
-| `1`                   | ✓                |              |                   |               |
-| `2`                   | ✓                | ✓            |                   |               |
-| `3`                   | ✓                | ✓            | ✓                 | ✓             |
+| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
+| --------------------- | -------- | ------------ | ------------- |
+| `0`                   |          |              |               |
+| `1`                   | ✓        |              |               |
+| `2`                   | ✓        | ✓            |               |
+| `3`                   | ✓        | ✓            | ✓             |

 ## Viewing API Audit Logs

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

@@ -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.
@@ -1,5 +1,5 @@
 ---
-title: Setup Guide
+title: Istio Setup Guides
 ---

 <head>
@@ -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.
@@ -1,5 +1,5 @@
 ---
-title: Configuration
+title: Monitoring Configuration Guides
 ---

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

@@ -6,11 +6,11 @@ title: Node Drivers
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers"/>
 </head>

-Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
+A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. By default, Rancher is packaged with many node drivers, but you can also create and add custom node drivers to Rancher.

-If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
+Only `Active` node drivers are displayed in the Rancher UI when you create node templates. If there are specific node drivers that you don't want to show your users, you must deactivate these node drivers.

-#### Managing Node Drivers
+## Managing Node Drivers

 :::note Prerequisites:

@@ -21,17 +21,31 @@ To create, edit, or delete drivers, you need _one_ of the following permissions:

 :::

-## Activating/Deactivating Node Drivers
+### Activating/Deactivating Node Drivers

-By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
+By default, Rancher only activates drivers for the most popular cloud providers, such as Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.

 1. In the upper left corner, click **☰ > Cluster Management**.
+1.  In the left navigation menu, click **Drivers**.
+1.	On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.

-2.  In the left navigation menu, click **Drivers**.
+:::danger 

-2.	On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.
+You can lose access to clusters after deactivating a node driver.

-## Adding Custom Node Drivers
+Deactivating a node driver doesn't just affect its visibility in the Rancher UI. When you deactivate or delete a node driver, any nodes deployed with that driver become inaccessible. 
+
+For example, if you deactivate a vSphere node driver to hide it in the UI, and you have a vSphere cluster that was deployed with that driver, the initial node in the cluster will fail, and the entire cluster will become inaccessible. Attempts to delete the vSphere nodes will fail, with nodes stuck in an extended `Removing` state.
+
+Before you deactivate a node driver, make sure that it has no associated clusters. One way to check is to see if the respective platform for a driver is listed among your clusters:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Select **Clusters**.
+1. Check the **Provider** column of the table for instances of the node driver you are deactivating.
+
+:::
+
+### Adding Custom Node Drivers

 If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add that provider's driver in order to start using them to create node templates and eventually node pools for your Kubernetes cluster.

@@ -40,6 +54,8 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
 1. On **Node Drivers** tab, click **Add Node Driver**.
 1.	Complete the **Add Node Driver** form. Then click **Create**.

-### Developing your own node driver
+### Developing Your Own Node Drivers

-Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
+Node drivers are implemented with [Rancher Machine](https://github.com/rancher/machine), a fork of [Docker Machine](https://github.com/docker/machine). Docker Machine is no longer under active development.
+
+Refer to the original [Docker Machine documentation](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) for details on how to develop your own node drivers.
@@ -1,5 +1,5 @@
 ---
-title: RKE Templates
+title: About RKE1 Templates
 ---

 <head>
@@ -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
@@ -42,7 +42,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

@@ -225,6 +225,9 @@ To complete configuration, enter information about your AD instance in the Ranch

 **Result:** Azure Active Directory authentication is configured.

+#### (Optional) Configure Authentication with Multiple Rancher Domains
+
+If you have multiple Rancher domains, it's not possible to configure multiple redirect URIs through the Rancher UI. The Azure AD configuration file, `azuread`, only allows one redirect URI by default. You must manually edit `azuread` to set the redirect URI as needed for any other domains. If you don't manually edit `azuread`, then upon a successful login attempt to any domain, Rancher automatically redirects the user to the **Redirect URI** value you set when you registered the app in [Step 1. Register Rancher with Azure](#1-register-rancher-with-azure).

 ### Migrating from Azure AD Graph API to Microsoft Graph API

@@ -51,7 +51,6 @@ You can integrate Okta with Rancher, so that authenticated users can access Ranc

    :::

-
 1. After you complete the **Configure Okta Account** form, click **Enable**.

    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
@@ -8,7 +8,7 @@ title: Users and Groups

 Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When you configure an external authentication provider, users from that provider will be able to log in to your Rancher server. When a user logs in, the authentication provider will supply your Rancher server with a list of groups to which the user belongs.

-Access to clusters, projects, multi-cluster apps, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
+Access to clusters, projects, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).

 ## Managing Members

@@ -70,6 +70,14 @@ Since SAML does not support user lookup, SAML-based authentication providers do

 :::

+## Minimum Password Length
+
+By default, user passwords must be at least 12 characters long. However, you can customize the password length requirement:
+
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to **`password-min-length`** and click **⋮ > Edit Setting**.
+1. Enter an integer value between 2 and 256, and click **Save**.
+
 ## Session Length

 The default length (TTL) of each user session is adjustable. The default session length is 16 hours.
@@ -30,6 +30,14 @@ Within Rancher, each person authenticates as a _user_, which is a login that gra

 For more information how authorization works and how to customize roles, see [Roles Based Access Control (RBAC)](manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).

+## User Retention
+
+In Rancher v2.8.5 and later, you can enable user retention. This feature automatically removes inactive users after a configurable period of time.
+
+The user retention feature is disabled by default.
+
+For more information, see [Enabling User Retention](../../advanced-user-guides/enable-user-retention.md).
+
 ## Pod Security Policies

 _Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
@@ -82,4 +90,4 @@ The following features are available under **Global Configuration**:
 - **Global DNS Entries**
 - **Global DNS Providers**

-As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
+As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
@@ -40,7 +40,7 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,

 :::note

-There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../deploy-apps-across-clusters/fleet.md#troubleshooting) for a workaround.
+There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../../../integrations-in-rancher/fleet/overview.md#troubleshooting) for a workaround.

 :::

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

@@ -8,14 +8,13 @@ title: Migrating Rancher to a New Cluster

 If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.

-
 ### Prerequisites

 These instructions assume that you have [created a backup](back-up-rancher.md) and  already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.

 :::caution

-It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
+You must use the same hostname that was set as the server URL in the original cluster. If you don't, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's **Explore** button.

 :::

@@ -25,7 +24,6 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes

 Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.

-
 ### 1. Install the rancher-backup Helm chart

 Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
@@ -54,10 +52,10 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o

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

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

     ```bash
-     --set image.repository $REGISTRY/rancher/backup-restore-operator
+     --set image.repository <registry>/rancher/backup-restore-operator
     ```

     :::
@@ -189,3 +187,9 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
 ```

 :::
+
+### 5. Redirect Traffic to the New Cluster
+
+After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.
+
+Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.
@@ -79,15 +79,20 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
    1. In the **Clusters** page, go to the cluster where you want to remove nodes.
    1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.

-1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
+1. After all etcd nodes are removed, add the new etcd node that you are planning to restore from. Assign the new node the role of `all` (etcd, controlplane, and worker).

-    - For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - If the node was previously in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
    - For node driver clusters, a new node is provisioned automatically.

    At this point, Rancher will indicate that restoration from etcd snapshot is required.

 1. Restore from an etcd snapshot.

+    :::note
+    As the etcd node is a clean node, you may need to manually create the `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` path.
+    :::
+
    - For S3 snapshots, restore using the UI.
      1. Click the **Snapshots** tab to view the list of saved snapshots.
      1. Go to the snapshot you want to restore and click **⋮ > Restore**.
@@ -95,7 +100,15 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
      1. Click **Restore**.
    - For local snapshots, restore using the UI is **not** available.
      1. In the upper right corner, click **⋮ > Edit YAML**.
-      1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
+      1. The example YAML below can be added under your `rkeConfig` to configure the etcd restore:
+
+      ```yaml
+        ...
+        rkeConfig:
+          etcdSnapshotRestore:
+            name: <string> # This field is required. Refers to the filename of the associated etcdsnapshot object.
+        ...
+      ```

 1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.

@@ -1,21 +0,0 @@
---
-title: Deploying Applications across Clusters
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
-</head>
-
-Rancher offers several ways to deploy applications across clusters, depending on version.
-
-## Fleet
-
-Rancher v2.5 and later uses Fleet to deploy applications across clusters.
-
-Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section](fleet.md).
-
-## Multi-cluster Apps
-
-In Rancher before v2.5, the multi-cluster apps feature was used to deploy applications across clusters. The multi-cluster apps feature is deprecated, but still available as a legacy feature.
-
-See the [multi-cluster app documentation](multi-cluster-apps.md) for more details.
@@ -1,71 +0,0 @@
---
-title: Continuous Delivery with Fleet
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
-</head>
-
-Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/installation#configuration-for-multi-cluster) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
-
-Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
-
-
-## Architecture
-
-For information about how Fleet works, see [this page.](../../../integrations-in-rancher/fleet/architecture.md)
-
-## Accessing Fleet in the Rancher UI
-
-Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
-
-Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
-
-Follow the steps below to access Continuous Delivery in the Rancher UI:
-
-1. Click **☰ > Continuous Delivery**.
-
-1. Select your namespace at the top of the menu, noting the following:
-    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
-    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
-    - You can then manage clusters by clicking on **Clusters** on the left navigation bar.
-
-1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
-
-1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
-
-1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
-
-## Windows Support
-
-For details on support for clusters with Windows nodes, see [this page.](../../../integrations-in-rancher/fleet/windows-support.md)
-
-
-## GitHub Repository
-
-The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest)
-
-
-## Using Fleet Behind a Proxy
-
-For details on using Fleet behind a proxy, see [this page.](../../../integrations-in-rancher/fleet/use-fleet-behind-a-proxy.md)
-
-## Helm Chart Dependencies
-
-In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.
-
-The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` or run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters.
-
-## Troubleshooting
-
---
-* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
-
-* **Temporary Workaround:** <br/>
-By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
-
---
-
-## Documentation
-
-The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
@@ -1,179 +0,0 @@
---
-title: Multi-cluster Apps
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps"/>
-</head>
-
-Typically, most applications are deployed on a single Kubernetes cluster, but there will be times you might want to deploy multiple copies of the same application across different clusters and/or projects. In Rancher, a _multi-cluster application_,  is an application deployed using a Helm chart across multiple clusters. With the ability to deploy the same application across multiple clusters, it avoids the repetition of the same action on each cluster, which could introduce user error during application configuration. With multi-cluster applications, you can customize to have the same configuration across all projects/clusters as well as have the ability to change the configuration based on your target project. Since multi-cluster application is considered a single application, it's easy to manage and maintain this application.
-
-Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
-
-After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application.
-
-## Prerequisites
-
-### Permissions
-
-To create a multi-cluster app in Rancher, you must have at least one of the following permissions:
-
- A [project-member role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) in the target cluster(s), which gives you the ability to create, read, update, and delete the workloads
- A [cluster owner role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) for the clusters(s) that include the target project(s)
-
-### Enable Legacy Features
-
-Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2.5, you will need to enable multi-cluster apps with a feature flag.
-
-1. In the upper left corner, click **☰ > Global Settings**.
-1. Click **Feature Flags**.
-1. Go to the `legacy` feature flag and click **Activate**.
-
-## Launching a Multi-Cluster App
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-1. Click **Launch**.
-1. Find the application that you want to launch.
-1.  (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
-1. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `<MULTI-CLUSTER_APPLICATION_NAME>-<PROJECT_ID>`.
-1. Select a **Template Version**.
-1. Complete the [multi-cluster applications specific configuration options](#multi-cluster-app-configuration-options) as well as the [application configuration options](#application-configuration-options).
-1. Select the **Members** who can [interact with the multi-cluster application](#members).
-1. Add any [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects) that would change the configuration for specific project(s) from the default application configuration answers.
-1. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
-
-**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
-
-## Multi-cluster App Configuration Options
-
-Rancher has divided the configuration option for the multi-cluster application into several sections.
-
-### Targets
-
-In the **Targets** section, select the projects that you want the application to be deployed in. The list of projects is based on what projects you have access to. For each project that you select, it will be added to the list, which shows the cluster name and project name that were selected. To remove a target project, click on **-**.
-
-### Upgrades
-
-In the **Upgrades** section, select the upgrade strategy to use, when you decide to upgrade your application.
-
-* **Rolling Update (batched):** When selecting this upgrade strategy, the number of applications upgraded at a time is based on the selected **Batch size** and the **Interval** specifies how many seconds to wait before starting the next batch of updates.
-
-* **Upgrade all apps simultaneously:** When selecting this upgrade strategy, all applications across all projects will be upgraded at the same time.
-
-### Roles
-
-In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications](../helm-charts-in-rancher/helm-charts-in-rancher.md), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
-
-For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
-
-Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions.
-
- **Project** - This is the equivalent of a [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or a [project owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles), then the user is considered to have the appropriate level of permissions.
-
- **Cluster** - This is the equivalent of a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), then the user is considered to have the appropriate level of permissions.
-
-When launching the application, Rancher will confirm if you have these permissions in the target projects before launching the application.
-
-:::note
-
-There are some applications like _Grafana_ or _Datadog_ that require access to specific cluster-scoped resources. These applications will require the _Cluster_ role. If you find out later that the application requires cluster roles, the multi-cluster application can be upgraded to update the roles.
-
-:::
-
-## Application Configuration Options
-
-For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
-
-:::note Example
-
-When entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
-
-:::
-
-### Using a questions.yml file
-
-If the Helm chart that you are deploying contains a `questions.yml` file, Rancher's UI will translate this file to display an easy to use UI to collect the answers for the questions.
-
-### Key Value Pairs for Native Helm Charts
-
-For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a custom Helm chart repository, answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
-
-### Members
-
-By default, multi-cluster applications can only be managed by the user who created it. In the **Members** section, other users can be added so that they can also help manage or view the multi-cluster application.
-
-1. Find the user that you want to add by typing in the member's name in the **Member** search box.
-
-2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean.
-
-    - **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#Multi-cluster App Configuration Options), the [application specific configuration options](#application-configuration-options), the members who can interact with the multi-cluster application and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type.
-
-    - **Member**: This access type can only modify the template version, the [application specific configuration options](#application-configuration-options) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _member_ of the multi-cluster application can modify the application without explicitly having access to these project(s). Only trusted users should be provided with this access type.
-
-    - **Read-only**: This access type cannot modify any configuration option for the multi-cluster application. Users can only view these applications.
-
-    :::caution
-
-    Please ensure only trusted users are given _Owner_ or _Member_ access as they will automatically be able to manage applications created for this multi-cluster application in target projects they might not have direct access to.
-
-    :::
-
-### Overriding Application Configuration Options for Specific Projects
-
-The ability to use the same configuration to deploy the same application across multiple clusters/projects is one of the main benefits of multi-cluster applications. There might be a specific project that requires a slightly different configuration option, but you want to manage that application with all the other matching applications. Instead of creating a brand new application, you can override specific [application specific configuration options](#application-configuration-options) for specific projects.
-
-1. In the **Answer Overrides** section, click **Add Override**.
-
-2. For each override, you can select the following:
-
-    - **Scope**: Select which target projects you want to override the answer in the configuration option.
-
-    - **Question**: Select which question you want to override.
-
-    - **Answer**: Enter the answer that you want to be used instead.
-
-## Upgrading Multi-Cluster App Roles and Projects
-
- **Changing Roles on an existing Multi-Cluster app**
-The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`.
-
- **Adding/Removing target projects**
-1. The creator and any users added with access-type "owner" to a multi-cluster app, can add or remove its target projects. When adding a new project, we check if the caller of this request has all Roles defined on multi-cluster app, in the new projects they want to add. The roles checks are again relaxed for global admins, cluster-owners and project-owners.
-2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list.
-
-
-## Multi-Cluster Application Management
-
-One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.
-
-:::note Prerequisite:
-
-The `legacy` feature flag needs to be enabled.
-
-:::
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-
-2. Choose the multi-cluster application you want to take one of these actions on and click the **⋮**. Select one of the following options:
-
-   * **Clone**: Creates another multi-cluster application with the same configuration. By using this option, you can easily duplicate a multi-cluster application.
-   * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members).
-   * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue.
-
-## Deleting a Multi-Cluster Application
-
-:::note Prerequisite:
-
-The `legacy` feature flag needs to be enabled.
-
-:::
-
-1. In the upper left corner, click **☰ > Multi-cluster Apps**.
-
-2. Choose the multi-cluster application you want to delete and click the **⋮ > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
-
-   :::note
-
-   The applications in the target projects, that are created for a multi-cluster application, cannot be deleted individually. The applications can only be deleted when the multi-cluster application is deleted.
-
-   :::
@@ -167,6 +167,23 @@ spec:

 Only Helm 3 compatible charts are supported.

+### Refresh Chart Repositories
+
+The **Refresh** button can be used to sync changes from selected Helm chart repositories on the **Repositories** page.
+
+To refresh a chart repository:
+
+1. Click **☰ > Cluster Management**.
+1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
+1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
+1. Use the toggle next to the **State** field to select all repositories, or toggle specified chart repositories to sync changes.
+1. Click **Refresh**.
+1. The **⋮** at the end of each chart repository row also includes a **Refresh** option, which can be clicked to refresh the respective repository.
+
+Non-Airgap Rancher installations upon refresh will reflect any chart repository changes immediately and you will see the **State** field for updated repositories move from `In Progress` to `Active` once the action is completed.
+
+Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
+
 ## Deploy and Upgrade Charts

 To install and deploy a chart:
@@ -1,12 +1,13 @@
 ---
-title: Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.
+title: Infrastructure Setup
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup"/>
 </head>

-To set up infrastructure for a high-availability K3s Kubernetes cluster with an external DB, refer to [this page.](ha-k3s-kubernetes-cluster.md)
+Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.

+To set up infrastructure for a high-availability K3s Kubernetes cluster with an external database, refer to [this page.](ha-k3s-kubernetes-cluster.md)

 To set up infrastructure for a high-availability RKE Kubernetes cluster, refer to [this page.](ha-rke1-kubernetes-cluster.md)
@@ -1,11 +1,13 @@
 ---
-title: "Don't have a Kubernetes cluster? Try one of these tutorials."
+title: Setting up a Kubernetes Cluster for Rancher Server
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup"/>
 </head>

+Don't have a Kubernetes cluster? Try one of these tutorials.
+
 This section contains information on how to install a Kubernetes cluster that the Rancher server can be installed on.

 Rancher can run on any Kubernetes cluster.
@@ -1,5 +1,5 @@
 ---
-title: Setting up Kubernetes Clusters in Rancher
+title: Kubernetes Clusters in Rancher Setup
 description: Provisioning Kubernetes Clusters
 ---

@@ -1,12 +1,12 @@
 ---
-title: Migrating vSphere In-tree to Out-of-tree
+title: Migrating VMware vSphere In-tree to Out-of-tree
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-vsphere"/>
 </head>

-Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
+Kubernetes is moving away from maintaining cloud providers in-tree. VMware vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.

 This page covers how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration.

@@ -1,12 +1,12 @@
 ---
-title: Setting Up an In-tree vSphere Cloud Provider
+title: Setting Up an In-tree VMware vSphere Cloud Provider
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere"/>
 </head>

-To set up the in-tree vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:
+To set up the in-tree VMware vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:

 1. Set **Cloud Provider** option to `Custom` or `Custom (In-Tree)`.
 1. Click on **Edit as YAML**
@@ -1,12 +1,12 @@
 ---
-title: Setting Up an Out-of-tree vSphere Cloud Provider
+title: Setting Up an Out-of-tree VMware vSphere Cloud Provider
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere"/>
 </head>

-Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
+Kubernetes is moving away from maintaining cloud providers in-tree. VMware vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.

 This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after setting up a cluster.

@@ -25,7 +25,7 @@ Using the vSphere out-of-tree cloud provider requires Linux nodes and is not sup

 The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).

-### 1. Create a vSphere cluster
+### 1. Create a VMware vSphere cluster

 1. Click **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
@@ -33,7 +33,7 @@ For details on enabling the Azure cloud provider, refer to [this page.](azure.md

 For details on enabling the Google Compute Engine cloud provider, refer to [this page.](google-compute-engine.md)

-### Setting up the vSphere Cloud Provider
+### Setting up the VMware vSphere Cloud Provider

 For details on enabling the vSphere cloud provider, refer to [in-tree vSphere config](configure-in-tree-vsphere.md) and [out-of-tree vSphere config](configure-out-of-tree-vsphere.md).

@@ -21,65 +21,48 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (
 Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):

 - Subscription ID
- Client ID
+- Client ID (also known as app ID)
 - Client secret

 The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.

 ### Setting Up the Service Principal with the Azure Command Line Tool

-You can create the service principal by running this command:
+You must assign roles to the service principal so that it has communication privileges with the AKS API. It also needs access to create and list virtual networks. 
+
+In the following example, the command creates the service principal and gives it the Contributor role. The Contributor role can manage anything on AKS but cannot give access to others. Note that you must provide `scopes` a full path to at least one Azure resource: 

 ```
-az ad sp create-for-rbac --skip-assignment
+az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>
 ```

 The result should show information about the new service principal:
+
 ```
 {
  "appId": "xxxx--xxx",
-  "displayName": "<SERVICE-PRINCIPAL-NAME>",
-  "name": "http://<SERVICE-PRINCIPAL-NAME>",
-  "password": "<SECRET>",
-  "tenant": "<TENANT NAME>"
+  "displayName": "<service-principal-name>",
+  "name": "http://<service-principal-name>",
+  "password": "<secret>",
+  "tenant": "<tenant-name>"
 }
 ```

-You also need to add roles to the service principal so that it has privileges for communication with the AKS API. It also needs access to create and list virtual networks.
-
-Below is an example command for assigning the Contributor role to a service principal. Contributors can manage anything on AKS but cannot give access to others:
+The following creates a [Resource Group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-cli) to contain your Azure resources:

 ```
-az role assignment create \
-  --assignee $appId \
-  --scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
-  --role Contributor
-```
-
-You can also create the service principal and give it Contributor privileges by combining the two commands into one. In this command, the scope needs to provide a full path to an Azure resource:
-
-```
-az ad sp create-for-rbac \
-  --scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
-  --role Contributor
-```
-
-Create the Resource Group by running this command:
-
-```
-az group create --location AZURE_LOCATION_NAME --resource-group AZURE_RESOURCE_GROUP_NAME
+az group create --location <azure-location-name> --resource-group <resource-group-name>
 ```

 ### Setting Up the Service Principal from the Azure Portal

-You can also follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
+Follow these instructions to set up a service principal and give it role-based access from the Azure Portal.

 1. Go to the Microsoft Azure Portal [home page](https://portal.azure.com).
-
 1. Click **Azure Active Directory**.
 1. Click **App registrations**.
 1. Click **New registration**.
-1. Enter a name. This will be the name of your service principal.
+1. Enter a name for your service principal.
 1. Optional: Choose which accounts can use the service principal.
 1. Click **Register**.
 1. You should now see the name of your service principal under **Azure Active Directory > App registrations**.
@@ -101,7 +84,7 @@ To give role-based access to your service principal,

 **Result:** Your service principal now has access to AKS.

-## 1. Create the AKS Cloud Credentials
+## Create the AKS Cloud Credentials

 1. In the Rancher UI, click **☰ > Cluster Management**.
 1. Click **Cloud Credentials**.
@@ -110,7 +93,7 @@ To give role-based access to your service principal,
 1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials)
 1. Click **Create**.

-## 2. Create the AKS Cluster
+## Create the AKS Cluster

 Use Rancher to set up and configure your Kubernetes cluster.

@@ -124,7 +107,8 @@ Use Rancher to set up and configure your Kubernetes cluster.

 You can access your cluster after its state is updated to **Active**.

-## Role-based Access Control
+## Configure Role-based Access Control
+
 When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.

 RBAC is required for AKS clusters that are registered or imported into Rancher.
@@ -135,8 +119,8 @@ Assign the Rancher AKSv2 role to the service principal with the Azure Command Li

 ```
 az role assignment create \
--assignee CLIENT_ID \
--scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME" \
+--assignee <client-id> \
+--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>" \
 --role "Rancher AKSv2"
 ```

@@ -86,7 +86,7 @@ Some Linux operating systems accept multiple domain names separated by spaces. H

 :::

-### Rancher on vSphere with ESXi 6.7u2 and above
+### Rancher on VMware vSphere with ESXi 6.7u2 and above

 If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `<VM network interface>` must be customized to the host `vmxnet3` network interface, e.g., `ens192`:

@@ -1,5 +1,5 @@
 ---
-title: The Horizontal Pod Autoscaler
+title: Horizontal Pod Autoscaler
 description: Learn about the horizontal pod autoscaler (HPA). How to manage HPAs and how to test them with a service deployment
 ---

@@ -1,5 +1,5 @@
 ---
-title: Kubernetes Resources
+title: Kubernetes Resources Setup
 ---

 <head>
@@ -1,5 +1,5 @@
 ---
-title: Set Up Load Balancer and Ingress Controller within Rancher
+title: Load Balancer and Ingress Controller Setup within Rancher
 description: Learn how you can set up load balancers and ingress controllers to redirect service requests within Rancher, and learn about the limitations of load balancers
 ---

@@ -21,11 +21,62 @@ The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher

 The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.

+### Requests
+
+The `cattle-cluster-agent` pod does not define the default CPU and memory request values. As a baseline, we recommend setting the CPU request at `50m` and memory request at `100Mi`. However, it is important that you assess your use case appropriately and that you allocate the correct resources to your cluster for your needs.
+
+To configure request values through the UI:
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE">
+
+1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Options** section.
+1. Expand the **Cluster Configuration** subsection.
+1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
+
+</TabItem>
+<TabItem value="RKE2/K3s">
+
+1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Configuration**.
+1. Select the **Cluster Agent** subsection.
+1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
+
+</TabItem>
+</Tabs>
+
+If you prefer to configure via YAML, add the following snippet to your configuration file:
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE">
+
+```yaml
+cluster_agent_deployment_customization:
+  override_resource_requirements:
+    requests:
+      cpu: 50m
+      memory: 100Mi
+```
+
+</TabItem>
+<TabItem value="RKE2/K3s">
+
+```yaml
+spec:
+  clusterAgentDeploymentCustomization:
+    overrideResourceRequirements:
+      requests:
+        cpu: 50m
+        memory: 100Mi 
+```
+
+</TabItem>
+</Tabs>
+
 ### Scheduling rules

-The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`. 
+The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.

-If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below. 
+If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.

 | Component              | nodeAffinity nodeSelectorTerms             | nodeSelector | Tolerations                                                                    |
 | ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
@@ -1,5 +1,5 @@
 ---
-title: Creating a vSphere Virtual Machine Template
+title: Creating a VMware vSphere Virtual Machine Template
 ---

 <head>
@@ -1,12 +1,12 @@
 ---
-title: Creating Credentials in the vSphere Console
+title: Creating Credentials in the VMware vSphere Console
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-credentials"/>
 </head>

-This section describes how to create a vSphere username and password. You will need to provide these vSphere credentials to Rancher, which allows Rancher to provision resources in vSphere.
+This section describes how to create a VMware vSphere username and password. You must provide these vSphere credentials to Rancher, which allows Rancher to provision resources in vSphere.

 The following table lists the permissions required for the vSphere user account:

@@ -1,12 +1,12 @@
 ---
-title: Provisioning Kubernetes Clusters in vSphere
+title: Provisioning Kubernetes Clusters in VMware vSphere
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere"/>
 </head>

-In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/)  Kubernetes cluster in vSphere.
+In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/)  Kubernetes cluster in VMware vSphere.

 First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.

@@ -17,16 +17,16 @@ For details on configuring the vSphere node template, refer to the [vSphere node
 For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.](../../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference)


- [Preparation in vSphere](#preparation-in-vsphere)
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
+- [Preparation in vSphere](#preparation-in-vmware-vsphere)
+- [Creating a vSphere Cluster](#creating-a-vmware-vsphere-cluster)

-## Preparation in vSphere
+## Preparation in VMware vSphere

 This section describes the requirements for setting up vSphere so that Rancher can provision VMs and clusters.

 The node templates are documented and tested with the vSphere Web Services API version 6.5.

-### Create Credentials in vSphere
+### Create Credentials in VMware vSphere

 Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. When you set up a node template, the template will need to use these vSphere credentials.

@@ -42,7 +42,7 @@ It must be ensured that the hosts running the Rancher server are able to establi

 See [Node Networking Requirements](../../../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.

-### Valid ESXi License for vSphere API Access
+### Valid ESXi License for VMware vSphere API Access

 The free ESXi license does not support API access. The vSphere servers must have a valid or evaluation ESXi license.

@@ -50,7 +50,7 @@ The free ESXi license does not support API access. The vSphere servers must have

 If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.

-## Creating a vSphere Cluster
+## Creating a VMware vSphere Cluster

 1. [Create your cloud credentials](#1-create-your-cloud-credentials)
 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
@@ -1,6 +1,6 @@
 ---
-title: Creating a vSphere Cluster
-description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
+title: Creating a VMware vSphere Cluster
+description: Use Rancher to create a VMware vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
 ---

 <head>
@@ -9,13 +9,13 @@ description: Use Rancher to create a vSphere cluster. It may consist of groups o

 import YouTube from '@site/src/components/YouTube'

-By using Rancher with vSphere, you can bring cloud operations on-premises.
+By using Rancher with VMware vSphere, you can bring cloud operations on-premises.

 Rancher can provision nodes in vSphere and install Kubernetes on them. When creating a Kubernetes cluster in vSphere, Rancher first provisions the specified number of virtual machines by communicating with the vCenter API. Then it installs Kubernetes on top of them.

 A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.

-## vSphere Enhancements in Rancher v2.3
+## VMware vSphere Enhancements in Rancher v2.3

 The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:

@@ -33,7 +33,7 @@ It is not recommended to enable node auto-replace on a node pool of master nodes

 Node templates for vSphere have been updated so that when you create a node template with your vSphere credentials, the template is automatically populated with the same options for provisioning VMs that you have access to in the vSphere console.

-For the fields to be populated, your setup needs to fulfill the [prerequisites.](provision-kubernetes-clusters-in-vsphere.md#preparation-in-vsphere)
+For the fields to be populated, your setup needs to fulfill the [prerequisites.](provision-kubernetes-clusters-in-vsphere.md#preparation-in-vmware-vsphere)

 ### More Supported Operating Systems

@@ -45,7 +45,7 @@ In this YouTube video, we demonstrate how to set up a node template with the new

 <YouTube id="dPIwg6x1AlU"/>

-## Creating a vSphere Cluster
+## Creating a VMware vSphere Cluster

 In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.

@@ -53,7 +53,7 @@ In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how

 For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../manage-clusters/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. Refer to [in-tree vSphere config](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere config](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md).

-## Enabling the vSphere Cloud Provider
+## Enabling the VMware vSphere Cloud Provider

 When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices.

@@ -1,5 +1,5 @@
 ---
-title: Cluster Access
+title: Access Clusters
 ---

 <head>
@@ -19,11 +19,11 @@ The kubeconfig file and its contents are specific to each cluster. It can be dow
 1. Find the cluster whose kubeconfig you want to download, and select **⁝** at the end of the row. 
 1. Select **Download KubeConfig** from the submenu.

-You will need a separate kubeconfig file for each cluster that you have access to in Rancher.
+You need a separate kubeconfig file for each cluster that you have access to in Rancher.

-After you download the kubeconfig file, you will be able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.
+After you download the kubeconfig file, you are able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.

-If admins have [kubeconfig token generation turned off](../../../../reference-guides/about-the-api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires [rancher cli](./authorized-cluster-endpoint.md) to be present in your PATH.
+If admins have [kubeconfig token generation turned off](../../../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires that the [Rancher CLI](./authorized-cluster-endpoint.md) to be present in your PATH.

 ### Two Authentication Methods for RKE Clusters

@@ -36,7 +36,7 @@ For RKE clusters, the kubeconfig file allows you to be authenticated in two ways

 This second method, the capability to connect directly to the cluster's Kubernetes API server, is important because it lets you access your downstream cluster if you can't connect to Rancher.

-To use the authorized cluster endpoint, you will need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
+To use the authorized cluster endpoint, you need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)

 These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.

@@ -1,5 +1,5 @@
 ---
-title: "Kubernetes Persistent Storage: Volumes and Storage Classes"
+title: Create Kubernetes Persistent Volumes and Storage Classes
 description: "Learn about the two ways with which you can create persistent storage in Kubernetes: persistent volumes and storage classes"
 ---

@@ -67,7 +67,7 @@ In [Rancher Launched Kubernetes clusters](../../launch-kubernetes-with-rancher/l
 ### hostPath Volumes
 Before you create a hostPath volume, you need to set up an [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/) in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.

-### Migrating vSphere Cloud Provider from In-tree to Out-of-tree
+### Migrating VMware vSphere Cloud Provider from In-tree to Out-of-tree

 Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.

@@ -70,7 +70,7 @@ StatefulSets manage the deployment and scaling of Pods while maintaining a stick
 1. Click **StatefulSet**.
 1. In the **Volume Claim Templates** tab, click **Add Claim Template**.
 1. Enter a name for the persistent volume.
-1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
+1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

@@ -84,7 +84,7 @@ To attach the PVC to an existing workload,
 1. Go to the workload that will use storage provisioned with the StorageClass that you cared at click **⋮ > Edit Config**.
 1. In the **Volume Claim Templates** section, click **Add Claim Template**.
 1. Enter a persistent volume name.
-1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
+1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Save**.

@@ -304,7 +304,7 @@ cloud-provider|-|Cloud provider type|
 |max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
 |nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
 |node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
-|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
+|estimator|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
 |expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
 |ignore-daemonsets-utilization|false|Should CA ignore DaemonSet pods when calculating resource utilization for scaling down|
 |ignore-mirror-pods-utilization|false|Should CA ignore Mirror pods when calculating resource utilization for scaling down|
@@ -76,7 +76,7 @@ To manage individual nodes, browse to the cluster that you want to manage and th

 ## Viewing a Node in the Rancher API

-Select this option to view the node's [API endpoints](../../../reference-guides/about-the-api/about-the-api.md).
+Select this option to view the node's [API endpoints](../../../api/quickstart.md).

 ## Deleting a Node

@@ -100,7 +100,7 @@ For [nodes hosted by an infrastructure provider](../launch-kubernetes-with-ranch

 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to SSH into a node and click the name of the cluster.
-1. On the **Machine Pools** tab, find the node that you want to remote into and click  **⋮ > Download SSH Key**. A ZIP file containing files used for SSH will be downloaded.
+1. On the **Machine Pools** tab, find the node that you want to remote into and click  **⋮ > Download SSH Key**. A ZIP file containing files used for SSH is then downloaded.
 1. Extract the ZIP file to any location.
 1. Open Terminal. Change your location to the extracted ZIP file.
 1. Enter the following command:
@@ -111,13 +111,13 @@ For [nodes hosted by an infrastructure provider](../launch-kubernetes-with-ranch

 ## Cordoning a Node

-_Cordoning_ a node marks it as unschedulable. This feature is useful for performing short tasks on the node during small maintenance windows, like reboots, upgrades, or decommissions.  When you're done, power back on and make the node schedulable again by uncordoning it.
+_Cordoning_ a node marks it as unschedulable. This feature is useful for performing short tasks on the node during small maintenance windows, like reboots, upgrades or decommissions. When you're done, power back on and make the node schedulable again by uncordoning it.

 ## Draining a Node

 _Draining_ is the process of first cordoning the node, and then evicting all its pods. This feature is useful for performing node maintenance (like kernel upgrades or hardware maintenance). It prevents new pods from deploying to the node while redistributing existing pods so that users don't experience service interruption.

- For pods with a replica set, the pod is replaced by a new pod that will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
+- For pods with a replica set, the pod is replaced by a new pod that is scheduled to a new node. Additionally, if the pod is part of a service, then clients are automatically redirected to the new pod.

 - For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.

@@ -127,20 +127,21 @@ However, you can override the conditions draining when you initiate the drain. Y

 ### Aggressive and Safe Draining Options

-When you configure the upgrade strategy for the cluster, you will be able to enable node draining. If node draining is enabled, you will be able to configure how pods are deleted and rescheduled.
+When you configure the upgrade strategy for the cluster, you can enable node draining. If node draining is enabled, you are able to configure how pods are deleted and rescheduled.

 - **Aggressive Mode**

    In this mode, pods won't get rescheduled to a new node, even if they do not have a controller. Kubernetes expects you to have your own logic that handles the deletion of these pods.

-    Kubernetes also expects the implementation to decide what to do with pods using emptyDir. If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Choosing aggressive mode will delete these pods.
+    Kubernetes also expects the implementation to decide what to do with pods using emptyDir. If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir is deleted once the pod is removed from the node. Choosing aggressive mode deletes these pods.

 - **Safe Mode**

-    If a node has standalone pods or ephemeral data it will be cordoned but not drained.
+    If a node has stand-alone pods or ephemeral data it is cordoned but not drained.
+
 ### Grace Period

-The timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. For example, when pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If negative, the default value specified in the pod will be used.
+The timeout given to each pod for cleaning things up so they have a chance to exit gracefully. For example, when pods might need to finish any outstanding requests, roll back transactions or save state to an external storage. If negative, the default value specified in the pod is used.

 ### Timeout

@@ -156,17 +157,17 @@ The [timeout setting](https://github.com/kubernetes/kubernetes/pull/64378) was n

 If there's any error related to user input, the node enters a `cordoned` state because the drain failed. You can either correct the input and attempt to drain the node again, or you can abort by uncordoning the node.

-If the drain continues without error, the node enters a `draining` state. You'll have the option to stop the drain when the node is in this state, which will stop the drain process and change the node's state to `cordoned`.
+If the drain continues without error, the node enters a `draining` state. You'll have the option to stop the drain when the node is in this state, which then stops the drain process and changes the node's state to `cordoned`.

-Once drain successfully completes, the node will be in a state of `drained`. You can then power off or delete the node.
+Once drain successfully completes, the node is in a state of `drained`. You can then power off or delete the node.

 **Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/).

 ## Labeling a Node to be Ignored by Rancher

-Some solutions, such as F5's BIG-IP integration, may require creating a node that is never registered to a cluster.
+Certain solutions, such as F5's BIG-IP integration, may require creating a node that is never registered to a cluster.

-Since the node will never finish registering, it will always be shown as unhealthy in the Rancher UI.
+Since the node never finishes registering, it is always shown as unhealthy in the Rancher UI.

 In that case, you may want to label the node to be ignored by Rancher so that Rancher only shows nodes as unhealthy when they are actually failing.

@@ -181,16 +182,16 @@ There is an [open issue](https://github.com/rancher/rancher/issues/24172) in whi

 ### Labeling Nodes to be Ignored with kubectl

-To add a node that will be ignored by Rancher, use `kubectl` to create a node that has the following label:
+To add a node that is ignored by Rancher, use `kubectl` to create a node that has the following label:

 ```
 cattle.rancher.io/node-status: ignore
 ```

-**Result:** If you add the node to a cluster, Rancher will not attempt to sync with this node. The node can still be part of the cluster and can be listed with `kubectl`.
+**Result**: If you add the node to a cluster, Rancher skips syncing with this node. The node can still be part of the cluster and can be listed with `kubectl`.

-If the label is added before the node is added to the cluster, the node will not be shown in the Rancher UI.
+If the label is added before the node is added to the cluster, the node is not shown in the Rancher UI.

-If the label is added after the node is added to a Rancher cluster, the node will not be removed from the UI.
+If the label is added after the node is added to a Rancher cluster, the node is not removed from the UI.

-If you delete the node from the Rancher server using the Rancher UI or API, the node will not be removed from the cluster if the `nodeName` is listed in the Rancher settings in the Rancher API under `v3/settings/ignore-node-name`.
+If you delete the node from the Rancher server using the Rancher UI or API, the node is not removed from the cluster if the `nodeName` is listed in the Rancher settings in the Rancher API under `v3/settings/ignore-node-name`.
@@ -1,12 +1,12 @@
 ---
-title: vSphere Storage
+title: VMware vSphere Storage
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/provisioning-storage-examples/vsphere-storage"/>
 </head>

-To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a PersistentVolumeClaim.
+To provide stateful workloads with VMware vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a PersistentVolumeClaim.

 In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. See the following pages for more: [Out-of-tree vSphere](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md) and [in-tree vSphere](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md).

@@ -35,7 +35,7 @@ The following steps can also be performed using the `kubectl` command line tool.
 5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/master/documentation/storageclass.md) for details.
 5. Click **Create**.

-### Creating a Workload with a vSphere Volume
+### Creating a Workload with a VMware vSphere Volume

 1. In the left navigation bar, click **Workload**.
 1. Click **Create**.
@@ -19,10 +19,12 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
-| v2.8.0          | v103.0.0+up3.0.0 |
-| v2.8.1          | v103.0.0+up3.0.0 |
-| v2.8.2          | v103.0.0+up3.0.0 |
+| v2.8.5          | v103.0.1+up3.0.1 |
+| v2.8.4          | v103.0.1+up3.0.1 |
 | v2.8.3          | v103.0.1+up3.0.1 |
+| v2.8.2          | v103.0.0+up3.0.0 |
+| v2.8.1          | v103.0.0+up3.0.0 |
+| v2.8.0          | v103.0.0+up3.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -0,0 +1,14 @@
+---
+title: Cluster API (CAPI) with Rancher Turtles
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cluster-api"/>
+</head>
+
+[Rancher Turtles](https://turtles.docs.rancher.com/) is a [Rancher extension](../rancher-extensions.md) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:
+
+- Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
+- Configure the [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values).
+
+The [Overview](./overview.md) section outlines installation options, Rancher Turtles architecture, and a brief demo. For more details, see the [Rancher Turtles documentation](https://turtles.docs.rancher.com/).
@@ -0,0 +1,260 @@
+---
+title: Overview
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cluster-api/overview"/>
+</head>
+
+## Architecture Diagram
+
+Below is a visual representation of the key components of Rancher Turtles and their relationship to Rancher and the Rancher Cluster Agent. Understanding these components is essential for gaining insights into how Rancher leverages the CAPI operator for cluster management.
+
+![overview](/img/30000ft_view.png)
+
+## Security
+
+As defined by [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/spec/v1.0/about), SLSA is a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. The specification set by SLSA is useful for both software producers and consumers: producers can follow SLSA’s guidelines to make their software supply chain more secure, and consumers can use SLSA to make decisions about whether to trust a software package.
+
+Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/security/slsa) document.
+
+## Prerequisites
+
+Before installing Rancher Turtles in your Rancher environment, you must disable Rancher's `embedded-cluster-api` functionality. This also includes cleaning up Rancher-specific webhooks that otherwise would conflict with CAPI ones.
+
+To simplify setting up Rancher for installing Rancher Turtles, the official Rancher Turtles Helm chart includes a `pre-install` hook that removes the following:
+
+- Disables the `embedded-cluster-api` feature in Rancher.
+- Deletes the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks, as they are no longer needed.
+
+These webhooks can be removed through the Rancher UI as well:
+
+1. In the upper left corner, click **☰** > **Cluster Management**.
+1. Select your local cluster.
+1. In the left-hand navigation menu, select **More Resources** > **Admission**.
+1. From the dropdown, select the Resource pages for `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`.
+1. On the respective Resource pages, click the **⋮** that are attached to the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks and select the **Delete** option.
+
+The webhooks can also be accessed by entering the names of the webhooks into the **Resource Search** field.
+
+The following `kubectl` commands can manually remove the necessary webhooks:
+
+```console
+kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
+```
+
+```console
+kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
+```
+
+Use the following example to disable the `embedded-cluster-api` feature from the console:
+
+1. Create a `feature.yaml` file, with `embedded-cluster-api` set to false:
+
+```yaml title="feature.yaml"
+apiVersion: management.cattle.io/v3
+kind: Feature
+metadata:
+  name: embedded-cluster-api
+spec:
+  value: false
+```
+
+2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
+
+```bash
+kubectl apply -f feature.yaml
+```
+
+## Installing the Rancher Turtles Operator
+
+You can install the Rancher Turtles operator via the Rancher UI, or with Helm. The first method is recommended for most environments.
+
+:::caution
+
+If you already have the Cluster API (CAPI) Operator installed in your cluster, you must use the [manual Helm installation method](#installing-via-helm).
+
+:::
+
+### Installing via the Rancher UI
+
+By adding the Turtles repository via the Rancher UI, Rancher can process the installation and configuration of the CAPI Extension.
+
+1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select **local**.
+1. In the left navigation menu of the **Cluster Dashboard**, select **Apps > Repositories**.
+1. Click **Create** to add a new repository.
+1. Enter the following:
+    - **Name**: turtles
+    - **Index URL**: https://rancher.github.io/turtles
+1. Wait until the new repository has a status of `Active`.
+1. In the left navigation menu, select **Apps > Charts**.
+1. Enter "turtles" into the search filter to find the Turtles chart.
+1. Click **Rancher Turtles - the Cluster API Extension**.
+1. Click **Install > Next > Install**.
+
+This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values).
+
+The installation may take a few minutes and after completing you can see the following new deployments in the cluster:
+
+- `rancher-turtles-system/rancher-turtles-controller-manager`
+- `rancher-turtles-system/rancher-turtles-cluster-api-operator`
+- `capi-system/capi-controller-manager`
+
+#### Demo
+
+This demo illustrates how to use the Rancher UI to install Rancher Turtles, create/import a CAPI cluster, and install monitoring on the cluster:
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/lGsr7KfBjgU?si=ORkzuAJjcdXUXMxh" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+### Installing via Helm
+
+There are two ways to install Rancher Turtles with Helm, depending on whether you include the [CAPI Operator](https://github.com/kubernetes-sigs/cluster-api-operator) as a dependency:
+
+- [Install Rancher Turtles with CAPI Operator as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency).
+- [Install Rancher Turtles without CAPI Operator](#installing-rancher-turtles-without-cluster-api-capi-operator-as-a-helm-dependency).
+
+The CAPI Operator is required for installing Rancher Turtles. You can choose whether you want to take care of this dependency yourself or let the Rancher Turtles Helm chart manage it for you. [Installing Turtles as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency) is simpler, but your best option depends on your specific configuration.
+
+The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/tasks/capi-operator/installing_core_provider) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).
+
+#### Installing Rancher Turtles with `Cluster API (CAPI) Operator` as a Helm dependency
+
+1. Add the Helm repository containing the `rancher-turtles` chart as the first step in installation:
+
+```bash
+helm repo add turtles https://rancher.github.io/turtles
+helm repo update
+```
+
+2. As mentioned before, installing Rancher Turtles requires the [CAPI Operator](https://github.com/kubernetes-sigs/cluster-api-operator). The Helm chart can automatically install it with a minimal set of flags:
+
+```bash
+helm install rancher-turtles turtles/rancher-turtles --version <version> \
+    -n rancher-turtles-system \
+    --dependency-update \
+    --create-namespace --wait \
+    --timeout 180s
+```
+
+3. This operation could take a few minutes and after completing you can review the installed controllers listed below:
+
+- `rancher-turtles-controller`
+- `capi-operator`
+
+:::note
+
+- If `cert-manager` is already available in the cluster, disable its installation as a Rancher Turtles dependency. This prevents dependency conflicts:
+`--set cluster-api-operator.cert-manager.enabled=false`
+- For a list of Rancher Turtles versions, refer to the [Turtles release page](https://github.com/rancher/turtles/releases).
+
+:::
+
+This is the basic, recommended configuration, which manages the creation of a secret containing the required CAPI feature flags (`CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL` enabled) in the core provider namespace. These feature flags are required to enable additional CAPI functionality.
+
+If you need to override the default behavior and use an existing secret (or add custom environment variables), you can pass the secret name Helm flag. In this case, as a user, you are in charge of managing the secret creation and its content, including enabling the minimum required features: `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL`.
+
+```bash
+helm install ...
+    # Passing secret name and namespace for additional environment variables
+    --set cluster-api-operator.cluster-api.configSecret.name=<secret-name>
+```
+
+The following is an example of a user-managed secret `cluster-api-operator.cluster-api.configSecret.name=variables` with `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL` feature flags set and an extra custom variable:
+
+```yaml title="secret.yaml"
+apiVersion: v1
+kind: Secret
+metadata:
+  name: variables
+  namespace: rancher-turtles-system
+type: Opaque
+stringData:
+  CLUSTER_TOPOLOGY: "true"
+  EXP_CLUSTER_RESOURCE_SET: "true"
+  EXP_MACHINE_POOL: "true"
+  CUSTOM_ENV_VAR: "false"
+```
+
+:::info
+
+For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
+
+:::
+
+#### Installing Rancher Turtles without `Cluster API (CAPI) Operator` as a Helm dependency
+
+:::note
+
+Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/contributing/install_capi_operator) in the Rancher Turtles documentation for assistance.
+
+:::
+
+1. Add the Helm repository containing the `rancher-turtles` chart as the first step in installation:
+
+```bash
+helm repo add turtles https://rancher.github.io/turtles
+helm repo update
+```
+
+2. Install the chart into the `rancher-turtles-system` namespace:
+
+```bash
+helm install rancher-turtles turtles/rancher-turtles --version <version>
+    -n rancher-turtles-system
+    --set cluster-api-operator.enabled=false
+    --set cluster-api-operator.cluster-api.enabled=false
+    --create-namespace --wait
+    --dependency-update
+```
+
+The previous commands tell Helm to ignore installing `cluster-api-operator` as a dependency.
+
+3. This operation could take a few minutes and after completing you can review the installed controller listed below:
+
+- `rancher-turtles-controller`
+
+## Uninstalling Rancher Turtles
+
+:::caution
+
+When installing Rancher Turtles in your Rancher environment, by default, Rancher Turtles enables the CAPI Operator cleanup. This includes cleaning up CAPI Operator specific webhooks and deployments that otherwise cause issues with Rancher provisioning.
+
+To simplify uninstalling Rancher Turtles (via Rancher or Helm command), the official Rancher Turtles Helm chart includes a `post-delete` hook that that removes the following:
+
+- Deletes the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks that are no longer needed.
+- Deletes the CAPI `deployments` that are no longer needed.
+
+:::
+
+To uninstall Rancher Turtles:
+
+```bash
+helm uninstall -n rancher-turtles-system rancher-turtles --cascade foreground --wait
+```
+
+This may take a few minutes to complete.
+
+:::note
+
+Remember that, if you use a different name for the installation or a different namespace, you may need to customize the command for your specific configuration.
+
+:::
+
+After Rancher Turtles is uninstalled, Rancher's `embedded-cluster-api` feature must be re-enabled:
+
+1. Create a `feature.yaml` file, with `embedded-cluster-api` set to true:
+
+```yaml title="feature.yaml"
+apiVersion: management.cattle.io/v3
+kind: Feature
+metadata:
+  name: embedded-cluster-api
+spec:
+  value: true
+```
+
+2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
+
+```bash
+kubectl apply -f feature.yaml
+```
@@ -1,5 +1,5 @@
 ---
-title: Architecture
+title: Fleet Architecture
 ---

 <head>
@@ -14,7 +14,7 @@ The Harvester feature flag is used to manage access to the Virtualization Manage

 To navigate to the Harvester cluster, click **☰ > Virtualization Management**. From Harvester Clusters page, click one of the clusters listed to go to the single Harvester cluster view.

-* If the Harvester feature flag is enabled, Harvester clusters will be filtered out from any pages or apps (such as Fleet and the multi-cluster app) that list Kubernetes clusters.
+* If the Harvester feature flag is enabled, Harvester clusters will be filtered out from any pages or apps (such as Continuous Delivery with Fleet) that list Kubernetes clusters.

 * If the Harvester feature flag is disabled, and a Harvester cluster is imported, the Harvester cluster will be shown in the Rancher cluster list in the Cluster Management page. Harvester clusters will only be shown on the cluster list when the feature flag is off.

@@ -1,5 +1,5 @@
 ---
-title: Architecture
+title: Logging Architecture
 ---

 <head>
@@ -6,7 +6,7 @@ title: Rancher Extensions
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/rancher-extensions"/>
 </head>

-New in Rancher v2.7.0, Rancher introduces **extensions**. Extensions allow users, developers, partners, and customers to extend and enhance the Rancher UI. In addition, users can make changes and create enhancements to their UI functionality independent of Rancher releases. Extensions will enable users to build on top of Rancher to better tailor it to their respective environments. Note that users will also have the ability to update to new versions as well as roll back to a previous version.
+Extensions allow users, developers, partners, and customers to extend and enhance the Rancher UI. In addition, users can make changes and create enhancements to their UI functionality independent of Rancher releases. Extensions will enable users to build on top of Rancher to better tailor it to their respective environments. Note that users will also have the ability to update to new versions as well as roll back to a previous version.

 Extensions are Helm charts that can only be installed once into a cluster; therefore, these charts have been simplified and separated from the general Helm charts listed under **Apps**.

@@ -28,13 +28,6 @@ Examples of built-in Rancher extensions are Fleet, Explorer, and Harvester. Exam

 3. On the **Extensions** page, click on the **Available** tab to select which extensions you want to install.

-:::info
-
-In v2.7.0, the built-in extensions aren't displayed under the **Available** tab. Therefore, you'll need to manually add the desired repos to install extensions.
-
-:::
-<br/>
-
 4. If no extensions are showing as available, you may manually add repos as follows:

    4.1. On the upper right of screen, click on **⋮ > Manage Repositories > Create**.
@@ -53,29 +46,32 @@ In v2.7.0, the built-in extensions aren't displayed under the **Available** tab.

    ![Reload button](/img/reload-button.png)

-### Importing and Installing Extensions in an Air-Gapped Environment
+## Updating and Upgrading Extensions

-1. Find the address of the container image repository  that you want to import as an extension. Rancher provides some extensions, such as Kubewarden and Elemental, through the `ui-plugin-catalog` container image at https://hub.docker.com/r/rancher/ui-plugin-catalog/tags. You should import and use the latest tagged version of the image to ensure you receive the latest features and security updates.
+1. Click **☰ > Extensions** under **Configuration**.
+1. Select the **Updates** tab. 
+1. Click **Update**.

-    * **(Optional)** If the container image is private: [Create](../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) a registry secret within the `cattle-ui-plugin-system` namespace. Enter the domain of the image address in the **Registry Domain Name** field.
+If there is a new version of the extension, there will also be an **Update** button visible on the associated card for the extension in the **Available** tab.
+
+## Deleting Extensions
+
+1. Click **☰**, then click on the name of your local cluster.
+1. From the sidebar, select **Apps > Installed Apps**.
+1. Find the name of the chart you want to delete and select the checkbox next to it. 
+1. Click **Delete**.
+
+## Deleting Extension Repositories
+
+1. Click **☰ > Extensions** under **Configuration**.
+1. On the top right, click **⋮ > Manage Repositories**.
+1. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.
+
+## Deleting Extension Repository Container Images

 1. Click **☰**, then select **Extensions**, under **Configuration**.
-
 1. On the top right, click **⋮ > Manage Extension Catalogs**.
-
-1. Select the **Import Extension Catalog** button.
-
-1. Enter the image address in the **Catalog Image Reference** field. 
-
-    * **(Optional)** If the container image is private: Select the secret you just created from the **Pull Secrets** drop-down menu.
-
-1. Click **Load**. The extension will now be **Pending**.
-
-1. Return to the **Extensions** page.
-
-1. Select the **Available** tab, and click the **Reload** button to make sure that the list of extensions is up to date.
-
-1. Find the extension you just added, and click the **Install** button.
+1. Find the name of the container image you want to delete, then click **⋮ > Uninstall**.

 ## Uninstalling Extensions

@@ -95,13 +91,94 @@ You must reload the page after disabling extensions or display issues may occur.

 :::

-## Updating and Upgrading Extensions
+## Developing Extensions

-1. Click **☰ > Extensions** under **Configuration**.
-1. Select the **Updates** tab. 
-1. Click **Update**.
+To learn how to develop your own extensions, refer to the official [Getting Started](https://rancher.github.io/dashboard/extensions/extensions-getting-started) guide.

-If there is a new version of the extension, there will also be an **Update** button visible on the associated card for the extension in the **Available** tab.
+## Working with Extensions in an Air-gapped Environment
+
+If you intend to work with extensions in an air-gapped environment, you must perform some extra steps before you can complete certain tasks.
+
+### Accessing Rancher UI Extensions in an Air-Gapped Environment
+
+Rancher provides some extensions, such as Kubewarden and Elemental, through the `ui-plugin-catalog` container image at https://hub.docker.com/r/rancher/ui-plugin-catalog/tags. If you're trying to install these extensions in an air-gapped environment, you must make the `ui-plugin-catalog` image accessible.
+
+1. Mirror the `ui-plugin-catalog` image to a private registry:
+
+  ```bash
+  export REGISTRY_ENDPOINT=<my-private-registry-endpoint> # e.g. "my-private-registry.com"
+  docker pull rancher/ui-plugin-catalog:<tag>
+  docker tag rancher/ui-plugin-catalog:<tag> $REGISTRY_ENDPOINT/rancher/ui-plugin-catalog:<tag>
+  docker push $REGISTRY_ENDPOINT/rancher/ui-plugin-catalog:<tag>
+2. Use the mirrored image to create a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/):
+  ```yaml
+  apiVersion: apps/v1
+  kind: Deployment
+  metadata:
+    name: ui-plugin-catalog
+    namespace: cattle-ui-plugin-system
+    labels:
+      catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
+  spec:
+    replicas: 1
+    selector:
+      matchLabels:
+        catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
+    template:
+      metadata:
+        namespace: cattle-ui-plugin-system
+        labels:
+          catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
+      spec:
+        containers:
+        - name: server
+          image: <my-private-registry-endpoint>/rancher/ui-plugin-catalog:<tag>
+          imagePullPolicy: Always
+        imagePullSecrets:
+          - name: <my-registry-credentials>
+  ```
+3. Expose the deployment by creating a [ClusterIP service](https://kubernetes.io/docs/concepts/services-networking/service/#type-clusterip):
+  ```yaml
+  apiVersion: v1
+  kind: Service
+  metadata:
+    name: ui-plugin-catalog-svc
+    namespace: cattle-ui-plugin-system
+  spec:
+    ports:
+      - name: catalog-svc-port
+        port: 8080
+        protocol: TCP
+        targetPort: 8080
+    selector:
+      catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
+    type: ClusterIP
+  ```
+4. Create a [ClusterRepo](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) that targets the ClusterIP service:
+  ```yaml
+  apiVersion: catalog.cattle.io/v1
+  kind: ClusterRepo
+  metadata:
+    name: ui-plugin-catalog-repo
+  spec:
+    url: http://ui-plugin-catalog-svc.cattle-ui-plugin-system:8080
+  ```
+
+After you successfully set up these resources, you can install the extensions from the `ui-plugin-charts` manifest into your air-gapped environment.
+
+### Importing and Installing Extensions in an Air-gapped Environment
+
+1. Find the address of the container image repository that you want to import as an extension. You should import and use the latest tagged version of the image to ensure you receive the latest features and security updates.
+    - **(Optional)** If the container image is private: [Create](../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) a registry secret within the `cattle-ui-plugin-system` namespace. Enter the domain of the image address in the **Registry Domain Name** field.
+1. Click **☰**, then select **Extensions**, under **Configuration**.
+1. On the top right, click **⋮ > Manage Extension Catalogs**.
+1. Select the **Import Extension Catalog** button.
+1. Enter the image address in the **Catalog Image Reference** field. 
+    * **(Optional)** If the container image is private, select the secret you just created from the **Pull Secrets** drop-down menu.
+1. Click **Load**. The extension will now be **Pending**.
+1. Return to the **Extensions** page.
+1. Select the **Available** tab, and click **Reload** to make sure that the list of extensions is up to date.
+1. Find the extension you just added, and click **Install**.

 ### Updating and Upgrading an Extensions Repository in an Air-gapped Environment

@@ -119,26 +196,3 @@ After you mirror the latest changes, follow these steps:
 1. Click **⋮ > Edit config**.
 1. Update the **Container Image** field within the deployment's container with the latest image.
 1. Click **Save**.
-
-## Deleting Helm Charts
-
-1. Click **☰**, then click on the name of your local cluster.
-1. From the sidebar, select **Apps > Installed Apps**.
-1. Find the name of the chart you want to delete and select the checkbox next to it. 
-1. Click **Delete**.
-
-## Deleting Extension Repositories
-
-1. Click **☰ > Extensions** under **Configuration**.
-1. On the top right, click **⋮ > Manage Repositories**.
-1. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.
-
-## Deleting Extension Repository Container Images
-
-1. Click **☰**, then select **Extensions**, under **Configuration**.
-1. On the top right, click **⋮ > Manage Extension Catalogs**.
-1. Find the name of the container image you want to delete. Click **⋮ > Uninstall**.
-
-## Developing Extensions
-
-To learn how to develop your own extensions, refer to the official [Getting Started](https://rancher.github.io/dashboard/extensions/extensions-getting-started) guide.
@@ -1,93 +0,0 @@
---
-title: API
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/about-the-api"/>
-</head>
-
-## How to use the API
-
-The API has its own user interface accessible from a web browser.  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 on 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 will look 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](../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, 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. 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 here](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 resources
-  - 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 filtering is allowed on
-  - What HTTP verb methods are available for the collection itself, or for individual resources in the collection.
-
-
- So the theory is that you can load just the list of schemas and know everything about the API.  This is in fact how the UI for the API works, it 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 other `links` inside of the returned resources to get any other information.
-
- In practice, you will probably 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 to 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 these, send a HTTP `POST` to the URL in the `actions` map for the action you want.  Some 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, e.g. `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, e.g. `/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 Rancher API Calls
-
-You can use browser developer tools to capture how the Rancher 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 will need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click on 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 will be able to see the POST request, including the URL it was sent to, all of the 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 Rancher API calls for your respective clusters and resources. This feature is not enabled by default. To enable it:
-
-1. Click on your **User Tile** in the top right corner of the UI and select **Preferences** from the dropdown menu.
-2. Under the **Advanced Features** section, click **Enable "View in API"**
-
-Once checked, the **View in API** link will now appear under the **⋮** sub-menu on resource pages in the UI.
@@ -1,5 +1,5 @@
 ---
-title: Best Practices Guide
+title: Best Practice Guides
 ---

 <head>
@@ -1,5 +1,5 @@
 ---
-title: Best Practices for Rancher Managed vSphere Clusters
+title: Best Practices for Rancher Managed VMware vSphere Clusters
 ---

 <head>
@@ -18,6 +18,6 @@ Configuring sensible monitoring and alerting rules is vital for running any prod

 Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.

-### Best Practices for Rancher Managed vSphere Clusters
+### Best Practices for Rancher Managed VMware vSphere Clusters

 This [guide](rancher-managed-clusters-in-vsphere.md) outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -1,12 +1,12 @@
 ---
-title: Installing Rancher in a vSphere Environment
+title: Installing Rancher in a VMware vSphere Environment
 ---

 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
 </head>

-This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
+This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a VMware vSphere environment. It also desctibes standard vSphere best practices as documented by VMware.


 <figcaption>Solution Overview</figcaption>
@@ -16,6 +16,6 @@ Refer to this [guide](tips-for-running-rancher.md) for our general advice for se

 This [guide](rancher-deployment-strategy.md) is designed to help you choose whether a regional deployment strategy or a hub-and-spoke deployment strategy is better for a Rancher server that manages downstream Kubernetes clusters.

-### Installing Rancher in a vSphere Environment
+### Installing Rancher in a VMware vSphere Environment

 This [guide](on-premises-rancher-in-vsphere.md) outlines a reference architecture for installing Rancher in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -49,7 +49,6 @@ This is typical in Rancher, as many operations create new `RoleBinding` objects

 You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
 * Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
-* If you use [external authentication](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md), use groups to assign roles.
 * Only add users to clusters and projects when necessary.
 * Remove clusters and projects when they are no longer needed.
 * Only use custom roles if necessary.
@@ -59,6 +58,12 @@ You can reduce the number of `RoleBindings` in the upstream cluster in the follo
 * Kubernetes permissions are always "additive" (allow-list) rather than "subtractive" (deny-list). Try to minimize configurations that gives access to all but one aspect of a cluster, project, or namespace, as that will result in the creation of a high number of `RoleBinding` objects.
 * Experiment to see if creating new projects or clusters manifests in fewer `RoleBindings` for your specific use case.

+### Using External Authentication
+
+If you have fifty or more users, you should configure an [external authentication provider](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md). This is necessary for better performance.
+
+After you configure external authentication, make sure to assign permissions to groups instead of to individual users. This helps reduce the `RoleBinding` object count.
+
 ### RoleBinding Count Estimation

 Predicting how many `RoleBinding` objects a given configuration will create is complicated. However, the following considerations can offer a rough estimate:
@@ -105,6 +110,14 @@ Although managed Kubernetes services make it easier to deploy and run Kubernetes

 Use RKE2 for large scale use cases.

+### Keep all Upstream Cluster Nodes co-located
+
+To provide high availability, Kubernetes is designed to run nodes and control components in different zones. However, if nodes and control plane components are located in different zones, network traffic may be slower.
+
+Traffic between Rancher components and the Kubernetes API is especially sensitive to network latency, as is etcd traffic between nodes.
+
+To improve performance, run all upstream node clusters in the same location. In particular, make sure that latency between etcd nodes and Rancher is as low as possible.
+
 ### Keeping Kubernetes Versions Up to Date

 You should keep the local Kubernetes cluster up to date. This will ensure that your cluster has all available performance enhancements and bug fixes.
@@ -118,3 +131,13 @@ The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.4/op-guid
 It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).

 Etcd performance will also be negatively affected by network latency between nodes as that will slow down network communication. Etcd nodes should be located together with Rancher nodes.
+
+### Browser Requirements
+
+At high scale, Rancher transfers more data from the upstream cluster to UI components running in the browser, and those components also need to perform more processing.
+
+For best performance, ensure that the host running the hardware meets these requirements:
+ - 2020 i5 10th generation Intel (4 cores) or equivalent
+ - 8 GB RAM
+ - Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
+ - Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
@@ -22,7 +22,7 @@ Run `kubectl cluster-info` or `kubectl get pods` successfully.

 _Requirements_

-If admins have [kubeconfig token generation turned off](../about-the-api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires the [Rancher CLI](./rancher-cli.md) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like:
+If admins have [kubeconfig token generation turned off](../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires the [Rancher CLI](./rancher-cli.md) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like:
 `Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`.

 This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:
@@ -33,4 +33,4 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
 4. OpenLDAP
 5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth

-When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../about-the-api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), or [gets deleted from the Rancher server](../about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
+When you first run kubectl, for example, `kubectl get pods`, you are prompted to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), or [gets deleted from the Rancher server](../../api/api-tokens.md#deleting-tokens). Upon expiration, you must log in with the Rancher server again to run the `kubectl get pods` command.
@@ -1,5 +1,5 @@
 ---
-title: VSphere Node Template Configuration
+title: VMware vSphere Node Template Configuration
 ---

 <head>
@@ -149,13 +149,13 @@ Project network isolation is available if you are using any RKE2 network plugin

 ##### CoreDNS

-By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
+By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#coredns) for additional CoreDNS configurations.

 ##### NGINX Ingress

-If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
+If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.

-Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
+Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.

 ##### Metrics Server

@@ -40,6 +40,10 @@ The AKSConfig, EKSConfig or GKEConfig represents the desired state. Nil values a

 UpstreamSpec represents the cluster as it is in the hosted Kubernetes provider. It's refreshed every 5 minutes. After the UpstreamSpec is refreshed, Rancher checks if the cluster has an update in progress. If it's currently updating, nothing further is done. If it is not currently updating, any managed fields on AKSConfig, EKSConfig or GKEConfig are overwritten with their corresponding value from the recently updated UpstreamSpec.

+:::warning
+When you import a cluster from a cloud provider into Rancher, UpstreamSpec represents the cluster state and Config is empty. If you then update the imported cluster through the Rancher UI, both UpstreamSpec and Config become non-null. Any further updates to the cluster should be applied through Rancher. This is because there is no safe way to determine if changes originating from UpstreamSpec represent the desired state or just a mismatch with Config. If you update the imported cluster through the cloud provider console after you apply any updates through the Rancher UI, the controller will deploy a rollback and the content of Config will be considered the desired state.
+:::
+
 The effective desired state can be thought of as the UpstreamSpec, plus all non-nil fields in the AKSConfig, EKSConfig or GKEConfig. This is what is displayed in the UI.

 If Rancher and another source attempt to update a cluster at the same time, or within 5 minutes of an update finishing, any managed fields are likely to get caught in a race condition. To use EKS as an example, a cluster may have PrivateAccess as a managed field. If PrivateAccess is false and then enabled in EKS console at 11:01, and tags are updated from Rancher before 11:05, then the value is likely to be overwritten. This can also occur if tags are updated while the cluster is still processing the update. The issue described in this example shouldn't occur if the cluster is registered and the PrivateAccess fields are nil.
@@ -1,5 +1,5 @@
 ---
-title: Monitoring V2 Configuration Examples
+title: Monitoring Configuration Examples
 ---

 <head>
--- a/Show More
+++ b/Show More