v2.11.11 - Rancher Manager Release Maintenance (#2199 )

Helps #2185. Co-authored-by: Petr Kovar <petr.kovar@suse.com>
Merge pull request #2074 from andreas-kupries/rancher-45110-global-resource-docs
2026-09-29 22:49:17 +00:00 · 2026-02-25 15:46:17 -08:00 · 2026-02-24 08:59:10 -08:00 · 2026-02-24 08:25:06 -08:00 · 2026-02-24 16:52:56 +01:00 · 2026-02-20 08:50:01 -08:00
1070 changed files with 105224 additions and 1116 deletions
@@ -93,7 +93,7 @@ Subsequent executions will check for updated dependencies, if there are none, it

 License
 =======
-Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)
+Copyright (c) 2014-2026 [SUSE, LLC.](https://www.suse.com/)

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
@@ -6,10 +6,6 @@ title: Deprecated Features in Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>

-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?

 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
@@ -6,10 +6,6 @@ title: Deprecated Features in Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>

-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?

 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -6,10 +6,6 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-### Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ### 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：
@@ -6,10 +6,6 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-### Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ### 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -6,10 +6,6 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-## Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：
@@ -0,0 +1,320 @@
+#!/bin/bash
+
+# backport_docs.sh
+#
+# A script to backport changes (added, modified, and removed files)
+# from 'docs/' and 'sidebars.js' to their versioned counterparts.
+
+# --- Configuration ---
+DOCS_DIR="docs"
+VERSIONED_DIR="versioned_docs"
+SIDEBARS_SOURCE_FILE="sidebars.js"
+SIDEBARS_VERSIONED_DIR="versioned_sidebars"
+
+# --- Colors ---
+GREEN="\033[0;32m"
+RED="\033[0;31m"
+YELLOW="\033[0;33m"
+BLUE="\033[0;34m"
+RESET="\033[0m"
+
+# --- Help Message ---
+usage() {
+    echo -e "${GREEN}Usage:${RESET} $0 [version1] [version2] ..."
+    echo
+    echo -e "${YELLOW}Description:${RESET}"
+    echo "  Backports changes (added, modified, removed) from the '$DOCS_DIR/' directory"
+    echo "  and modifications from '$SIDEBARS_SOURCE_FILE' to specified versioned directories."
+    echo
+    echo -e "${YELLOW}Arguments:${RESET}"
+    echo "  [version]   (Optional) One or more specific versions to backport to."
+    echo "              If no versions are provided, the script attempts to backport"
+    echo "              to all valid versions found in '$VERSIONED_DIR/'."
+    echo
+    echo -e "${YELLOW}Options:${RESET}"
+    echo "  -h, --help  Show this help message."
+    echo
+    echo -e "${YELLOW}Example (all versions):${RESET}"
+    echo "  $0"
+    echo
+    echo -e "${YELLOW}Example (specific versions):${RESET}"
+    echo "  $0 version-2.12 version-2.13"
+}
+
+# --- Argument Parsing ---
+if [[ "$1" == "-h" || "$1" == "--help" ]]; then
+    usage
+    exit 0
+fi
+
+TARGET_VERSIONS=("$@")
+
+# --- Sanity Checks ---
+if [ ! -d "$DOCS_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$DOCS_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -d "$VERSIONED_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$VERSIONED_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -f "$SIDEBARS_SOURCE_FILE" ]; then
+    echo -e "${RED}Error:${RESET} Source file '$SIDEBARS_SOURCE_FILE' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -d "$SIDEBARS_VERSIONED_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$SIDEBARS_VERSIONED_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+# --- Validate Provided Versions ---
+# This block only runs if arguments were passed
+if [ ${#TARGET_VERSIONS[@]} -gt 0 ]; then
+    echo -e "${BLUE}Validating provided versions...${RESET}"
+    for version in "${TARGET_VERSIONS[@]}"; do
+        # Fail if the argument looks like an option (starts with -)
+        if [[ "$version" == -* ]]; then
+            echo -e "${RED}Error:${RESET} Unknown option '$version'."
+            echo "Use -h or --help for usage."
+            exit 1
+        fi
+        
+        if [ ! -d "$VERSIONED_DIR/$version" ]; then
+            echo -e "${RED}Error:${RESET} Provided version '$version' is not a valid directory under '$VERSIONED_DIR/'."
+            exit 1
+        fi
+    done
+    echo -e "${GREEN}All provided versions are valid.${RESET}"
+    echo # Newline
+fi
+
+# --- Find Target Versions (if not specified) ---
+# This block only runs if NO arguments were passed
+if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
+    echo -e "${BLUE}No versions specified. Detecting all valid versions in '$VERSIONED_DIR'...${RESET}"
+    # Find all subdirectories
+    for dir in "$VERSIONED_DIR"/*/; do
+        # Check if the directory exists and is a directory
+        if [ -d "$dir" ]; then
+            # Check if the directory contains any file *other* than notice.md
+            # We use -print -quit to stop find immediately after the first match
+            if find "$dir" -type f -not -name "notice.md" -print -quit | grep -q .; then
+                # It's a valid version, add its basename
+                TARGET_VERSIONS+=("$(basename "$dir")")
+            fi
+        fi
+    done
+fi
+
+if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
+    echo -e "${RED}Error:${RESET} No target versions found or specified."
+    exit 1
+fi
+
+echo -e "${GREEN}Target versions:${RESET} ${TARGET_VERSIONS[*]}"
+echo # Newline
+
+# --- Find Files to Backport (Docs) ---
+echo -e "${BLUE}Finding modified/new/removed files in '$DOCS_DIR'...${RESET}"
+# Find staged (cached) and unstaged (HEAD) changes (Added, Modified, or Deleted)
+FILES_TO_BACKPORT=$( (git diff --name-only --diff-filter=AMD HEAD -- "$DOCS_DIR"; \
+                       git diff --name-only --diff-filter=AMD --cached -- "$DOCS_DIR") \
+                       | sort -u)
+
+if [ -z "$FILES_TO_BACKPORT" ]; then
+    echo -e "${GREEN}No modified, new, or removed files found in '$DOCS_DIR'. Nothing to do.${RESET}"
+else
+    echo -e "${GREEN}Files to backport:${RESET}"
+    echo -e "${FILES_TO_BACKPORT}"
+    echo # Newline
+
+    # --- Main Logic (Docs) ---
+    echo -e "${BLUE}Starting backport process for docs...${RESET}"
+
+    # Use 'read' to handle file paths
+    echo "$FILES_TO_BACKPORT" | while IFS= read -r file; do
+        if [ -z "$file" ]; then # Skip empty lines
+            continue
+        fi
+
+        echo -e "${YELLOW}Processing file:${RESET} $file"
+
+        # Get the relative path inside 'docs/'
+        # e.g., 'docs/guides/intro.md' -> 'guides/intro.md'
+        REL_PATH="${file#$DOCS_DIR/}"
+        if [ "$REL_PATH" == "$file" ]; then
+            echo -e "  ${RED}Error:${RESET} Could not determine relative path for '$file'. Skipping."
+            continue
+        fi
+
+        # Check if the file exists in the source.
+        # If it does, it's ADDED or MODIFIED.
+        # If it doesn't, it's DELETED.
+        if [ -f "$file" ]; then
+            # --- LOGIC FOR ADDED/MODIFIED FILES ---
+            
+            PATCH_DATA_STAGED=$(git diff --cached -- "$file")
+            PATCH_DATA_UNSTAGED=$(git diff -- "$file")
+
+            # Loop through each target version
+            for version in "${TARGET_VERSIONS[@]}"; do
+                TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
+                TARGET_DIR=$(dirname "$TARGET_FILE")
+
+                # Check if the target *versioned file* exists
+                if [ ! -f "$TARGET_FILE" ]; then
+                    # File doesn't exist in the versioned directory.
+                    # This is a NEW file. Copy it directly.
+                    echo -e "  ${BLUE}Backporting as new file to version:${RESET} $version"
+                    # Ensure target directory exists
+                    mkdir -p "$TARGET_DIR"
+                    if [ $? -ne 0 ]; then
+                        echo -e "    ${RED}Error:${RESET} Could not create directory '$TARGET_DIR'. Skipping."
+                        continue
+                    fi
+                    # Copy the new file
+                    cp "$file" "$TARGET_FILE"
+                    if [ $? -eq 0 ]; then
+                        echo -e "    ${GREEN}Copied:${RESET} $file -> $TARGET_FILE"
+                    else
+                        echo -e "    ${RED}Error:${RESET} Failed to copy '$file' to '$TARGET_FILE'."
+                    fi
+                else
+                    # File *does* exist. Patch it using the deltas.
+                    echo -e "  ${BLUE}Backporting changes to version:${RESET} $version"
+                    
+                    patch_applied=false
+                    patch_failed=false
+
+                    if [ -n "$PATCH_DATA_STAGED" ]; then
+                        echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+                        if [ $? -eq 0 ]; then
+                            echo -e "    ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
+                            patch_applied=true
+                        else
+                            echo -e "    ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
+                            patch_failed=true
+                        fi
+                    fi
+
+                    if [ -n "$PATCH_DATA_UNSTAGED" ]; then
+                        echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+                        if [ $? -eq 0 ]; then
+                            echo -e "    ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
+                            patch_applied=true
+                        else
+                            echo -e "    ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
+                            patch_failed=true
+                        fi
+                    fi
+
+                    if [ "$patch_failed" = true ]; then
+                        echo -e "    ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
+                    elif [ "$patch_applied" = false ]; then
+                        echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
+                    fi
+                fi
+            done # end version loop
+        
+        else
+            # --- LOGIC FOR DELETED FILES ---
+            echo -e "  ${BLUE}File was deleted. Propagating deletion...${RESET}"
+
+            # Loop through each target version
+            for version in "${TARGET_VERSIONS[@]}"; do
+                TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
+                
+                if [ -f "$TARGET_FILE" ]; then
+                    rm "$TARGET_FILE"
+                    if [ $? -eq 0 ]; then
+                        echo -e "    ${GREEN}Deleted:${RESET} $TARGET_FILE"
+                    else
+                        echo -e "    ${RED}Error:${RESET} Failed to delete '$TARGET_FILE'."
+                    fi
+                else
+                    echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already deleted)"
+                fi
+            done # end version loop
+        fi # end add/modify/delete check
+
+        echo # Add a newline for readability
+    done # end file loop
+fi
+
+echo # Newline
+
+# --- Main Logic (Sidebars) ---
+echo -e "${BLUE}Checking for sidebars changes...${RESET}"
+
+# Check for staged or unstaged MODIFICATIONS to the source sidebars file
+# We only care about modifications (M), not additions or deletions.
+SIDEBARS_CHANGED=$( (git diff --name-only --diff-filter=M HEAD -- "$SIDEBARS_SOURCE_FILE"; \
+                     git diff --name-only --diff-filter=M --cached -- "$SIDEBARS_SOURCE_FILE") \
+                     | sort -u)
+
+if [ -z "$SIDEBARS_CHANGED" ]; then
+    echo -e "${GREEN}No modifications found in '$SIDEBARS_SOURCE_FILE'. Skipping sidebars backport.${RESET}"
+else
+    echo -e "${YELLOW}Processing file:${RESET} $SIDEBARS_SOURCE_FILE"
+    
+    # Get the patch data for STAGED changes (vs. HEAD)
+    PATCH_DATA_STAGED=$(git diff --cached -- "$SIDEBARS_SOURCE_FILE")
+    # Get the patch data for UNSTAGED changes (vs. Index)
+    PATCH_DATA_UNSTAGED=$(git diff -- "$SIDEBARS_SOURCE_FILE")
+
+    for version in "${TARGET_VERSIONS[@]}"; do
+
+        # The $version variable already contains "version-X.Y"
+        TARGET_FILE="$SIDEBARS_VERSIONED_DIR/${version}-sidebars.json"
+
+        # Check if the corresponding versioned sidebars file exists
+        if [ ! -f "$TARGET_FILE" ]; then
+            echo -e "  ${YELLOW}Skipped:${RESET} $TARGET_FILE (not found)"
+            continue
+        fi
+
+        echo -e "  ${BLUE}Backporting changes to:${RESET} $TARGET_FILE"
+        
+        patch_applied=false
+        patch_failed=false
+
+        if [ -n "$PATCH_DATA_STAGED" ]; then
+            echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+            if [ $? -eq 0 ]; then
+                echo -e "    ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
+                patch_applied=true
+            else
+                echo -e "    ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
+                patch_failed=true
+            fi
+        fi
+
+        if [ -n "$PATCH_DATA_UNSTAGED" ]; then
+            echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+            if [ $? -eq 0 ]; then
+                echo -e "    ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
+                patch_applied=true
+            else
+                echo -e "    ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
+                patch_failed=true
+            fi
+        fi
+
+        if [ "$patch_failed" = true ]; then
+            echo -e "    ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
+        elif [ "$patch_applied" = false ]; then
+            echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
+        fi
+        echo # Add a newline
+    done # end version loop
+fi
+
+echo # Newline
+echo -e "${GREEN}Backport complete.${RESET}"
@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api-v2-12" />
+<ApiDocMdx id="rancher-api-v2-13" />
@@ -60,17 +60,23 @@ This feature affects all tokens which include, but are not limited to, the follo

 These global settings affect Rancher token behavior.

-| Setting                                                                         | Description                                                                                                                                                                                                                    |
-| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
-| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).                                                 |
-| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
-| [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |
+| Setting | Description |
+| ------- | ----------- |
+| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | TTL in minutes on a user auth session token. |
+| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes). |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | If true, automatically generate tokens when a user downloads a kubeconfig. |

 ### auth-user-session-ttl-minutes

 Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.

+### auth-user-session-idle-ttl-minutes
+
+Time to live (TTL) without user activity for login sessions tokens, in minutes.
+By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
+
 ### kubeconfig-default-token-ttl-minutes

 Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). As of Rancher v2.8, the default duration is `43200`, which means that tokens expire in 30 days.
@@ -20,14 +20,6 @@ To get a description of the fields and structure of the Kubeconfig resource, run
 kubectl explain kubeconfigs.ext.cattle.io
 ```

-## Feature Flag
-
-The Kubeconfigs Public API is available since Rancher v2.12.0 and is enabled by default. It can be disabled by setting the `ext-kubeconfigs` feature flag to `false`.
-
-```sh
-kubectl patch feature ext-kubeconfigs -p '{"spec":{"value":false}}'
-```
-
 ## Creating a Kubeconfig

 Only a **valid and active** Rancher user can create a Kubeconfig. For example, trying to create a Kubeconfig using a `system:admin` service account will lead to an error:
@@ -25,11 +25,15 @@ spec:
 EOF
 ```

-Use `metadata.generateName` to ensure a unique project ID, but note that `kubectl apply` does not work with `metadata.generateName`, so `kubectl create` must be used instead.
+When creating a new project, you have two primary options for setting the name:
+
+- **Automatic Generation:** Use `metadata.generateName` to ensure a unique project ID. However, note that you must use `kubectl create` (instead of `kubectl apply`) with this option, as `kubectl apply` does not support it.
+- **Manual Naming:** You can explicitly set the project ID using `metadata.name`. If a project with that exact name already exists, the name request is denied.
+The display name seen in the UI is set by `spec.displayName`. If `spec.displayName` is not provided, the field `metadata.name` is used instead.

 Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.

-If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+If you create a project through a cluster member account and want that account to be able to access the project, you must include the annotation `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.

 ```bash
 kubectl create -f - <<EOF
@@ -37,8 +41,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -47,7 +50,7 @@ spec:
 EOF
 ```

-Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+Setting the `field.cattle.io/creatorId` field creates a `ProjectRoleTemplateBinding` that grants the specified user the ability to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.

 Setting the  `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.

@@ -98,9 +101,13 @@ spec:
 EOF
 ```

+### Backing Namespace
+
+After creating the project, the field `status.backingNamespace` gets populated. This represents the namespace in the management cluster that is created to manage project related resources. Examples of resources stored in the backing namespace are [project scoped secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) and [project role template bindings](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles).
+
 ## Adding a Member to a Project

-Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
+Look up the project's [backing namespace](#backing-namespace) to specify the `metadata.namespace` field value and look up the project's ID to specify the `projectName` field value.

 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -120,7 +127,7 @@ apiVersion: management.cattle.io/v3
 kind: ProjectRoleTemplateBinding
 metadata:
  generateName: prtb-
-  namespace: p-vwxyz
+  namespace: c-m-abcde-p-vwxyz
 projectName: c-m-abcde:p-vwxyz
 roleTemplateName: project-member
 userPrincipalName: keycloak_user://user
@@ -146,16 +153,16 @@ Create a projectroletemplatebinding for each role you want to assign to the proj

 ## Listing Project Members

-Look up the project ID:
+Look up the project backing namespace:

 ```bash
 kubectl --namespace c-m-abcde get projects
 ```

-to list projectroletemplatebindings in the project's namespace:
+To list projectroletemplatebindings in the project's backing namespace:

 ```bash
-kubectl --namespace p-vwxyz get projectroletemplatebindings
+kubectl --namespace c-m-abcde-p-vwxyz get projectroletemplatebindings
 ```

 ## Deleting a Member From a Project
@@ -165,14 +172,14 @@ Lookup the projectroletemplatebinding IDs containing the member in the project's
 Delete the projectroletemplatebinding from the project's namespace:

 ```bash
-kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
+kubectl --namespace c-m-abcde-p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
 ```

 ## Creating a Namespace in a Project

 The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.

-On the management cluster, look up the project ID for the cluster you are administrating since it generated using `metadata.generateName`:
+On the management cluster, look up the project ID for the cluster you are administrating if generated using `metadata.generateName`:

 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -208,3 +215,5 @@ kubectl --namespace c-m-abcde delete project p-vwxyz
 ```

 Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
+
+It does delete all project role template bindings for the projects, so recreating the project will not restore members added to the project, and you have to add users as members again.
@@ -20,20 +20,14 @@ To get a description of the fields and structure of the Token resource, run:
 kubectl explain tokens.ext.cattle.io
 ```

-## Feature Flag
-
-The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
-
-```sh
-kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
-```
-
 ## Creating a Token

 :::caution
 The Token value is only returned once in the `status.value` field.
 :::

+Since Rancher v2.13.0 the `status.bearerToken` now contains a fully formed and ready-to-use Bearer token that can be used to authenticate to [Rancher API](../v3-rancher-api-guide.md).
+
 Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.

 ```bash
@@ -0,0 +1,187 @@
+---
+title: Users
+---
+
+## User Resource
+
+The `User` resource (users.management.cattle.io) represents a user account in Rancher.
+
+To get a description of the fields and structure of the `User` resource, run:
+
+```sh
+kubectl explain users.management.cattle.io
+```
+
+## Creating a User
+
+Creating a local user is a two-step process: you must create the `User` resource, then provide a password via a Kubernetes `Secret`.
+
+Only a user with sufficient permissions can create a `User` resource.
+
+```bash
+kubectl create -f -<<EOF
+apiVersion: management.cattle.io/v3
+kind: User
+metadata:
+ name: testuser     
+displayName: "Test User"             
+username: "testuser"
+EOF
+```
+The user's password must be provided in a `Secret` object within the `cattle-local-user-passwords` namespace. The Rancher webhook will automatically hash the password and update the `Secret`.
+
+:::important
+
+Important: The `Secret` must have the same name as the metadata.name (and username) of the `User` resource. 
+
+:::
+
+```bash
+kubectl create -f -<<EOF
+apiVersion: v1
+kind: Secret
+metadata:
+ name: testuser
+ namespace: cattle-local-user-passwords
+type: Opaque
+stringData:
+ password: Pass1234567!
+EOF
+```
+
+After the plaintext password is submitted, the Rancher-Webhook automatically hashes it, replacing the content of the `Secret`, ensuring that the plaintext password is never stored:
+
+```yaml
+apiVersion: v1
+data:
+  password: 1c1Y4CdjlehGWFz26F414x2qoj4gch5L5OXsx35MAa8=
+  salt: m8Co+CfMDo5XwVl0FqYzGcRIOTgRrwFSqW8yurh5DcE=
+kind: Secret
+metadata:
+  annotations:
+    cattle.io/password-hash: pbkdf2sha3512
+  name: testuser
+  namespace: cattle-local-user-passwords
+  ownerReferences:
+  - apiVersion: management.cattle.io/v3
+    kind: User
+    name: testuser
+    uid: 663ffb4f-8178-46c8-85a3-337f4d5cbc2e
+  uid: bade9f0a-b06f-4a77-9a39-4284dc2349c5
+type: Opaque
+```
+
+## Updating User's Password
+
+To change a user's password, use the `PasswordChangeRequest` resource, which handles secure password updates.
+
+```yaml
+kubectl create  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: PasswordChangeRequest
+spec:
+  userID: "testuser"
+  currentPassword: "Pass1234567!"
+  newPassword: "NewPass1234567!"
+EOF
+```
+
+## Listing Users
+
+List all `User` resources in the cluster:
+
+```sh
+kubectl get users
+NAME           AGE
+testuser       3m54s
+user-4n5ws     12m
+```
+
+## Viewing a User
+
+View a specific `User` resource by name:
+
+```sh
+kubectl get user testuser
+NAME           AGE
+testuser       3m54s
+```
+
+## Deleting a User
+
+Deleting a user will automatically delete the corresponding password `Secret`.
+
+```sh
+kubectl delete user testuser
+user.management.cattle.io "testuser" deleted
+```
+
+## Get a Current User's Information
+
+A client uses the `SelfUser` resource to retrieve information about the currently authenticated user without knowing their ID. The user ID is returned in the `.status.userID` field.
+
+```bash
+kubectl create -o jsonpath='{.status.userID}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: SelfUser
+EOF
+
+testuser
+```
+
+## Refreshing a User's Group Membership
+
+Updates to user group memberships are triggered by the `GroupMembershipRefreshRequest` resource.
+
+:::note
+Group membership is only supported for external authentication providers.
+:::
+
+### For a Single User
+
+```bash
+kubectl create -o jsonpath='{.status}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: GroupMembershipRefreshRequest
+spec:
+  userId: testuser
+EOF
+
+{
+    "conditions": [
+        {
+            "lastTransitionTime": "2025-11-10T12:01:03Z",
+            "message": "",
+            "reason": "",
+            "status": "True",
+            "type": "UserRefreshInitiated"
+        }
+    ],
+    "summary": "Completed"
+}
+```
+
+### For All Users
+
+```bash
+
+kubectl create -o jsonpath='{.status}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: GroupMembershipRefreshRequest
+spec:
+   userId: "*"
+EOF
+
+{
+    "conditions": [
+        {
+            "lastTransitionTime": "2025-11-10T12:01:59Z",
+            "message": "",
+            "reason": "",
+            "status": "True",
+            "type": "UserRefreshInitiated"
+        }
+    ],
+    "summary": "Completed"
+}
+```
@@ -92,7 +92,7 @@ Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (heal

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

-For more information, see the [Canal GitHub Page.](https://github.com/projectcalico/canal)
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).

 #### Cilium

@@ -6,20 +6,15 @@ title: Deprecated Features in Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>

-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?

 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | October 23, 2025 |
-| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | September 25, 2025 |
-| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | August 28, 2025 |
-| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 30, 2025 |
+| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | January 29, 2026 |
+| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | December 18, 2025 |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | November 25, 2025 |

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

@@ -50,6 +50,38 @@ The following CLI tools are required for setting up the Kubernetes cluster. Plea

 ## Install the Rancher Helm Chart

+:::important
+
+**Important:** In Rancher Community v2.13.1 if your registry configuration is one of the following you may see Rancher generate the `cattle-cluster-agent` image with an incorrect `docker.io` path segment:
+
+- Environments where a **cluster-scoped container registry** is configured for system images.
+- Environments where a **global `system-default-registry`** is configured (e.g. airgap setups), even if no cluster-scoped registry is set.
+
+**Workaround for Affected Setups:** As a workaround, override the `cattle-cluster-agent` image via the `CATTLE_AGENT_IMAGE` environment variable. This value must **not** contain any registry prefix (Rancher will handle that automatically). It should be set only to the repository and tag, for example:`rancher/rancher-agent:v2.13.1`
+
+**Helm `install` example:**
+
+```bash
+helm install rancher rancher-latest/rancher \
+...
+ --set extraEnv[0].name=CATTLE_AGENT_IMAGE \
+ --set extraEnv[0].value=rancher/rancher-agent:v2.13.1
+```
+
+**Helm `upgrade` example:**
+
+```bash
+helm upgrade rancher rancher-latest/rancher \
+...
+ --set extraEnv[0].name=CATTLE_AGENT_IMAGE \
+ --set extraEnv[0].value=rancher/rancher-agent:v2.13.1
+```
+
+**Important Upgrade Note:**
+
+The `CATTLE_AGENT_IMAGE` override is intended only as a temporary workaround for the affected configurations. Once a Rancher version is available that corrects this behavior, the `CATTLE_AGENT_IMAGE` override should be **removed** from Helm values, so that Rancher can resume managing the agent image normally and automatically track future image and tag changes. See [#53187](https://github.com/rancher/rancher/issues/53187#issuecomment-3676484603) for further information.
+:::
+
 Rancher is installed using the [Helm](https://helm.sh/) package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, we can create configurable deployments instead of just using static files.

 For systems without direct internet access, see [Air Gap: Kubernetes install](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md).
@@ -28,6 +28,38 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 ### Helm Version

+:::important
+
+**Important:** In Rancher Community v2.13.1 if your registry configuration is one of the following you may see Rancher generate the `cattle-cluster-agent` image with an incorrect `docker.io` path segment:
+
+- Environments where a **cluster-scoped container registry** is configured for system images.
+- Environments where a **global `system-default-registry`** is configured (e.g. airgap setups), even if no cluster-scoped registry is set.
+
+**Workaround for Affected Setups:** As a workaround, override the `cattle-cluster-agent` image via the `CATTLE_AGENT_IMAGE` environment variable. This value must **not** contain any registry prefix (Rancher will handle that automatically). It should be set only to the repository and tag, for example:`rancher/rancher-agent:v2.13.1`
+
+**Helm `install` example:**
+
+```bash
+helm install rancher rancher-latest/rancher \
+...
+ --set extraEnv[0].name=CATTLE_AGENT_IMAGE \
+ --set extraEnv[0].value=rancher/rancher-agent:v2.13.1
+```
+
+**Helm `upgrade` example:**
+
+```bash
+helm upgrade rancher rancher-latest/rancher \
+...
+ --set extraEnv[0].name=CATTLE_AGENT_IMAGE \
+ --set extraEnv[0].value=rancher/rancher-agent:v2.13.1
+```
+
+**Important Upgrade Note:**
+
+The `CATTLE_AGENT_IMAGE` override is intended only as a temporary workaround for the affected configurations. Once a Rancher version is available that corrects this behavior, the `CATTLE_AGENT_IMAGE` override should be **removed** from Helm values, so that Rancher can resume managing the agent image normally and automatically track future image and tag changes. See [#53187](https://github.com/rancher/rancher/issues/53187#issuecomment-3676484603) for further information.
+:::
+
 The upgrade instructions assume you are using Helm 3.

 <DeprecationHelm2 />
@@ -18,7 +18,7 @@ Some feature flags require a restart of the Rancher container. Features that req

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

- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [Cluster Role Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md) for more information.
+- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [RoleTemplate Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation.md) for more information.
 - `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
 - `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
 - `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
@@ -61,7 +61,7 @@ The following table shows the availability and default values for some feature f

 | Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
 | ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
-| `aggregated-roletemplates` | `Disabled` | Highly experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
+| `aggregated-roletemplates` | `Disabled` | Experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
 | `clean-stale-secrets` | `Active` | GA | v2.10.2 | |
 | `continuous-delivery` | `Active` | GA | v2.6.0 | |
 | `external-rules` | v2.7.14: `Disabled`, v2.8.5: `Active` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
@@ -6,4 +6,4 @@ title: Installation References
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
 </head>

-Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
+Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
@@ -25,10 +25,16 @@ Rancher needs to be installed on a supported Kubernetes version. Consult the [Ra

 Regardless of version and distribution, the Kubernetes cluster must have the aggregation API layer properly configured to support the [extension API](../../../api/extension-apiserver.md) used by Rancher.

-### Install Rancher on a Hardened Kubernetes cluster
+### Install Rancher on a Hardened Kubernetes Cluster

 If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.

+### Install Rancher on an IPv6-only or Dual-stack Kubernetes Cluster
+
+You can deploy Rancher on an IPv6-only or dual-stack Kubernetes cluster.
+
+For details on Rancher’s IPv6-only and dual-stack support, see the [IPv4/IPv6 Dual-stack](../../../reference-guides/dual-stack.md) page.
+
 ## Operating Systems and Container Runtime Requirements

 All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
@@ -238,21 +238,23 @@ In these cases, you have to explicitly allow this traffic in your host firewall,

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

-|       Type      | Protocol |  Port Range | Source/Destination     | Rule Type |
+| Type            | Protocol | Port Range  | Source/Destination     | Rule Type |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-|       SSH       |    TCP   | 22          | 0.0.0.0/0              | Inbound   |
-|       HTTP      |    TCP   | 80          | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 443         | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 2376        | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 2379-2380   | sg-xxx (rancher-nodes) | Inbound   |
-| Custom UDP Rule |    UDP   | 4789        | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 6443        | 0.0.0.0/0              | Inbound   |
-| Custom UDP Rule |    UDP   | 8472        | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 10250-10252 | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 10256       | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 30000-32767 | 0.0.0.0/0              | Inbound   |
-| Custom UDP Rule |    UDP   | 30000-32767 | 0.0.0.0/0              | Inbound   |
-| All traffic     |    All   | All         | 0.0.0.0/0              | Outbound  |
+| SSH             |   TCP    |     22      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| HTTP            |   TCP    |     80      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    2376     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    6443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     179     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    9345     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |  2379-2380  | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 10250-10252 | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    10256    | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    4789     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    8472     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom UDP Rule |   UDP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| All traffic     |   All    |     All     | 0.0.0.0/0 and ::/0     | Outbound  |

 ### Opening SUSE Linux Ports

@@ -42,8 +42,24 @@ kubectl -n cattle-system create secret generic tls-ca \

 The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.

+The certificate chain must be properly formatted, or components may fail to download resources from the Rancher server. 
+
 :::

+## Adding Additional CA Certificates
+
+If you are using a node driver that makes API requests with a different CA than the one configured for Rancher, you can add additional root certificates and certificate chains. 
+
+Create a unique file ending in `.pem` for each certificate that is required, and use kubectl to create the 
+`tls-additional` secret in the `cattle-system` namespace.
+
+```console
+kubectl -n cattle-system create secret generic tls-additional \
+  --from-file=cacerts1.pem=cacerts1.pem --from-file=cacerts2.pem=cacerts2.pem
+```
+
+Rancher mounts these CA root certificates and certificate chains into the node driver pod during provisioning.
+
 ## Updating a Private CA Certificate

 Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -96,7 +96,8 @@ To enable draining each node during a cluster upgrade,

 :::note

-There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.
+- There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.
+- During an upgrade, nodes may be drained even when no user-visible YAML changes are present. This can occur if non-dynamic configuration files are updated or if a new `system-agent-installer` image is introduced. In such cases, Rancher generates a new upgrade plan, resulting in a new plan hash. When `Upgrade Strategy` is set to `Drain nodes`, this plan change can trigger node draining.

 :::

@@ -16,11 +16,15 @@ For configuration details, refer to the [official Kubernetes documentation](http
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2" default>

-### Method 1 (Recommended): Set `audit-policy-file` in `machineGlobalConfig`
+### Method 1 (Recommended): Set `audit-policy-file` in `machineGlobalConfig` or `machineSelectorConfig`

-You can set `audit-policy-file` in the configuration file. Rancher delivers the file to the path `/var/lib/rancher/rke2/etc/config-files/audit-policy-file` in control plane nodes, and sets the proper options in the RKE2 server.
+You can set `audit-policy-file` in the configuration file using either `machineGlobalConfig` or `machineSelectorConfig`.

-Example:
+When using `machineGlobalConfig`, Rancher delivers the file to the path `/var/lib/rancher/rke2/etc/config-files/audit-policy-file` on **all nodes** (both control plane and worker nodes), and sets the proper options in the RKE2 server. This may cause unwanted worker node reconciliation when the audit policy is modified.
+
+To avoid worker node reconciliation, use `machineSelectorConfig` with a label selector to target only control plane nodes. This ensures that the audit policy file is only delivered to control plane nodes.
+
+Example using `machineGlobalConfig`:
 ```yaml
 apiVersion: provisioning.cattle.io/v1
 kind: Cluster
@@ -38,6 +42,28 @@ spec:
                  - pods
 ```

+Example using `machineSelectorConfig` (recommended to avoid worker node reconciliation):
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          audit-policy-file: |
+            apiVersion: audit.k8s.io/v1
+            kind: Policy
+            rules:
+              - level: RequestResponse
+                resources:
+                  - group: ""
+                    resources:
+                      - pods
+        machineLabelSelector:
+          matchLabels:
+            rke.cattle.io/control-plane-role: 'true'
+```
+
 ### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`

 :::note
@@ -103,12 +129,6 @@ spec:
            rke.cattle.io/control-plane-role: 'true'
 ```

-:::tip
-
-You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
-
-:::
-
 For more information about cluster configuration, refer to the [RKE2 cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) pages.

 </TabItem>
@@ -178,12 +198,6 @@ spec:
            rke.cattle.io/control-plane-role: 'true'
 ```

-:::tip
-
-You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
-
-:::
-
 For more information about cluster configuration, refer to the [K3s cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) pages.

 </TabItem>
@@ -1,19 +0,0 @@
---
-title: ClusterRole Aggregation
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation"/>
-</head>
-
-:::caution
-ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11 and v2.12. It is expected to be available as a beta for users in v2.13.
-:::
-
-ClusterRole aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
-
-| Environment Variable Key | Default Value | Description |
-| --- | --- | --- |
-| `aggregated-roletemplates` | `false` | [Experimental] Make RoleTemplates use aggregation for generated RBAC roles. |
-
-The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -0,0 +1,21 @@
+---
+title: RoleTemplate Aggregation
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation"/>
+</head>
+
+:::caution
+RoleTemplate aggregation is an experimental feature in v2.13 that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. Breaking changes may occur between v2.13 and v2.14.
+:::
+
+RoleTemplate aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
+
+For more information on how the feature can improve scalability and performance, please see the [Rancher Blog post](https://www.suse.com/c/rancher_blog/fewer-bindings-more-power-ranchers-rbac-boost-for-enhanced-performance-and-scalability/).
+
+| Environment Variable Key | Default Value | Description |
+| --- | --- | --- |
+| `aggregated-roletemplates` | `false` | [Beta] Make RoleTemplates use aggregation for generated RBAC roles. |
+
+The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -15,10 +15,8 @@ The etcd data set is automatically cleaned up on a five-minute interval by Kuber
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      quota-backend-bytes: 5368709120
+etcd-arg:
+  - "quota-backend-bytes=5368709120"
 ```

 ## Scaling etcd Disk Performance
@@ -32,12 +30,7 @@ To implement this solution in an RKE2/K3s cluster, the `/var/lib/etcd/data` and
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      data-dir: '/var/lib/rancher/etcd/data/'
-      wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
-    extra_binds:
-      - '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
-      - '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
+etcd-arg:
+  - "data-dir=/var/lib/etcd/data"
+  - "wal-dir=/var/lib/etcd/wal"
 ```
@@ -58,3 +58,7 @@ if the user has not yet logged in to Rancher. However, if the user has previousl
 ### You are not redirected to your authentication provider

 If you fill out the **Configure an Amazon Cognito account** form and click on **Enable**, and you are not redirected to Amazon Cognito, verify your Amazon Cognito configuration.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -363,3 +363,22 @@ Since the filter prevents Rancher from seeing that the user belongs to an exclud
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
    - Use the built-in Rancher auth or
    - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
+
+## Azure AD Roles Claims
+
+Rancher supports the Roles claim provided by the Azure AD OIDC provider token, allowing for complete delegation of Role-Based Access Control (RBAC) to Azure AD. Previously, Rancher only processed the `Groups` claim to determine a user's `group` membership. This enhancement extends the logic to also include the Roles claim within the user's OIDC token.
+
+By including the Roles claim, administrators can:
+
+- Define specific high-level roles in Azure AD.
+- Bind these Azure AD Roles directly to ProjectRoles or ClusterRoles within Rancher.
+- Centralize and fully delegate access control decisions to the external OIDC provider.
+
+For example, consider the following role structure in Azure AD:
+
+| Azure AD Role Name | Members        |
+|--------------------|----------------|
+| project-alpha-dev  | User A, User C |
+
+
+User A logs into Rancher via Azure AD. The OIDC token includes a Roles claim, [`project-alpha-dev`]. The Rancher logic processes the token, and the internal list of `groups`/roles for User A which includes `project-alpha-dev`. An administrator has created a Project Role Binding that maps the Azure AD Role `project-alpha-dev` to the Project Role `Dev Member` for Project Alpha. User A is automatically granted the `Dev Member` role in Project Alpha.
@@ -7,60 +7,75 @@ description: Create an OpenID Connect (OIDC) client and configure Rancher to wor
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc"/>
 </head>

-If your organization uses an OIDC provider for user authentication, you can configure Rancher to allow login using Identity Provider (IdP) credentials. Rancher supports integration with the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to configure Rancher to work using the OIDC protocol.
+Generic OpenID Connect (OIDC) allows users to sign in to Rancher using their credentials from their existing account at an OIDC Identity Provider (IdP). Rancher supports integration with the OIDC protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to create an OIDC client and configure Rancher to work with your authentication provider. Users can then sign into Rancher using their login from the OIDC IdP.

 ## Prerequisites

- In Rancher:
-  - Generic OIDC is disabled.
+### Identity Provider
+
+In Rancher, Generic OIDC is disabled.

 :::note
+
 Consult the documentation for your specific IdP to complete the listed prerequisites.
+
 :::

- In your IdP:
-  - Create a new client with the settings below:
+#### OIDC Client
+
+In your IdP, create a new client with the settings below:
+
+  Setting | Value
+  ------------|------------
+  `Client ID` | <CLIENT_ID> (e.g. `rancher`)
+  `Name` | <CLIENT_NAME> (e.g. `rancher`)
+  `Client Protocol` | `openid-connect`
+  `Access Type` | `confidential`
+  `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+
+In the new OIDC client, create mappers to expose the user's fields.
+
+:::note
+
+The `groups` and `full_group_path` claims generated by the Groups and Group Path mappers, which you create within the OIDC client in your Identity Provider, should be JSON arrays, e.g. `"groups":["admins","devs","qa"]` and `"full_group_path":["/admins","/devs","/qa"]`.
+
+:::
+
+  1. Create a new `Groups Mapper` with the settings below:

    Setting | Value
    ------------|------------
-    `Client ID` | <CLIENT_ID> (e.g. `rancher`)
-    `Name` | <CLIENT_NAME> (e.g. `rancher`)
-    `Client Protocol` | `openid-connect`
-    `Access Type` | `confidential`
-    `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+    `Name` | `Groups Mapper`
+    `Mapper Type` | `Group Membership`
+    `Token Claim Name` | `groups`
+    `Add to ID token` | `OFF`
+    `Add to access token` | `OFF`
+    `Add to user info` | `ON`

-  - In the new OIDC client, create mappers to expose the users fields.
-    - Create a new Groups Mapper with the settings below:
+  1. Create a new `Client Audience` with the settings below:

-      Setting | Value
-      ------------|------------
-      `Name` | `Groups Mapper`
-      `Mapper Type` | `Group Membership`
-      `Token Claim Name` | `groups`
-      `Add to ID token` | `OFF`
-      `Add to access token` | `OFF`
-      `Add to user info` | `ON`
+    Setting | Value
+    ------------|------------
+    `Name` | `Client Audience`
+    `Mapper Type` | `Audience`
+    `Included Client Audience` | `CLIENT_NAME`
+    `Add to access token` | `ON`

-    - Create a new Client Audience with the settings below:
+  1. Create a new `Groups Path` with the settings below.

-      Setting | Value
-      ------------|------------
-      `Name` | `Client Audience`
-      `Mapper Type` | `Audience`
-      `Included Client Audience` | <CLIENT_NAME>
-      `Add to access token` | `ON`
+    Setting | Value
+    ------------|------------
+    `Name` | `Group Path`
+    `Mapper Type` | `Group Membership`
+    `Token Claim Name` | `full_group_path`
+    `Full group path` | `ON`
+    `Add to user info` | `ON`

-    - Create a new "Groups Path" with the settings below.
+:::warning

-      Setting | Value
-      ------------|------------
-      `Name` | `Group Path`
-      `Mapper Type` | `Group Membership`
-      `Token Claim Name` | `full_group_path`
-      `Full group path` | `ON`
-      `Add to user info` | `ON`
+Rancher uses the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that is unique and immutable.

- Important:  Rancher will use the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that will be unique and immutable.
+:::

 ## Configuring Generic OIDC in Rancher

@@ -80,7 +95,31 @@ Consult the documentation for your specific IdP to complete the listed prerequis

 **Result:** Rancher is configured to work with your provider using the OIDC protocol. Your users can now sign into Rancher using their IdP logins.

-## Configuration Reference
+### Custom Claim Mapping
+
+Custom claim mapping within the Generic OIDC configuration is supported for `name`, `email` and `groups` claims. This allows you to manually map these OIDC claims when your IdP doesn't use standard names in tokens.
+
+#### How a Custom Groups Claim Works
+
+A custom groups claim influences how user groups work:
+
+- If both the standard OIDC `groups` claim and the custom groups claim are present in the user's token, the custom claim supplements the list of groups provided by the standard claim.
+- If there is no standard groups claim in the token, the groups listed in the custom claim will form the user's only groups.
+
+:::note
+There is no search functionality available for groups sourced from a custom claim. To assign a role to one of these groups, you must manually enter the group's exact name into the RBAC field.
+:::
+
+#### Configuring Custom Claims
+
+When on the **Configure an OIDC account** form:
+
+1. Select **Add custom claims**.
+1. Add your custom `name`, `email` or `groups` claims to the appropriate **Custom Claims** field.
+
+For example, if your IdP sends `groups` in a claim called `custom_roles`, enter `custom_roles` into the **Custom Groups Claim** field. Rancher then supplements the standard OIDC `groups` claim or looks for that specific claim when processing the user's token.
+
+### Configuration Reference

 | Field                     | Description                                                                                                                                        |
 | ------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -91,6 +130,15 @@ Consult the documentation for your specific IdP to complete the listed prerequis
 | Rancher URL               | The URL for your Rancher Server.                                                                                                                   |
 | Issuer                    | The URL of your IdP.  If your provider has discovery enabled, Rancher uses the Issuer URL to fetch all of the required URLs.                   |
 | Auth Endpoint             | The URL where users are redirected to authenticate.                                                                                                |
+
+#### Custom Claims
+
+| Custom Claim Field | Default OIDC Claim | Custom Claim Description |
+| ------------- | ------------------ | ------------------------ |
+| Custom Name Claim | `name`           | The name of the claim in the OIDC token that contains the user's full name or display name. |
+| Custom Email Claim | `email` | The name of the claim in the OIDC token that contains the user's email address. |
+| Custom Groups Claim | `groups` | The name of the claim in the OIDC token that contains the user's group memberships (used for RBAC). |
+
 ## Troubleshooting

 If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -108,3 +156,7 @@ If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Config
 ### Error: "Invalid grant_type"

 In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -0,0 +1,84 @@
+---
+title: Configure GitHub App
+---
+
+<head> 
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-github-app"/>
+</head>
+
+In environments using GitHub, you can configure the new GitHub App authentication provider in Rancher, which allows users to authenticate against a GitHub Organization account using a dedicated [GitHub App](https://docs.github.com/en/apps/overview). This new provider runs alongside the existing standard GitHub authentication provider, offering increased security and better management of permissions based on GitHub Organization teams.
+
+## Prerequisites
+
+:::warning
+
+The GitHub App authentication provider only works with [GitHub Organization accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts). It does not function with individual [GitHub User accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#user-accounts).
+
+:::
+
+Before configuring the provider in Rancher, you must first create a GitHub App for your organization, generate a client secret for your GitHub App and generate a private key for your GitHub App. Refer to [Registering a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) for details.
+
+### Create GitHub App
+
+1. Open your [GitHub organization settings](https://github.com/settings/organizations).
+1. To the right of the organization, select **Settings**.
+1. In the left sidebar, click **Developer settings** > **GitHub Apps**.
+1. Click **New Github App**.
+1. Fill in the GitHub App configuration form with these values:
+
+    - **GitHub App name**: Anything you like, e.g. `My Rancher`.
+    - **Application description**: Optional, can be left blank.
+    - **Homepage URL**: `https://localhost:8443`.
+    - **Callback URL**: `https://localhost:8443/verify-auth`.
+
+1. Select **Create Github App**.
+
+### Generate a Client Secret
+
+Generate a [client secret](https://docs.github.com/en/rest/authentication/authenticating-to-the-rest-api#using-basic-authentication) on the settings page for your app.
+
+1. Go to your GitHub App.
+1. Next to **Client Secrets**, select **Generate a new client secret**.
+
+### Generate a Private Key
+
+Generate a [private key](https://docs.github.com/en/enterprise-server/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#generating-private-keys) on the settings page for your app.
+
+1. Go to your GitHub App.
+1. Next to **Private Keys**, click **Generate a private key**.
+
+## GitHub App Auth Provider Configuration
+
+To set up the GitHub App Auth Provider in Rancher, follow these steps:
+
+1. Navigate to the **Users & Authentication** section in the Rancher UI.
+1. Select **Auth Providers**.
+1. Select the **GitHub App** tile.
+1. Gather and enter the details of your GitHub App into the configuration form fields.
+
+    | Field Name | Description |
+    | ---------- | ----------- |
+    | **Client ID** (Required) | The client ID of your GitHub App. |
+    | **Client Secret** (Required) | The client secret of your GitHub App. |
+    | **GitHub App ID** (Required) | The numeric ID associated with your GitHub App. |
+    | **Installation ID** (Optional) | If you want to restrict authentication to a single installation of the App, provide its specific numeric Installation ID. |
+    | **Private Key** (Required) | The contents of the Private Key file (in PEM format) generated by GitHub for your App. |
+
+  :::note
+
+  A GitHub App can be installed across multiple Organizations, and each installation has a unique Installation ID. If you want to restrict authentication to a single App installation and GitHub Organization, provide the Installation ID during configuration. If you do not provide an Installation ID, the user's permissions are aggregated across all installations.
+
+  :::
+
+1. Select **Enable**. Rancher attempts to validate the credentials and, upon success, activates the GitHub App provider.
+
+After it is enabled, users logging in via the GitHub App provider are automatically identified and you can leverage your GitHub Organization's teams and users to configure Role-Based Access Control (RBAC) and to assign permissions to projects and clusters.
+
+:::note
+
+Ensure that the users and teams you intend to use for authorization exist within the GitHub organization managed by the App.
+
+:::
+
+- **Users**: Individual GitHub users who are members of the GitHub Organization where the App is installed can log in.
+- **Groups**: GitHub Organization teams are mapped to Rancher Groups, allowing you to assign entire teams permissions within Rancher projects and clusters.
@@ -203,3 +203,7 @@ To resolve this, you can either:
    3. Save your changes.
 
 2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -114,6 +114,8 @@ You can create custom GlobalRoles to satisfy use cases not directly addressed by

 Create custom GlobalRoles through the UI or through automation (such as the Rancher Kubernetes API). You can specify the same type of rules as the rules for upstream roles and clusterRoles. 

+See the list [Global Resources](global-resources.md) for relevant resources.
+
 #### Escalate and Bind verbs

 When giving permissions on GlobalRoles, keep in mind that Rancher respects the `escalate` and `bind` verbs, in a similar fashion to [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
@@ -0,0 +1,44 @@
+---
+title: Global Resources
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-resources"/>
+</head>
+
+Global Resources are non-namespaced resources provided by Rancher. Users who are
+cluster-owners/project-owners do not have access to several of these by
+default. For example principals and roletemplates.
+
+The resources are documented here to support administrators creating and/or
+modifying custom sets of permissions with finding the minimum set of permissions
+needed for a particular task in the dashboard.
+
+As an example, to use the cluster/project permissions pages of the dashboard
+requires permissions on principals to search/display a readable name for users,
+and on roleTemplates, to see a list of usable roleTemplates as well as to
+display a readable name for the role.
+
+Please see the list below to determine what permissions you may need when creating a least-privilege user.
+
+| Group                | Resource                       | Purpose                                                                     |
+| -------------------- | ------------------------------ | --------------------------------------------------------------------------- |
+| auditlog.cattle.io   | auditpolicies                  | Specification of log filers, redactions, verbosity                          |
+| catalog.cattle.io    | clusterrepos                   | Helm chart repository location and credentials                              |
+| ext.cattle.io        | groupmembershiprefreshrequests | Creation triggers refresh of group membership for specific or all users     |
+| ext.cattle.io        | kubeconfigs                    | Kubeconfig file for access to remote clusters                               |
+| ext.cattle.io        | passwordchangerequests         | Creation triggers update of the referenced User's password                  |
+| ext.cattle.io        | selfusers                      | Get delivers User making the request                                        |
+| ext.cattle.io        | tokens                         | Raw API key. See Kubeconfig for wrapped API keys                            |
+| management.cattle.io | authconfigs                    | Configuration of external auth service providers                            |
+| management.cattle.io | clusters                       | Remote cluster management                                                   |
+| management.cattle.io | features                       | Feature controlling rancher behaviour                                       |
+| management.cattle.io | globalrolebindings             | Binding of user/group to a global role                                      |
+| management.cattle.io | globalroles                    | Custom role for global permissions (applied local and remote)               |
+| management.cattle.io | nodedrivers                    | Configuration of driver to provision clusters with a cloud service provider |
+| management.cattle.io | roletemplates                  | Template for custom roles managing project- or cluster-specific permissions |
+| management.cattle.io | settings                       | Setting controlling Rancher behaviour                                       |
+| management.cattle.io | tokens                         | Raw API key, old style.                                                     |
+| management.cattle.io | userattributes                 | Additional information about a managed User                                 |
+| management.cattle.io | users                          | User known to and managed by Rancher                                        |
+| telemetry.cattle.io  | secretrequests                 | Request creation of a secret with arbitrary name, in any namespace          |
@@ -42,7 +42,7 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
     ```

  1. Install the charts:
-   
+
     ```bash
     helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
     helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
@@ -55,7 +55,25 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
     For an **air-gapped environment**, use the following Helm values to pull the `backup-restore-operator` and `kubectl` images from your private registry when you install the rancher-backup Helm chart.

     ```bash
-     --set image.repository <registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
+     --set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
+     ```
+
+     If the host running the Helm commands is **also air-gapped and cannot reach charts.rancher.io**, download the charts on a non-air-gapped host and then install them from local files on the air-gapped host.
+
+     On a non-air-gapped host:
+
+     ```bash
+     helm repo add rancher-charts https://charts.rancher.io
+     helm repo update
+     helm fetch rancher-charts/rancher-backup-crd --version $CHART_VERSION
+     helm fetch rancher-charts/rancher-backup --version $CHART_VERSION
+     ```
+
+     Copy the `rancher-backup-crd-<chart-version>.tgz` and `rancher-backup-<chart-version>.tgz` files to the air-gapped host, then use them to install the charts:
+
+     ```bash
+     helm install rancher-backup-crd ./rancher-backup-crd-<chart-version>.tgz -n cattle-resources-system --create-namespace
+     helm install rancher-backup ./rancher-backup-<chart-version>.tgz -n cattle-resources-system --set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
     ```

     :::
@@ -197,3 +215,31 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
 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.
+
+### 6. Scale Down the Original Rancher Instance
+
+After redirecting traffic to the new Rancher environment, **scale the original Rancher instance to 0 replicas** so it no longer contacts your managed clusters.
+
+Leaving the old server up can cause agents to keep contacting the original `server-url`, which often leaves clusters stuck in **Updating** in the new environment.
+
+```bash
+kubectl scale deployment rancher -n cattle-system --replicas=0
+```
+
+If you originally ran Rancher in Docker:
+
+```bash
+docker stop <original-rancher-container>
+```
+
+:::note
+
+If you wish to keep the original Rancher environment running, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.
+
+```bash
+kubectl rollout restart deployment cattle-cluster-agent -n cattle-system
+```
+
+This triggers a rolling restart of the agent so it re-establishes the connection to the new Rancher environment.
+
+:::
@@ -66,7 +66,8 @@ Before you create your own custom catalog, you should have a basic understanding
    ![values.yaml](/img/helm-app-2.6.png)


-### Chart.yaml annotations
+### Chart.yaml
+#### Annotations

 Rancher supports additional annotations that you can add to the `Chart.yaml` file. These annotations allow you to define application dependencies or configure additional UI defaults:

@@ -76,10 +77,14 @@ Rancher supports additional annotations that you can add to the `Chart.yaml` fil
 | catalog.cattle.io/display-name    | A display name that should be displayed in the App Marketplace instead of the chart name | Display Name of Chart |
 | catalog.cattle.io/namespace       | A fixed namespace where the chart should be deployed in. If set, this can't be changed by the user | fixed-namespace |
 | catalog.cattle.io/release-name    | A fixed release name for the Helm installation. If set, this can't be changed by the user | fixed-release-name |
-| catalog.cattle.io/requests-cpu    | Total amount of CPU that should be unreserverd in the cluster. If less CPU is available, a warning will be shown | 2000m |
-| catalog.cattle.io/requests-memory | Total amount of memory that should be unreserverd in the cluster. If less memory is available, a warning will be shown | 2Gi |
+| catalog.cattle.io/requests-cpu    | Total amount of CPU that should be unreserved in the cluster. If less CPU is available, a warning will be shown | 2000m |
+| catalog.cattle.io/requests-memory | Total amount of memory that should be unreserved in the cluster. If less memory is available, a warning will be shown | 2Gi |
 | catalog.cattle.io/os              | Restricts the OS where this chart can be installed. Possible values: `linux`, `windows`. Default: no restriction | linux |

+### Keywords
+
+With the `keywords` option in the `Chart.yaml` file it is possible to provide a list of categories for sorting your application in the Rancher UI, like `infrastructure`, `monitoring` and more.
+
 ### questions.yml

 Inside the `questions.yml`, most of the content will be around the questions to ask the end user, but there are some additional fields that can be set in this file.
@@ -120,6 +120,18 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and

 Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes).

+### IPv6 Address Requirements
+
+Rancher supports clusters configured with IPv4-only, IPv6-only, or dual-stack networking.
+
+You must provision each node with at least one valid IPv4 address, one IPv6 address, or both, according to the cluster networking configuration.
+
+For IPv6-only environments, ensure you correctly configure the operating system and that the `/etc/hosts` file includes a valid localhost entry, for example:
+
+```
+::1       localhost
+```
+
 :::caution

 You should never register a node with the same hostname or IP address as an existing node. Doing so causes RKE to prevent the node from joining, and provisioning to hang. This can occur for both node driver and custom clusters. If a node must reuse a hostname or IP of an existing node, you must set the `hostname_override` [RKE option](https://rke.docs.rancher.com/config-options/nodes#overriding-the-hostname) before registering the node, so that it can join correctly.
@@ -54,6 +54,7 @@ IAM Policy for nodes with the `controlplane` role:
        "autoscaling:DescribeTags",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
@@ -123,6 +124,7 @@ IAM policy for nodes with the `etcd` or `worker` role:
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
@@ -299,7 +301,7 @@ rancher_kubernetes_engine_config:
    useInstanceMetadataHostname: true
 ```

-You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add [`--node-name`](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.
+You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add `--node-name` to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.

 2. Select the cloud provider. 

@@ -12,7 +12,7 @@ In Kubernetes 1.30 and later, you must use an out-of-tree Azure cloud provider.

 You can also [migrate from an in-tree to an out-of-tree Azure cloud provider](../migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure.md) on Kubernetes 1.29 and earlier. All existing clusters must migrate prior to upgrading to v1.30 in order to stay functional.

-Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
+Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must set `DisableCloudProviders` and `DisableKubeletCloudCredentialProviders` feature gates to `false` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Setting `DisableKubeletCloudCredentialProviders=false` in the Kubelet, Controller Manager, and API Server arguments enables in-tree functionality for authenticating to Azure container registries for image pull credentials. See the [Kubernetes 1.29: Mandala release notes](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/#in-tree-cloud-provider-integration-removal) and this [blog post](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/#continue-using-in-tree-provider-code) for more details.

 Starting with Kubernetes version 1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and will no longer be supported. For new clusters, [install the CSI drivers](#installing-csi-drivers), or migrate to the corresponding CSI drivers `disk.csi.azure.com` and `file.csi.azure.com` by following the [upstream migration documentation](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
 :::
@@ -103,11 +103,11 @@ The `worker` nodes, which is where your workloads will be deployed on, will typi

 We recommend the minimum three-node architecture listed in the table below, but you can always add more Linux and Windows workers to scale up your cluster for redundancy:

-| Node   | Operating System                                    | Kubernetes Cluster Role(s)                                                                                                                                                                                                                         | Purpose                                                                             |
-| ------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
-| Node 1 | Linux (Ubuntu Server 18.04 recommended)             | Control plane, etcd, worker | Manage the Kubernetes cluster                                                       |
-| Node 2 | Linux (Ubuntu Server 18.04 recommended)             | Worker                                                                                                                                                                       | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
-| Node 3 | Windows (Windows Server core version 1809 or above) | Worker                                                                                                                                                                       | Run your Windows containers                                                         |
+| Node   | Operating System                                                                       | Kubernetes Cluster Role(s)  | Purpose                                                                             |
+|--------|----------------------------------------------------------------------------------------|-----------------------------|-------------------------------------------------------------------------------------|
+| Node 1 | Linux (Ubuntu Server 18.04 recommended)                                                | Control plane, etcd, worker | Manage the Kubernetes cluster                                                       |
+| Node 2 | Linux (Ubuntu Server 18.04 recommended)                                                | Worker                      | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
+| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) | Worker                      | Run your Windows containers                                                         |

 ### Container Requirements

@@ -126,8 +126,6 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the

 This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#recommended-architecture)

-When you provision a cluster with Rancher on existing nodes, you add nodes to the cluster by installing the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) on each one. To create or edit your cluster from the Rancher UI, run the **Registration Command** on each server to add it to your cluster.
-
 To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below.

 ### 1. Provision Hosts
@@ -142,15 +140,15 @@ Your hosts can be:

 You will provision three nodes:

- One Linux node, which manages the Kubernetes control plane and stores your `etcd`
+- One Linux node, which manages the Kubernetes control plane, stores your `etcd`, and optionally be a worker node
 - A second Linux node, which will be another worker node
 - The Windows node, which will run your Windows containers as a worker node

-| Node   | Operating System                                             |
-| ------ | ------------------------------------------------------------ |
-| Node 1 | Linux (Ubuntu Server 18.04 recommended)                      |
-| Node 2 | Linux (Ubuntu Server 18.04 recommended)                      |
-| Node 3 | Windows (Windows Server core version 1809 or above required) |
+| Node   | Operating System                                                                       |
+|--------|----------------------------------------------------------------------------------------|
+| Node 1 | Linux (Ubuntu Server 18.04 recommended)                                                |
+| Node 2 | Linux (Ubuntu Server 18.04 recommended)                                                |
+| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) |

 If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](../set-up-cloud-providers/set-up-cloud-providers.md)

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

 ### 3. Add Nodes to the Cluster

-This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.
+This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the rancher system agent and allow Rancher to manage each node.

 #### Add Linux Master Node

@@ -177,23 +175,18 @@ In this section, we fill out a form on the Rancher UI to get a custom command to
 The first node in your cluster should be a Linux host that has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.

 1. After cluster creation, navigate to the **Registration** tab.
-1. In **Step 1** under the **Node Role** section, select at least **etcd** and **Control Plane**. We recommend selecting all three.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. In **Step 1** under the **Node Role** section, select all three roles. Although you can choose only the **etcd** and **Control Plane** roles, we recommend selecting all three.
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
 1. SSH into your Linux host and run the command that you copied to your clipboard.

-**Result:**
+**Results:**

-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+Your cluster is created and assigned a state of **Updating**. Rancher is standing up your cluster.

-You can access your cluster after its state is updated to **Active**.
+It may take a few minutes for the node to register and appear under the **Machines** tab.

-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
-
-It may take a few minutes for the node to be registered in your cluster.
+You’ll be able to access the cluster once its state changes to **Active**.

 #### Add Linux Worker Node

@@ -203,11 +196,13 @@ After the initial provisioning of your cluster, your cluster only has a single L

 1. After cluster creation, navigate to the **Registration** tab.
 1. In **Step 1** under the **Node Role** section, select **Worker**.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
 1. SSH into your Linux host and run the command that you copied to your clipboard.

-**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
+**Results:** 
+
+The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.

 :::note

@@ -216,7 +211,7 @@ Taints on Linux Worker Nodes
 For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.

 | Taint Key      | Taint Value | Taint Effect |
-| -------------- | ----------- | ------------ |
+|----------------|-------------|--------------|
 | `cattle.io/os` | `linux`     | `NoSchedule` |

 :::
@@ -231,12 +226,16 @@ The registration command to add the Windows workers only appears after the clust

 1. After cluster creation, navigate to the **Registration** tab.
 1. In **Step 1** under the **Node Role** section, select **Worker**.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command for Windows workers displayed on the screen to your clipboard.
-1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
+1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **PowerShell Console** as an Administrator.
 1. Optional: Repeat these instructions if you want to add more Windows nodes to your cluster.

-**Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. You now have a Windows Kubernetes cluster.
+**Results:** 
+
+The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. 
+
+You now have a Windows Kubernetes cluster.

 ### Optional Next Steps

@@ -20,7 +20,8 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
  - [Example IAM Policy](#example-iam-policy)
  - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
  - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.
+- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to a user.
+- **IPv4-only or IPv6-only or dual-stack subnet and/or VPC** where nodes can be provisioned and assigned IPv4 and/or IPv6 addresses. See [Amazon Documentation: IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html).

 ## Creating an EC2 Cluster

@@ -141,7 +141,8 @@ You need to remove the following components from Rancher-provisioned RKE2 nodes:
 To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### Removing RKE2
@@ -165,7 +166,8 @@ You need to remove the following components from Rancher-provisioned K3s nodes:
 To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh 
 ```

 ### Removing K3s
@@ -13,7 +13,7 @@ A project is a group of namespaces, and it is a concept introduced by Rancher. P

 :::note

-Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled.
+Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope.

 :::

@@ -196,3 +196,7 @@ To add a resource quota,
 1. Select **Delete**.

 When you delete a project, any namespaces that were formerly associated with the project will remain on the cluster. You can find these namespaces in the Rancher UI, in the **Not in a Project** tab of the **Projects/Namespaces** page. You can reassign these namespaces to a project by [moving](../manage-namespaces.md#moving-namespaces-to-another-project) them.
+
+## Further Reading
+
+You can create projects and project members more programmatically via the [Public API](../../../api/quickstart.md). See the [project workflow doc](../../../api/workflows/projects.md) for more information.
@@ -19,10 +19,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
-| v2.12.3         |  107.0.0+up7.0.0 |
-| v2.12.2         |  107.0.0+up7.0.0 |
-| v2.12.1         |  107.0.0+up7.0.0 |
-| v2.12.0         |  107.0.0+up7.0.0 |
+| v2.13.2         |  108.0.0+up8.0.0 |
+| v2.13.1         |  108.0.0+up8.0.0 |
+| v2.13.0         |  108.0.0+up8.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -80,3 +80,18 @@ Use [Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/A

 Add metadata using [tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) to categorize resources.

+### IPv6 Address Count
+
+Specify how many IPv6 addresses to assign to the instance’s network interface.
+
+### IPv6 Address Only
+
+Enable this option if the instance should use IPv6 exclusively. IPv6-only VPCs or subnets require this. When enabled, the instance will have IPv6 as its sole address, and the IPv6 Address Count must be greater than zero.
+
+### HTTP Protocol IPv6
+
+Enable or disable IPv6 endpoints for the instance metadata service.
+
+### Enable Primary IPv6
+
+Enable this option to designate the first assigned IPv6 address as the primary address. This ensures a consistent, non-changing IPv6 address for the instance. It does not control whether IPv6 addresses are assigned.
@@ -28,6 +28,8 @@ Enable the DigitalOcean agent for additional [monitoring](https://docs.digitaloc

 Enable IPv6 for Droplets.

+For more information, refer to the [Digital Ocean IPv6 documentation](https://docs.digitalocean.com/products/networking/ipv6).
+
 ### Private Networking

 Enable private networking for Droplets.
@@ -71,7 +71,7 @@ Tags is a list of _network tags_, which can be used to associate preexisting Fir

 ### Labels

-A comma seperated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.
+A comma separated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.

 ## Advanced Options

@@ -6,4 +6,4 @@ title: Machine Configuration
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration"/>
 </head>

-Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), and [Azure](azure.md) to learn more.
+Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), [Google GCE](google-gce.md), and [Azure](azure.md) to learn more.
@@ -6,4 +6,6 @@ title: Node Template Configuration
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration"/>
 </head>

+<EOLRKE1Warning />
+
 To learn about node template config, refer to [EC2 Node Template Configuration](amazon-ec2.md), [DigitalOcean Node Template Configuration](digitalocean.md), [Azure Node Template Configuration](azure.md), [vSphere Node Template Configuration](vsphere.md), and [Nutanix Node Template Configuration](nutanix.md).
@@ -63,7 +63,15 @@ Enable network policy enforcement on the cluster. A network policy defines the l

 _Mutable: yes_

-choose whether to enable or disable inter-project communication. Note that enabling Project Network Isolation will automatically enable Network Policy and Network Policy Config, but not vice versa.
+Choose whether to enable or disable inter-project communication.
+
+#### Imported Clusters
+
+For imported clusters, Project Network Isolation (PNI) requires Kubernetes Network Policy to be enabled on the cluster beforehand.
+For clusters created by Rancher, Rancher enables Kubernetes Network Policy automatically.
+
+1. In GKE, enable Network Policy at the cluster level. Refer to the [official GKE guide](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy) for instructions.
+1. After enabling Network Policy, import the cluster into Rancher and enable PNI for project-level isolation.

 ### Node Ipv4 CIDR Block

@@ -13,7 +13,7 @@ This section covers the configuration options that are available in Rancher for
 You can configure the Kubernetes options one of two ways:

 - [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
+- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file lets you set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available during a K3s installation.

 ## Editing Clusters in the Rancher UI

@@ -32,7 +32,7 @@ To edit your cluster,

 ### Editing Clusters in YAML

-For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation](https://docs.k3s.io/installation/configuration).

 To edit your cluster with YAML:

@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast

 - [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
 - [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)

 ##### Pool Name

@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
 #### Basics
 ##### Kubernetes Version

-The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
+The version of Kubernetes installed on your cluster nodes.

-For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
+For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).

 ##### Pod Security Admission Configuration Template

@@ -108,7 +109,7 @@ Option to enable or disable [SELinux](https://rancher.com/docs/k3s/latest/en/adv

 ##### 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 [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details..
+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 [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details.

 ##### Klipper Service LB

@@ -148,15 +149,49 @@ Option to choose whether to expose etcd metrics to the public or only within the

 ##### Cluster CIDR

-IPv4/IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+IPv4/IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).
+
+Example values:
+
+- IPv4-only: `10.42.0.0/16`
+- IPv6-only: `2001:cafe:42::/56`
+- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
+- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::

 ##### Service CIDR

-IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
+IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).
+
+Example values:
+
+- IPv4-only: `10.43.0.0/16` 
+- IPv6-only: `2001:cafe:43::/112` 
+- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
+- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::

 ##### Cluster DNS

-IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
+IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).

 ##### Cluster Domain

@@ -168,11 +203,11 @@ Option to change the range of ports that can be used for [NodePort services](htt

 ##### Truncate Hostnames

-Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
+Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.

 This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.

-Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
+Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.

 ##### TLS Alternate Names

@@ -186,6 +221,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,

 We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)

+##### Stack Preference
+
+Choose the networking stack for the cluster. This option affects:
+
+- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
+- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
+- The `advertise-client-urls` setting for etcd during snapshot restoration.
+
+Options are `ipv4`, `ipv6`, `dual`:
+
+- When set to `ipv4`, the cluster uses `127.0.0.1`
+- When set to `ipv6`, the cluster uses `[::1]`
+- When set to `dual`, the cluster uses `localhost`
+
+The stack preference must match the cluster’s networking configuration:
+
+- Set to `ipv4` for IPv4-only clusters
+- Set to `ipv6` for IPv6-only clusters
+- Set to `dual` for dual-stack clusters
+
+:::caution
+
+Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
+For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
+
+:::
+
 #### Registries

 Select the image repository to pull Rancher images from. For more details and configuration options, see the [K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/).
@@ -32,7 +32,7 @@ To edit your cluster,

 ### Editing Clusters in YAML

-For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+For a complete reference of configurable options for RKE2 clusters in YAML, see the [RKE2 documentation](https://docs.rke2.io/install/configuration).

 To edit your cluster in YAML:

@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast

 - [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
 - [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)

 ##### Pool Name

@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
 #### Basics
 ##### Kubernetes Version

-The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
+The version of Kubernetes installed on your cluster nodes.

-For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
+For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).

 ##### Container Network Provider

@@ -105,20 +106,19 @@ Out of the box, Rancher is compatible with the following network providers:
 - [Canal](https://github.com/projectcalico/canal)
 - [Cilium](https://cilium.io/)*
 - [Calico](https://docs.projectcalico.org/v3.11/introduction/)
+- [Flannel](https://github.com/flannel-io/flannel)
 - [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)

 \* When using [project network isolation](#project-network-isolation) in the [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium) to learn more.

-For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
+For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/networking/basic_network_options).

-###### Dual-stack Networking
-
-[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
-
-###### Dual-stack Additional Configuration
+:::caution

 When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.

+:::
+
 ##### Cloud Provider

 You can configure a [Kubernetes cloud provider](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md). If you want to use dynamically provisioned [volumes and storage](../../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
@@ -181,27 +181,62 @@ Option to choose whether to expose etcd metrics to the public or only within the

 ##### Cluster CIDR

-IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).

-###### Dual-stack Networking
+Example values:

-To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+- IPv4-only: `10.42.0.0/16`
+- IPv6-only: `2001:cafe:42::/56`
+- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`

-[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
+- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::
+
+:::caution
+
+When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
+
+:::

 ##### Service CIDR

-IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
+IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).

-###### Dual-stack Networking
+Example values:

-To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+- IPv4-only: `10.43.0.0/16`
+- IPv6-only: `2001:cafe:43::/112`
+- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`

-[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
+- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::
+
+:::caution
+
+When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
+
+:::

 ##### Cluster DNS

-IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
+IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).

 ##### Cluster Domain

@@ -213,11 +248,11 @@ Option to change the range of ports that can be used for [NodePort services](htt

 ##### Truncate Hostnames

-Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
+Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.

 This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.

-Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
+Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.

 ##### TLS Alternate Names

@@ -233,6 +268,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,

 We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)

+##### Stack Preference
+
+Choose the networking stack for the cluster. This option affects:
+
+- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
+- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
+- The `advertise-client-urls` setting for etcd during snapshot restoration.
+
+Options are `ipv4`, `ipv6`, `dual`:
+
+- When set to `ipv4`, the cluster uses `127.0.0.1`
+- When set to `ipv6`, the cluster uses `[::1]`
+- When set to `dual`, the cluster uses `localhost`
+
+The stack preference must match the cluster’s networking configuration:
+
+- Set to `ipv4` for IPv4-only clusters
+- Set to `ipv6` for IPv6-only clusters
+- Set to `dual` for dual-stack clusters
+
+:::caution
+
+Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
+For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
+
+:::
+
 #### Registries

 Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
@@ -1,57 +0,0 @@
---
-title: Rancher Agent Options
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
-</head>
-
-Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
-
-For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)
-
-## General options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--server` | `CATTLE_SERVER` | The configured Rancher `server-url` setting which the agent connects to |
-| `--token`  | `CATTLE_TOKEN` | Token that is needed to register the node in Rancher |
-| `--ca-checksum`  | `CATTLE_CA_CHECKSUM` | The SHA256 checksum of the configured Rancher `cacerts` setting to validate |
-| `--node-name` | `CATTLE_NODE_NAME` | Override the hostname that is used to register the node (defaults to `hostname -s`) |
-| `--label` | `CATTLE_NODE_LABEL` | Add node labels to the node. For multiple labels, pass additional `--label` options. (`--label key=value`) |
-| `--taints` | `CATTLE_NODE_TAINTS` | Add node taints to the node. For multiple taints, pass additional `--taints` options.  (`--taints key=value:effect`) |
-
-## Role options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--all-roles` | `ALL=true` | Apply all roles (`etcd`,`controlplane`,`worker`) to the node |
-| `--etcd`  | `ETCD=true` | Apply the role `etcd` to the node |
-| `--controlplane`  | `CONTROL=true` | Apply the role `controlplane` to the node |
-| `--worker`  | `WORKER=true` | Apply the role `worker` to the node |
-
-## IP address options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--address` | `CATTLE_ADDRESS` | The IP address the node will be registered with (defaults to the IP used to reach `8.8.8.8`) |
-| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | The IP address used for inter-host communication on a private network |
-
-### Dynamic IP address options
-
-For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
-
-| Value  | Example | Description |
-| ---------- | -------------------- | ----------- |
-| Interface name | `--address eth0` | The first configured IP address will be retrieved from the given interface |
-| `ipify` | `--address ipify` | Value retrieved from `https://api.ipify.org` will be used |
-| `awslocal` | `--address awslocal` | Value retrieved from `http://169.254.169.254/latest/meta-data/local-ipv4` will be used |
-| `awspublic` | `--address awspublic` | Value retrieved from `http://169.254.169.254/latest/meta-data/public-ipv4` will be used |
-| `doprivate` | `--address doprivate` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` will be used |
-| `dopublic` | `--address dopublic` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` will be used |
-| `azprivate` | `--address azprivate` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` will be used |
-| `azpublic` | `--address azpublic` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` will be used |
-| `gceinternal` | `--address gceinternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` will be used |
-| `gceexternal` | `--address gceexternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` will be used |
-| `packetlocal` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` will be used |
-| `packetpublic` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` will be used |
@@ -9,7 +9,7 @@ description: To create a cluster with custom nodes, you’ll need to access serv

 When you create a custom cluster, Rancher can use RKE2/K3s to create a Kubernetes cluster in on-prem bare-metal servers, on-prem virtual machines, or in any node hosted by an infrastructure provider.

-To use this option you'll need access to servers you intend to use in your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md), which includes some hardware specifications and Docker. After you install Docker on each server, you willl also run the command provided in the Rancher UI on each server to turn each one into a Kubernetes node.
+To use this option, you need access to the servers that will be part of your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md). Then, run the command provided in the Rancher UI on each server to convert it into a Kubernetes node.

 This section describes how to set up a custom cluster.

@@ -33,7 +33,15 @@ If you want to reuse a node from a previous custom cluster, [clean the node](../

 Provision the host according to the [installation requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) and the [checklist for production-ready clusters.](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md)

-If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when provisioning the host.
+:::note IPv6-only cluster
+
+For an IPv6-only cluster, ensure that your operating system correctly configures the `/etc/hosts` file.
+
+```
+::1       localhost
+```
+
+:::

 ### 2. Create the Custom Cluster

@@ -41,39 +49,43 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
 1. On the **Clusters** page, click **Create**.
 1. Click **Custom**.
 1. Enter a **Cluster Name**.
-1. Use **Cluster Configuration** section to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**.
+1. Use the **Cluster Configuration** section to set up the cluster. For more information, see [RKE2 Cluster Configuration Reference](../rke2-cluster-configuration.md) and [K3s Cluster Configuration Reference](../k3s-cluster-configuration.md).

-    :::note Using Windows nodes as Kubernetes workers?
+   :::note Windows nodes

-    - See [Enable the Windows Support Option](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
-    - The only Network Provider available for clusters with Windows support is Flannel.
+   To learn more about using Windows nodes as Kubernetes workers, see [Launching Kubernetes on Windows Clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).

-    :::
+   :::

-    :::note Dual-stack on Amazon EC2:
+1. Click **Create**.

-    If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
+**Result:** The UI redirects to the **Registration** page, where you can generate the registration command for your nodes.

-    :::
+1. From **Node Role**, select the roles you want a cluster node to fill. You must provision at least one node for each role: etcd, worker, and control plane. A custom cluster requires all three roles to finish provisioning. For more information on roles, see [Roles for Nodes in Kubernetes Clusters](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters).

-6. Click **Next**.
+   :::note  Bare-Metal Server

-4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
+   If you plan to dedicate bare-metal servers to each role, you must provision a bare-metal server for each role (i.e., provision multiple bare-metal servers).

-7.	From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters)
+   :::note

-:::note
+1. **Optional**: Click **Show Advanced** to configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node

- Using Windows nodes as Kubernetes workers? See [this section](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
+   :::note

-:::
+   The **Node Public IP** and **Node Private IP** fields can accept either a single address or a comma-separated list of addresses (for example: `10.0.0.5,2001:db8::1`). 

-8. **Optional**: Click **[Show advanced options](rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
+   :::

-9. Copy the command displayed on screen to your clipboard.
+   :::note Ipv6-only or Dual-stack Cluster

-10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+   In both IPv6-only and dual-stack clusters, you should specify the node’s **IPv6 address** as the **Node Private IP**.
+
+   :::
+
+1. Copy the command displayed on screen to your clipboard.
+
+1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.

 :::note

@@ -81,11 +93,9 @@ Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles.

 :::

-11. When you finish running the command(s) on your Linux host(s), click **Done**.
-
 **Result:**

-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+The cluster is created and transitions to the **Updating** state while Rancher initializes and provisions cluster components.

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

@@ -0,0 +1,122 @@
+---
+title: IPv4/IPv6 Dual-stack
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/dual-stack/"/>
+</head>
+
+Kubernetes supports IPv4-only, IPv6-only, and dual-stack networking configurations.
+For more details, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/).
+
+## Installing Rancher on IPv6-Only or Dual-Stack Clusters
+
+Rancher can run on clusters using:
+
+- IPv4-only
+- IPv6-only
+- Dual-stack (IPv4 + IPv6)
+
+When you install Rancher on an **IPv6-only cluster**, it can communicate externally **only over IPv6**. This means it can provision:
+
+- IPv6-only clusters
+- Dual-stack clusters  
+  _(IPv4-only downstream clusters are not possible in this case)_
+
+When you install Rancher on a **dual-stack cluster**, it can communicate over both IPv4 and IPv6, and can therefore provision:
+
+- IPv4-only clusters
+- IPv6-only clusters
+- Dual-stack clusters
+
+For installation steps, see the guide: **[Installing and Upgrading Rancher](../getting-started/installation-and-upgrade/installation-and-upgrade.md)**.
+
+### Requirement for the Rancher Server URL
+
+When provisioning IPv6-only downstream clusters, the **Rancher Server URL must be reachable over IPv6** because downstream nodes connect back to the Rancher server using IPv6.
+
+## Provisioning IPv6-Only or Dual-Stack Clusters
+
+You can provision RKE2 and K3s **Node driver** (machine pools) or **Custom cluster** (existing hosts) clusters using IPv4-only, IPv6-only, or dual-stack networking.
+
+### Network Configuration
+
+To enable IPv6-only or dual-stack networking, you must configure:
+
+- Cluster CIDR
+- Service CIDR
+- Stack Preference
+
+Configuration references:
+
+- [K3s Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md)
+- [RKE2 Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md)
+
+### Support for Windows
+
+Kubernetes on Windows:
+
+| Feature             | Support Status                |
+|---------------------|-------------------------------|
+| IPv6-only clusters  | Not supported                 |
+| Dual-stack clusters | Supported                     |
+| Services            | Limited to a single IP family |
+
+For more information, see the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#windows-support).
+
+K3s does **not** support Windows ([FAQ](https://docs.k3s.io/faq#does-k3s-support-windows))
+
+RKE2 supports Windows, but requires using either `Calico` or `Flannel` as the CNI.  
+Note that Windows installations of RKE2 do not support dual-stack clusters using BGP.
+For more details, see [RKE2 Network Options](https://docs.rke2.io/networking/basic_network_options).
+
+
+### Provisioning Node Driver Clusters
+
+Rancher currently supports assigning IPv6 addresses in **node driver** clusters with:
+
+- [Amazon EC2](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md)
+- [DigitalOcean](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md)
+
+Support for additional providers will be introduced in future releases.
+
+:::note DigitalOcean Limitation
+
+Creating an **IPv6-only cluster** using the DigitalOcean node driver is currently **not supported**.
+For more details, please see [rancher/rancher#52523](https://github.com/rancher/rancher/issues/52523#issuecomment-3457803572).
+
+:::
+
+#### Infrastructure Requirements
+
+Cluster nodes must meet the requirements listed in the [Node Requirements for Rancher Managed Clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+
+Machine pool configuration guides:
+
+- [Amazon EC2 Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [DigitalOcean Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean.md)
+
+### Provisioning Custom Clusters
+
+To provision on your own nodes, follow the instructions in [Provision Kubernetes on Existing Nodes](cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).
+
+:::note
+
+- **Node Public IP** and **Node Private IP** fields accept IPv4, IPv6, or both (comma-separated).  
+    >   Example: `10.0.0.5,2001:db8::1`
+- In **IPv6-only** and **dual-stack** clusters, specify the node’s **IPv6 address** as the **Private IP**.
+
+:::
+
+#### Infrastructure Requirements
+
+Infrastructure requirements are the same as above for node-driver clusters.
+
+## Other Limitations
+
+### GitHub.com
+
+GitHub.com does **not** support IPv6. As a result:
+
+- Any application repositories ( `ClusterRepo.catalog.cattle.io/v1` CR) hosted on GitHub.com will **not be reachable** from IPv6-only clusters.
+- Similarly, any **non-builtin node drivers** hosted on GitHub.com will also **not be accessible** in IPv6-only environments.
@@ -1,15 +0,0 @@
---
-title: Kubernetes Security Best Practices
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
-</head>
-
-## Restricting Cloud Metadata API Access
-
-Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
-
-It is advised to consult your cloud provider's security best practices for further recommendations and specific details on how to restrict access to cloud instance metadata API.
-
-Further references: MITRE ATT&CK knowledge base on - [Unsecured Credentials: Cloud Instance Metadata API](https://attack.mitre.org/techniques/T1552/005/).
@@ -55,6 +55,7 @@ plugins:
                     cert-manager,
                     cis-operator-system,
                     fleet-default,
+                     fleet-local,
                     ingress-nginx,
                     istio-system,
                     kube-node-lease,
@@ -63,5 +64,6 @@ plugins:
                     longhorn-system,
                     rancher-alerting-drivers,
                     security-scan,
+                     sr-operator-system,
                     tigera-operator]
 ```
@@ -41,9 +41,7 @@ For details, refer to the section on [security scans](../../how-to-guides/advanc
 `
 ## SELinux RPM

-[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
-
-We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).
+We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux`, `rke2-selinux` and `k3s-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

 ## Rancher Hardening Guide

@@ -80,8 +78,39 @@ Rancher is committed to informing the community of security issues in our produc

 ## Kubernetes Security Best Practices

-For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.
+For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Cluster Security Best Practices](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) guide.

 ## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
+
+## Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guides
+
+Rancher uses the following Kubernetes distributions:
+
+- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
+- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
+
+To harden a Kubernetes cluster that's running a distribution other than those listed, refer to your Kubernetes provider's docs.
+
+### Hardening Guides and Benchmark Versions
+
+Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guide was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
+
+### RKE2 Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Standalone RKE2 | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.rke2.io/security/cis_self_assessment18) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.rke2.io/security/cis_self_assessment19) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.rke2.io/security/cis_self_assessment110) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.rke2.io/security/cis_self_assessment111) | [Link](https://docs.rke2.io/security/hardening_guide) |
+
+### K3s Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Standalone K3s | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.k3s.io/security/self-assessment-1.8) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.k3s.io/security/self-assessment-1.9) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.k3s.io/security/self-assessment-1.10) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.k3s.io/security/self-assessment-1.11) | [Link](https://docs.k3s.io/security/hardening-guide) |
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc

 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
+| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
+| [CVE-2024-58269](https://github.com/rancher/rancher/security/advisories/GHSA-mw39-9qc2-f7mg) | The Rancher audit log redaction process has changed to the following: <br/><br/><ul><li> It now redacts `kubectl.kubernetes.io/last-applied-configuration` annotations on both Response and Request body contents. Previously it did not redact Response body content.</li><li> It now redacts Cluster Import URLs on both Request URLs and Referer headers. Previously it did not redact Referer headers.</li></ul> | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) |
 | [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -0,0 +1,13 @@
+---
+title: About k3s-selinux
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/selinux-rpm/about-k3s-selinux"/>
+</head>
+
+`k3s-selinux` provides policies for K3s. It is installed automatically when the K3s installer script detects that it is running on an RPM-based distro.
+
+The `k3s-selinux` GitHub repository is [here](https://github.com/rancher/k3s-selinux).
+
+For more information about installing K3s on SELinux-enabled hosts, see the [K3s documentation](https://docs.k3s.io/advanced#selinux-support).
@@ -16,7 +16,7 @@ The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/ra

 :::note Requirement:

-The rancher-selinux RPM was tested with CentOS 7, 8 and 9.
+The `rancher-selinux` RPM was tested on openSUSE Tumbleweed and RHEL-based distributions including Centos/RockyLinux 8 and 9. 

 :::

@@ -24,19 +24,6 @@ The rancher-selinux RPM was tested with CentOS 7, 8 and 9.

 Set up the yum repo to install `rancher-selinux` directly on all hosts in the cluster.

-In order to use the RPM repository, on a CentOS 7 or RHEL 7 system, run the following bash snippet:
-
-```
-# cat << EOF > /etc/yum.repos.d/rancher.repo 
-[rancher] 
-name=Rancher 
-baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
-enabled=1 
-gpgcheck=1 
-gpgkey=https://rpm.rancher.io/public.key 
-EOF
-```
-
 In order to use the RPM repository, on a CentOS 8 or RHEL 8 system, run the following bash snippet:

 ```
@@ -71,14 +58,14 @@ Install the RPM:
 yum -y install rancher-selinux
 ```

-## Configuring the Logging Application to Work with SELinux
+## Configuring the Logging and Monitoring Applications to Work with SELinux

 :::note Requirement:

-Logging v2 was tested with SELinux on RHEL/CentOS 7, 8 and 9.
+Logging v2 and Monitoring v2 were tested with SELinux on RHEL/CentOS 8, 9, and Tumbleweed.

 :::

 Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM. 

-To configure the `rancher-logging` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the chart.
+To configure the `rancher-logging` or the `rancher-monitoring` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the charts.
@@ -10,11 +10,14 @@ title: SELinux RPM

 Developed by Red Hat, it is an implementation of mandatory access controls (MAC) on Linux. Mandatory access controls allow an administrator of a system to define how applications and users can access different resources such as files, devices, networks and inter-process communication. SELinux also enhances security by making an OS restrictive by default.

-After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8. To check whether SELinux is enabled and enforcing on your system, use `getenforce`:
+After being historically used by government agencies, SELinux is now an industry standard and enabled by default on SUSE distributions such as SUSE Linux Enterprise 16, openSUSE distributions such as openSUSE Tumbleweed, and RHEL-based OS such as Rocky Linux. To check whether SELinux is enabled and enforced on your system, use `getenforce`:

 ```
 # getenforce
 Enforcing
 ```

-We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: [`rancher-selinux`](about-rancher-selinux.md) and [`rke2-selinux`](about-rke2-selinux.md).
+We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts: 
+- [`rancher-selinux`](about-rancher-selinux.md)
+- [`rke2-selinux`](about-rke2-selinux.md)
+- [`k3s-selinux`](about-k3s-selinux.md)
@@ -20,10 +20,9 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.12.3         |     v0.8.3      | &check;               | &check;                   |
-| v2.12.2         |     v0.8.2      | &check;               | &check;                   |
-| v2.12.1         |     v0.8.1      | &check;               | &check;                   |
-| v2.12.0         |     v0.8.0      | &cross;               | &check;                   |
+| v2.13.2         |     v0.9.2      | &check;               | &check;                   |
+| v2.13.1         |     v0.9.1      | &check;               | &check;                   |
+| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -184,7 +184,12 @@ module.exports = {
            current: {
              label: "Latest",
            },
-            '2.12': {
+            "2.13": {
+              label: "v2.13",
+              path: "v2.13",
+              banner: 'none'
+            },
+            "2.12": {
              label: "v2.12",
              path: "v2.12",
              banner: "none"
@@ -251,6 +256,11 @@ module.exports = {
      {
        // Plugin Options for loading OpenAPI files
        specs: [
+          {
+            id: "rancher-api-v2-13",
+            spec: "openapi/swagger-v2.13.json",
+            // route: '/api/',
+          },
          {
            id: "rancher-api-v2-12",
            spec: "openapi/swagger-v2.12.json",
@@ -14,4 +14,4 @@ title: API 参考

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api-v2-12" />
+<ApiDocMdx id="rancher-api-v2-13" />
@@ -63,6 +63,7 @@ title: API 令牌
 | 设置 | 描述 |
 | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL（单位：分钟）。 |
+| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
 | [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL，应用于所有 kubeconfig 令牌（除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌)）。**此设置从 2.6.6 版本开始引入。** |
 | [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用，并将在 2.8.0 中删除**。请知悉，`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
 | [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外，所有令牌的最大 TTL。 |
@@ -71,6 +72,11 @@ title: API 令牌
 ### auth-user-session-ttl-minutes
 存活时间（TTL）（单位：分钟），用于确定用户身份验证会话令牌的到期时间。过期后，用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。

+### auth-user-session-idle-ttl-minutes
+
+Time to live (TTL) without user activity for login sessions tokens, in minutes.
+By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
+
 ### kubeconfig-default-token-TTL-minutes
 存活时间（TTL）（单位：分钟），用于确定 kubeconfig 令牌的到期时间。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌，不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
 **此设置从 2.6.6 版本开始引入**。
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -88,7 +88,7 @@ Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`

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

-有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).

 #### Cilium

@@ -6,20 +6,15 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-## Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
-| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
-| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日  |
-| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日  |
-| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | 2025 年 7 月 30 日  |
+| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | 2026 年 01 月 29 日 |
+| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2025 年 12 月 18 日 |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日  |

 ## 当一个功能被标记为弃用我可以得到什么样的预期？

@@ -11,10 +11,8 @@ Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      quota-backend-bytes: 5368709120
+etcd-arg:
+  - "quota-backend-bytes=5368709120"
 ```

 ## 扩展 etcd 磁盘性能
@@ -28,12 +26,7 @@ services:
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      data-dir: '/var/lib/rancher/etcd/data/'
-      wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
-    extra_binds:
-      - '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
-      - '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
+etcd-arg:
+  - "data-dir=/var/lib/etcd/data"
+  - "wal-dir=/var/lib/etcd/wal"
 ```
@@ -36,71 +36,72 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
-  {
-    "Effect": "Allow",
-    "Action": [
-      "autoscaling:DescribeAutoScalingGroups",
-      "autoscaling:DescribeLaunchConfigurations",
-      "autoscaling:DescribeTags",
-      "ec2:DescribeInstances",
-      "ec2:DescribeRegions",
-      "ec2:DescribeRouteTables",
-      "ec2:DescribeSecurityGroups",
-      "ec2:DescribeSubnets",
-      "ec2:DescribeVolumes",
-      "ec2:CreateSecurityGroup",
-      "ec2:CreateTags",
-      "ec2:CreateVolume",
-      "ec2:ModifyInstanceAttribute",
-      "ec2:ModifyVolume",
-      "ec2:AttachVolume",
-      "ec2:AuthorizeSecurityGroupIngress",
-      "ec2:CreateRoute",
-      "ec2:DeleteRoute",
-      "ec2:DeleteSecurityGroup",
-      "ec2:DeleteVolume",
-      "ec2:DetachVolume",
-      "ec2:RevokeSecurityGroupIngress",
-      "ec2:DescribeVpcs",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:AttachLoadBalancerToSubnets",
-      "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancerPolicy",
-      "elasticloadbalancing:CreateLoadBalancerListeners",
-      "elasticloadbalancing:ConfigureHealthCheck",
-      "elasticloadbalancing:DeleteLoadBalancer",
-      "elasticloadbalancing:DeleteLoadBalancerListeners",
-      "elasticloadbalancing:DescribeLoadBalancers",
-      "elasticloadbalancing:DescribeLoadBalancerAttributes",
-      "elasticloadbalancing:DetachLoadBalancerFromSubnets",
-      "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
-      "elasticloadbalancing:ModifyLoadBalancerAttributes",
-      "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
-      "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:CreateListener",
-      "elasticloadbalancing:CreateTargetGroup",
-      "elasticloadbalancing:DeleteListener",
-      "elasticloadbalancing:DeleteTargetGroup",
-      "elasticloadbalancing:DescribeListeners",
-      "elasticloadbalancing:DescribeLoadBalancerPolicies",
-      "elasticloadbalancing:DescribeTargetGroups",
-      "elasticloadbalancing:DescribeTargetHealth",
-      "elasticloadbalancing:ModifyListener",
-      "elasticloadbalancing:ModifyTargetGroup",
-      "elasticloadbalancing:RegisterTargets",
-      "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
-      "iam:CreateServiceLinkedRole",
-      "kms:DescribeKey"
-    ],
-    "Resource": [
-      "*"
-    ]
-  }
-]
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "autoscaling:DescribeAutoScalingGroups",
+        "autoscaling:DescribeLaunchConfigurations",
+        "autoscaling:DescribeTags",
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ec2:DescribeRouteTables",
+        "ec2:DescribeSecurityGroups",
+        "ec2:DescribeSubnets",
+        "ec2:DescribeVolumes",
+        "ec2:CreateSecurityGroup",
+        "ec2:CreateTags",
+        "ec2:CreateVolume",
+        "ec2:ModifyInstanceAttribute",
+        "ec2:ModifyVolume",
+        "ec2:AttachVolume",
+        "ec2:AuthorizeSecurityGroupIngress",
+        "ec2:CreateRoute",
+        "ec2:DeleteRoute",
+        "ec2:DeleteSecurityGroup",
+        "ec2:DeleteVolume",
+        "ec2:DetachVolume",
+        "ec2:RevokeSecurityGroupIngress",
+        "ec2:DescribeVpcs",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:AttachLoadBalancerToSubnets",
+        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancerPolicy",
+        "elasticloadbalancing:CreateLoadBalancerListeners",
+        "elasticloadbalancing:ConfigureHealthCheck",
+        "elasticloadbalancing:DeleteLoadBalancer",
+        "elasticloadbalancing:DeleteLoadBalancerListeners",
+        "elasticloadbalancing:DescribeLoadBalancers",
+        "elasticloadbalancing:DescribeLoadBalancerAttributes",
+        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
+        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
+        "elasticloadbalancing:ModifyLoadBalancerAttributes",
+        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
+        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:CreateListener",
+        "elasticloadbalancing:CreateTargetGroup",
+        "elasticloadbalancing:DeleteListener",
+        "elasticloadbalancing:DeleteTargetGroup",
+        "elasticloadbalancing:DescribeListeners",
+        "elasticloadbalancing:DescribeLoadBalancerPolicies",
+        "elasticloadbalancing:DescribeTargetGroups",
+        "elasticloadbalancing:DescribeTargetHealth",
+        "elasticloadbalancing:ModifyListener",
+        "elasticloadbalancing:ModifyTargetGroup",
+        "elasticloadbalancing:RegisterTargets",
+        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
+        "iam:CreateServiceLinkedRole",
+        "kms:DescribeKey"
+      ],
+      "Resource": [
+        "*"
+      ]
+    }
+  ]
 }
 ```

@@ -108,24 +109,25 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
+  "Version": "2012-10-17",
+  "Statement": [
    {
-        "Effect": "Allow",
-        "Action": [
-            "ec2:DescribeInstances",
-            "ec2:DescribeRegions",
-            "ecr:GetAuthorizationToken",
-            "ecr:BatchCheckLayerAvailability",
-            "ecr:GetDownloadUrlForLayer",
-            "ecr:GetRepositoryPolicy",
-            "ecr:DescribeRepositories",
-            "ecr:ListImages",
-            "ecr:BatchGetImage"
-        ],
-        "Resource": "*"
+      "Effect": "Allow",
+      "Action": [
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ecr:GetAuthorizationToken",
+        "ecr:BatchCheckLayerAvailability",
+        "ecr:GetDownloadUrlForLayer",
+        "ecr:GetRepositoryPolicy",
+        "ecr:DescribeRepositories",
+        "ecr:ListImages",
+        "ecr:BatchGetImage"
+      ],
+      "Resource": "*"
    }
-]
+  ]
 }
 ```

@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -14,11 +14,10 @@ title: 安装 Adapter
 :::

 | Rancher 版本 | Adapter 版本 |
-|-----------------|:----------------:|
-| v2.12.3         |  107.0.0+up7.0.0 |
-| v2.12.2         |  107.0.0+up7.0.0 |
-| v2.12.1         |  107.0.0+up7.0.0 |
-| v2.12.0         |  107.0.0+up7.0.0 |
+|-----------------|------------------|
+| v2.13.2         |  108.0.0+up8.0.0 |
+| v2.13.1         |  108.0.0+up8.0.0 |
+| v2.13.0         |  108.0.0+up8.0.0 |

 ## 1. 获取对 Local 集群的访问权限

@@ -10,6 +10,10 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
+| [CVE-2024-58269](https://github.com/rancher/rancher/security/advisories/GHSA-mw39-9qc2-f7mg) | The Rancher audit log redaction process has changed to the following: <br/><br/><ul><li> It now redacts `kubectl.kubernetes.io/last-applied-configuration` annotations on both Response and Request body contents. Previously it did not redact Response body content.</li><li> It now redacts Cluster Import URLs on both Request URLs and Referer headers. Previously it did not redact Referer headers.</li></ul> | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) |
 | [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,10 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.12.3         |     v0.8.3      | &check;               | &check;                   |
-| v2.12.2         |     v0.8.2      | &check;               | &check;                   |
-| v2.12.1         |     v0.8.1      | &check;               | &check;                   |
-| v2.12.0         |     v0.8.0      | &cross;               | &check;                   |
+| v2.13.2         |     v0.9.2      | &check;               | &check;                   |
+| v2.13.1         |     v0.9.1      | &check;               | &check;                   |
+| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |

 ## 为什么我们需要它？

@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -61,7 +61,7 @@ Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`

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

-有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).

 #### Flannel

@@ -6,16 +6,13 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-## Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：

 | Patch 版本                                                      | 发布时间              |
 | --------------------------------------------------------------- | -------------------- |
+| [2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) | 2026 年 01 月 29 日 |
 | [2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10) | 2025 年 9 月 25 日 |
 | [2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) | 2025 年 8 月 27 日  |
 | [2.10.8](https://github.com/rancher/rancher/releases/tag/v2.10.8) | 2025 年 7 月 30 日  |
@@ -36,71 +36,72 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
-  {
-    "Effect": "Allow",
-    "Action": [
-      "autoscaling:DescribeAutoScalingGroups",
-      "autoscaling:DescribeLaunchConfigurations",
-      "autoscaling:DescribeTags",
-      "ec2:DescribeInstances",
-      "ec2:DescribeRegions",
-      "ec2:DescribeRouteTables",
-      "ec2:DescribeSecurityGroups",
-      "ec2:DescribeSubnets",
-      "ec2:DescribeVolumes",
-      "ec2:CreateSecurityGroup",
-      "ec2:CreateTags",
-      "ec2:CreateVolume",
-      "ec2:ModifyInstanceAttribute",
-      "ec2:ModifyVolume",
-      "ec2:AttachVolume",
-      "ec2:AuthorizeSecurityGroupIngress",
-      "ec2:CreateRoute",
-      "ec2:DeleteRoute",
-      "ec2:DeleteSecurityGroup",
-      "ec2:DeleteVolume",
-      "ec2:DetachVolume",
-      "ec2:RevokeSecurityGroupIngress",
-      "ec2:DescribeVpcs",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:AttachLoadBalancerToSubnets",
-      "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancerPolicy",
-      "elasticloadbalancing:CreateLoadBalancerListeners",
-      "elasticloadbalancing:ConfigureHealthCheck",
-      "elasticloadbalancing:DeleteLoadBalancer",
-      "elasticloadbalancing:DeleteLoadBalancerListeners",
-      "elasticloadbalancing:DescribeLoadBalancers",
-      "elasticloadbalancing:DescribeLoadBalancerAttributes",
-      "elasticloadbalancing:DetachLoadBalancerFromSubnets",
-      "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
-      "elasticloadbalancing:ModifyLoadBalancerAttributes",
-      "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
-      "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:CreateListener",
-      "elasticloadbalancing:CreateTargetGroup",
-      "elasticloadbalancing:DeleteListener",
-      "elasticloadbalancing:DeleteTargetGroup",
-      "elasticloadbalancing:DescribeListeners",
-      "elasticloadbalancing:DescribeLoadBalancerPolicies",
-      "elasticloadbalancing:DescribeTargetGroups",
-      "elasticloadbalancing:DescribeTargetHealth",
-      "elasticloadbalancing:ModifyListener",
-      "elasticloadbalancing:ModifyTargetGroup",
-      "elasticloadbalancing:RegisterTargets",
-      "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
-      "iam:CreateServiceLinkedRole",
-      "kms:DescribeKey"
-    ],
-    "Resource": [
-      "*"
-    ]
-  }
-]
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "autoscaling:DescribeAutoScalingGroups",
+        "autoscaling:DescribeLaunchConfigurations",
+        "autoscaling:DescribeTags",
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ec2:DescribeRouteTables",
+        "ec2:DescribeSecurityGroups",
+        "ec2:DescribeSubnets",
+        "ec2:DescribeVolumes",
+        "ec2:CreateSecurityGroup",
+        "ec2:CreateTags",
+        "ec2:CreateVolume",
+        "ec2:ModifyInstanceAttribute",
+        "ec2:ModifyVolume",
+        "ec2:AttachVolume",
+        "ec2:AuthorizeSecurityGroupIngress",
+        "ec2:CreateRoute",
+        "ec2:DeleteRoute",
+        "ec2:DeleteSecurityGroup",
+        "ec2:DeleteVolume",
+        "ec2:DetachVolume",
+        "ec2:RevokeSecurityGroupIngress",
+        "ec2:DescribeVpcs",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:AttachLoadBalancerToSubnets",
+        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancerPolicy",
+        "elasticloadbalancing:CreateLoadBalancerListeners",
+        "elasticloadbalancing:ConfigureHealthCheck",
+        "elasticloadbalancing:DeleteLoadBalancer",
+        "elasticloadbalancing:DeleteLoadBalancerListeners",
+        "elasticloadbalancing:DescribeLoadBalancers",
+        "elasticloadbalancing:DescribeLoadBalancerAttributes",
+        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
+        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
+        "elasticloadbalancing:ModifyLoadBalancerAttributes",
+        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
+        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:CreateListener",
+        "elasticloadbalancing:CreateTargetGroup",
+        "elasticloadbalancing:DeleteListener",
+        "elasticloadbalancing:DeleteTargetGroup",
+        "elasticloadbalancing:DescribeListeners",
+        "elasticloadbalancing:DescribeLoadBalancerPolicies",
+        "elasticloadbalancing:DescribeTargetGroups",
+        "elasticloadbalancing:DescribeTargetHealth",
+        "elasticloadbalancing:ModifyListener",
+        "elasticloadbalancing:ModifyTargetGroup",
+        "elasticloadbalancing:RegisterTargets",
+        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
+        "iam:CreateServiceLinkedRole",
+        "kms:DescribeKey"
+      ],
+      "Resource": [
+        "*"
+      ]
+    }
+  ]
 }
 ```

@@ -108,24 +109,25 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
+  "Version": "2012-10-17",
+  "Statement": [
    {
-        "Effect": "Allow",
-        "Action": [
-            "ec2:DescribeInstances",
-            "ec2:DescribeRegions",
-            "ecr:GetAuthorizationToken",
-            "ecr:BatchCheckLayerAvailability",
-            "ecr:GetDownloadUrlForLayer",
-            "ecr:GetRepositoryPolicy",
-            "ecr:DescribeRepositories",
-            "ecr:ListImages",
-            "ecr:BatchGetImage"
-        ],
-        "Resource": "*"
+      "Effect": "Allow",
+      "Action": [
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ecr:GetAuthorizationToken",
+        "ecr:BatchCheckLayerAvailability",
+        "ecr:GetDownloadUrlForLayer",
+        "ecr:GetRepositoryPolicy",
+        "ecr:DescribeRepositories",
+        "ecr:ListImages",
+        "ecr:BatchGetImage"
+      ],
+      "Resource": "*"
    }
-]
+  ]
 }
 ```

@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -14,7 +14,8 @@ title: 安装 Adapter
 :::

 | Rancher 版本 | Adapter 版本 |
-|-----------------|:---------------:|
+|-----------------|:----------------:|
+| v2.10.11        | v105.0.0+up5.0.1 |
 | v2.10.10        | v105.0.0+up5.0.1 |
 | v2.10.9         | v105.0.0+up5.0.1 |
 | v2.10.8         | v105.0.0+up5.0.1 |
@@ -10,6 +10,8 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
 | [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,7 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 | --------------- | --------------- | --------------------- | ------------------------- |
+| v2.10.11        |     v0.6.12     | &check;               | &cross;                   |
 | v2.10.10        |     v0.6.11     | &check;               | &cross;                   |
 | v2.10.9         |     v0.6.10     | &check;               | &cross;                   |
 | v2.10.8         |     v0.6.9      | &check;               | &cross;                   |
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -61,7 +61,7 @@ Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`

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

-有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).

 #### Flannel

@@ -6,16 +6,16 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-## Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：

 | Patch 版本                                                      | 发布时间           |
 | --------------------------------------------------------------- | ------------------ |
+| [2.11.11](https://github.com/rancher/rancher/releases/tag/v2.11.11) | 2026 年 02 月 25 日 |
+| [2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10) | 2026 年 01 月 29 日 |
+| [2.11.9](https://github.com/rancher/rancher/releases/tag/v2.11.9) | 2025 年 12 月 18 日 |
+| [2.11.8](https://github.com/rancher/rancher/releases/tag/v2.11.8) | 2025 年 11 月 24 日 |
 | [2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) | 2025 年 10 月 23 日 |
 | [2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6) | 2025 年 9 月 25 日  |
 | [2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) | 2025 年 8 月 28 日  |
@@ -36,71 +36,72 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
-  {
-    "Effect": "Allow",
-    "Action": [
-      "autoscaling:DescribeAutoScalingGroups",
-      "autoscaling:DescribeLaunchConfigurations",
-      "autoscaling:DescribeTags",
-      "ec2:DescribeInstances",
-      "ec2:DescribeRegions",
-      "ec2:DescribeRouteTables",
-      "ec2:DescribeSecurityGroups",
-      "ec2:DescribeSubnets",
-      "ec2:DescribeVolumes",
-      "ec2:CreateSecurityGroup",
-      "ec2:CreateTags",
-      "ec2:CreateVolume",
-      "ec2:ModifyInstanceAttribute",
-      "ec2:ModifyVolume",
-      "ec2:AttachVolume",
-      "ec2:AuthorizeSecurityGroupIngress",
-      "ec2:CreateRoute",
-      "ec2:DeleteRoute",
-      "ec2:DeleteSecurityGroup",
-      "ec2:DeleteVolume",
-      "ec2:DetachVolume",
-      "ec2:RevokeSecurityGroupIngress",
-      "ec2:DescribeVpcs",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:AttachLoadBalancerToSubnets",
-      "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancerPolicy",
-      "elasticloadbalancing:CreateLoadBalancerListeners",
-      "elasticloadbalancing:ConfigureHealthCheck",
-      "elasticloadbalancing:DeleteLoadBalancer",
-      "elasticloadbalancing:DeleteLoadBalancerListeners",
-      "elasticloadbalancing:DescribeLoadBalancers",
-      "elasticloadbalancing:DescribeLoadBalancerAttributes",
-      "elasticloadbalancing:DetachLoadBalancerFromSubnets",
-      "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
-      "elasticloadbalancing:ModifyLoadBalancerAttributes",
-      "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
-      "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:CreateListener",
-      "elasticloadbalancing:CreateTargetGroup",
-      "elasticloadbalancing:DeleteListener",
-      "elasticloadbalancing:DeleteTargetGroup",
-      "elasticloadbalancing:DescribeListeners",
-      "elasticloadbalancing:DescribeLoadBalancerPolicies",
-      "elasticloadbalancing:DescribeTargetGroups",
-      "elasticloadbalancing:DescribeTargetHealth",
-      "elasticloadbalancing:ModifyListener",
-      "elasticloadbalancing:ModifyTargetGroup",
-      "elasticloadbalancing:RegisterTargets",
-      "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
-      "iam:CreateServiceLinkedRole",
-      "kms:DescribeKey"
-    ],
-    "Resource": [
-      "*"
-    ]
-  }
-]
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "autoscaling:DescribeAutoScalingGroups",
+        "autoscaling:DescribeLaunchConfigurations",
+        "autoscaling:DescribeTags",
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ec2:DescribeRouteTables",
+        "ec2:DescribeSecurityGroups",
+        "ec2:DescribeSubnets",
+        "ec2:DescribeVolumes",
+        "ec2:CreateSecurityGroup",
+        "ec2:CreateTags",
+        "ec2:CreateVolume",
+        "ec2:ModifyInstanceAttribute",
+        "ec2:ModifyVolume",
+        "ec2:AttachVolume",
+        "ec2:AuthorizeSecurityGroupIngress",
+        "ec2:CreateRoute",
+        "ec2:DeleteRoute",
+        "ec2:DeleteSecurityGroup",
+        "ec2:DeleteVolume",
+        "ec2:DetachVolume",
+        "ec2:RevokeSecurityGroupIngress",
+        "ec2:DescribeVpcs",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:AttachLoadBalancerToSubnets",
+        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancerPolicy",
+        "elasticloadbalancing:CreateLoadBalancerListeners",
+        "elasticloadbalancing:ConfigureHealthCheck",
+        "elasticloadbalancing:DeleteLoadBalancer",
+        "elasticloadbalancing:DeleteLoadBalancerListeners",
+        "elasticloadbalancing:DescribeLoadBalancers",
+        "elasticloadbalancing:DescribeLoadBalancerAttributes",
+        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
+        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
+        "elasticloadbalancing:ModifyLoadBalancerAttributes",
+        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
+        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:CreateListener",
+        "elasticloadbalancing:CreateTargetGroup",
+        "elasticloadbalancing:DeleteListener",
+        "elasticloadbalancing:DeleteTargetGroup",
+        "elasticloadbalancing:DescribeListeners",
+        "elasticloadbalancing:DescribeLoadBalancerPolicies",
+        "elasticloadbalancing:DescribeTargetGroups",
+        "elasticloadbalancing:DescribeTargetHealth",
+        "elasticloadbalancing:ModifyListener",
+        "elasticloadbalancing:ModifyTargetGroup",
+        "elasticloadbalancing:RegisterTargets",
+        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
+        "iam:CreateServiceLinkedRole",
+        "kms:DescribeKey"
+      ],
+      "Resource": [
+        "*"
+      ]
+    }
+  ]
 }
 ```

@@ -108,24 +109,25 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
+  "Version": "2012-10-17",
+  "Statement": [
    {
-        "Effect": "Allow",
-        "Action": [
-            "ec2:DescribeInstances",
-            "ec2:DescribeRegions",
-            "ecr:GetAuthorizationToken",
-            "ecr:BatchCheckLayerAvailability",
-            "ecr:GetDownloadUrlForLayer",
-            "ecr:GetRepositoryPolicy",
-            "ecr:DescribeRepositories",
-            "ecr:ListImages",
-            "ecr:BatchGetImage"
-        ],
-        "Resource": "*"
+      "Effect": "Allow",
+      "Action": [
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ecr:GetAuthorizationToken",
+        "ecr:BatchCheckLayerAvailability",
+        "ecr:GetDownloadUrlForLayer",
+        "ecr:GetRepositoryPolicy",
+        "ecr:DescribeRepositories",
+        "ecr:ListImages",
+        "ecr:BatchGetImage"
+      ],
+      "Resource": "*"
    }
-]
+  ]
 }
 ```

@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -15,6 +15,10 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.11.11        | v106.0.0+up6.0.0 |
+| v2.11.10        | v106.0.0+up6.0.0 |
+| v2.11.9         | v106.0.0+up6.0.0 |
+| v2.11.8         | v106.0.0+up6.0.0 |
 | v2.11.7         | v106.0.0+up6.0.0 |
 | v2.11.6         | v106.0.0+up6.0.0 |
 | v2.11.5         | v106.0.0+up6.0.0 |
@@ -10,6 +10,9 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已

 | ID | 描述 | 日期 | 解决 |
 |----|-------------|------|------------|
+| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
+| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
 | [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
 | [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,10 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.11.11        |     v0.7.8      | &check;               | &cross;                   |
+| v2.11.10        |     v0.7.8      | &check;               | &cross;                   |
+| v2.11.9         |     v0.7.8      | &check;               | &cross;                   |
+| v2.11.8         |     v0.7.8      | &check;               | &cross;                   |
 | v2.11.7         |     v0.7.7      | &check;               | &cross;                   |
 | v2.11.6         |     v0.7.6      | &check;               | &cross;                   |
 | v2.11.5         |     v0.7.5      | &check;               | &cross;                   |
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -88,7 +88,7 @@ Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`

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

-有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).

 #### Cilium

@@ -6,16 +6,15 @@ title: Rancher 中已弃用的功能
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
 </head>

-## Rancher 的弃用策略是什么？
-
-我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
-
 ## 在哪里可以了解 Rancher 中已弃用哪些功能？

 Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
+| [2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6) | 2026 年 01 月 29 日 |
+| [2.12.5](https://github.com/rancher/rancher/releases/tag/v2.12.5) | 2025 年 12 月 18 日 |
+| [2.12.4](https://github.com/rancher/rancher/releases/tag/v2.12.4) | 2025 年 11 月 24 日 |
 | [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
 | [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日  |
 | [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日  |
@@ -11,10 +11,8 @@ Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      quota-backend-bytes: 5368709120
+etcd-arg:
+  - "quota-backend-bytes=5368709120"
 ```

 ## 扩展 etcd 磁盘性能
@@ -28,12 +26,7 @@ services:
 ```yaml
 # RKE2/K3s config.yaml
 ---
-services:
-  etcd:
-    extra_args:
-      data-dir: '/var/lib/rancher/etcd/data/'
-      wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
-    extra_binds:
-      - '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
-      - '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
+etcd-arg:
+  - "data-dir=/var/lib/etcd/data"
+  - "wal-dir=/var/lib/etcd/wal"
 ```
@@ -36,71 +36,72 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
-  {
-    "Effect": "Allow",
-    "Action": [
-      "autoscaling:DescribeAutoScalingGroups",
-      "autoscaling:DescribeLaunchConfigurations",
-      "autoscaling:DescribeTags",
-      "ec2:DescribeInstances",
-      "ec2:DescribeRegions",
-      "ec2:DescribeRouteTables",
-      "ec2:DescribeSecurityGroups",
-      "ec2:DescribeSubnets",
-      "ec2:DescribeVolumes",
-      "ec2:CreateSecurityGroup",
-      "ec2:CreateTags",
-      "ec2:CreateVolume",
-      "ec2:ModifyInstanceAttribute",
-      "ec2:ModifyVolume",
-      "ec2:AttachVolume",
-      "ec2:AuthorizeSecurityGroupIngress",
-      "ec2:CreateRoute",
-      "ec2:DeleteRoute",
-      "ec2:DeleteSecurityGroup",
-      "ec2:DeleteVolume",
-      "ec2:DetachVolume",
-      "ec2:RevokeSecurityGroupIngress",
-      "ec2:DescribeVpcs",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:AttachLoadBalancerToSubnets",
-      "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancer",
-      "elasticloadbalancing:CreateLoadBalancerPolicy",
-      "elasticloadbalancing:CreateLoadBalancerListeners",
-      "elasticloadbalancing:ConfigureHealthCheck",
-      "elasticloadbalancing:DeleteLoadBalancer",
-      "elasticloadbalancing:DeleteLoadBalancerListeners",
-      "elasticloadbalancing:DescribeLoadBalancers",
-      "elasticloadbalancing:DescribeLoadBalancerAttributes",
-      "elasticloadbalancing:DetachLoadBalancerFromSubnets",
-      "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
-      "elasticloadbalancing:ModifyLoadBalancerAttributes",
-      "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
-      "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
-      "elasticloadbalancing:AddTags",
-      "elasticloadbalancing:CreateListener",
-      "elasticloadbalancing:CreateTargetGroup",
-      "elasticloadbalancing:DeleteListener",
-      "elasticloadbalancing:DeleteTargetGroup",
-      "elasticloadbalancing:DescribeListeners",
-      "elasticloadbalancing:DescribeLoadBalancerPolicies",
-      "elasticloadbalancing:DescribeTargetGroups",
-      "elasticloadbalancing:DescribeTargetHealth",
-      "elasticloadbalancing:ModifyListener",
-      "elasticloadbalancing:ModifyTargetGroup",
-      "elasticloadbalancing:RegisterTargets",
-      "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
-      "iam:CreateServiceLinkedRole",
-      "kms:DescribeKey"
-    ],
-    "Resource": [
-      "*"
-    ]
-  }
-]
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "autoscaling:DescribeAutoScalingGroups",
+        "autoscaling:DescribeLaunchConfigurations",
+        "autoscaling:DescribeTags",
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ec2:DescribeRouteTables",
+        "ec2:DescribeSecurityGroups",
+        "ec2:DescribeSubnets",
+        "ec2:DescribeVolumes",
+        "ec2:CreateSecurityGroup",
+        "ec2:CreateTags",
+        "ec2:CreateVolume",
+        "ec2:ModifyInstanceAttribute",
+        "ec2:ModifyVolume",
+        "ec2:AttachVolume",
+        "ec2:AuthorizeSecurityGroupIngress",
+        "ec2:CreateRoute",
+        "ec2:DeleteRoute",
+        "ec2:DeleteSecurityGroup",
+        "ec2:DeleteVolume",
+        "ec2:DetachVolume",
+        "ec2:RevokeSecurityGroupIngress",
+        "ec2:DescribeVpcs",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:AttachLoadBalancerToSubnets",
+        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancer",
+        "elasticloadbalancing:CreateLoadBalancerPolicy",
+        "elasticloadbalancing:CreateLoadBalancerListeners",
+        "elasticloadbalancing:ConfigureHealthCheck",
+        "elasticloadbalancing:DeleteLoadBalancer",
+        "elasticloadbalancing:DeleteLoadBalancerListeners",
+        "elasticloadbalancing:DescribeLoadBalancers",
+        "elasticloadbalancing:DescribeLoadBalancerAttributes",
+        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
+        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
+        "elasticloadbalancing:ModifyLoadBalancerAttributes",
+        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
+        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
+        "elasticloadbalancing:AddTags",
+        "elasticloadbalancing:CreateListener",
+        "elasticloadbalancing:CreateTargetGroup",
+        "elasticloadbalancing:DeleteListener",
+        "elasticloadbalancing:DeleteTargetGroup",
+        "elasticloadbalancing:DescribeListeners",
+        "elasticloadbalancing:DescribeLoadBalancerPolicies",
+        "elasticloadbalancing:DescribeTargetGroups",
+        "elasticloadbalancing:DescribeTargetHealth",
+        "elasticloadbalancing:ModifyListener",
+        "elasticloadbalancing:ModifyTargetGroup",
+        "elasticloadbalancing:RegisterTargets",
+        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
+        "iam:CreateServiceLinkedRole",
+        "kms:DescribeKey"
+      ],
+      "Resource": [
+        "*"
+      ]
+    }
+  ]
 }
 ```

@@ -108,24 +109,25 @@ weight: 1

 ```json
 {
-"Version": "2012-10-17",
-"Statement": [
+  "Version": "2012-10-17",
+  "Statement": [
    {
-        "Effect": "Allow",
-        "Action": [
-            "ec2:DescribeInstances",
-            "ec2:DescribeRegions",
-            "ecr:GetAuthorizationToken",
-            "ecr:BatchCheckLayerAvailability",
-            "ecr:GetDownloadUrlForLayer",
-            "ecr:GetRepositoryPolicy",
-            "ecr:DescribeRepositories",
-            "ecr:ListImages",
-            "ecr:BatchGetImage"
-        ],
-        "Resource": "*"
+      "Effect": "Allow",
+      "Action": [
+        "ec2:DescribeInstances",
+        "ec2:DescribeRegions",
+        "ec2:DescribeAvailabilityZones",
+        "ecr:GetAuthorizationToken",
+        "ecr:BatchCheckLayerAvailability",
+        "ecr:GetDownloadUrlForLayer",
+        "ecr:GetRepositoryPolicy",
+        "ecr:DescribeRepositories",
+        "ecr:ListImages",
+        "ecr:BatchGetImage"
+      ],
+      "Resource": "*"
    }
-]
+  ]
 }
 ```

@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -15,6 +15,9 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.12.6         |  107.0.0+up7.0.0 |
+| v2.12.5         |  107.0.0+up7.0.0 |
+| v2.12.4         |  107.0.0+up7.0.0 |
 | v2.12.3         |  107.0.0+up7.0.0 |
 | v2.12.2         |  107.0.0+up7.0.0 |
 | v2.12.1         |  107.0.0+up7.0.0 |
--- a/Show More
+++ b/Show More