Merge pull request #1726 from rancher/v2.8.14

Merge release branch v2.8.14 into main
Merge pull request #1725 from rancher/v2.9.8
2026-09-29 14:38:50 +00:00 · 2025-03-31 16:54:11 -07:00 · 2025-03-31 16:54:00 -07:00 · 2025-03-31 16:53:46 -07:00 · 2025-03-31 16:53:20 -07:00 · 2025-03-31 09:01:05 -07:00
293 changed files with 3076 additions and 904 deletions
@@ -0,0 +1 @@
+f288d286db3b7c65e02cb6635d0c048f0f7a88fa
@@ -52,7 +52,7 @@ As an [administrator](../../../how-to-guides/advanced-user-guides/authentication
 > | 10252 | Controlplane | Kube controller manager |
 > | 2379 | Etcd | Etcd server |

-> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)
+> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)

 1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.

@@ -0,0 +1,15 @@
+---
+title: Extension API Server
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/extension-apiserver"/>
+</head>
+
+Rancher extends Kubernetes with additional APIs by registering an extension API server using the [Kubernetes API Aggregation Layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+
+## Disabling the extension API server
+
+The [aggregation layer must be configured](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) on the local Kubernetes cluster for the `imperative-api-extension` feature to be enabled and to work correctly. The feature assumes this is configured and is enabled by default. If it is not possible to configure the aggregation layer for your local Kubernetes cluster, then you must disable the feature. The `imperative-api-extension` feature flag can be disabled by either using the [Rancher UI](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-ui) or [Rancher API](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-api).
+
+It will still be possible to access the additional APIs when the feature is disabled. The additional APIs are available at `https://<rancher url>/ext` and they are compatible with the Kubernetes apiserver. This means you can use `curl` or `kubectl` to interact with the APIs.
@@ -16,10 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3) | Feb 27, 2025 |
-| [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 |
-| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
-| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
+| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | Mar 31, 2025 |

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

@@ -18,8 +18,6 @@ In this section,
 - **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
 - **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.

-Note the `restrictedAdmin` Helm chart option available for **the Rancher Server**. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)
-
 ## Overview of Installation Options

 Rancher can be installed on these main architectures:
@@ -18,10 +18,12 @@ 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.
 - `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.
 - `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
+- `imperative-api-extension`: Enables Rancher's [extension API server](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) to register new APIs to Kubernetes. This flag is enabled by default. See the [Extension API Server](../../../api/extension-apiserver.md) page for more information.
 - `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
 - `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
 - `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
@@ -38,12 +40,14 @@ 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` | `false` | Highly experimentatl | v2.11.0 | This flag value is locked on install and can't be changed. |
 | `clean-stale-secrets` | `true` | GA | v2.10.2 | |
 | `continuous-delivery` | `true` | GA | v2.6.0 | |
 | `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
 | `fleet`  | `true` | Can no longer be disabled | v2.6.0 | |
 | `fleet`  | `true` | GA | v2.5.0 | |
 | `harvester` | `true` | Experimental | v2.6.1 | |
+| `imperative-api-extension` | `true` | GA | v2.11.0 | |
 | `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
 | `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
 | `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
@@ -59,7 +59,6 @@ For information on enabling experimental features, refer to [this page.](../../.
 | `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
 | `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.                                                                                                        |
 | `resources`                    | {}                                                    | `map` - rancher pod resource requests & limits                                                                                                    |
-| `restrictedAdmin`              | `false`                                               | `bool` - When this option is set to `true`, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin). |
 | `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
 | `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
 | `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |
@@ -6,6 +6,8 @@ title: Upgrading Kubernetes without Upgrading Rancher
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
 </head>

+<EOLRKE1Warning />
+
 The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.

 :::note
@@ -0,0 +1,78 @@
+---
+title: Enabling Cluster Agent Scheduling Customization
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-cluster-agent-scheduling-customization"/>
+</head>
+
+In Rancher v2.11.0 and later, you can enable the automatic deployment of a Priority Class and Pod Disruption Budget for the `cattle-cluster-agent`.
+
+When this feature is enabled, all newly provisioned Node Driver, Custom, and Imported RKE2 and K3s clusters will automatically deploy a Priority Class and Pod Disruption Budget during the provisioning process. Existing clusters can be gradually updated with this new behavior using the [Rancher UI or by setting a specific annotation](#updating-existing-clusters) on cluster objects.
+
+This feature is disabled by default.
+
+## Enabling Cluster Agent Scheduling Customization
+
+:::info
+Enabling or disabling this feature only impacts new clusters. Existing downstream clusters will not be automatically updated. See [_Updating Existing Clusters_](#updating-existing-clusters).
+:::
+
+1. In the upper left corner, click **☰ > Global Settings**
+1. Select **Feature Flags**
+1. Find the `cluster-agent-scheduling-customization` feature and click **⋮ > Activate**
+
+## Configuring the Global Settings
+
+You can customize the default Priority Class (PC) and Pod Disruption Budget (PDB) by updating the `cluster-agent-default-priority-class` and `cluster-agent-default-pod-disruption-budget` global settings in the Rancher UI. Note that both the Priority Class and Pod Disruption Budget have configuration restrictions:
+
+ The `Value` set for the default PC cannot be less than negative 1 billion, or greater than 1 billion.
+ The `PreemptionPolicy` set for the PC must be equal to `PreemptLowerPriority` or `Never`.
+ You cannot configure the PDB `minAvailable` and `maxUnavailable` fields to both have a non-zero value.
+ The PDB `minAvailable` must either be a non-negative whole number integer, or a non-negative whole number percent (e.g. `1` or `100%`).
+ The PDB `maxUnavailable` must either be a non-negative whole number integer, or a non-negative whole number percent (e.g. `1` or `100%`).
+
+
+## Updating Existing Clusters
+
+:::info
+When this feature is disabled, you cannot modify the cluster agent scheduling customization fields for existing clusters. However, you can always remove the configuration, regardless of the feature's status.
+:::
+
+After enabling this feature, you can configure scheduling customization for existing clusters in two ways:
+
+ **Using the Rancher UI**
+  + Edit the desired cluster and navigate to the **Cluster Agent** tab within the **Cluster Configuration** section.
+  + Enable the `Prevent Rancher cluster agent pod eviction` checkbox.
+    + The necessary fields on the associated `clusters.provisioning.cattle.io` or `clusters.management.cattle.io` object will be automatically configured using the values set in the global settings.
+  + Save the cluster.
+ **Using an annotation**
+  + The `provisioning.cattle.io/enable-scheduling-customization` annotation can be used to update clusters without requiring the use of the Rancher UI. This annotation will be automatically removed from the cluster after the Priority Class and Pod Disruption Budget are configured.
+    + The value of this annotation can be either `true` or `false`, to add or remove scheduling customization automatically.
+    + For Node Driver Provisioned and Custom clusters, apply this annotation on the associated `clusters.provisioning.cattle.io` object.
+    + For Imported clusters, apply the annotation on the associated `clusters.management.cattle.io` object.
+
+## Applying Updated Global Settings
+
+In order to prevent unexpected changes in scheduler behavior, Rancher does not update existing downstream clusters when the `cluster-agent-default-priority-class` and `cluster-agent-default-pod-disruption-budget` global settings are changed. There are two ways to update existing clusters to use the most recent global settings:
+
+ **Using the Rancher UI**
+  + When configuring a cluster, an additional checkbox will be shown in the **Cluster Agent** tab within the **Cluster Configuration** section. Checking the `Apply global settings for Priority Class and Pod Disruption Budget` checkbox will automatically update the Priority Class and Pod Disruption Budget to match the global settings once the cluster is saved.
+ **Adjusting the cluster yaml**
+  + You may manually adjust the relevant fields in the cluster object using `kubectl` or the Rancher UI 'Edit As Yaml' feature. Scheduling customization can be found in the `spec.ClusterAgentDeploymentCustomization.SchedulingCustomization` section of the cluster object.
+  + Alternatively, the `provisioning.cattle.io/enable-scheduling-customization` annotation can be used to remove and re-add the updated scheduling customization fields set on a specific cluster.
+
+## Downstream Objects
+
+When this feature is enabled for a given cluster, two downstream resources will be automatically created by Rancher:
+
+ A Pod Disruption Budget will be automatically created in the `cattle-system` namespace, named `cattle-cluster-agent-pod-disruption-budget`.
+ A Priority Class will be automatically created, named `cattle-cluster-agent-priority-class`.
+
+These objects are maintained by Rancher and must not be modified or deleted. The Rancher server will automatically update these objects to match the configuration set on the Cluster object and remove them when they are no longer needed.
+
+### RBAC considerations
+
+Before enabling this feature on a downstream cluster, cluster administrators should assess their current RBAC configuration to prevent common access to the `cattle-cluster-agent-priority-class`. In cases where external users have access to a cluster, such as when offering clusters as a service, it is recommended to limit access to the `cattle-cluster-agent-priority-class` object to prevent changes or deletion.
+
+Similar considerations do not need to be made for the `cattle-cluster-agent-pod-disruption-budget` object, as Pod Disruption Budgets are namespaced objects. Rancher will create the `cattle-cluster-agent-pod-disruption-budget` in the privileged `cattle-system` namespace.
@@ -0,0 +1,19 @@
+---
+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. It is expected to be available as a beta for users in v2.12 with a prospective GA in Rancher 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.
@@ -6,6 +6,14 @@ title: Istio Setup Guides
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide"/>
 </head>

+:::note
+
+[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
+
+Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
+
+:::
+
 This section describes how to enable Istio and start using it in your projects.

 If you use Istio for traffic management, you will need to allow external traffic to the cluster. In that case, you will need to follow all of the steps below.
@@ -6,6 +6,8 @@ title: About RKE1 Templates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
 RKE templates are designed to allow DevOps and security teams to standardize and simplify the creation of Kubernetes clusters.

 RKE is the [Rancher Kubernetes Engine,](https://rancher.com/docs/rke/latest/en/) which is the tool that Rancher uses to provision Kubernetes clusters.
@@ -6,6 +6,8 @@ title: Creating and Revising RKE Templates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
 This section describes how to manage RKE templates and revisions. You an create, share, update, and delete templates from the **Cluster Management** view under **RKE1 Configuration > RKE Templates**.

 Template updates are handled through a revision system. When template owners want to change or update a template, they create a new revision of the template. Individual revisions cannot be edited. However, if you want to prevent a revision from being used to create a new cluster, you can disable it.
@@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth

 ## Users and Groups

-Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
-
 :::note

-Local authentication does not support creating or managing groups.
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
+
 For more information, see [Users and Groups](manage-users-and-groups.md)

 ## Scope of Rancher Authorization
@@ -8,12 +8,10 @@ title: Global Permissions

 _Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.

-Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Restricted Admin`,`Standard User` and `User-base`.
+Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Standard User` and `User-base`.

 - **Administrator:** These users have full control over the entire Rancher system and all clusters within it.

- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
-
 - **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.

 - **User-Base:** User-Base users have login-access only.
@@ -286,79 +284,3 @@ To refresh group memberships,
 1. Click **Refresh Group Memberships**.

 **Result:** Any changes to the group members' permissions will take effect.
-
-## Restricted Admin
-
-:::warning Deprecated
-
-The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
-
-:::
-
-A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
-
-The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
-
-A new setting was added to Rancher to set the initial bootstrapped administrator to have the `restricted-admin` role. This applies to the first user created when the Rancher server is started for the first time. If the environment variable is set, then no global administrator would be created, and it would be impossible to create the global administrator through Rancher.
-
-To bootstrap Rancher with the `restricted-admin` as the initial user, the Rancher server should be started with the following environment variable:
-
-```
-CATTLE_RESTRICTED_DEFAULT_ADMIN=true
-```
-### List of `restricted-admin` Permissions
-
-The following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
-
-| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
-| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
-| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
-| | Create Projects/namespaces | Yes | No | No | |
-| | Add cluster/project members | Yes | No | No | |
-| | Global DNS | Yes | No | No | |
-| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
-| | Save as RKE Template | Yes | No | No | |
-| Security | | | | | |
-| Enable auth | Configure Authentication | Yes | No | Yes | |
-| Roles	| Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
-| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
-| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
-| Users	| Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
-| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
-| | Refresh Groups | Yes | No | Yes | |
-| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
-| Tools | | | | | |
-| | Manage RKE Templates | Yes | No | Yes | |
-| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
-| | Cluster Drivers | Yes | No | Yes | |
-| | Node Drivers | Yes | No | Yes | |
-| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
-| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
-| Settings | | | | | |
-| | Manage Settings | Yes | No (Can list) | No (Can list) | |
-| User | | | | | |
-| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
-| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
-| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
-| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
-| | Edit Cluster | Yes | Yes | Yes | |
-| | Rotate Certificates	| Yes | | Yes | |
-| | Snapshot Now | Yes | | Yes | |
-| | Restore Snapshot | Yes | | Yes | |
-| | Save as RKE Template | Yes | No | Yes | |
-| | Run CIS Scan | Yes | Yes | Yes | |
-| | Add Members	| Yes | Yes | Yes | |
-| | Create Projects | Yes | Yes | Yes | |
-| Feature Charts since v2.5 | | | | | |
-| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
-| | Deploy EKS cluster | Yes | Yes | Yes | |
-| | Deploy GKE cluster | Yes | Yes | Yes | |
-| | Deploy AKS cluster | Yes | Yes | Yes | |
-
-### Changing Global Administrators to Restricted Admins
-
-In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach. 
-
-This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
-
-Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
@@ -8,6 +8,10 @@ title: Pod Security Admission (PSA) Configuration Templates

 [Pod Security admission (PSA)](./pod-security-standards.md) configuration templates are a Rancher custom-defined resource (CRD), available in Rancher v2.7.2 and above. The templates provide pre-defined security configurations that you can apply to a cluster:

+:::info important
+The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#exempting-required-rancher-namespaces) that won't be used within your environments.
+:::
+
 - `rancher-privileged`: The most permissive configuration. It doesn't restrict the behavior of any pods. This allows for known privilege escalations. This policy has no exemptions.
 - `rancher-restricted`: A heavily restricted configuration that follows current best practices for hardening pods. You must make [namespace-level exemptions](./pod-security-standards.md#rancher-on-psa-restricted-clusters) for Rancher components.

@@ -140,6 +140,26 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o

   1. Once the Restore resource has the status `Completed`, you can continue the cert-manager and Rancher installation.

+:::note Important:
+
+When migrating Rancher between any two different Kubernetes distributions (e.g. from K3s to RKE2), the object representing the local cluster has to be modified to allow Rancher to detect the new distribution. After the restoration is completed, and **before** bringing up Rancher on the new cluster, edit the local cluster object:
+
+```bash
+kubectl edit clusters.management.cattle.io local
+```
+
+1. Change the value of `status.driver` to `imported`.
+1. Remove `status.provider`.
+1. Remove the entire `status.version` map.
+1. Remove the label with the key `provider.cattle.io` in `metadata.labels`.
+1. Remove the annotation with the key `management.cattle.io/current-cluster-controllers-version` in `metadata.annotations`.
+1. Remove the entire `spec.rke2Config` or `spec.k3sConfig` map, if present.
+1. Save the changes.
+
+Note that removing `spec.rke2Config` or `spec.k3sConfig` will erase your distribution-specific upgrade configuration for the local cluster. It can be [reconfigured](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) if the new distribution is configurable for the local cluster.
+
+:::
+
 ### 3. Install cert-manager

 Follow the steps to [install cert-manager](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
@@ -6,12 +6,6 @@ title: Using OCI-Based Helm Chart Repositories
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/oci-registries"/>
 </head>

-:::caution
-
-This feature is currently experimental and is not officially supported in Rancher.
-
-:::
-
 Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means that you can deploy apps that are stored as OCI artifacts.

 ## Add an OCI-Based Helm Chart Repository
@@ -6,6 +6,8 @@ title: Setting up Infrastructure for a High Availability RKE Kubernetes Cluster
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster"/>
 </head>

+<EOLRKE1Warning />
+
 This tutorial is intended to help you create a high-availability RKE cluster that can be used to install a Rancher server.

 :::note Important:
@@ -6,6 +6,8 @@ title: Setting up a High-availability RKE Kubernetes Cluster
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher"/>
 </head>

+<EOLRKE1Warning />
+
 This section describes how to install a Kubernetes cluster. This cluster should be dedicated to run only the Rancher server.

 :::note
@@ -31,13 +31,13 @@ kubectl create clusterrolebinding cluster-admin-binding \

 Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-admin` role, you must run these commands on GKE clusters before you can register them. To learn more about role-based access control for GKE, please see [the official Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).

-### Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)  
+### Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)

-To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group. 
+To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group.

 AKS clusters can only be imported if local accounts are enabled. If a cluster is configured to use Microsoft Entra ID for authentication, Rancher will not be able to import the cluster and report an error.

-EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher. 
+EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher.

 GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison) for more information about the differences between GKE modes.

@@ -47,9 +47,10 @@ GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard
 2. On the **Clusters** page, **Import Existing**.
 3. Choose the type of cluster.
 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.
-5. If you are importing a generic Kubernetes cluster in Rancher, perform the following steps for setup:<br/>
-  a. Click **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent](../launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.<br/>
-  b. Enable Project Network Isolation to ensure the cluster supports Kubernetes `NetworkPolicy` resources. Users can select the **Project Network Isolation** option under the **Advanced Options** dropdown to do so.
+5. If you are importing a generic Kubernetes cluster in Rancher, perform the following steps for setup:
+   1. Click **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent](../launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
+   1. Enable Project Network Isolation to ensure the cluster supports Kubernetes `NetworkPolicy` resources. Users can select the **Project Network Isolation** option under the **Advanced Options** dropdown to do so.
+   1. [Configure the version management feature for imported RKE2 and K3s clusters](#configuring-version-management-for-rke2-and-k3s-clusters).
 6. Click **Create**.
 7. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite.
 8. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher.
@@ -124,18 +125,16 @@ After registering a cluster, the cluster owner can:
 ### Additional Features for Registered RKE2 and K3s Clusters

 [K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution for edge installations.
+
 [RKE2](https://docs.rke2.io) is Rancher's next-generation Kubernetes distribution for datacenter and cloud installations.

-When an RKE2 or K3s cluster is registered in Rancher, Rancher will recognize it. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster:
+When an RKE2 or K3s cluster is registered in Rancher, Rancher will recognize it.
+The Rancher UI will expose features available to [all registered clusters](#features-for-all-registered-clusters), along with the following options for editing and upgrading the cluster:

- The ability to [upgrade the Kubernetes version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
-  :::danger
-
-  After a cluster has been imported into Rancher, upgrades should be performed using Rancher. Upgrading an imported cluster outside of Rancher is **not** supported.
-
-  :::
- The ability to configure the maximum number of nodes that will be upgraded concurrently
- The ability to see a read-only version of the cluster's configuration arguments and environment variables used to launch each node in the cluster
+- Enable or disable [version management](#configuring-version-management-for-rke2-and-k3s-clusters)
+- [Upgrade the Kubernetes version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) when version management is enabled
+- Configure the [upgrade strategy](#configuring-rke2-and-k3s-cluster-upgrades) when version management is enabled
+- View a read-only version of the cluster’s configuration arguments and environment variables used to launch each node

 ### Additional Features for Registered EKS, AKS, and GKE Clusters

@@ -145,6 +144,24 @@ When you create an EKS, AKS, or GKE cluster in Rancher, then delete it, Rancher

 See [Cluster Management Capabilities by Cluster Type](kubernetes-clusters-in-rancher-setup.md) for more information about what features are available for managing registered clusters.

+## Configuring Version Management for RKE2 and K3s Clusters
+
+:::danger
+
+When version management is enabled for an imported cluster, upgrading it outside of Rancher may lead to unexpected consequences.
+
+:::
+
+The version management feature for imported RKE2 and K3s clusters can be configured using one of the following options:
+
+- **Global default** (default): Inherits behavior from the global **imported-cluster-version-management** setting.
+- **True**: Enables version management, allowing users to control the Kubernetes version and upgrade strategy of the cluster through Rancher.
+- **False**: Disables version management, enabling users to manage the cluster’s Kubernetes version independently, outside of Rancher.
+
+You can define the default behavior for newly created clusters or existing ones set to "Global default" by modifying the **imported-cluster-version-management** setting.
+
+Changes to the global **imported-cluster-version-management** setting take effect during the cluster’s next reconciliation cycle.
+
 ## Configuring RKE2 and K3s Cluster Upgrades

 :::tip
@@ -180,8 +197,12 @@ The current status of the plans can be viewed with this command:
 kubectl get plans -A -o yaml
 ```

+:::tip
+
 If the cluster becomes stuck in upgrading, restart the `system-upgrade-controller`.

+:::
+
 To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed.

 ## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
@@ -304,4 +325,4 @@ This section lists some of the most common errors that may occur when importing

    ```sh
    az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts
-    ```
+    ```
@@ -175,34 +175,6 @@ stringData:
      "loadBalancerSku": "standard",
      "excludeMasterFromStandardLB": false,
    }
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-rules:
-  - apiGroups: [""]
-resources: ["secrets"]
-resourceNames: ["azure-cloud-config"]
-verbs:
-  - get
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: system:azure-cloud-provider-secret-getter
-  subjects:
-    - kind: ServiceAccount
-      name: azure-cloud-config
-      namespace: kube-system
   ``` 

 ## Using the Out-of-tree Azure Cloud Provider
@@ -212,109 +184,85 @@ roleRef:

 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.

-2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
-  - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.

-3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. 
+3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.

-Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+    Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+
+4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
+Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+
+  Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).

  ```yaml
-apiVersion: helm.cattle.io/v1
-kind: HelmChart
-metadata:
-  name: azure-cloud-controller-manager
-  namespace: kube-system
-spec:
-  chart: cloud-provider-azure
-  repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
-  targetNamespace: kube-system
-  bootstrap: true
-  valuesContent: |-
-    infra:
-      clusterName: <cluster-name>
-    cloudControllerManager:
-      cloudConfigSecretName: azure-cloud-config
-      cloudConfig: null
-      clusterCIDR: null
-      enableDynamicReloading: 'true'
-      nodeSelector: 
-        node-role.kubernetes.io/control-plane: 'true'
-      allocateNodeCidrs: 'false' 
-      hostNetworking: true
-      caCertDir: /etc/ssl
-      configureCloudRoutes: 'false'
-      enabled: true
-      tolerations:
-        - effect: NoSchedule
-          key: node-role.kubernetes.io/master
-        - effect: NoSchedule
-          key: node-role.kubernetes.io/control-plane
-          value: 'true'
-        - effect: NoSchedule
-          key: node.cloudprovider.kubernetes.io/uninitialized
-          value: 'true'
---
-apiVersion: v1
-kind: Secret
-metadata:
-  name: azure-cloud-config
-  namespace: kube-system
-type: Opaque
-stringData:
-  cloud-config: |-
-    {
-      "cloud": "AzurePublicCloud",
-      "tenantId": "<tenant-id>",
-      "subscriptionId": "<subscription-id>",
-      "aadClientId": "<client-id>",
-      "aadClientSecret": "<tenant-id>",
-      "resourceGroup": "docker-machine",
-      "location": "westus",
-      "subnetName": "docker-machine",
-      "securityGroupName": "rancher-managed-kqmtsjgJ",
-      "securityGroupResourceGroup": "docker-machine",
-      "vnetName": "docker-machine-vnet",
-      "vnetResourceGroup": "docker-machine",
-      "primaryAvailabilitySetName": "docker-machine",  
-      "routeTableResourceGroup": "docker-machine",
-      "cloudProviderBackoff": false,
-      "useManagedIdentityExtension": false,
-      "useInstanceMetadata": true,
-      "loadBalancerSku": "standard",
-      "excludeMasterFromStandardLB": false,
-    }
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-rules:
-  - apiGroups: [""]
-resources: ["secrets"]
-resourceNames: ["azure-cloud-config"]
-verbs:
-  - get
---
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  labels:
-    kubernetes.io/cluster-service: "true"
-  name: system:azure-cloud-provider-secret-getter
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: system:azure-cloud-provider-secret-getter
-  subjects:
-    - kind: ServiceAccount
-      name: azure-cloud-config
-      namespace: kube-system
+  apiVersion: helm.cattle.io/v1
+  kind: HelmChart
+  metadata:
+    name: azure-cloud-controller-manager
+    namespace: kube-system
+  spec:
+    chart: cloud-provider-azure
+    repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+    targetNamespace: kube-system
+    bootstrap: true
+    valuesContent: |-
+      infra:
+        clusterName: <cluster-name>
+      cloudControllerManager:
+        cloudConfigSecretName: azure-cloud-config
+        cloudConfig: null
+        clusterCIDR: null
+        enableDynamicReloading: 'true'
+        nodeSelector: 
+          node-role.kubernetes.io/control-plane: 'true'
+        allocateNodeCidrs: 'false' 
+        hostNetworking: true
+        caCertDir: /etc/ssl
+        configureCloudRoutes: 'false'
+        enabled: true
+        tolerations:
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/master
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/control-plane
+            value: 'true'
+          - effect: NoSchedule
+            key: node.cloudprovider.kubernetes.io/uninitialized
+            value: 'true'
+  ---
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: azure-cloud-config
+    namespace: kube-system
+  type: Opaque
+  stringData:
+    cloud-config: |-
+      {
+        "cloud": "AzurePublicCloud",
+        "tenantId": "<tenant-id>",
+        "subscriptionId": "<subscription-id>",
+        "aadClientId": "<client-id>",
+        "aadClientSecret": "<tenant-id>",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-kqmtsjgJ",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",  
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true,
+        "loadBalancerSku": "standard",
+        "excludeMasterFromStandardLB": false,
+      }
  ```

-4. Click **Create** to submit the form and create the cluster.
+5. Click **Create** to submit the form and create the cluster.

 </TabItem>

@@ -6,6 +6,8 @@ title: Behavior Differences Between RKE1 and RKE2
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/rke1-vs-rke2-differences"/>
 </head>

+<EOLRKE1Warning />
+
 RKE2, also known as RKE Government, is a Kubernetes distribution that focuses on security and compliance for U.S. Federal Government entities. It is considered the next iteration of the Rancher Kubernetes Engine, now known as RKE1.

 RKE1 and RKE2 have several slight behavioral differences to note, and this page will highlight some of these at a high level.
@@ -6,7 +6,7 @@ title: Adding Users to Clusters
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters"/>
 </head>

-If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
+To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.

 :::tip

@@ -52,12 +52,6 @@ In this section, you'll learn how to add the cluster template to the `local` clu

 **Result:** The cluster template available from the **Apps** in Rancher's `local` cluster. It can now be used to deploy clusters.

-:::note Restricted Admin access:
-
-If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management >  Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
-
-:::
-
 ## Creating a Cluster from a Cluster Template

 :::note Prerequisites:
@@ -19,10 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
-| v2.10.3         | v105.0.0+up5.0.1 |
-| v2.10.2         | v105.0.0+up5.0.1 |
-| v2.10.1         | v105.0.0+up5.0.1 |
-| v2.10.0         | v105.0.0+up5.0.1 |
+| v2.11.0         | v106.0.0+up6.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -6,6 +6,14 @@ title: Istio
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio"/>
 </head>

+:::note
+
+[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
+
+Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
+
+:::
+
 [Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, secure, control, and troubleshoot the traffic within a complex network of microservices.

 As a network of microservices changes and grows, the interactions between them can become increasingly difficult to manage and understand. In such a situation, it is useful to have a service mesh as a separate infrastructure layer. Istio's service mesh lets you manipulate traffic between microservices without changing the microservices directly.
@@ -48,7 +48,6 @@ Etcd is the backing database for Kubernetes and for Rancher. The database may ev
 This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.

 You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
-* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
 * Only add users to clusters and projects when necessary.
 * Remove clusters and projects when they are no longer needed.
 * Only use custom roles if necessary.
@@ -73,7 +72,6 @@ Predicting how many `RoleBinding` objects a given configuration will create is c
  * `Ua` is the average number of users with a membership on a cluster.
  * `P` is the total number of projects.
  * `Pa` is the average number of users with a membership on a project.
-* The Restricted Admin role follows a different formula, as every user with this role results in at least `7C + 2P + 2` additional `RoleBinding` objects.
 * The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.

 ### Using New Apps Over Legacy Apps
@@ -6,6 +6,8 @@ title: RKE Cluster Configuration Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
 </head>

+<EOLRKE1Warning />
+
 When Rancher installs Kubernetes, it uses [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) or [RKE2](https://docs.rke2.io/) as the Kubernetes distribution.

 This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.
@@ -2,6 +2,8 @@
 title: RKE Hardening Guides
 ---

+<EOLRKE1Warning />
+
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
 </head>
@@ -6,6 +6,8 @@ title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
 </head>

+<EOLRKE1Warning />
+
 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

 This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
@@ -1,10 +1,12 @@
 ---
 title: RKE Self-Assessment Guide - CIS Benchmark v1.24 - K8s v1.24
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
-</head>
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
+</head>
+
+<EOLRKE1Warning />

 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

@@ -1,10 +1,12 @@
 ---
 title: RKE Self-Assessment Guide - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
-</head>
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
+</head>
+
+<EOLRKE1Warning />

 This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.

@@ -20,10 +20,7 @@ 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.10.3         |     v0.6.4      | &check;               | &check;                   |
-| v2.10.2         |     v0.6.3      | &check;               | &check;                   |
-| v2.10.1         |     v0.6.2      | &check;               | &check;                   |
-| v2.10.0         |     v0.6.1      | &cross;               | &check;                   |
+| v2.11.0         |     v0.7.0      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -6,6 +6,8 @@ title: RKE1 Example YAML
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rke1-template-example-yaml"/>
 </head>

+<EOLRKE1Warning />
+
 Below is an example RKE template configuration file for reference.

 The YAML in the RKE template uses the same customization that is used when you create an RKE cluster. However, since the YAML is within the context of a Rancher provisioned RKE cluster, the customization from the RKE docs needs to be nested under the `rancher_kubernetes_engine` directive.
@@ -185,7 +185,7 @@ module.exports = {
              label: 'Latest',
            },
            '2.11': {
-              label: 'v2.11 (Preview)',
+              label: 'v2.11 (Unreleased)',
              path: 'v2.11',
              banner: 'unreleased'
            },
@@ -2,6 +2,8 @@
 title: 在不升级 Rancher 的情况下升级 Kubernetes
 ---

+<EOLRKE1Warning />
+
 RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本，而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用，例如，在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中，将 Kubernetes 升级到 v1.14.7。

 :::note
@@ -6,6 +6,9 @@ title: RKE 模板
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
+
 RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。

 RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
@@ -2,6 +2,8 @@
 title: 创建和修改 RKE 模板
 ---

+<EOLRKE1Warning />
+
 本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。

 模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
@@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。

 ## 用户和组

-Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
-
 :::note

-本地认证不支持创建或管理组
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
+
 更多信息，请查看[用户和组](manage-users-and-groups.md)

 ## Rancher 授权范围
@@ -4,6 +4,10 @@ title: Pod 安全准入 (PSA) 配置模板

 [Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：

+:::info important
+The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#豁免必须的-rancher-命名空间) that won't be used within your environments.
+:::
+
 - `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
 - `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。

@@ -2,6 +2,8 @@
 title: 为高可用 RKE Kubernetes 集群设置基础设施
 ---

+<EOLRKE1Warning />
+
 本教程旨在帮助你创建一个高可用的 RKE 集群，用于安装 Rancher Server。

 :::note 重要提示：
@@ -2,6 +2,8 @@
 title: 配置高可用的 RKE Kubernetes 集群
 ---

+<EOLRKE1Warning />
+
 本文介绍如何安装 Kubernetes 集群。该集群应专用于运行 Rancher Server。

 :::note
@@ -109,3 +109,437 @@ Azure 订阅不支持以下账号类型：
 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。

 1. 单击**创建**按钮来提交表单并创建集群。
+
+## Cloud Provider Configuration
+
+Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names.
+
+**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).**
+
+:::note 
+1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`.
+2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB).
+3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information.
+:::
+
+Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret.
+
+Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret.
+
+  ```yaml
+# azure-cloud-config.yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: azure-cloud-config
+  namespace: kube-system
+type: Opaque
+stringData:
+  cloud-config: |-
+    {
+      "cloud": "AzurePublicCloud",
+      "tenantId": "<tenant-id>",
+      "subscriptionId": "<subscription-id>",
+      "aadClientId": "<client-id>",
+      "aadClientSecret": "<tenant-id>",
+      "resourceGroup": "docker-machine",
+      "location": "westus",
+      "subnetName": "docker-machine",  
+      "securityGroupName": "rancher-managed-kqmtsjgJ",
+      "securityGroupResourceGroup": "docker-machine",
+      "vnetName": "docker-machine-vnet",
+      "vnetResourceGroup": "docker-machine",
+      "primaryAvailabilitySetName": "docker-machine",  
+      "routeTableResourceGroup": "docker-machine",
+      "cloudProviderBackoff": false,
+      "useManagedIdentityExtension": false,
+      "useInstanceMetadata": true,
+      "loadBalancerSku": "standard",
+      "excludeMasterFromStandardLB": false,
+    }
+   ``` 
+
+## Using the Out-of-tree Azure Cloud Provider
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
+
+2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
+
+3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
+
+    Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+
+4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
+Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+
+  Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).
+
+  ```yaml
+  apiVersion: helm.cattle.io/v1
+  kind: HelmChart
+  metadata:
+    name: azure-cloud-controller-manager
+    namespace: kube-system
+  spec:
+    chart: cloud-provider-azure
+    repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+    targetNamespace: kube-system
+    bootstrap: true
+    valuesContent: |-
+      infra:
+        clusterName: <cluster-name>
+      cloudControllerManager:
+        cloudConfigSecretName: azure-cloud-config
+        cloudConfig: null
+        clusterCIDR: null
+        enableDynamicReloading: 'true'
+        nodeSelector: 
+          node-role.kubernetes.io/control-plane: 'true'
+        allocateNodeCidrs: 'false' 
+        hostNetworking: true
+        caCertDir: /etc/ssl
+        configureCloudRoutes: 'false'
+        enabled: true
+        tolerations:
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/master
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/control-plane
+            value: 'true'
+          - effect: NoSchedule
+            key: node.cloudprovider.kubernetes.io/uninitialized
+            value: 'true'
+  ---
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: azure-cloud-config
+    namespace: kube-system
+  type: Opaque
+  stringData:
+    cloud-config: |-
+      {
+        "cloud": "AzurePublicCloud",
+        "tenantId": "<tenant-id>",
+        "subscriptionId": "<subscription-id>",
+        "aadClientId": "<client-id>",
+        "aadClientSecret": "<tenant-id>",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-kqmtsjgJ",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",  
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true,
+        "loadBalancerSku": "standard",
+        "excludeMasterFromStandardLB": false,
+      }
+  ```
+
+5. Click **Create** to submit the form and create the cluster.
+
+</TabItem>
+
+<TabItem value="RKE1">
+
+1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components.
+
+2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui).
+
+Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager.
+
+</TabItem>
+</Tabs>
+
+### Helm Chart Installation from CLI
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github.
+
+1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). 
+
+```shell 
+kubectl apply -f azure-cloud-config.yaml
+```
+
+2. Add the Helm repository:
+
+```shell
+helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+helm repo update
+```
+
+3. Create a `values.yaml` file with the following contents to override the default `values.yaml`:
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+```yaml
+# values.yaml
+infra:
+  clusterName: <cluster-name>
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/control-plane: 'true'
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/master
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/control-plane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+```
+
+</TabItem>
+
+<TabItem value="RKE">
+
+```yaml
+# values.yaml
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null  
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/controlplane: 'true'
+    node-role.kubernetes.io/control-plane: null
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/controlplane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+infra:
+  clusterName: <cluster-name>
+```
+
+</TabItem>
+</Tabs>
+
+4. Install the Helm chart:
+
+```shell
+helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml
+```
+
+Verify that the Helm chart installed successfully:
+
+```shell
+helm status cloud-provider-azure -n kube-system
+```
+
+5. (Optional) Verify that the cloud controller manager update succeeded:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Helm Chart Installation from UI
+
+1. Click **☰**, then select the name of the cluster from the left navigation.
+
+2. Select **Apps** > **Repositories**.
+
+3. Click the **Create** button.
+
+4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field.
+
+5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart.
+
+6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**.
+
+7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading:
+
+```yaml
+  cloudConfigSecretName: azure-cloud-config
+  enableDynamicReloading: 'true'
+```
+
+8. Update the following fields as required:
+
+```yaml 
+  allocateNodeCidrs: 'false'
+  configureCloudRoutes: 'false'
+  clusterCIDR: null
+```
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector:
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/control-plane: 'true'
+```
+</TabItem>
+
+<TabItem value="RKE">
+
+10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+
+```yaml
+tolerations:
+  - effect: NoSchedule
+    key: node.cloudprovider.kubernetes.io/uninitialized
+    value: 'true'
+  - effect: NoSchedule
+    value: 'true'
+    key: node-role.kubernetes.io/controlplane
+```
+
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/controlplane: 'true'
+```
+</TabItem>
+</Tabs>
+
+11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Installing CSI Drivers
+
+Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively.
+
+The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md).
+
+::: note Important: 
+
+Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. 
+
+::: 
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github.
+
+1. Add and update the helm repository:
+
+```shell 
+helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
+helm repo update azuredisk-csi-driver
+``` 
+
+1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration).
+
+```shell
+helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
+``` 
+
+2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: 
+
+```shell 
+kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch 
+``` 
+
+3. Provision an example Storage Class: 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: standard
+provisioner: kubernetes.io/azure-disk
+parameters:
+  storageaccounttype: Standard_LRS
+  kind: Managed
+EOF
+```
+
+Verify that the storage class has been provisioned: 
+```shell 
+kubectl get storageclasses
+```
+
+4. Create a PersistentVolumeClaim:
+```shell 
+cat <<EOF | kubectl create -f -
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: azure-disk-pvc
+spec:
+  storageClassName: standard
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 5Gi
+EOF
+```
+
+Verify that the PersistentVolumeClaim and PersistentVolume have been created: 
+```shell
+kubectl get persistentvolumeclaim 
+kubectl get persistentvolume
+```
+
+5. Attach the new Azure Disk: 
+
+You can now mount the Kubernetes PersistentVolume into a Kubernetes Pod. The disk can be consumed by any Kubernetes object type, including a Deployment, DaemonSet, or StatefulSet. However, the following example simply mounts the PersistentVolume into a standalone Pod. 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod-dynamic-azuredisk
+spec:
+  containers:
+    - name: mypod
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: storage
+  volumes:
+    - name: storage
+      persistentVolumeClaim:
+        claimName: azure-disk-pvc
+EOF
+```
@@ -2,6 +2,8 @@
 title: RKE1 和 RKE2 差异
 ---

+<EOLRKE1Warning />
+
 RKE2，也称为 RKE Government，是一个完全符合标准的 Kubernetes 发行版，它专注于安全性和合规性。它被认为是 Rancher Kubernetes Engine（即 RKE1）的下一个迭代。

 RKE1 和 RKE2 有一些细微的差异，本文将重点介绍这些差异。
@@ -2,7 +2,7 @@
 title: 将用户添加到集群
 ---

-如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。
+To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.

 :::tip

@@ -2,6 +2,8 @@
 title: RKE 集群配置参考
 ---

+<EOLRKE1Warning />
+
 Rancher 安装 Kubernetes 时，它使用 [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 或 [RKE2](https://docs.rke2.io/) 作为 Kubernetes 发行版。

 本文介绍 Rancher 中可用于新的或现有的 RKE Kubernetes 集群的配置选项。
@@ -6,6 +6,8 @@ title: RKE 加固指南
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
 </head>

+<EOLRKE1Warning />
+
 本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。

 :::note
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.24 - K8s v1.24
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -2,6 +2,8 @@
 title: RKE1 示例 YAML
 ---

+<EOLRKE1Warning />
+
 以下是一个供参考的 RKE 模板配置文件示例。

 RKE 模板中的 YAML 使用与创建 RKE 集群时相同的自定义项。但是，由于 YAML 位于 Rancher 配置的 RKE 集群的上下文中，因此 RKE 文档中的自定义项需要嵌套在 `rancher_kubernetes_engine` 指令下。
@@ -89,7 +89,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \

 升级后出现网络问题？

-请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
+请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。

 :::

@@ -139,7 +139,7 @@ helm rollback rancher 3 -n cattle-system

 ## 回滚到 Rancher 2.2-2.4

-要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。
+要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。

 有关回滚 Docker 安装的 Rancher，请参见[本页](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)。

@@ -151,4 +151,4 @@ helm rollback rancher 3 -n cattle-system

 ## 回滚到 Rancher 2.0-2.1

-我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。
+我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。
@@ -30,7 +30,7 @@ kubeconfig 也可以通过 `--kubeconfig` 标签（详情请参见 https://helm.

 <DeprecationHelm2 />

-如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。
+如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。

 ### 离线安装：推送镜像到私有镜像仓库

@@ -200,7 +200,7 @@ helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \

 升级后出现网络问题？

-请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
+请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。

 :::

@@ -380,7 +380,7 @@ docker run -d --volumes-from rancher-data \

 :::note 升级后下游集群出现网络问题？

-请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
+请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。

 :::

@@ -4,7 +4,7 @@ title: Helm 版本要求

 本文介绍 Helm 的要求。Helm 是用于把 Rancher 安装在高可用 Kubernetes 集群上的工具。

-> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3，可以使用这个说明安装。
+> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3，可以使用这个说明安装。

 <DeprecationHelm2 />

@@ -2,6 +2,8 @@
 title: 在不升级 Rancher 的情况下升级 Kubernetes
 ---

+<EOLRKE1Warning />
+
 RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本，而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用，例如，在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中，将 Kubernetes 升级到 v1.14.7。

 :::note
@@ -6,6 +6,9 @@ title: RKE 模板
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
+
 RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。

 RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
@@ -2,6 +2,8 @@
 title: 创建和修改 RKE 模板
 ---

+<EOLRKE1Warning />
+
 本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。

 模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
@@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。

 ## 用户和组

-Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
-
 :::note

-本地认证不支持创建或管理组
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
+
 更多信息，请查看[用户和组](manage-users-and-groups.md)

 ## Rancher 授权范围
@@ -82,4 +82,4 @@ Rancher 包含一些默认处于实验性和/或禁用的功能，功能开关
 - **全局 DNS 条目**
 - **全局 DNS 提供商**

-由于这些是旧版特性，请参考 Rancher v2.0-v2.4 的[应用商店](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [全局 DNS 条目](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), 以及 [全局 DNS 提供商](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider)。
+由于这些是旧版特性，请参考 Rancher v2.0-v2.4 的[应用商店](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [全局 DNS 条目](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), 以及 [全局 DNS 提供商](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider)。
@@ -4,6 +4,10 @@ title: Pod 安全准入 (PSA) 配置模板

 [Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：

+:::info important
+The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#豁免必须的-rancher-命名空间) that won't be used within your environments.
+:::
+
 - `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
 - `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。

@@ -16,7 +16,7 @@ Rancher 使用应用商店系统导入一系列的 charts 包到仓库里，然

 ### Catalogs, Apps, Rancher UI

-[在 Rancher v2.4 及更早版本中](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), 存储部署的应用程序的仓库被称为 "catalogs"。这些仓库是通过 UI 的 **Catalogs** 进行管理的。
+[在 Rancher v2.4 及更早版本中](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), 存储部署的应用程序的仓库被称为 "catalogs"。这些仓库是通过 UI 的 **Catalogs** 进行管理的。

 Rancher v2.5 用新的 **Apps & Marketplace** 功能替代了之前的 **应用商店**。

@@ -2,6 +2,8 @@
 title: 为高可用 RKE Kubernetes 集群设置基础设施
 ---

+<EOLRKE1Warning />
+
 本教程旨在帮助你创建一个高可用的 RKE 集群，用于安装 Rancher Server。

 :::note 重要提示：
@@ -2,6 +2,8 @@
 title: 配置高可用的 RKE Kubernetes 集群
 ---

+<EOLRKE1Warning />
+
 本文介绍如何安装 Kubernetes 集群。该集群应专用于运行 Rancher Server。

 :::note
@@ -109,3 +109,438 @@ Azure 订阅不支持以下账号类型：
 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。

 1. 单击**创建**按钮来提交表单并创建集群。
+
+## Cloud Provider Configuration
+
+Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names.
+
+**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).**
+
+:::note 
+1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`.
+2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB).
+3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information.
+:::
+
+Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret.
+
+Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret.
+
+  ```yaml
+# azure-cloud-config.yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: azure-cloud-config
+  namespace: kube-system
+type: Opaque
+stringData:
+  cloud-config: |-
+    {
+      "cloud": "AzurePublicCloud",
+      "tenantId": "<tenant-id>",
+      "subscriptionId": "<subscription-id>",
+      "aadClientId": "<client-id>",
+      "aadClientSecret": "<tenant-id>",
+      "resourceGroup": "docker-machine",
+      "location": "westus",
+      "subnetName": "docker-machine",  
+      "securityGroupName": "rancher-managed-kqmtsjgJ",
+      "securityGroupResourceGroup": "docker-machine",
+      "vnetName": "docker-machine-vnet",
+      "vnetResourceGroup": "docker-machine",
+      "primaryAvailabilitySetName": "docker-machine",  
+      "routeTableResourceGroup": "docker-machine",
+      "cloudProviderBackoff": false,
+      "useManagedIdentityExtension": false,
+      "useInstanceMetadata": true,
+      "loadBalancerSku": "standard",
+      "excludeMasterFromStandardLB": false,
+    }
+
+   ``` 
+
+## Using the Out-of-tree Azure Cloud Provider
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
+
+2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
+
+3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
+
+    Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+
+4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
+Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+
+  Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).
+
+  ```yaml
+  apiVersion: helm.cattle.io/v1
+  kind: HelmChart
+  metadata:
+    name: azure-cloud-controller-manager
+    namespace: kube-system
+  spec:
+    chart: cloud-provider-azure
+    repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+    targetNamespace: kube-system
+    bootstrap: true
+    valuesContent: |-
+      infra:
+        clusterName: <cluster-name>
+      cloudControllerManager:
+        cloudConfigSecretName: azure-cloud-config
+        cloudConfig: null
+        clusterCIDR: null
+        enableDynamicReloading: 'true'
+        nodeSelector: 
+          node-role.kubernetes.io/control-plane: 'true'
+        allocateNodeCidrs: 'false' 
+        hostNetworking: true
+        caCertDir: /etc/ssl
+        configureCloudRoutes: 'false'
+        enabled: true
+        tolerations:
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/master
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/control-plane
+            value: 'true'
+          - effect: NoSchedule
+            key: node.cloudprovider.kubernetes.io/uninitialized
+            value: 'true'
+  ---
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: azure-cloud-config
+    namespace: kube-system
+  type: Opaque
+  stringData:
+    cloud-config: |-
+      {
+        "cloud": "AzurePublicCloud",
+        "tenantId": "<tenant-id>",
+        "subscriptionId": "<subscription-id>",
+        "aadClientId": "<client-id>",
+        "aadClientSecret": "<tenant-id>",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-kqmtsjgJ",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",  
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true,
+        "loadBalancerSku": "standard",
+        "excludeMasterFromStandardLB": false,
+      }
+  ```
+
+5. Click **Create** to submit the form and create the cluster.
+
+</TabItem>
+
+<TabItem value="RKE1">
+
+1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components.
+
+2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui).
+
+Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager.
+
+</TabItem>
+</Tabs>
+
+### Helm Chart Installation from CLI
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github.
+
+1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). 
+
+```shell 
+kubectl apply -f azure-cloud-config.yaml
+```
+
+2. Add the Helm repository:
+
+```shell
+helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+helm repo update
+```
+
+3. Create a `values.yaml` file with the following contents to override the default `values.yaml`:
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+```yaml
+# values.yaml
+infra:
+  clusterName: <cluster-name>
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/control-plane: 'true'
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/master
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/control-plane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+```
+
+</TabItem>
+
+<TabItem value="RKE">
+
+```yaml
+# values.yaml
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null  
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/controlplane: 'true'
+    node-role.kubernetes.io/control-plane: null
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/controlplane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+infra:
+  clusterName: <cluster-name>
+```
+
+</TabItem>
+</Tabs>
+
+4. Install the Helm chart:
+
+```shell
+helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml
+```
+
+Verify that the Helm chart installed successfully:
+
+```shell
+helm status cloud-provider-azure -n kube-system
+```
+
+5. (Optional) Verify that the cloud controller manager update succeeded:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Helm Chart Installation from UI
+
+1. Click **☰**, then select the name of the cluster from the left navigation.
+
+2. Select **Apps** > **Repositories**.
+
+3. Click the **Create** button.
+
+4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field.
+
+5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart.
+
+6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**.
+
+7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading:
+
+```yaml
+  cloudConfigSecretName: azure-cloud-config
+  enableDynamicReloading: 'true'
+```
+
+8. Update the following fields as required:
+
+```yaml 
+  allocateNodeCidrs: 'false'
+  configureCloudRoutes: 'false'
+  clusterCIDR: null
+```
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector:
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/control-plane: 'true'
+```
+</TabItem>
+
+<TabItem value="RKE">
+
+10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+
+```yaml
+tolerations:
+  - effect: NoSchedule
+    key: node.cloudprovider.kubernetes.io/uninitialized
+    value: 'true'
+  - effect: NoSchedule
+    value: 'true'
+    key: node-role.kubernetes.io/controlplane
+```
+
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/controlplane: 'true'
+```
+</TabItem>
+</Tabs>
+
+11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Installing CSI Drivers
+
+Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively.
+
+The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md).
+
+::: note Important: 
+
+Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. 
+
+::: 
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github.
+
+1. Add and update the helm repository:
+
+```shell 
+helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
+helm repo update azuredisk-csi-driver
+``` 
+
+1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration).
+
+```shell
+helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
+``` 
+
+2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: 
+
+```shell 
+kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch 
+``` 
+
+3. Provision an example Storage Class: 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: standard
+provisioner: kubernetes.io/azure-disk
+parameters:
+  storageaccounttype: Standard_LRS
+  kind: Managed
+EOF
+```
+
+Verify that the storage class has been provisioned: 
+```shell 
+kubectl get storageclasses
+```
+
+4. Create a PersistentVolumeClaim:
+```shell 
+cat <<EOF | kubectl create -f -
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: azure-disk-pvc
+spec:
+  storageClassName: standard
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 5Gi
+EOF
+```
+
+Verify that the PersistentVolumeClaim and PersistentVolume have been created: 
+```shell
+kubectl get persistentvolumeclaim 
+kubectl get persistentvolume
+```
+
+5. Attach the new Azure Disk: 
+
+You can now mount the Kubernetes PersistentVolume into a Kubernetes Pod. The disk can be consumed by any Kubernetes object type, including a Deployment, DaemonSet, or StatefulSet. However, the following example simply mounts the PersistentVolume into a standalone Pod. 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod-dynamic-azuredisk
+spec:
+  containers:
+    - name: mypod
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: storage
+  volumes:
+    - name: storage
+      persistentVolumeClaim:
+        claimName: azure-disk-pvc
+EOF
+```
@@ -2,6 +2,8 @@
 title: RKE1 和 RKE2 差异
 ---

+<EOLRKE1Warning />
+
 RKE2，也称为 RKE Government，是一个完全符合标准的 Kubernetes 发行版，它专注于安全性和合规性。它被认为是 Rancher Kubernetes Engine（即 RKE1）的下一个迭代。

 RKE1 和 RKE2 有一些细微的差异，本文将重点介绍这些差异。
@@ -2,7 +2,7 @@
 title: 将用户添加到集群
 ---

-如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。
+To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.

 :::tip

@@ -114,4 +114,4 @@ Alertmanager UI 可让你查看最近触发的告警。

 ## 旧版 UI

-有关在引入 `rancher-monitoring` 应用程序之前 Rancher v2.2 到 v2.4 中可用仪表板的信息，请参阅 [Rancher v2.0—v2.4 文档](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md)。
+有关在引入 `rancher-monitoring` 应用程序之前 Rancher v2.2 到 v2.4 中可用仪表板的信息，请参阅 [Rancher v2.0—v2.4 文档](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md)。
@@ -11,7 +11,7 @@ description: Prometheus 允许你查看来自不同 Rancher 和 Kubernetes 对

 在 Rancher v2.5 中引入的 `rancher-monitoring` operator 由 [Prometheus](https://prometheus.io/)、[Grafana](https://grafana.com/grafana/)、[Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)， [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 和 [Prometheus adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter) 提供支持。

-有关在 Rancher v2.2 到 v2.4 中可用的 V1 监控和告警的信息，请参阅 Rancher v2.0 到 v2.4 文档中的[集群监控](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md)，[告警](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md)，[通知](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md)和[工具](/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md)。
+有关在 Rancher v2.2 到 v2.4 中可用的 V1 监控和告警的信息，请参阅 Rancher v2.0 到 v2.4 文档中的[集群监控](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md)，[告警](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md)，[通知](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md)和[工具](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md)。

 使用 `rancher-monitoring` 应用程序，你可以快速部署领先的开源监控和告警解决方案到你的集群上。

@@ -204,7 +204,7 @@ _可变：是_

 :::note

-默认选项是 “Container-Optimized OS with Docker”。GCP Container-Optimized OS 上的只读文件系统与 Rancher 中的 [legacy logging](/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md) 实现不兼容。如果你需要使用旧版日志管理功能，请选择 “Ubuntu with Docker” 或 “Ubuntu with Containerd”。[current logging feature](../../../../integrations-in-rancher/logging/logging.md) 与 Container-Optimized OS 镜像兼容。
+默认选项是 “Container-Optimized OS with Docker”。GCP Container-Optimized OS 上的只读文件系统与 Rancher 中的 [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/pages-for-subheaders/cluster-logging.md) 实现不兼容。如果你需要使用旧版日志管理功能，请选择 “Ubuntu with Docker” 或 “Ubuntu with Containerd”。[current logging feature](../../../../integrations-in-rancher/logging/logging.md) 与 Container-Optimized OS 镜像兼容。

 :::

@@ -2,6 +2,8 @@
 title: RKE 集群配置参考
 ---

+<EOLRKE1Warning />
+
 Rancher 安装 Kubernetes 时，它使用 [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 或 [RKE2](https://docs.rke2.io/) 作为 Kubernetes 发行版。

 本文介绍 Rancher 中可用于新的或现有的 RKE Kubernetes 集群的配置选项。
@@ -6,6 +6,8 @@ title: RKE 加固指南
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
 </head>

+<EOLRKE1Warning />
+
 本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。

 :::note
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.24 - K8s v1.24
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -2,6 +2,8 @@
 title: RKE1 示例 YAML
 ---

+<EOLRKE1Warning />
+
 以下是一个供参考的 RKE 模板配置文件示例。

 RKE 模板中的 YAML 使用与创建 RKE 集群时相同的自定义项。但是，由于 YAML 位于 Rancher 配置的 RKE 集群的上下文中，因此 RKE 文档中的自定义项需要嵌套在 `rancher_kubernetes_engine` 指令下。
@@ -2,6 +2,8 @@
 title: 在不升级 Rancher 的情况下升级 Kubernetes
 ---

+<EOLRKE1Warning />
+
 RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本，而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用，例如，在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中，将 Kubernetes 升级到 v1.14.7。

 :::note
@@ -6,6 +6,9 @@ title: RKE 模板
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
+
 RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。

 RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
@@ -2,6 +2,8 @@
 title: 创建和修改 RKE 模板
 ---

+<EOLRKE1Warning />
+
 本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。

 模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
@@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。

 ## 用户和组

-Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
-
 :::note

-本地认证不支持创建或管理组
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
+
 更多信息，请查看[用户和组](manage-users-and-groups.md)

 ## Rancher 授权范围
@@ -4,6 +4,10 @@ title: Pod 安全准入 (PSA) 配置模板

 [Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：

+:::info important
+The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#豁免必须的-rancher-命名空间) that won't be used within your environments.
+:::
+
 - `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
 - `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。

@@ -2,6 +2,8 @@
 title: 为高可用 RKE Kubernetes 集群设置基础设施
 ---

+<EOLRKE1Warning />
+
 本教程旨在帮助你创建一个高可用的 RKE 集群，用于安装 Rancher Server。

 :::note 重要提示：
@@ -2,6 +2,8 @@
 title: 配置高可用的 RKE Kubernetes 集群
 ---

+<EOLRKE1Warning />
+
 本文介绍如何安装 Kubernetes 集群。该集群应专用于运行 Rancher Server。

 :::note
@@ -109,3 +109,438 @@ Azure 订阅不支持以下账号类型：
 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。

 1. 单击**创建**按钮来提交表单并创建集群。
+
+## Cloud Provider Configuration
+
+Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names.
+
+**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).**
+
+:::note 
+1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`.
+2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB).
+3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information.
+:::
+
+Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret.
+
+Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret.
+
+  ```yaml
+# azure-cloud-config.yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: azure-cloud-config
+  namespace: kube-system
+type: Opaque
+stringData:
+  cloud-config: |-
+    {
+      "cloud": "AzurePublicCloud",
+      "tenantId": "<tenant-id>",
+      "subscriptionId": "<subscription-id>",
+      "aadClientId": "<client-id>",
+      "aadClientSecret": "<tenant-id>",
+      "resourceGroup": "docker-machine",
+      "location": "westus",
+      "subnetName": "docker-machine",  
+      "securityGroupName": "rancher-managed-kqmtsjgJ",
+      "securityGroupResourceGroup": "docker-machine",
+      "vnetName": "docker-machine-vnet",
+      "vnetResourceGroup": "docker-machine",
+      "primaryAvailabilitySetName": "docker-machine",  
+      "routeTableResourceGroup": "docker-machine",
+      "cloudProviderBackoff": false,
+      "useManagedIdentityExtension": false,
+      "useInstanceMetadata": true,
+      "loadBalancerSku": "standard",
+      "excludeMasterFromStandardLB": false,
+    }
+
+   ``` 
+
+## Using the Out-of-tree Azure Cloud Provider
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
+
+2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
+
+3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
+
+    Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
+
+4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
+Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
+
+  Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).
+
+  ```yaml
+  apiVersion: helm.cattle.io/v1
+  kind: HelmChart
+  metadata:
+    name: azure-cloud-controller-manager
+    namespace: kube-system
+  spec:
+    chart: cloud-provider-azure
+    repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+    targetNamespace: kube-system
+    bootstrap: true
+    valuesContent: |-
+      infra:
+        clusterName: <cluster-name>
+      cloudControllerManager:
+        cloudConfigSecretName: azure-cloud-config
+        cloudConfig: null
+        clusterCIDR: null
+        enableDynamicReloading: 'true'
+        nodeSelector: 
+          node-role.kubernetes.io/control-plane: 'true'
+        allocateNodeCidrs: 'false' 
+        hostNetworking: true
+        caCertDir: /etc/ssl
+        configureCloudRoutes: 'false'
+        enabled: true
+        tolerations:
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/master
+          - effect: NoSchedule
+            key: node-role.kubernetes.io/control-plane
+            value: 'true'
+          - effect: NoSchedule
+            key: node.cloudprovider.kubernetes.io/uninitialized
+            value: 'true'
+  ---
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: azure-cloud-config
+    namespace: kube-system
+  type: Opaque
+  stringData:
+    cloud-config: |-
+      {
+        "cloud": "AzurePublicCloud",
+        "tenantId": "<tenant-id>",
+        "subscriptionId": "<subscription-id>",
+        "aadClientId": "<client-id>",
+        "aadClientSecret": "<tenant-id>",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-kqmtsjgJ",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",  
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true,
+        "loadBalancerSku": "standard",
+        "excludeMasterFromStandardLB": false,
+      }
+  ```
+
+5. Click **Create** to submit the form and create the cluster.
+
+</TabItem>
+
+<TabItem value="RKE1">
+
+1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components.
+
+2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui).
+
+Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager.
+
+</TabItem>
+</Tabs>
+
+### Helm Chart Installation from CLI
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github.
+
+1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). 
+
+```shell 
+kubectl apply -f azure-cloud-config.yaml
+```
+
+2. Add the Helm repository:
+
+```shell
+helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
+helm repo update
+```
+
+3. Create a `values.yaml` file with the following contents to override the default `values.yaml`:
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+```yaml
+# values.yaml
+infra:
+  clusterName: <cluster-name>
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/control-plane: 'true'
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/master
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/control-plane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+```
+
+</TabItem>
+
+<TabItem value="RKE">
+
+```yaml
+# values.yaml
+cloudControllerManager:
+  cloudConfigSecretName: azure-cloud-config
+  cloudConfig: null
+  clusterCIDR: null  
+  enableDynamicReloading: 'true'
+  configureCloudRoutes: 'false'
+  allocateNodeCidrs: 'false'
+  caCertDir: /etc/ssl
+  enabled: true
+  replicas: 1
+  hostNetworking: true
+  nodeSelector:
+    node-role.kubernetes.io/controlplane: 'true'
+    node-role.kubernetes.io/control-plane: null
+  tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/controlplane
+      value: 'true'
+    - effect: NoSchedule
+      key: node.cloudprovider.kubernetes.io/uninitialized
+      value: 'true'
+infra:
+  clusterName: <cluster-name>
+```
+
+</TabItem>
+</Tabs>
+
+4. Install the Helm chart:
+
+```shell
+helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml
+```
+
+Verify that the Helm chart installed successfully:
+
+```shell
+helm status cloud-provider-azure -n kube-system
+```
+
+5. (Optional) Verify that the cloud controller manager update succeeded:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Helm Chart Installation from UI
+
+1. Click **☰**, then select the name of the cluster from the left navigation.
+
+2. Select **Apps** > **Repositories**.
+
+3. Click the **Create** button.
+
+4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field.
+
+5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart.
+
+6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**.
+
+7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading:
+
+```yaml
+  cloudConfigSecretName: azure-cloud-config
+  enableDynamicReloading: 'true'
+```
+
+8. Update the following fields as required:
+
+```yaml 
+  allocateNodeCidrs: 'false'
+  configureCloudRoutes: 'false'
+  clusterCIDR: null
+```
+
+<Tabs groupId="k8s-distro">
+<TabItem value="RKE2">
+
+9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector:
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/control-plane: 'true'
+```
+</TabItem>
+
+<TabItem value="RKE">
+
+10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
+
+```yaml
+tolerations:
+  - effect: NoSchedule
+    key: node.cloudprovider.kubernetes.io/uninitialized
+    value: 'true'
+  - effect: NoSchedule
+    value: 'true'
+    key: node-role.kubernetes.io/controlplane
+```
+
+```yaml
+nodeSelector:
+  node-role.kubernetes.io/controlplane: 'true'
+```
+</TabItem>
+</Tabs>
+
+11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully:
+
+```shell
+kubectl rollout status deployment -n kube-system cloud-controller-manager
+kubectl rollout status daemonset -n kube-system cloud-node-manager
+```
+
+12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
+
+```shell
+kubectl describe nodes | grep "ProviderID"
+```
+
+### Installing CSI Drivers
+
+Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively.
+
+The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md).
+
+::: note Important: 
+
+Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. 
+
+::: 
+
+Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github.
+
+1. Add and update the helm repository:
+
+```shell 
+helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
+helm repo update azuredisk-csi-driver
+``` 
+
+1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration).
+
+```shell
+helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
+``` 
+
+2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: 
+
+```shell 
+kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch 
+``` 
+
+3. Provision an example Storage Class: 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: standard
+provisioner: kubernetes.io/azure-disk
+parameters:
+  storageaccounttype: Standard_LRS
+  kind: Managed
+EOF
+```
+
+Verify that the storage class has been provisioned: 
+```shell 
+kubectl get storageclasses
+```
+
+4. Create a PersistentVolumeClaim:
+```shell 
+cat <<EOF | kubectl create -f -
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: azure-disk-pvc
+spec:
+  storageClassName: standard
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 5Gi
+EOF
+```
+
+Verify that the PersistentVolumeClaim and PersistentVolume have been created: 
+```shell
+kubectl get persistentvolumeclaim 
+kubectl get persistentvolume
+```
+
+5. Attach the new Azure Disk: 
+
+You can now mount the Kubernetes PersistentVolume into a Kubernetes Pod. The disk can be consumed by any Kubernetes object type, including a Deployment, DaemonSet, or StatefulSet. However, the following example simply mounts the PersistentVolume into a standalone Pod. 
+
+```shell
+cat <<EOF | kubectl create -f -
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod-dynamic-azuredisk
+spec:
+  containers:
+    - name: mypod
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: storage
+  volumes:
+    - name: storage
+      persistentVolumeClaim:
+        claimName: azure-disk-pvc
+EOF
+```
@@ -2,6 +2,8 @@
 title: RKE1 和 RKE2 差异
 ---

+<EOLRKE1Warning />
+
 RKE2，也称为 RKE Government，是一个完全符合标准的 Kubernetes 发行版，它专注于安全性和合规性。它被认为是 Rancher Kubernetes Engine（即 RKE1）的下一个迭代。

 RKE1 和 RKE2 有一些细微的差异，本文将重点介绍这些差异。
@@ -2,7 +2,7 @@
 title: 将用户添加到集群
 ---

-如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。
+To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.

 :::tip

@@ -2,6 +2,8 @@
 title: RKE 集群配置参考
 ---

+<EOLRKE1Warning />
+
 Rancher 安装 Kubernetes 时，它使用 [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 或 [RKE2](https://docs.rke2.io/) 作为 Kubernetes 发行版。

 本文介绍 Rancher 中可用于新的或现有的 RKE Kubernetes 集群的配置选项。
@@ -6,6 +6,8 @@ title: RKE 加固指南
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
 </head>

+<EOLRKE1Warning />
+
 本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。

 :::note
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.24 - K8s v1.24
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
 </head>

+<EOLRKE1Warning />
+
 本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。

 本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
@@ -2,6 +2,8 @@
 title: RKE1 示例 YAML
 ---

+<EOLRKE1Warning />
+
 以下是一个供参考的 RKE 模板配置文件示例。

 RKE 模板中的 YAML 使用与创建 RKE 集群时相同的自定义项。但是，由于 YAML 位于 Rancher 配置的 RKE 集群的上下文中，因此 RKE 文档中的自定义项需要嵌套在 `rancher_kubernetes_engine` 指令下。
@@ -2,6 +2,8 @@
 title: 在不升级 Rancher 的情况下升级 Kubernetes
 ---

+<EOLRKE1Warning />
+
 RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本，而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用，例如，在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中，将 Kubernetes 升级到 v1.14.7。

 :::note
@@ -6,6 +6,9 @@ title: RKE 模板
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
 </head>

+<EOLRKE1Warning />
+
+
 RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。

 RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
@@ -2,6 +2,8 @@
 title: 创建和修改 RKE 模板
 ---

+<EOLRKE1Warning />
+
 本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。

 模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
@@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。

 ## 用户和组

-Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目、多集群应用以及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
-
 :::note

-本地认证不支持创建或管理组
+- Local authentication does not support creating or managing groups.
+- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.

 :::

+Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目、多集群应用以及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
+
 更多信息，请查看[用户和组](manage-users-and-groups.md)

 ## Rancher 授权范围
@@ -2,6 +2,8 @@
 title: 为高可用 RKE Kubernetes 集群设置基础设施
 ---

+<EOLRKE1Warning />
+
 本教程旨在帮助你创建一个高可用的 RKE 集群，用于安装 Rancher Server。

 :::note 重要提示：
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Sunil Singh	baf9710b62	Merge pull request #1726 from rancher/v2.8.14 Merge release branch v2.8.14 into main	2025-03-31 16:54:11 -07:00
Sunil Singh	ff784f2d74	Merge pull request #1725 from rancher/v2.9.8 Merge release branch v2.9.8 into main	2025-03-31 16:54:00 -07:00
Sunil Singh	7e003c84bc	Merge pull request #1724 from rancher/v2.10.4 Merge release branch v2.10.4 into main	2025-03-31 16:53:46 -07:00
Sunil Singh	f6446459c2	Merge pull request #1723 from rancher/v2.11.0 Merge release branch v2.11.0 into main	2025-03-31 16:53:20 -07:00
Sunil Singh	bd4bd46ffb	Merge pull request #1730 from sunilarjun/v2.8.14-maintenance [2.8.14] Updating Deprecated Features Date	2025-03-31 09:01:05 -07:00
Sunil Singh	77b026618c	Merge pull request #1729 from sunilarjun/v2.9.8-maintenance [2.9.8] Updating Deprecated Features Date	2025-03-31 09:00:52 -07:00
Sunil Singh	ebf7a0931f	Merge pull request #1728 from sunilarjun/v2.10.4-maintenance [2.10.4] Updating Deprecated Features Date	2025-03-31 09:00:36 -07:00
Sunil Singh	76e2de984c	Merge pull request #1727 from sunilarjun/v2.11.0-maintenance [2.11.0] Updating Deprecated Features Date	2025-03-31 09:00:24 -07:00
Sunil Singh	fa0ebe0596	[2.8.14] Updating Deprecated Features Date Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-31 08:45:02 -07:00
Sunil Singh	c241877eec	[2.9.8] Updating Deprecated Features Date Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-31 08:43:35 -07:00
Sunil Singh	769c692792	[2.10.4] Updating Deprecated Features Date Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-31 08:41:22 -07:00
Sunil Singh	8db890f12e	[2.11.0] Updating Deprecated Features Date Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-31 08:38:56 -07:00
Sunil Singh	012bf9af13	Merge pull request #1722 from sunilarjun/v2.8.14-maintenance [2.8.14] Updating Deprecated Features Date	2025-03-28 15:00:40 -07:00
Sunil Singh	8837aa2565	Merge pull request #1721 from sunilarjun/v2.9.8-maintenance [2.9.8] Updating Deprecated Features Date	2025-03-28 15:00:24 -07:00
Billy Tat	17d11822c8	Merge pull request #1720 from sunilarjun/v2.10.4-maintenance [2.10.4] Updating Deprecated Features Date	2025-03-27 11:35:47 -07:00
Billy Tat	a15f568e4a	Merge pull request #1719 from sunilarjun/v2.11.0-maintenance [2.11.0] Updating Deprecated Features Date	2025-03-27 11:35:29 -07:00
Sunil Singh	b041b54ca9	[2.8.14] Updating deprecated features date field. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-27 10:57:46 -07:00
Sunil Singh	1045a6bbbf	[2.9.8] Updating deprecated features date field. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-27 10:56:40 -07:00
Sunil Singh	007ccb7050	[2.10.4] Updating deprecated features date field. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-27 10:37:09 -07:00
Sunil Singh	84995b6b4d	[2.11.0] Updating deprecated features date field. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-27 10:32:57 -07:00
Billy Tat	cf0d726935	Merge pull request #1717 from pedromfcarvalho/local-fixup Document workaround for migrating across distributions	2025-03-27 09:01:31 -07:00
Pedro Franco de Carvalho	94ccdfbf63	Better wording	2025-03-26 15:45:49 -03:00
Pedro Franco de Carvalho	371275ee24	Emphasize workaround applies to any two distros	2025-03-26 15:41:11 -03:00
Pedro Franco de CarvalhoandBilly Tat	bb190560b5	Update versioned_docs/version-2.11/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md Co-authored-by: Billy Tat <btat@suse.com>	2025-03-26 15:10:56 -03:00
Pedro Franco de CarvalhoandBilly Tat	1748e5b6f3	Update versioned_docs/version-2.10/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md Co-authored-by: Billy Tat <btat@suse.com>	2025-03-26 15:10:49 -03:00
Pedro Franco de CarvalhoandBilly Tat	5e2157add8	Update docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md Co-authored-by: Billy Tat <btat@suse.com>	2025-03-26 15:10:41 -03:00
Billy Tat	31c29541a9	Merge pull request #1702 from HarrisonWAffel/2.11-pc-pdb New feature in 2.11: cluster agent scheduling customization	2025-03-24 15:19:30 -07:00
Billy Tat	7453e0a3a2	Merge pull request #1713 from sunilarjun/v2.11.0-maintenance v2.11.0 Maintenance Items	2025-03-24 15:13:01 -07:00
Pedro Franco de Carvalho	58ee12d367	Document workaround for migrating across distributions Migrating rancher across different Kubernetes distributions causes the local cluster object not to specify the correct distribution and driver. This commit adds a workaround to be applied after restoration for a migration and before bringing Rancher up, so that the local cluster will have the correct data for the new distribution it runs on.	2025-03-24 17:01:42 -03:00
Harrison Affel	5bb67118ca	Add documentation for 2.11 scheduling customization feature	2025-03-24 10:12:58 -04:00
Billy Tat	efbb0bf99b	Merge pull request #1714 from sunilarjun/v2.10.4-maintenance v2.10.4 Maintenance Items	2025-03-21 16:39:06 -07:00
Sunil Singh	3a051ce759	Updating webhook after review Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 16:09:51 -07:00
Sunil Singh	b4f93428f1	Updating webhook and versions after review. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 15:57:04 -07:00
Billy Tat	d43ef027ef	Merge pull request #1715 from sunilarjun/v2.9.8-maintenance v2.9.8 Maintenance Items	2025-03-21 15:12:04 -07:00
Billy Tat	1fc5b9f561	Merge pull request #1716 from sunilarjun/v2.8.14-maintenance v2.8.14 Maintenance Items	2025-03-21 15:10:11 -07:00
Sunil Singh	8861ed72f4	[2.8.14] deprecated features update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:07:41 -07:00
Sunil Singh	0499d43c5e	[2.8.14] CSP adapter update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:06:56 -07:00
Sunil Singh	b000e9331b	[2.8.14] webhook update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:06:14 -07:00
Sunil Singh	fa85adb908	[2.8.14] versions update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:05:06 -07:00
Sunil Singh	27e459d758	[2.9.8] deprecated features update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:03:20 -07:00
Sunil Singh	be60da5c47	[2.9.8] CSP adapter update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:02:30 -07:00
Sunil Singh	91d08e44c1	[2.9.8] webhook update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:01:34 -07:00
Sunil Singh	da61624d84	[2.9.8] versions update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 11:00:08 -07:00
Sunil Singh	b56e9e9728	[2.10.4] deprecated features update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:57:10 -07:00
Sunil Singh	2bf036b61e	[2.10.4] CSP adapter update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:55:37 -07:00
Sunil Singh	02a5539358	[2.10.4] webhook update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:54:26 -07:00
Sunil Singh	d061a7e869	[2.10.4] versions update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:52:28 -07:00
Sunil Singh	22f8ded140	[2.11.0] CNI update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:33:33 -07:00
Sunil Singh	b51410aabe	[2.11.0] deprecated features update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:29:30 -07:00
Sunil Singh	c9ec3422b1	[2.11.0] CSP adapter update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:26:56 -07:00
Sunil Singh	fb653154e7	[2.11.0] webhook update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:17:56 -07:00
Sunil Singh	bfccf4adbf	[2.11.0] versions update Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-21 10:14:37 -07:00
Billy Tat	359425ec6c	Merge pull request #1704 from rancher/issue-1632 [v2.11] Policy Exemption User Note	2025-03-19 15:15:52 -07:00
Sunil Singh	844ee18464	Merge pull request #1710 from tomleb/extension-apiserver Document extension APIserver	2025-03-19 13:52:38 -07:00
Billy Tat	03e291d56c	Merge pull request #1712 from sunilarjun/v2.11-RKE1-EOL-warning [v2.11] RKE1 EOL Warning Banner	2025-03-19 13:28:41 -07:00
Tom Lebreux	5a8a96fc0a	Fix link reference	2025-03-19 16:02:08 -04:00
Billy Tat	47c4e4c093	Merge pull request #1649 from JonCrowther/aggregated-cluster-roles-feature-flag [v2.11] Add documentation for aggregated clusterroles	2025-03-19 13:00:45 -07:00
Tom Lebreux	d43f53d0fa	Document extension API server for 2.11	2025-03-19 15:14:30 -04:00
Tom Lebreux	1bf1ac8ba3	Apply feedback	2025-03-19 15:09:50 -04:00
Jonathan Crowther	d55be97e14	Added versioned docs and sidebar	2025-03-19 09:46:07 -04:00
Jonathan Crowther	81c14ffd09	Fix some wording	2025-03-19 09:41:58 -04:00
Jonathan Crowther	d0a35e1a3e	Missing quote	2025-03-19 09:41:58 -04:00
Jonathan Crowther	826ae8e86c	Add documentation for aggregated clusterroles	2025-03-19 09:41:58 -04:00
Sunil Singh	d77072be9d	Adding EOL warning message tag to relevant RKE1 pages across versions/i18n folders. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-18 15:32:05 -07:00
Sunil Singh	919ad43458	Adding partial file for RKE1 EOL warning message. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-18 15:15:58 -07:00
Sunil Singh	b93f050ea7	Merge pull request #1711 from rancher/main Syncing Main Branch into v2.11.0 Branch	2025-03-17 17:21:29 -07:00
Billy Tat	d97217c6f6	Merge pull request #1708 from btat/2.11-restricted-admin-refs Remove restricted admin references	2025-03-17 13:12:34 -07:00
Tom Lebreux	1391623ae5	Document extension APIserver	2025-03-17 13:18:11 -04:00
Sunil Singh	7fbb1248a2	Merge pull request #1699 from jiaqiluo/211-imported-cluster-version-mgmt New feature in 2.11: imported cluster version management	2025-03-14 16:56:56 -07:00
Jiaqi Luo	6916290155	new feature in 2.11: imported cluster version management	2025-03-14 16:09:53 -07:00
Billy Tat	b5c2511793	Remove restricted admin references	2025-03-13 14:34:42 -07:00
Sunil Singh	f7f3bbd5ab	Adding note to PSA template on users handling policy exemptions, tied to Rancher docs issue 1632. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-11 16:32:48 -07:00
Sunil Singh	af896b7aba	Merge pull request #1700 from sunilarjun/fix-azure-YAML Fixing Tab Indent - Azure Cloud Provider Page	2025-03-07 16:00:51 -08:00
Sunil Singh	31f1c92397	Editing step 4 tab indent as text was being included in code block incorrectly. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-07 14:43:37 -08:00
Billy Tat	2d34a1e59f	Merge pull request #1593 from rohitsakala/remove-experimental-flag-for-oci-feature Remove experimental banner for OCI	2025-03-06 12:42:49 -08:00
Billy Tat	1edd657336	Merge pull request #1698 from rancher/main Sync changes from main to v2.11.0	2025-03-06 12:40:16 -08:00
Billy Tat	edbc6eb35e	Apply `dc05dfb5` (Remove experimental banner for OCI) to version-2.11	2025-03-06 11:38:11 -08:00
Venkata Krishna Rohit Sakala	dc05dfb53f	Remove experimental banner for OCI	2025-03-06 11:37:04 -08:00
Billy Tat	0156c64962	Merge pull request #1697 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-f288d28 Bump .github/styles/suse-vale-styleguide from `a0d8a04` to `f288d28`	2025-03-06 09:43:43 -08:00
dependabot[bot]	c48166e40d	Bump .github/styles/suse-vale-styleguide from `a0d8a04` to `f288d28` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `a0d8a04` to `f288d28`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/a0d8a04abd0679fb7208b76bda95aee9caf884ca...f288d286db3b7c65e02cb6635d0c048f0f7a88fa) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2025-03-06 16:37:53 +00:00
Billy Tat	17e4d800bf	Merge pull request #1694 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-a0d8a04 Bump .github/styles/suse-vale-styleguide from `1d1d8c5` to `a0d8a04`	2025-03-05 14:34:14 -08:00
Billy Tat	35a2186904	Merge pull request #1696 from diogoasouza/fix-broken-link fix broken link to rancher forums	2025-03-05 14:33:57 -08:00
Diogo Souza	e5beb733e3	fix broken link to rancher forums	2025-03-05 18:47:45 -03:00
Billy Tat	71f2167a3f	Merge pull request #1695 from LucasSaintarbor/add-note-adding-users-to-clusters Sync PR #157 from Product docs	2025-03-05 13:46:38 -08:00
LucasSaintarbor	3901b2a9d9	Add note about cluster membership limitations to intro	2025-03-05 12:59:26 -08:00
dependabot[bot]	cf7dfbcd78	Bump .github/styles/suse-vale-styleguide from `1d1d8c5` to `a0d8a04` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `1d1d8c5` to `a0d8a04`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/1d1d8c53eeb4117bf024df38d6ee24f140b74e01...a0d8a04abd0679fb7208b76bda95aee9caf884ca) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2025-03-05 17:12:37 +00:00
Sunil Singh	b3d1e0176a	Merge pull request #1692 from rancher/revert-1653-main Revert "docs: add auth-user-session-idle-ttl-minutes setting"	2025-03-04 10:10:13 -08:00
Billy Tat	e2bba9b3e1	Merge pull request #1691 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-1d1d8c5 Bump .github/styles/suse-vale-styleguide from `4a53783` to `1d1d8c5`	2025-03-04 09:41:56 -08:00
Billy Tat	f0fbf6609e	Merge pull request #1687 from btat/fix-links-archived-docs Fix broken links	2025-03-04 09:41:25 -08:00
Sunil Singh	d946eb97c5	Revert "docs: add auth-user-session-idle-ttl-minutes setting" This reverts commit `0d84fe35ac`.	2025-03-04 09:05:49 -08:00
Sunil Singh	94763d89fd	Revert "Update docs/api/api-tokens.md" This reverts commit `d4a7f7023a`.	2025-03-04 09:05:49 -08:00
Sunil Singh	4cc1d07215	Revert "update versioned_docs" This reverts commit `16fa2b39ae`.	2025-03-04 09:05:49 -08:00
dependabot[bot]	e5153269f6	Bump .github/styles/suse-vale-styleguide from `4a53783` to `1d1d8c5` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `4a53783` to `1d1d8c5`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/4a53783d19350e32e7c7a2afef78c9e2d24c0287...1d1d8c53eeb4117bf024df38d6ee24f140b74e01) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2025-03-04 16:43:03 +00:00
Sunil Singh	480418ff93	Merge pull request #1635 from sunilarjun/issue-1611 Update Authentication Configuration Page - Local Rancher Admin Note	2025-03-03 16:17:05 -08:00
Billy Tat	9280cb7902	Merge pull request #1545 from kinarashah/azdocs2 update correct location for azure's cloud controller manager manifest	2025-03-03 15:12:50 -08:00
Billy Tat	2eb6c8b388	Apply `5d982da5` (update correct location for azure's cloud controller manager manifest) plus formatting fixes to other versions Also sync outdated zh page	2025-03-03 14:03:21 -08:00
Billy Tat	06b70dfb46	Merge branch 'main' into azdocs2	2025-03-03 13:32:41 -08:00
Billy Tat	b00f9baf7e	Merge pull request #1688 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-4a53783 Bump .github/styles/suse-vale-styleguide from `e83b279` to `4a53783`	2025-03-03 13:17:57 -08:00
Sunil Singh	0d34121f0a	Rebased and added update to v2.11 docs. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-03 10:48:38 -08:00
Sunil Singh	fd4f97a1cd	Updating after review. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-03 10:40:12 -08:00
Sunil Singh	116d1daa3d	Updating note entry on authentication config page to include information regarding external authentication configuration and the resource access scope of the relative local Rancher admin user. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-03-03 10:40:06 -08:00
dependabot[bot]	59a5b3e27e	Bump .github/styles/suse-vale-styleguide from `e83b279` to `4a53783` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `e83b279` to `4a53783`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/e83b27903567c8cc69fc6a73617b05b0f7603000...4a53783d19350e32e7c7a2afef78c9e2d24c0287) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2025-03-03 16:15:41 +00:00
Sunil Singh	7f2a75afb4	Merge pull request #1686 from sunilarjun/update-preview-unreleased Update Docs Preview Naming	2025-02-28 16:46:56 -08:00
Billy Tat	b4b98a1e10	Fix broken links	2025-02-28 16:10:35 -08:00
Sunil Singh	a36fc63f6e	Update naming from (Preview) to (Unreleased) for docs preview versions. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-02-28 16:00:08 -08:00
Billy Tat	7c7b8bd70e	Merge pull request #1684 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-e83b279 Bump .github/styles/suse-vale-styleguide from `419bd8a` to `e83b279`	2025-02-28 09:21:05 -08:00
dependabot[bot]	53be000d06	Bump .github/styles/suse-vale-styleguide from `419bd8a` to `e83b279` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `419bd8a` to `e83b279`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/419bd8a09a06aefdc13142cd5c7794d190e64218...e83b27903567c8cc69fc6a73617b05b0f7603000) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2025-02-28 16:25:44 +00:00
Alessio Greggi	16fa2b39ae	update versioned_docs Signed-off-by: Alessio Greggi <alessio.greggi@suse.com>	2025-02-26 17:18:16 +01:00
Alessio GreggiandEnrico Candino	d4a7f7023a	Update docs/api/api-tokens.md Co-authored-by: Enrico Candino <enrico.candino@gmail.com>	2025-02-26 17:18:16 +01:00
Alessio Greggi	0d84fe35ac	docs: add auth-user-session-idle-ttl-minutes setting Signed-off-by: Alessio Greggi <alessio.greggi@suse.com>	2025-02-26 17:18:16 +01:00
Diogo SouzaandLucasSaintarbor	b457c9eb68	adding rancher-istio deprecation notice (#1627 ) * adding rancher-istio deprecation notice * Rebased / Added changes to v2.11 directory --------- Co-authored-by: LucasSaintarbor <lucas.saintarbor@suse.com>	2025-02-19 11:37:20 -08:00
Kinara Shah	5d982da52a	update correct location for azure's cloud controller manager manifest remove unnecessary objects from manifest	2024-11-11 23:49:35 -08:00