Update CVE pages (#2174)

* Sync changes from main to v2.13.2 (#2156)

* Fixed links to images

* Added documentation for using the keywords option in Chart.yaml

* Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)

* Revert image link change, it would break the docs website

* Fixed some typos and backported docs

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

* v2.13.2 - Rancher Manager Release Maintenance (#2160)

* Update the versions table

* Update the Rancher:webhook version mapping table

* Update the CSP adapter compatibility matrix

* Update the deprecated features table

* Update release date (#2171)

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

README.md

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

archived_docs/en/version-2.8/api/workflows/projects.md

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

archived_docs/zh/version-2.8/api/workflows/projects.md

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

backport_docs.sh

@@ -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}"

docs/api/api-reference.mdx

@@ -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" />

docs/api/api-tokens.md

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

docs/api/workflows/kubeconfigs.md

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

docs/api/workflows/projects.md

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

docs/api/workflows/tokens.md

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

docs/api/workflows/users.md

@@ -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"
+}
+```

docs/faq/deprecated-features.md

@@ -8,7 +8,7 @@ title: Deprecated Features in Rancher
 
 ## 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).
+The community version of Rancher follows the same deprecation policy as Rancher Prime. The official deprecation policy is documented in the [Rancher Prime Deprecation Policy](https://www.suse.com/support/rancher-prime/#Rancher-Prime-Deprecation-Policy).
 
 ## Where can I find out which features have been deprecated in Rancher?
 
@@ -16,10 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
 
 | 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?
 

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

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

docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.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 />

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

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

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

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

docs/getting-started/installation-and-upgrade/installation-requirements/installation-requirements.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.

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

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

docs/getting-started/installation-and-upgrade/resources/add-tls-secrets.md

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

docs/how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md

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

docs/how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation.md

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

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

@@ -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"
 ```

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

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

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

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

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

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

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

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

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

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

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

@@ -197,3 +197,32 @@ 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.
+
+:::
+

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

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

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

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

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

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

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

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

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

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

docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md

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

docs/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md

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

docs/how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md

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

docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md

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

docs/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2.md

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

docs/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean.md

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

docs/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/google-gce.md

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

docs/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/machine-configuration.md

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

docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/node-template-configuration.md

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

docs/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.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
 

docs/reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md

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

docs/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md

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

docs/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md

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

docs/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md

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

docs/reference-guides/dual-stack.md

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

docs/reference-guides/rancher-security/kubernetes-security-best-practices.md

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

docs/reference-guides/rancher-security/psa-restricted-exemptions.md

@@ -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]
 ```

docs/reference-guides/rancher-security/rancher-security.md

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

docs/reference-guides/rancher-security/security-advisories-and-cves.md

@@ -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. For more information. | 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. For more information. | 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) |

docs/reference-guides/rancher-security/selinux-rpm/about-k3s-selinux.md

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

docs/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md

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

docs/reference-guides/rancher-security/selinux-rpm/selinux-rpm.md

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

docs/reference-guides/rancher-webhook.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      | ✓               | ✓                   |
-| v2.12.2         |     v0.8.2      | ✓               | ✓                   |
-| v2.12.1         |     v0.8.1      | ✓               | ✓                   |
-| v2.12.0         |     v0.8.0      | ✗               | ✓                   |
+| v2.13.2         |     v0.9.2      | ✓               | ✓                   |
+| v2.13.1         |     v0.9.1      | ✓               | ✓                   |
+| v2.13.0         |     v0.9.0      | ✗               | ✓                   |
 
 ## Why Do We Need It?
 

docusaurus.config.js

@@ -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",

i18n/zh/docusaurus-plugin-content-docs/current/api/api-reference.mdx

@@ -14,4 +14,4 @@ title: API 参考
 
 import ApiDocMdx from '@theme/ApiDocMdx';
 
-<ApiDocMdx id="rancher-api-v2-12" />
+<ApiDocMdx id="rancher-api-v2-13" />

i18n/zh/docusaurus-plugin-content-docs/current/api/api-tokens.md

@@ -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 版本开始引入**。

i18n/zh/docusaurus-plugin-content-docs/current/api/workflows/projects.md

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

i18n/zh/docusaurus-plugin-content-docs/current/faq/deprecated-features.md

@@ -16,10 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
 
 | 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 日  |
 
 ## 当一个功能被标记为弃用我可以得到什么样的预期？
 

i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md

@@ -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"
 ```

i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/amazon.md

@@ -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": "*"
     }
-]
+  ]
 }
 ```
 

i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md

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

i18n/zh/docusaurus-plugin-content-docs/current/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md

@@ -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 集群的访问权限
 

i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/security-advisories-and-cves.md

@@ -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. For more information. | 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. For more information. | 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) |

i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-webhook.md

@@ -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      | ✓               | ✓                   |
-| v2.12.2         |     v0.8.2      | ✓               | ✓                   |
-| v2.12.1         |     v0.8.1      | ✓               | ✓                   |
-| v2.12.0         |     v0.8.0      | ✗               | ✓                   |
+| v2.13.2         |     v0.9.2      | ✓               | ✓                   |
+| v2.13.1         |     v0.9.1      | ✓               | ✓                   |
+| v2.13.0         |     v0.9.0      | ✗               | ✓                   |
 
 ## 为什么我们需要它？
 

i18n/zh/docusaurus-plugin-content-docs/version-2.10/api/workflows/projects.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.10/faq/deprecated-features.md

@@ -16,6 +16,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
 
 | 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 日  |

i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/amazon.md

@@ -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": "*"
     }
-]
+  ]
 }
 ```
 

i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.10/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.10/reference-guides/rancher-security/security-advisories-and-cves.md

@@ -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. For more information. | 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. For more information. | 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) |

i18n/zh/docusaurus-plugin-content-docs/version-2.10/reference-guides/rancher-webhook.md

@@ -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     | ✓               | ✗                   |
 | v2.10.10        |     v0.6.11     | ✓               | ✗                   |
 | v2.10.9         |     v0.6.10     | ✓               | ✗                   |
 | v2.10.8         |     v0.6.9      | ✓               | ✗                   |

i18n/zh/docusaurus-plugin-content-docs/version-2.11/api/workflows/projects.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.11/faq/deprecated-features.md

@@ -16,6 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
 
 | Patch 版本                                                      | 发布时间           |
 | --------------------------------------------------------------- | ------------------ |
+| [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 日  |

i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/amazon.md

@@ -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": "*"
     }
-]
+  ]
 }
 ```
 

i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.11/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md

@@ -15,6 +15,9 @@ title: 安装 Adapter
 
 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| 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 |

i18n/zh/docusaurus-plugin-content-docs/version-2.11/reference-guides/rancher-security/security-advisories-and-cves.md

@@ -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. For more information. | 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. For more information. | 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) |

i18n/zh/docusaurus-plugin-content-docs/version-2.11/reference-guides/rancher-webhook.md

@@ -20,6 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
 
 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.11.10        |     v0.7.8      | ✓               | ✗                   |
+| v2.11.9         |     v0.7.8      | ✓               | ✗                   |
+| v2.11.8         |     v0.7.8      | ✓               | ✗                   |
 | v2.11.7         |     v0.7.7      | ✓               | ✗                   |
 | v2.11.6         |     v0.7.6      | ✓               | ✗                   |
 | v2.11.5         |     v0.7.5      | ✓               | ✗                   |

i18n/zh/docusaurus-plugin-content-docs/version-2.12/api/workflows/projects.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.12/faq/deprecated-features.md

@@ -16,6 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
 
 | 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 日  |

i18n/zh/docusaurus-plugin-content-docs/version-2.12/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md

@@ -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"
 ```

i18n/zh/docusaurus-plugin-content-docs/version-2.12/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/amazon.md

@@ -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": "*"
     }
-]
+  ]
 }
 ```
 

i18n/zh/docusaurus-plugin-content-docs/version-2.12/how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.12/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md

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

i18n/zh/docusaurus-plugin-content-docs/version-2.12/reference-guides/rancher-security/security-advisories-and-cves.md

@@ -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. For more information. | 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. For more information. | 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) |

i18n/zh/docusaurus-plugin-content-docs/version-2.12/reference-guides/rancher-webhook.md

@@ -20,6 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
 
 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.12.6         |     v0.8.5      | ✓               | ✗                   |
+| v2.12.5         |     v0.8.4      | ✓               | ✗                   |
+| v2.12.4         |     v0.8.4      | ✓               | ✗                   |
 | v2.12.3         |     v0.8.3      | ✓               | ✓                   |
 | v2.12.2         |     v0.8.2      | ✓               | ✓                   |
 | v2.12.1         |     v0.8.1      | ✓               | ✓                   |

i18n/zh/docusaurus-plugin-content-docs/version-2.13/api/api-reference.mdx

@@ -0,0 +1,17 @@
+---
+title: API 参考
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/api-reference"/>
+</head>
+
+:::note
+
+目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
+
+:::
+
+import ApiDocMdx from '@theme/ApiDocMdx';
+
+<ApiDocMdx id="rancher-api-v2-13" />

i18n/zh/docusaurus-plugin-content-docs/version-2.13/api/api-tokens.md

@@ -0,0 +1,93 @@
+---
+title: API 令牌
+---
+
+默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。令牌不会因为更改密码而失效。
+
+要停用 API 令牌，你可以删除令牌或停用用户账号。
+
+## 删除令牌
+要删除令牌：
+
+1. 转到 `https://<Rancher-Server-IP>/v3/tokens`，在 Rancher API 视图中查看包含所有令牌的列表。
+
+1. 通过 ID 访问要删除的令牌。例如，`https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`。
+
+1. 单击**删除**。
+
+以下是使用 `ttl=0` 生成的完整令牌列表：
+
+| 令牌 | 描述 |
+| ----------------- | -------------------------------------------------------------------------------------- |
+| `kubeconfig-*` | Kubeconfig 令牌 |
+| `kubectl-shell-*` | 在浏览器中访问 `kubectl` shell |
+| `agent-*` | Agent deployment 令牌 |
+| `compose-token-*` | compose 令牌 |
+| `helm-token-*` | Helm Chart deployment 令牌 |
+| `telemetry-*` | 遥测令牌 |
+| `drain-node-*` | 用于清空的令牌（由于没有原生 Kubernetes API，我们使用 `kubectl` 来清空） |
+
+
+## 在 Kubeconfig 令牌上设置 TTL
+
+管理员可以在 Kubeconfig 令牌上设置全局存活时间 (time-to-live，TTL)。如需更改默认 kubeconfig TTL，你可以导航到全局设置并将 [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 设置为所需的持续时间（单位：分钟）。[`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 的默认值为 0，表示令牌永不过期。
+
+:::note
+
+除了由 CLI 创建的用于[生成 kubeconfig 令牌](#在生成的-kubeconfig-中禁用令牌)的令牌之外，所有 kubeconfig 令牌都使用此设置。
+
+:::
+
+## 在生成的 Kubeconfig 中禁用令牌
+
+1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置，生成的 kubeconfig 将引用 [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端（例如 `kubectl`）中使用时，你需要安装 Rancher CLI 来完成登录请求。
+
+2. 将 `kubeconfig-token-ttl-minutes` 设置为所需的时长（单位：分钟）。`kubeconfig-token-ttl-minutes` 默认设置为 960（即 16 小时）。
+
+## 令牌哈希
+
+你可以启用令牌哈希，令牌将使用 SHA256 算法进行单向哈希。这是一个不可逆的操作，一旦启用，此功能将无法禁用。在启用功能或在测试环境中评估之前，建议你先进行备份。
+
+要启用令牌哈希，请参阅[本节](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
+
+此功能将影响所有令牌，包括但不限于以下内容：
+
+- Kubeconfig 令牌
+- 持有者令牌 API 密钥/调用
+- 内部操作使用的令牌
+
+## 令牌设置
+
+以下全局设置会影响 Rancher 令牌的行为：
+
+| 设置 | 描述 |
+| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [`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。 |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | 如果为 true，则在用户下载 kubeconfig 时自动生成令牌。 |
+
+### 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 版本开始引入**。
+
+### kubeconfig-token-ttl-minutes
+存活时间（TTL）（单位：分钟），用于确定由 CLI 生成的 kubeconfig 令牌的到期时间。当 [`kubeconfig-generate-token`](#kubeconfig-generate-token) 设为 false 时，则由 CLI 生成令牌。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。
+**自版本 2.6.6 起已弃用，并将在 2.8.0 中删除。请知悉，此设置将被 [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) 的值替换**。
+
+### auth-token-max-ttl-minutes
+身份验证令牌的最大生存时间 (TTL)（单位：分钟）。如果用户尝试创建一个 TTL 大于 `auth-token-max-ttl-minutes` 的令牌，Rancher 会将令牌 TTL 设置为 `auth-token-max-ttl-minutes` 的值。身份验证令牌是为验证 API 请求而创建的。
+**2.6.6 版本更改：适用于所有 kubeconfig 令牌和 API 令牌。**
+
+### kubeconfig-generate-token
+如果设置为 true，则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false，kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后，[CLI 将为用户检索和缓存令牌](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证)。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/api/quickstart.md

@@ -0,0 +1,152 @@
+---
+title: API 快速入门指南
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/quickstart"/>
+</head>
+
+你可以通过 Kubernetes API 访问 Rancher 的资源。本指南将帮助你以 Rancher 用户的身份开始使用此 API。
+
+1. 在左上角，点击 **☰ > 全局设置**.
+2. 找到 `server-url` 字段并复制其地址。
+3. [创建](../reference-guides/user-settings/api-keys.md#创建-api-密钥)一个没有作用域的 Rancher API 密钥。
+
+  :::danger
+
+  没有作用域的 Rancher API 密钥授予用户可以访问的所有资源的无限制的访问权限。为防止未经授权的使用，此密钥应安全存储并经常轮换。
+
+  :::
+
+4. 创建一个 `kubeconfig.yaml` 文件，将 `$SERVER_URL` 替换成上面从全局设置中复制的地址，并且将 `$API_KEY` 替换为上面创建的 Rancher API 密钥：
+
+    ```yaml
+    apiVersion: v1
+    kind: Config
+    clusters:
+    - name: "rancher"
+      cluster:
+        server: "$SERVER_URL"
+    
+    users:
+    - name: "rancher"
+      user:
+        token: "$API_KEY"
+
+    contexts:
+    - name: "rancher"
+      context:
+        user: "rancher"
+        cluster: "rancher"
+
+    current-context: "rancher"
+    ```
+
+你可以使用任何兼容的工具来引用这个文件，例如 kubectl 或 [client-go](https://github.com/kubernetes/client-go)。快速演示内容请参阅 [kubectl 示例](#api-kubectl-示例)
+
+更多有关处理更复杂证书的设置信息，请参阅[指定 CA 证书](#指定-ca-证书)。
+
+更多关于可用的 kubeconfig 选项，请参阅[上游文档](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
+
+## API kubectl 示例
+
+在此示例中，我们将展示如何使用 kubectl 创建一个项目，然后删除它。关于其他可用的 Rancher 资源列表，请参阅 [API 参考](./api-reference.mdx)。
+
+:::note
+
+目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
+
+:::
+
+1. 将 KUBECONFIG 环境变量设置为刚才创建的 kubeconfig 文件：
+
+  ```bash
+  export KUBECONFIG=$(pwd)/kubeconfig.yaml
+  ```
+
+2. 使用 `kubectl explain` 查看项目的可用字段，或者复杂资源的子字段：
+
+  ```bash
+  kubectl explain projects
+  kubectl explain projects.spec
+  ```
+  
+不是所有的资源都有详细的输出。
+
+3. 在名称为 `project.yaml` 的文件中添加以下内容：
+
+  ```yaml
+  apiVersion: management.cattle.io/v3
+  kind: Project
+  metadata:
+    # name 应在每个集群的所有项目中都是唯一的
+    name: p-abc123
+    # generateName 可以替代 `name` 来随机生成一个名称
+    # generateName: p-
+    # namespace 应与 spec.ClusterName 匹配
+    namespace: local
+  spec:
+    # clusterName 应与目标集群的 `metadata.Name` 匹配
+    clusterName: local
+    description: Example Project 
+    # displayName 是人类可读的名称并且从 UI 中显示
+    displayName: Example
+  ```
+
+4. 创建项目：
+
+  ```bash
+  kubectl create -f project.yaml
+  ```
+
+5. 删除项目：
+
+  项目删除的方式取决于项目名称的创建方式。
+
+  **A. 如果在创建项目时使用 `name`**：
+
+    ```bash
+    kubectl delete -f project.yaml
+    ```
+
+  **B. 如果你使用 `generateName`**：
+
+    将 `$PROJECT_NAME` 替换为 kubectl 创建项目后随机生成的项目名称。
+
+    ```bash
+    kubectl delete project $PROJECT_NAME -n local
+    ```
+
+## 指定 CA 证书
+
+为确保你的工具能够识别 Rancher 的 CA 证书，大多数设置都需要对上述模板进行额外修改。
+
+1. 在左上角点击 **☰ > 全局设置**.
+2. 查找并复制 `ca-certs` 字段中的值。
+3. 将复制的值保存在名称为 `rancher.crt` 的文件中。
+
+  :::note
+  如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并将其添加到 kubeconfig 文件中，如步骤 5 所示。
+  :::
+
+4. 以下命令会将 `rancher.crt` 转换为 base64 输出，除去所有换行符，并使用证书内容更新 kubeconfig 中的 cluster 选项，然后删除 `rancher.crt` 文件：
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.certificate-authority-data $(cat rancher.crt | base64 -i - | tr -d '\n')
+  rm rancher.crt
+  ```
+5. （可选项）如果你使用不受系统信任的自签名证书，则可以通过 kubectl 在 kubeconfig 中设置不安全选项：
+
+  :::danger
+
+  此选项不应该在生产环境中使用，因为它存在安全风险。
+
+  :::
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.insecure-skip-tls-verify true
+  ```
+
+  如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并如上面演示的方法，将其添加到 kubeconfig 文件中。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/api/v3-rancher-api-guide.md

@@ -0,0 +1,93 @@
+---
+title: API
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/about-the-api"/>
+</head>
+
+## 如何使用 API
+
+API 有自己的用户界面，你可以从 Web 浏览器访问它。这是查看资源、执行操作以及查看等效 cURL 或 HTTP 请求和响应的一种简单的方法。要访问它：
+
+<Tabs>
+<TabItem value="Rancher v2.6.4+">
+
+1. 单击右上角的用户头像。
+1. 单击**账号 & API 密钥**。
+1. 在 **API 密钥**下，找到 **API 端点**字段并单击链接。该链接类似于 `https://<RANCHER_FQDN>/v3`，其中 `<RANCHER_FQDN>` 是 Rancher deployment 的完全限定域名。
+
+</TabItem>
+<TabItem value="Rancher 版本低于 v2.6.4">
+
+转到位于 `https://<RANCHER_FQDN>/v3` 的 URL 端点，其中 `<RANCHER_FQDN>` 是你的 Rancher deployment 的完全限定域名。
+
+</TabItem>
+</Tabs>
+
+## 认证
+
+API 请求必须包含认证信息。认证是通过 [API 密钥](../reference-guides/user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键，并限制账号可以查看的集群和项目以及可以执行的操作。
+
+默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。有关如何使 API 令牌失效的详细信息，请参阅 [API 令牌](api-tokens.md)。
+
+## 发出请求
+
+该 API 通常是 RESTful 的，但是还具有多种功能。这些功能可以使客户端发现所有内容，因此可以编写通用客户端，而不必为每种资源编写特定代码。有关通用 API 规范的详细信息，请参阅[此处](https://github.com/rancher/api-spec/blob/master/specification.md)。
+
+- 每种类型都有一个 Schema，这个 Schema 描述了以下内容：
+   - 用于获取此类资源集合的 URL
+   - 资源可以具有的每个字段及其类型、基本验证规则、是必填还是可选字段等
+   - 在此类资源上可以执行的每个操作，以及它们的输入和输出（也作为 schema）
+   - 允许过滤的每个字段
+   - 集合本身或集合中的单个资源可以使用的 HTTP 操作方法
+
+
+- 因此，你可以只加载 schema 列表并了解 API 的所有信息。实际上，这是 API 的 UI 工作方式，它不包含特定于 Rancher 本身的代码。每个 HTTP 响应中的 `X-Api-Schemas` 标头都会发送获取 Schemas 的 URL。你可以按照每个 schema 上的 `collection` 链接了解要在哪里列出资源，并在返回资源中的其他 `links` 中获取其他信息。
+
+- 在实践中，你可能只想构造 URL 字符串。我们强烈建议将此限制为在顶层列出的集合 (`/v3/<type>`)，或获取特定资源 (`/v3/<type>/<id>`)。除此之外的任何内容都可能在将来的版本中发生更改。
+
+- 资源之间相互之间有联系，称为链接（links）。每个资源都包含一个 `links` 映射，其中包含链接名称和用于检索该信息的 URL。同样，你应该 `GET` 资源并遵循 `links` 映射中的 URL，而不是自己构造这些字符串。
+
+- 大多数资源都有操作（action），表示可以执行某个操作或改变资源的状态。要使用操作，请将 HTTP `POST` 请求发送到 `actions` 映射中你想要的操作的 URL。某些操作需要输入或生成输出，请参阅每种类型的独立文档或 schema 以获取具体信息。
+
+- 要编辑资源，请将 HTTP `PUT` 请求发送到资源上的 `links.update` 链接，其中包含要更改的字段。如果链接丢失，则你无权更新资源。未知字段和不可编辑的字段将被忽略。
+
+- 要删除资源，请将 HTTP `DELETE` 请求发送到资源上的 `links.remove` 链接。如果链接丢失，则你无权更新资源。
+
+- 要创建新资源，HTTP `POST` 到 schema（即 `/v3/<type>`）中的集合 URL。
+
+## 过滤
+
+你可以使用 HTTP 查询参数的公共字段在服务器端过滤大多数集合。`filters` 映射显示了可以过滤的字段，以及过滤后的值在你发起的请求中是什么。API UI 具有设置过滤和显示适当请求的控件。对于简单的 "equals" 匹配，它只是 `field=value`。你可以将修饰符添加到字段名称，例如 `field_gt=42` 表示“字段大于 42”。详情请参阅 [API 规范](https://github.com/rancher/api-spec/blob/master/specification.md#filtering)。
+
+## 排序
+
+你可以使用 HTTP 查询参数的公共字段在服务器端排序大多数集合。`sortLinks` 映射显示了可用的排序，以及用于获取遵循该排序的集合的 URL。它还包括当前响排序依据的信息（如果指定）。
+
+## 分页
+
+默认情况下，API 响应以每页 100 个资源的限制进行分页。你可以通过 `limit` 查询参数进行更改，最大为 1000，例如 `/v3/pods?limit=1000`。集合响应中的 `pagination` 映射能让你知道你是否拥有完整的结果集，如果没有，则会指向下一页的链接。
+
+## 捕获 Rancher API 调用
+
+You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning a Rancher Kubernetes distribution cluster:
+
+1. 在 Rancher UI 中，转到**集群管理**并单击**创建**。
+1. 单击某个集群类型。此示例使用 Digital Ocean。
+1. 使用集群名称和节点模板填写表单，但不要单击**创建**。
+1. 在创建集群之前，你需要打开开发人员工具才能看到正在记录的 API 调用。要打开工具，右键单击 Rancher UI，然后单击**检查**。
+1. 在开发者工具中，单击 **Network** 选项卡。
+1. 在 **Network** 选项卡上，确保选择了 **Fetch/XHR**。
+1. 在 Rancher UI 中，单击**创建**。在开发者工具中，你应该会看到一个名为 `cluster?_replace=true` 的新网络请求。
+1. 右键单击 `cluster?_replace=true` 并单击**复制 > 复制为 cURL**。
+1. 将结果粘贴到文本编辑器中。你将能够看到 POST 请求，包括被发送到的 URL、所有标头以及请求的完整正文。此命令可用于从命令行创建集群。请注意，请求包含凭证，因此请将请求存储在安全的地方。
+
+### 启用在 API 中查看
+
+你还可以查看针对各自集群和资源捕获的 Rancher API 调用。 默认情况下不启用此功能。 要启用它：
+
+1. 单击 UI 右上角的 **用户图标**，然后从下拉菜单中选择 **偏好设置**
+1. 在**高级功能**部分下，单击**启用"在 API 中查看"**
+
+选中后，**在 API 中查看**链接现在将显示在 UI 资源页面上的 **⋮** 子菜单下。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/api/workflows/projects.md

@@ -0,0 +1,134 @@
+---
+title: 项目
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/workflows/projects"/>
+</head>
+
+## 创建项目
+
+项目资源只能在管理集群上创建，请参考下文了解如何[在管理集群中的项目下创建命名空间](#在项目中创建命名空间)
+
+### 创建一个基本项目
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+使用 `metadata.generateName` 来确保一个唯一的项目 ID，但是需要注意 `kubectl apply` 不能与 `metadata.generateName` 一起使用，因此必须使用 `kubectl create` 来替代。
+
+将 `metadata.namespace` 和 `spec.clusterName` 设置为项目所属的集群 ID。
+
+如果你通过集群成员账户创建项目，则必须包含注释 `field.cattle.io/creatorId`，并将注释值设置为集群成员账号的用户 ID。
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  annotations: 
+    field.cattle.io/creatorId: user-id
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+设置 `field.cattle.io/creatorId` 字段允许集群成员账户通过 `get` 命令查看项目资源，并可以在 Rancher UI 中查看项目。集群所有者和管理员账号不需要设置此注释。
+
+### 创建一个具有 Resource Quota 的项目
+
+请查看 [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)。
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  resourceQuota:
+    limit:
+      limitsCpu: 1000m
+  namespaceDefaultResourceQuota:
+    limit:
+      limitsCpu: 50m
+EOF
+```
+
+### 创建一个具有 Container Limit Ranges 的项目
+
+请查看 [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/)。
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  containerDefaultResourceLimit:
+    limitsCpu:    100m
+    limitsMemory: 100Mi
+    requestsCpu:  50m
+    requestsMemory: 50Mi
+```
+
+## 在项目中创建命名空间
+
+项目资源保存在管理集群中，即使该项目使用于托管集群也是如此。项目下的命名空间保存在托管集群中。
+
+在管理集群上查找你正在管理的集群的项目 ID，因为它是使用 `metadata.generateName` 生成的：
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+在托管集群上，使用项目注释创建命名空间:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: mynamespace
+  annotations:
+    field.cattle.io/projectId: c-m-abcde:p-vwxyz
+EOF
+```
+
+注意格式：`<cluster ID>:<project ID>`
+
+## 删除项目
+
+在集群命名空间中查找要删除的项目：
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+删除集群命名空间下的项目：
+
+```bash
+kubectl --namespace c-m-abcde delete project p-vwxyz
+```
+
+请注意此命令不会删除以前属于该项目的命名空间和资源。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/contribute-to-rancher.md

@@ -0,0 +1,114 @@
+---
+title: 参与 Rancher 社区贡献
+---
+
+本文介绍了 Rancher 仓库和 Rancher 文档、如何构建 Rancher 仓库以及提交 issue 时要包含哪些信息。
+
+有关如何为 Rancher 项目开发做出贡献的更多详细信息，请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源：
+
+- 如何搭建 Rancher 开发环境并运行测试
+- Issue 在开发生命周期中的典型流程
+- 编码指南和开发最佳实践
+- 调试和故障排除
+- 开发 Rancher API
+
+在 Rancher Users Slack 上，开发者的频道是 **#developer**。
+
+## Rancher 文档
+
+如果你对此网站上的文档有建议，请在主 [Rancher 文档](https://github.com/rancher/rancher-docs)仓库中[提交 issue](https://github.com/rancher/rancher-docs/issues/new/choose)。此仓库包含 Rancher v2.0 及更高版本的文档。
+
+有关贡献和构建 Rancher v2.x 文档仓库的更多详细信息，请参阅 [Rancher 文档 README](https://github.com/rancher/rancher-docs#readme)。
+
+有关 Rancher v1.6 及更早版本的文档，请参阅 [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) 仓库，其中包含 https://rancher.com/docs/rancher/v1.6/en/ 的源文件。
+
+## Rancher 仓库
+
+所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库，以下是部分主要仓库的描述：
+
+| 仓库 | URL | 描述 |
+-----------|-----|-------------
+| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
+| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
+| API Framework | https://github.com/rancher/norman | API 框架，用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
+| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
+| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
+| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
+| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库，它是配置托管 Kubernetes 集群的工具。 |
+| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
+| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
+| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
+| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库，用于动态更改日志级别。 |
+
+要查看 Rancher 使用的所有库/项目，请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
+
+![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)<br/>
+<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
+
+### 构建 Rancher 仓库
+
+每个仓库都应该有一个 Makefile，并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本，每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作，它包含了所需的所有构建工具。
+
+默认目标是 `ci`，它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中，通常也打包在 Docker 镜像中。
+
+### Rancher Bug、Issue 或疑问
+
+如果你发现任何 bug 或问题，由于有人可能遇到过同样的问题，或者我们已经正在寻找解决方案，因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
+
+如果找不到与你的问题相关的内容，请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多，但请将 issue 提交到 Rancher 仓库中，这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户，你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
+
+#### 提交 Issue 的检查清单
+
+提交问题时请遵循此清单，以便我们调查和解决问题。如果你能提供更多信息，我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
+
+:::note
+
+如果数据量很大，请使用 [GitHub Gist](https://gist.github.com/) 或类似工具，并在 issue 中链接你创建的资源。
+
+:::
+
+:::note 重要提示：
+
+请删除所有敏感数据。
+
+:::
+
+- **资源**：请尽量详细地提供所使用的资源。导致问题的原因可能很多，因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例：
+   - **主机**：主机的规格（例如 CPU/内存/磁盘），运行在什么云厂商上，使用的 Amazon Machine Image，使用的 DigitalOcean droplet，配置的镜像（复现时用于重新构建或使用）。
+   - **操作系统**：使用的是什么操作系统。在此处提供详细信息，例如 `cat /etc/os-release` 的输出（确切的操作系统版本）和 `uname -r` 的输出（确切的内核）。
+   - **Docker**：使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
+   - **环境**：是否使用了代理，是否使用可信的 CA/自签名证书，是否使用了外部负载均衡器。
+   - **Rancher**：使用的 Rancher 版本，可以在 UI 左下角或者从主机运行的 image 标签中获取。
+   - **集群**：创建了什么样的集群，如何创建的，在创建时指定了什么参数。
+- **复现 issue 的步骤**：尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
+   - 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
+- **日志**：提供使用资源的数据/日志。
+   - Rancher
+      - Docker 安装
+
+      ```
+      docker logs \
+      --timestamps \
+      $(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
+      ```
+      - 使用 `kubectl` 的 Kubernetes 安装
+
+      :::note
+
+      确保你配置了正确的 kubeconfig（例如，如果 Rancher 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
+
+      :::
+
+      ```
+      kubectl -n cattle-system \
+      logs \
+      -l app=rancher \
+      --timestamps=true
+      ```
+   - 系统日志记录（可能不存在，取决于操作系统）
+      - `/var/log/messages`
+      - `/var/log/syslog`
+      - `/var/log/kern.log`
+   - Docker Daemon 日志记录（可能并不全部存在，取决于操作系统）
+      - `/var/log/docker.log`
+- **指标**：如果你遇到性能问题，请提供尽可能多的指标数据（文件或屏幕截图）来帮助我们确定问题。如果你遇到主机相关的问题，你可以提供 `top`、`free -m`、`df` 的输出，这些输出会显示进程/内存/磁盘的使用情况。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/container-network-interface-providers.md

@@ -0,0 +1,169 @@
+---
+title: CNI 网络插件
+description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能，以及如何选择网络提供商
+---
+
+## 什么是 CNI？
+
+CNI（容器网络接口）是一个[云原生计算基金会项目](https://cncf.io/)，它包含了一些规范和库，用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接，并在容器被删除时移除所分配的资源。
+
+Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
+
+![CNI Logo](/img/cni-logo.png)
+
+有关更多信息，请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
+
+## CNI 使用了哪些网络模型？
+
+CNI 网络插件使用封装网络模型（例如 Virtual Extensible Lan，缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)）或非封装网络模型（例如 Border Gateway Protocol，缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)）来实现网络结构。
+
+### 什么是封装网络？
+
+此网络模型提供了一个逻辑二层（L2）网络，该网络封装在跨 Kubernetes 集群节点的现有三层（L3）网络拓扑上。使用此模型，你可以为容器提供一个隔离的 L2 网络，而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发，交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
+
+简单来说，这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥，其中连接了 pod。
+
+如果你偏向使用扩展 L2 网桥，则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置，请确保它们之间的延迟较低，以避免最终的网络分段。
+
+使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下，Calico 不会使用此模型，但你可以对其进行配置。
+
+![封装网络](/img/encapsulated-network.png)
+
+### 什么是非封装网络？
+
+该网络模型提供了一个 L3 网络，用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络，也不会产生开销。这些好处的代价是，Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装，而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接，例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
+
+简而言之，这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器，提供了如何连接 Pod 的信息。
+
+如果你偏向使用 L3 网络，则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
+
+使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置，即使这不是默认模式。
+
+![非封装网络](/img/unencapsulated-network.png)
+
+## Rancher 提供哪些 CNI 插件？
+
+### RKE2 Kubernetes 集群
+
+Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Calico 和 Cilium。
+
+如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下，Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
+
+Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要，你可以使用它。Calico 还支持策略隔离，让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
+
+如果使用 BGP，Kubernetes Worker 需要打开 TCP 端口 `179`，如果使用 VXLAN 封装，则需要打开 UDP 端口 `4789`。另外，使用 Typha 时需要 TCP 端口 `5473`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
+
+:::note 重要提示：
+
+在 Rancher 2.6.3 中，Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意，此问题已在 v2.6.4 中解决。</b>
+
+- 要解决此问题，请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
+
+- 在那里，将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
+
+:::
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+有关详细信息，请参阅以下页面：
+
+- [Project Calico 官方网站](https://www.projectcalico.org/)
+- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
+
+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal 是一个 CNI 网络插件，它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案，将 Calico 的网络策略执行与 Calico（未封装）和 Flannel（封装）丰富的网络连接选项结合起来。
+
+Canal 是 Rancher 默认的 CNI 网络插件，并采用了 Flannel 和 VXLAN 封装。
+
+Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`（健康检查）。如果使用 Wireguard，则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
+
+![](/img/canal-diagram.png)
+
+有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)
+
+#### Cilium
+
+![Cilium Logo](/img/cilium-logo.png)
+
+Cilium 在 Kubernetes 中启用网络和网络策略（L3、L4 和 L7）。默认情况下，Cilium 使用 eBPF 技术在节点内部路由数据包，并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
+
+Cilium 推荐大于 5.2 的内核版本，从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`（VXLAN）和 TCP 端口 `4240`（健康检查）。此外，还必须为健康检查启用 ICMP 8/0。有关详细信息，请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
+
+##### Cilium 中跨节点的 Ingress 路由
+<br/>
+默认情况下，Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题，请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
+
+选择 Cilium CNI 并为新集群启用项目网络隔离后，配置如下：
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {}
+  ingress:
+    - fromEntities:
+      - remote-node
+```
+
+## 各个网络插件的 CNI 功能
+
+下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能：
+
+| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
+| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
+| Calico | 封装（VXLAN，IPIP）或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
+| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+
+- 网络模型：封装或未封装。如需更多信息，请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
+
+- 路由分发：一种外部网关协议，用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的，并且通常由 BGP 完成。如果你想构建跨网段拆分的集群，路由分发是一个很好的功能。
+
+- 网络策略：Kubernetes 提供了强制执行规则的功能，这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能，可以与某些网络插件一起使用。
+
+- 网格：允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
+
+- 外部数据存储：具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
+
+- 加密：允许加密和安全的网络控制和数据平面。
+
+- Ingress/Egress 策略：允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
+
+
+## CNI 社区人气
+
+下表总结了不同的 GitHub 指标，让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
+
+| 提供商 | 项目 | Stars | Forks | Contributors |
+| ---- | ---- | ---- | ---- | ---- |
+| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
+| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
+| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
+| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
+| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
+
+<br/>
+
+## 使用哪个 CNI 插件？
+
+这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
+
+Canal 是默认的 CNI 网络插件。对于大多数用例，我们推荐你使用它。它使用 Flannel 为容器提供封装网络，同时添加 Calico 网络策略，可以在网络方面提供项目/命名空间隔离。
+
+## 如何配置 CNI 网络插件？
+
+如需了解如何为你的集群配置网络插件，请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项，请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/deprecated-features.md

@@ -0,0 +1,25 @@
+---
+title: Rancher 中已弃用的功能
+---
+
+<head>
+  <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.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 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 日 |
+
+## 当一个功能被标记为弃用我可以得到什么样的预期？
+
+当功能被标记为“已弃用”时，它依然可用并得到支持，允许按照常规的流程进行升级。一旦升级完成，用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署，建议不要使用已弃用的功能。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/general-faq.md

@@ -0,0 +1,51 @@
+---
+title: 一般常见问题解答
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
+</head>
+
+本文包含了用户常见的 Rancher 2.x 问题。
+
+有关常见技术问题，请参阅[常见技术问题解答](technical-items.md)。
+
+## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？
+
+如果你在 Rancher 2.x 中创建环境，Swarm 和 Mesos 将不再是可选的标准选项。但是，Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定，但这是大势所趋。比如说，15,000 多个集群可能只有大约 200 个在运行 Swarm。
+
+## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？
+
+是的。请参阅我们的[集群管理](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md)指南，了解 AKS 上可用的 Rancher 功能，以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
+
+## Rancher 是否支持 Windows？
+
+Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
+
+## Rancher 是否支持 Istio？
+
+Rancher 支持 [Istio](../integrations-in-rancher/istio/istio.md)。
+
+## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？
+
+密文管理已在我们的 roadmap 上，但我们尚未将该功能分配给特定版本。
+
+## Rancher 2.x 是否也支持 RKT 容器？
+
+目前，我们只支持 Docker。
+
+## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？
+
+Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息，请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
+
+## Rancher 是否计划支持 Traefik？
+
+目前，我们不打算提供嵌入式 Traefik 支持，但我们仍在探索负载均衡方案。
+
+## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗？
+
+我们的目标是运行任何上游 Kubernetes 集群。因此，Rancher 2.x 应该可以与 OpenShift 一起使用，但我们尚未对此进行测试。
+
+## Rancher 会集成 Longhorn 吗？
+
+是的。Longhorn 已集成到 Rancher 2.5+ 中。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/install-and-configure-kubectl.md

@@ -0,0 +1,23 @@
+---
+title: 安装和配置 kubectl
+---
+
+`kubectl` 是一个 CLI 工具，用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
+
+## 安装
+
+请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
+
+## 配置
+
+When you create a Kubernetes cluster with RKE2/K3s, the Kubeconfig file is stored at `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` depending on your chosen distribution. These files are used to configure access to the Kubernetes cluster.
+
+使用 `kubectl` 测试你的连接性，并查看你是否可以获取节点列表：
+
+```shell
+kubectl get nodes
+ NAME                          STATUS    ROLES                      AGE       VERSION
+165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.116.167               Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.127.226               Ready     controlplane,etcd,worker   11m       v1.10.1
+```

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/rancher-is-no-longer-needed.md

@@ -0,0 +1,60 @@
+---
+title: 卸载 Rancher
+---
+
+本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。
+
+## 如果 Rancher Server 被删除，下游集群中的工作负载会怎样？
+
+如果 Rancher 删除了或无法恢复，Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。
+
+## 如果删除了 Rancher Server，该如何访问下游集群？
+
+如果删除了 Rancher，访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之：
+
+- **Registered/Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
+- **托管的 Kubernetes 集群**：如果你在 Kubernetes 云提供商（例如 EKS、GKE 或 AKS）中创建集群，你可以继续使用提供商的云凭证来管理集群。
+- **Rancher provisioned clusters:** To access an [RKE2/K3s cluster](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
+
+## 如果我不想再使用 Rancher 了该怎么做？
+
+:::note
+
+之前推荐的 [System Tools](../reference-guides/system-tools.md) 自 2022 年 6 月起已弃用。
+
+:::
+
+如果你[在 Kubernetes 集群上安装了 Rancher](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)，你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
+
+在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序：
+
+- fleet
+- fleet-agent
+- rancher-operator
+- rancher-webhook
+
+自定义资源 (CRD) 和自定义命名空间仍需要手动删除。
+
+如果你在 Docker 中安装 Rancher，则可以通过删除运行 Rancher 的单个 Docker 容器来卸载 Rancher。
+
+移除 Rancher 不会影响导入的集群。有关其他集群类型，请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。
+
+## 如果我不想 Rancher 管理我的注册集群该怎么办？
+
+如果你在 Rancher UI 中删除了已注册的集群，则该集群将与 Rancher 分离，集群不会发生改变，你可以使用注册集群之前的方法访问该集群。
+
+要分离集群：
+
+1. 在左上角，单击 **☰ > 集群管理**。
+2. 转到要与 Rancher 分离的已注册集群，然后单击 **⋮ > 删除**。
+3. 单击**删除**。
+
+**结果**：注册的集群已与 Rancher 分离，并在 Rancher 外正常运行。
+
+## What if I don't want my hosted Kubernetes cluster managed by Rancher?
+
+目前，我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下，“分离”指的是将 Rancher 组件移除出集群，并独立于 Rancher 管理对集群的访问。
+
+[此 issue](https://github.com/rancher/rancher/issues/25234) 跟踪了在没有 Rancher 的情况下管理这些集群的功能。
+
+有关如何在删除 Rancher Server 后访问集群的更多信息，请参阅[本节](#如果删除了-rancher-server该如何访问下游集群)。

i18n/zh/docusaurus-plugin-content-docs/version-2.13/faq/security.md

@@ -0,0 +1,14 @@
+---
+title: 安全
+
+---
+
+**是否有强化指南？**
+
+强化指南现在位于[安全](../reference-guides/rancher-security/rancher-security.md)部分。
+
+<br/>
+
+**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么？**
+
+我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../reference-guides/rancher-security/rancher-security.md)中找到该评估的结果。