Rancher Release Notes

Release v2.15.1

Important

If you are using Active Directory Federation Service (AD FS), upgrading to Rancher v2.10.1 or later may cause issues with authentication, requiring manual intervention. These issues are due to the AD FS Relying Party Trust not being able to pick up a signature verification certificate from the metadata. For more information, see #48655. These issues can be corrected by either of two methods:

Updating the Relying Party Trust information from federation metadata (Relying Party Trust → Update from Federation Metadata…​).

Directly adding the certificate (Relying Party Trust → Properties → Signature tab → Add → Select the certificate).

Rancher v2.15.1 is the latest patch release of Rancher. This is a Community version release that introduces maintenance updates and bug fixes.

For more information on new features in the general minor release, see the v2.15.0 release notes.

Security Fixes for Vulnerabilities

This release addresses the following security issues:

Rancher

Fixed a security vulnerability in Rancher's SAML authentication handler where the assertion replay protection was ineffective in high-availability (multi-replica) deployments. Because each replica tracked consumed assertion IDs in a separate in-memory cache, a captured SAML assertion could be replayed against other replicas to create additional authenticated sessions as the victim. The fix tracks consumed assertion IDs across all replicas. All SAML providers were affected. For more information, refer to CVE-2026-75034.

Fixes a security vulnerability in the Rancher project-scoped secretsController where Project Secrets propagate to namespaces based only on the field.cattle.io/projectId annotation without validating that the referenced project belongs to the same cluster. An authenticated user with namespace creation permissions on one downstream cluster could spoof this annotation to leak Project Secrets from an unauthorized project in a different cluster. The controller now validates that the annotation references a project within the same cluster before propagating secrets. For more information, see CVE-2026-75033.

Fixed a security vulnerability in the Rancher imperative ext Token API (ext.cattle.io/v1 tokens) where any authenticated user can list and watch other users' tokens by supplying a crafted label selector, disclosing token metadata and the stored bearer token hash. The store now enforces per-user scoping unconditionally so callers see only their own tokens, and read responses no longer return the stored token hash. For more information, see CVE-2026-75035.

Fixed a security vulnerability in Rancher's GlobalRole controller where a user with delegated create or update permissions for GlobalRole resources could set the authz.management.cattle.io/cr-name annotation to target an arbitrary existing ClusterRole (such as the built-in cluster-admin). The controller then overwrites the rules without an ownership check, stripping permissions from all bound principals and causing a persistent, cluster-wide RBAC lockout on the local management cluster. For more information, refer to CVE-2026-71404.

Fixed a security vulnerability in the SUSE Rancher Norman /v3/users API where the update path did not enforce immutability of the username, principalIds, and displayName fields on a User resource. A caller holding update permissions on users could rebind a user's external principal identity, enabling account takeover during the next external login or creating a denial-of-service condition that left existing role bindings inaccessible. The API store and admission-webhook layers were updated to reject post-creation changes to these identity fields. For more information, see CVE-2026-71403.

Fleet

Fixed a security vulnerability in Fleet's Helm template preprocessing where templates evaluated by the Fleet controller could reach network resources. A user who can supply untrusted bundle content can expose cluster metadata and information about hosts reachable from the controller. Fleet now rejects bundles whose Helm template values require network access, reporting an error for the corresponding GitRepo. For more information, refer to CVE-2026-75036.

K3s and RKE2 Provisioning

Known Issues

A known issue exists related to CAPI infrastructure providers within Rancher’s V2 provisioning framework. Creating or editing v2prov clusters with native infrastructure providers (such as CAPA or CAPV) from the UI can under some failure conditions leave unused, orphaned infrastructure resources (e.g., AWSMachineTemplate or AWSCluster) in the management cluster which need to be cleaned up manually. See #55752.

Changes Since v2.15.0

See the full list of changes.

Install/Upgrade Notes

If you’re installing Rancher for the first time, your environment must fulfill the installation requirements.

Important

Rancher now requires the cluster it runs on to have the Kubernetes API Aggregation Layer enabled. This is because Rancher extends Kubernetes with additional APIs by registering its own extension API server. Please note that all versions of Kubernetes supported in this Rancher versions K8s distributions (RKE2/K3s) will have the aggregation layer configured and enabled by default.

Refer to the Extension API Server documentation and #50400 for more information.

Rancher Kubernetes Engine (RKE/RKE1) has reached end of life as of July 31, 2025. Rancher versions 2.12.0 and later no longer support provisioning or managing downstream RKE1 clusters. We recommend replatforming RKE1 clusters to RKE2 to ensure continued support and security updates. Learn more about the transition here.

Rancher now has a pre-upgrade validation check for RKE1 resources which fails and lists the RKE1 resources if present. Refer to #50286 for more information.

It is crucial that you review the available disk space on your nodes and plan accordingly before upgrading to Rancher v2.12.0 and later to avoid potential disk pressure and pod eviction issues.

For additional information, refer to the UI Server Side Pagination - Disk Space documentation.

Rancher now has an enablement option called AUDIT_LOG_ENABLED for API Audit Logs for a Rancher installation.

In Rancher versions 2.11.x and earlier, only the AUDIT_LEVEL could be set and the default log level (0) would disable the audit log. In Rancher versions 2.12.x and later, the default log level (0) now only contains the log request and response metadata, and can be set when configuring AUDIT_LOG_ENABLED. If installing or upgrading via Helm you can enable the API Audit Logs and specify the log level by applying the following setting to your Helm command: --set auditLog.enabled=true --set auditLog.level=0. See the Enabling the API Audit Log to Record System Events documentation and #48941.

Changes in Image Artifacts

Image artifact digests are renamed in Rancher v2.12.0, v2.11.4 and v2.10.8. Up until this change, separate image digests files for each operating system and architecture have been maintained for compatibility reasons. With this change, only one file for each operating system is to be provided:

• The rancher-images-digests-linux-amd64.txt and rancher-images-digests-linux-arm64.txt files are to be renamed to rancher-images-digests-linux.txt.
• The rancher-images-digests-windows-ltsc2019.txt and rancher-images-digests-windows-ltsc2022.txt files are to be renamed to rancher-images-digests-windows.txt.

Upgrade Requirements

Creating backups: Create a backup before you upgrade Rancher. To roll back Rancher after an upgrade, you must first back up and restore Rancher to the previous Rancher version. Because Rancher will be restored to the same state as when the backup was created, any changes post-upgrade will not be included after the restore.

Helm version requirements:

To manage Rancher 2.12.x and later, you must upgrade your Helm client to version 3.18 or newer.

This change is required to reflect the addition of Kubernetes 1.33 support with this release.

Currently, the official Helm Version Support Policy dictates that only Helm 3.18 supports the proper Kubernetes version range for Rancher 2.12.

CNI requirements:

For Kubernetes v1.19 and later, disable firewalld as it’s incompatible with various CNI plugins. See #28840.

When upgrading or installing a Linux distribution that uses nf_tables as the backend packet filter, such as SLES 15, RHEL 8, Ubuntu 20.10, Debian 10, or later, upgrade to RKE v1.19.2 or later to get Flannel v0.13.0. Flannel v0.13.0 supports nf_tables. See Flannel #1317.

Requirements for air-gapped environments:

When using a proxy in front of an air-gapped Rancher instance, you must pass additional parameters to NO_PROXY. See the documentation and issue #2725.

When installing Rancher with Docker in an air-gapped environment, you must supply a custom registries.yaml file to the docker run command, as shown in the K3s documentation. If the registry has certificates, then you’ll also need to supply those. See #28969.

Versions

Images

rancher/rancher:v2.15.1

Tools

CLI - v2.15.1

Kubernetes Versions for RKE2/K3s

v1.36.3 (Default)

v1.35.7

v1.34.10

Rancher Helm Chart Versions

In Rancher v2.6.0 and later, in the Apps & Marketplace UI, many Rancher Helm charts are named with a major version that starts with 100. This avoids simultaneous upstream changes and Rancher changes from causing conflicting version increments. This also complies with semantic versioning (SemVer), which is a requirement for Helm. You can see the upstream version number of a chart in the build metadata, for example: 100.0.0+up2.1.0. See #32294.

Previous Rancher Behavior Changes

Previous Rancher Behavior Changes - Rancher General

Rancher v2.15.0:

Rancher v2.15 removes support for Kubernetes v1.33. See #55306.

Previous Rancher Behavior Changes Changes - Rancher App (Global UI)

Rancher v2.15.0:

The option to disable the feature flag ui-sql-cache / Vai / Server-Side Pagination (SSP) in the Rancher UI has been removed in preparation for Rancher v2.16, where the feature will always be enabled. See #16822.

Removal: Support for Ember-based UI plugins for cluster and node drivers (deprecated since Rancher v2.11.0) is removed in Rancher v2.15.0. Migrate your plugins to the UI Extensions Framework. For details, see #14005.

Previous Rancher Behavior Changes - K3s and RKE2 Provision

Rancher v2.15.0:

By default, the Standard User and Create Clusters global permissions now allow creating and then updating CAPI infrastructure objects in the fleet-default namespace. Note that manually created infrastructure provider identity objects, such as AWSClusterStaticIdentity or VSphereClusterIdentity, that target the fleet-default namespace can be used through CAPI infrastructure objects such as AWSCluster or VsphereCluster. See #53777.

When using native CAPI infrastructure providers with v2prov, Rancher will now generate the bootstrap cloud-config in the Jinja format. User-data for regular node drivers with v2prov is unaffected. See #53777.

Previous Rancher Behavior Changes - Continuous Delivery (Fleet)

Rancher v2.15.0:

Deprecation: Fleet will be removing support for GitRepoRestriction in a future release, making the use of the Policy resource for configuring multi-tenant environments the only option. See #55652.

Deprecation: Fleet support for unauthenticated webhook calls will be removed in a future release, making the setup of a webhook secret the only option. See #55633.

Long-standing Known Issues

Long-standing Known Issues - Rancher General

Rancher v2.15.0:

A known issue exists with Rancher v2.15.0 and Kubernetes v1.36 clusters where Rancher Backups is not listed under the Cluster Tools due to a Backups chart issue. See #1055.

Long-standing Known Issues - Cluster Provisioning

Not all cluster tools can be installed on a hardened cluster.

Rancher v2.8.1:

When you attempt to register a new etcd/controlplane node in a CAPR-managed cluster after a failed etcd snapshot restoration, the node can become stuck in a perpetual paused state, displaying the error message [ERROR] 000 received while downloading Rancher connection information. Sleeping for 5 seconds and trying again. As a workaround, you can unpause the cluster by running kubectl edit clusters.cluster clustername -n fleet-default and set spec.unpaused to false. See #43735.

Long-standing Known Issues - RKE2 Provisioning

Rancher v2.7.7:

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.

Rancher v2.7.6:

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Long-standing Known Issues - K3s Provisioning

Rancher v2.7.6:

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Rancher v2.7.2:

Clusters remain in an Updating state even when they contain nodes in an Error state. See #39164.

Long-standing Known Issues - Rancher App (Global UI)

Rancher v2.10.0:

After deleting a Namespace or Project in the Rancher UI, the Namespace or Project remains visible. As a workaround, refresh the page. See #12220.

Rancher v2.9.2:

Although system mode node pools must have at least one node, the Rancher UI allows a minimum node count of zero. Inputting a zero minimum node count through the UI can cause cluster creation to fail due to an invalid parameter error. To prevent this error from occurring, enter a minimum node count at least equal to the node count. See #11922.

Rancher v2.7.7:

When creating a cluster in the Rancher UI it does not allow the use of an underscore _ in the Cluster Name field. See #9416.

Rancher v2.6.4:

Deployment securityContext section is missing when a new workload is created. This prevents pods from starting when Pod Security Policy Support is enabled. See #4815.

Long-standing Known Issues - EKS

Rancher v2.7.0:

EKS clusters on Kubernetes v1.21 or below on Rancher v2.7 cannot be upgraded. See #39392.

Long-standing Known Issues - Authentication

Rancher v2.9.0:

There are some known issues with the OpenID Connect provider support:

When the generic OIDC auth provider is enabled, and you attempt to add auth provider users to a cluster or project, users are not populated in the dropdown search bar. This is expected behavior as the OIDC auth provider alone is not searchable. See #46104.

When the generic OIDC auth provider is enabled, auth provider users that are added to a cluster/project by their username are not able to access resources upon logging in. A user will only have access to resources upon login if the user is added by their userID. See #46105.

When the generic OIDC auth provider is enabled and an auth provider user in a nested group is logged into Rancher, the user will see the following error when they attempt to create a Project: projectroletemplatebindings.management.cattle.io is forbidden: User "u-gcxatwsnku" cannot create resource "projectroletemplatebindings" in API group "management.cattle.io" in the namespace "p-9t5pg". However, the project is still created. See #46106.

Long-standing Known Issues - Rancher Webhook

Rancher v2.7.2:

A webhook is installed in all downstream clusters. There are several issues that users may encounter with this functionality:

If you rollback from a version of Rancher v2.7.2 or later, to a Rancher version earlier than v2.7.2, the webhooks will remain in downstream clusters. Since the webhook is designed to be 1:1 compatible with specific versions of Rancher, this can cause unexpected behaviors to occur downstream. The Rancher team has developed a script which should be used after rollback is complete (meaning after a Rancher version earlier than v2.7.2 is running). This removes the webhook from affected downstream clusters. See #40816.

Long-standing Known Issues - Virtualization Management (Harvester)

Rancher v2.13.1:

When upgrading to Rancher v2.13.1 or higher while using Harvester v1.6.1, users may encounter an issue with their Load Balancers in downstream clusters using the Harvester Cloud Provider, and must perform the following workaround to instruct Calico to not use any of the IP/interface managed by kube-vip. See #9767.

Rancher v2.7.2:

If you’re using Rancher v2.7.2 with Harvester v1.1.1 clusters, you won’t be able to select the Harvester cloud provider when deploying or updating guest clusters. The Harvester release notes contain instructions on how to resolve this. See #3750.

Long-standing Known Issues - Backup/Restore

When migrating to a cluster with the Rancher Backup feature, the server-url cannot be changed to a different location. It must continue to use the same URL.

Rancher v2.13.0:

When performing a rollback from Rancher v2.13.0 to v2.12.3 using the backup and restore operator (BRO), the restore does not complete successfully. See #844. To work around this issue, you must scale down your Rancher deployment and uninstall the Webhook chart before performing the restore. For details, refer to this Knowledge Base article.

Rancher v2.7.7:

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.

Original source

Images with -rc

rancher/rancher-agent:v2.15.1-rc2

rancher/rancher:v2.15.1-rc2

Components with -rc

DASHBOARD_UI_VERSION v2.15.1-rc1

Min version components with -rc

Chart/KDM sources

CHART_DEFAULT_BRANCH: release-v2.15 (scripts/package-env)

CHART_DEFAULT_BRANCH: release-v2.15 (package/Dockerfile)

CATTLE_KDM_BRANCH: release-v2.15 (package/Dockerfile)

CATTLE_KDM_BRANCH: release-v2.15 (Dockerfile.runtime)

KDMBranch: release-v2.15 (pkg/settings/setting.go)

ChartDefaultBranch: release-v2.15 (pkg/settings/setting.go)

Original source

Images with -rc

rancher/prometheus-federator:v7.0.1-rc.1
rancher/rancher-agent:v2.15.1-rc1
rancher/rancher:v2.15.1-rc1

Components with -rc

Min version components with -rc

Chart/KDM sources

CHART_DEFAULT_BRANCH: dev-v2.15 (scripts/package-env)
CHART_DEFAULT_BRANCH: dev-v2.15 (package/Dockerfile)
CATTLE_KDM_BRANCH: release-v2.15 (package/Dockerfile)
CATTLE_KDM_BRANCH: release-v2.15 (Dockerfile.runtime)
KDMBranch: release-v2.15 (pkg/settings/setting.go)
ChartDefaultBranch: dev-v2.15 (pkg/settings/setting.go)

Original source

Images with -rc

rancher/rancher-agent:v2.15.1-alpha1

rancher/rancher-webhook:v0.11.1-rc.1

rancher/rancher:v2.15.1-alpha1

Components with -rc

ALI-OPERATOR v1.15.0-rc.3

WRANGLER

Min version components with -rc

Chart/KDM sources

CHART_DEFAULT_BRANCH: dev-v2.15 (scripts/package-env)

CHART_DEFAULT_BRANCH: dev-v2.15 (package/Dockerfile)

CATTLE_KDM_BRANCH: dev-v2.15 (package/Dockerfile)

CATTLE_KDM_BRANCH: dev-v2.15 (Dockerfile.runtime)

KDMBranch: dev-v2.15 (pkg/settings/setting.go)

ChartDefaultBranch: dev-v2.15 (pkg/settings/setting.go)

Original source

Release v2.15.0

Important

If you are using Active Directory Federation Service (AD FS), upgrading to Rancher v2.10.1 or later may cause issues with authentication, requiring manual intervention. These issues are due to the AD FS Relying Party Trust not being able to pick up a signature verification certificate from the metadata. For more information, see #48655. These issues can be corrected by either of two methods:

Updating the Relying Party Trust information from federation metadata (Relying Party Trust → Update from Federation Metadata…​).

Directly adding the certificate (Relying Party Trust → Properties → Signature tab → Add → Select the certificate).

Rancher v2.15.0 is the latest minor release of Rancher. This is a Community version release that introduces new features, enhancements, and various updates.

What's New - v2.15.0

Kubernetes Support and Lifecycle Updates

Rancher v2.15 adds support for Kubernetes v1.36 while removing support for Kubernetes v1.33.

Rancher App Chart Retention Policy: Enforces a new lifecycle policy preserving chart versions in the "Rancher" repository for the 7 most recent minor releases (approx. 2.5 years). Older chart versions have been removed.

Cluster Provisioning

Cluster API (CAPI) GA: Support for native CAPI infrastructure providers within the V2 provisioning framework (v2prov) has been promoted to General Availability (GA).

Updated CAPI support to v1.13.2.

Authentication

Inherited Namespace Rules for GlobalRoles: Administrators can now define inheritedNamespacedRules in GlobalRoles to automatically propagate specific namespace RBAC permissions across all downstream clusters.

Azure AD SSO Logout: Added support for Single Logout (SLO) with Azure AD, allowing users to terminate their Azure AD session directly upon logging out of Rancher, with support for custom sovereign-cloud endpoints.

Hide Local Auth Provider: Introduced a new hide-local-auth-provider feature flag to restrict local UI authentication once an External Authentication Provider (EAP) is configured.

Dashboard

Workloads Overview UI: Replaces the legacy all-in-one Workloads list in the Rancher Dashboard with a high-performance Workloads Overview UI view designed for large-scale environments.

Rancher General

Features and Enhancements

Rancher now supports Kubernetes v1.36. See #54303 for information on Rancher support for Kubernetes v1.36. You can view the upstream Kubernetes changelog for v1.36 for a complete list of changes.

Added a cap on the maximum number of public endpoint annotations (field.cattle.io/publicEndpoints) written for Ingress objects. This prevents workloads with extensive custom domain lists from exceeding Kubernetes’ 256 KB metadata annotation size limit and triggering API validation errors. See #42058.

Optimized rancher-images.txt to include only the latest patch release per Kubernetes minor version compatible with the target Rancher release. Release Candidate (RC) pre-releases and superseded patch/minor versions are now filtered out, significantly reducing the size of air-gapped image tarballs while ensuring system-agent-installer and auxiliary images remain fully up to date. See #46174.

Behavior Changes

Rancher v2.15 removes support for Kubernetes v1.33. See #55306.

Retention Policy for Rancher App Charts

To improve repository performance, Rancher is introducing a lifecycle management policy for charts available in the Apps feature of Rancher, specifically in the "Rancher" repository.

The Policy: Rancher will transition from a cumulative model (retaining all historical versions forever) to a retention model that preserves chart versions for the seven (7) most recent Rancher minor releases (approximately a 2.5-year window).

Timeline - Rancher v2.13 & v2.14: Legacy chart versions (older than the 7-version window) remain available.

Rancher v2.15: This release is the first version to enforce the policy. Versions falling outside the 7-version window and older than two years will no longer be available.

Impact: This change is non-destructive for existing Rancher installations. Historical versions will remain accessible but will not be available in newer release branches once they age out of the 7-version window. You are advised to upgrade your applications before upgrading to Rancher v2.15. Uninstallation after v2.15 and replacement with an updated version will still be possible.

Major Bug Fixes

Fixed an issue where rancher-save-images.sh failed to pull OCI-based Helm charts when the local Docker daemon was configured to use the overlay2 storage driver. See #55068.

Rancher App (Global UI)

Features and Enhancements

The Rancher Dashboard replaces the legacy all-in-one Workloads list with a new Workloads Overview UI view to solve major performance and scalability issues when viewing workload resources. See #11513.

Behavior Changes

The option to disable the feature flag ui-sql-cache / Vai / Server-Side Pagination (SSP) in the Rancher UI has been removed in preparation for Rancher v2.16, where the feature will always be enabled. See #16822.

Removal: Support for Ember-based UI plugins for cluster and node drivers (deprecated since Rancher v2.11.0) is removed in Rancher v2.15.0. Migrate your plugins to the UI Extensions Framework. For details, see #14005.

Major Bug Fixes

Fixed an issue where selecting Enable Dual-Stack with Stack Preference set to IPv6 omitted the required UI warning. Dual-stack clusters require the Stack Preference option to be set to Dual. For details, see #16788.

Authentication

Features and Enhancements

Azure AD SSO Logout: Rancher now supports Single Logout (SLO) for the Azure AD auth provider. When enabled, logging out of Rancher also terminates the user’s Azure AD session by redirecting to Azure AD’s end-session endpoint. A LogoutEndpoint override field is available for sovereign-cloud deployments (Azure US Government, China). An optional LogoutAllForced flag can prevent users from bypassing SSO logout. See #54566.

Added the hide-local-auth-provider feature flag (disabled by default) to restrict local authentication usage once an External Authentication Provider (EAP) is active. When enabled, the flag hides the local login interface and removes the ability to create, edit, or delete local users from the UI. Note that password rotation for required administrative local accounts remains allowed to support emergency fallback workflows. See #46078.

Cluster Provisioning

Features and Enhancements

Rancher v2.15 adds support for Cluster API (CAPI) v1.13.2. See #54304.

Users with the clusters-create role can now view the CAPIprovider resource. See #55167.

K3s and RKE2 Provisioning

Features and Enhancements

General Availability: Promoted support for native Cluster API (CAPI) infrastructure providers within Rancher’s V2 provisioning framework (v2prov) from Tech Preview to General Availability (GA). See #53777.

If the CAPA infrastructure provider is installed, Rancher will mirror cloud credentials for AWS and create a corresponding AWSClusterStaticIdentity object that targets the fleet-default namespace.

Behavior Changes

By default, the Standard User and Create Clusters global permissions now allow creating and then updating CAPI infrastructure objects in the fleet-default namespace. Note that manually created infrastructure provider identity objects, such as AWSClusterStaticIdentity or VSphereClusterIdentity, that target the fleet-default namespace can be used through CAPI infrastructure objects such as AWSCluster or VsphereCluster. See #53777.

When using native CAPI infrastructure providers with v2prov, Rancher will now generate the bootstrap cloud-config in the Jinja format. User-data for regular node drivers with v2prov is unaffected. See #53777.

Known Issues

A known issue exists related to CAPI infrastructure providers within Rancher’s V2 provisioning framework. Creating or editing v2prov clusters with native infrastructure providers (such as CAPA or CAPV) from the UI can under some failure conditions leave unused, orphaned infrastructure resources (e.g., AWSMachineTemplate or AWSCluster) in the management cluster which need to be cleaned up manually. See #55752.

Continuous Delivery (Fleet)

Behavior Changes

Deprecation: Fleet will be removing support for GitRepoRestriction in a future release, making the use of the Policy resource for configuring multi-tenant environments the only option. See #55652.

Deprecation: Fleet support for unauthenticated webhook calls will be removed in a future release, making the setup of a webhook secret the only option. See #55633.

Role-Based Access Control (RBAC)

Features and Enhancements

Rancher introduces a new inheritedNamespacedRules field for GlobalRoles, allowing administrators to automatically grant users RBAC permissions to specific namespaces across all downstream clusters (for example, shared monitoring or logging namespaces). Rules defined in inheritedNamespacedRules automatically propagate to all downstream clusters managed by Rancher. If the namespace doesn’t exist on a cluster no rules are added. However, if the namespace does not exist but gets created, the controller triggers and creates the rules. Please note that these inherited rules apply exclusively to downstream clusters and do not affect the local management cluster.

Configuring inheritedNamespacedRules currently requires editing the GlobalRole YAML directly or via the API, as direct UI inputs for this specific map are not yet available. Example YAML configuration for a GlobalRole with inheritedNamespacedRules:

apiVersion: management.cattle.io/v3
kind: GlobalRole
metadata:
namespace: default
name: test-gr-1
rules:
- apiGroups:
- catalog.cattle.io
resources:
- apps
verbs:
- create
inheritedNamespacedRules:
shared-namespace:
- apiGroups:
- catalog.cattle.io
resources:
- apps
verbs:
- edit

See #50663 for more information.

Virtualization Management (Harvester)

Features and Enhancements

This release adds support for the harvester-baremetal-container-workload feature flag, disabled by default, within Rancher’s Fleet continuous delivery targeting mechanism. When enabled, the UI stops filtering out Harvester clusters, allowing Fleet bundles and applications to target and deploy container workloads directly to them. After enabling the harvester-baremetal-container-workload feature flag, please validate existing Fleet Bundles to ensure they now select, or don’t select, the required clusters. When disabled, the UI maintains the default behavior and excludes Harvester clusters from Fleet targets. See #12518.

Install/Upgrade Notes

If you’re installing Rancher for the first time, your environment must fulfill the installation requirements.

Important

Rancher now requires the cluster it runs on to have the Kubernetes API Aggregation Layer enabled. This is because Rancher extends Kubernetes with additional APIs by registering its own extension API server. Please note that all versions of Kubernetes supported in this Rancher versions K8s distributions (RKE2/K3s) will have the aggregation layer configured and enabled by default.

Refer to the Extension API Server documentation and #50400 for more information.

Rancher Kubernetes Engine (RKE/RKE1) has reached end of life as of July 31, 2025. Rancher versions 2.12.0 and later no longer support provisioning or managing downstream RKE1 clusters. We recommend replatforming RKE1 clusters to RKE2 to ensure continued support and security updates. Learn more about the transition here.

Rancher now has a pre-upgrade validation check for RKE1 resources which fails and lists the RKE1 resources if present. Refer to #50286 for more information.

It is crucial that you review the available disk space on your nodes and plan accordingly before upgrading to Rancher v2.12.0 and later to avoid potential disk pressure and pod eviction issues.

For additional information, refer to the UI Server Side Pagination - Disk Space documentation.

Rancher now has an enablement option called AUDIT_LOG_ENABLED for API Audit Logs for a Rancher installation.

In Rancher versions 2.11.x and earlier, only the AUDIT_LEVEL could be set and the default log level (0) would disable the audit log. In Rancher versions 2.12.x and later, the default log level (0) now only contains the log request and response metadata, and can be set when configuring AUDIT_LOG_ENABLED. If installing or upgrading via Helm you can enable the API Audit Logs and specify the log level by applying the following setting to your Helm command: --set auditLog.enabled=true --set auditLog.level=0. See the Enabling the API Audit Log to Record System Events documentation and #48941.

Changes in Image Artifacts

Image artifact digests are renamed in Rancher v2.12.0, v2.11.4 and v2.10.8. Up until this change, separate image digests files for each operating system and architecture have been maintained for compatibility reasons. With this change, only one file for each operating system is to be provided:

The rancher-images-digests-linux-amd64.txt and rancher-images-digests-linux-arm64.txt files are to be renamed to rancher-images-digests-linux.txt.

The rancher-images-digests-windows-ltsc2019.txt and rancher-images-digests-windows-ltsc2022.txt files are to be renamed to rancher-images-digests-windows.txt.

Upgrade Requirements

Creating backups: Create a backup before you upgrade Rancher. To roll back Rancher after an upgrade, you must first back up and restore Rancher to the previous Rancher version. Because Rancher will be restored to the same state as when the backup was created, any changes post-upgrade will not be included after the restore.

Helm version requirements:

To manage Rancher 2.12.x and later, you must upgrade your Helm client to version 3.18 or newer.

This change is required to reflect the addition of Kubernetes 1.33 support with this release.

Currently, the official Helm Version Support Policy dictates that only Helm 3.18 supports the proper Kubernetes version range for Rancher 2.12.

CNI requirements:

For Kubernetes v1.19 and later, disable firewalld as it’s incompatible with various CNI plugins. See #28840.

When upgrading or installing a Linux distribution that uses nf_tables as the backend packet filter, such as SLES 15, RHEL 8, Ubuntu 20.10, Debian 10, or later, upgrade to RKE v1.19.2 or later to get Flannel v0.13.0. Flannel v0.13.0 supports nf_tables. See Flannel #1317.

Requirements for air-gapped environments:

When using a proxy in front of an air-gapped Rancher instance, you must pass additional parameters to NO_PROXY. See the documentation and issue #2725.

When installing Rancher with Docker in an air-gapped environment, you must supply a custom registries.yaml file to the docker run command, as shown in the K3s documentation. If the registry has certificates, then you’ll also need to supply those. See #28969.

Versions

Images

rancher/rancher:v2.15.0

Tools

CLI - v2.15.0

Kubernetes Versions for RKE2/K3s

v1.36.3 (Default)

v1.35.7

v1.34.9

Rancher Helm Chart Versions

In Rancher v2.6.0 and later, in the Apps & Marketplace UI, many Rancher Helm charts are named with a major version that starts with 100. This avoids simultaneous upstream changes and Rancher changes from causing conflicting version increments. This also complies with semantic versioning (SemVer), which is a requirement for Helm. You can see the upstream version number of a chart in the build metadata, for example: 100.0.0+up2.1.0. See #32294.

Long-standing Known Issues

Long-standing Known Issues - Cluster Provisioning

Not all cluster tools can be installed on a hardened cluster.

Rancher v2.8.1:

When you attempt to register a new etcd/controlplane node in a CAPR-managed cluster after a failed etcd snapshot restoration, the node can become stuck in a perpetual paused state, displaying the error message [ERROR] 000 received while downloading Rancher connection information. Sleeping for 5 seconds and trying again. As a workaround, you can unpause the cluster by running kubectl edit clusters.cluster clustername -n fleet-default and set spec.unpaused to false. See #43735.

Long-standing Known Issues - RKE2 Provisioning

Rancher v2.7.7:

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.

Rancher v2.7.6:

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Long-standing Known Issues - K3s Provisioning

Rancher v2.7.6:

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Rancher v2.7.2:

Clusters remain in an Updating state even when they contain nodes in an Error state. See #39164.

Long-standing Known Issues - Rancher App (Global UI)

Rancher v2.10.0:

After deleting a Namespace or Project in the Rancher UI, the Namespace or Project remains visible. As a workaround, refresh the page. See #12220.

Rancher v2.9.2:

Although system mode node pools must have at least one node, the Rancher UI allows a minimum node count of zero. Inputting a zero minimum node count through the UI can cause cluster creation to fail due to an invalid parameter error. To prevent this error from occurring, enter a minimum node count at least equal to the node count. See #11922.

Rancher v2.7.7:

When creating a cluster in the Rancher UI it does not allow the use of an underscore _ in the Cluster Name field. See #9416.

Rancher v2.6.4:

Deployment securityContext section is missing when a new workload is created. This prevents pods from starting when Pod Security Policy Support is enabled. See #4815.

Long-standing Known Issues - EKS

Rancher v2.7.0:

EKS clusters on Kubernetes v1.21 or below on Rancher v2.7 cannot be upgraded. See #39392.

Long-standing Known Issues - Authentication

Rancher v2.9.0:

There are some known issues with the OpenID Connect provider support:

When the generic OIDC auth provider is enabled, and you attempt to add auth provider users to a cluster or project, users are not populated in the dropdown search bar. This is expected behavior as the OIDC auth provider alone is not searchable. See #46104.

When the generic OIDC auth provider is enabled, auth provider users that are added to a cluster/project by their username are not able to access resources upon logging in. A user will only have access to resources upon login if the user is added by their userID. See #46105.

When the generic OIDC auth provider is enabled and an auth provider user in a nested group is logged into Rancher, the user will see the following error when they attempt to create a Project: projectroletemplatebindings.management.cattle.io is forbidden: User "u-gcxatwsnku" cannot create resource "projectroletemplatebindings" in API group "management.cattle.io" in the namespace "p-9t5pg". However, the project is still created. See #46106.

Long-standing Known Issues - Rancher Webhook

Rancher v2.7.2:

A webhook is installed in all downstream clusters. There are several issues that users may encounter with this functionality:

If you rollback from a version of Rancher v2.7.2 or later, to a Rancher version earlier than v2.7.2, the webhooks will remain in downstream clusters. Since the webhook is designed to be 1:1 compatible with specific versions of Rancher, this can cause unexpected behaviors to occur downstream. The Rancher team has developed a script which should be used after rollback is complete (meaning after a Rancher version earlier than v2.7.2 is running). This removes the webhook from affected downstream clusters. See #40816.

Long-standing Known Issues - Virtualization Management (Harvester)

Rancher v2.13.1:

When upgrading to Rancher v2.13.1 or higher while using Harvester v1.6.1, users may encounter an issue with their Load Balancers in downstream clusters using the Harvester Cloud Provider, and must perform the following workaround to instruct Calico to not use any of the IP/interface managed by kube-vip. See #9767.

Rancher v2.7.2:

If you’re using Rancher v2.7.2 with Harvester v1.1.1 clusters, you won’t be able to select the Harvester cloud provider when deploying or updating guest clusters. The Harvester release notes contain instructions on how to resolve this. See #3750.

Long-standing Known Issues - Backup/Restore

When migrating to a cluster with the Rancher Backup feature, the server-url cannot be changed to a different location. It must continue to use the same URL.

Rancher v2.13.0:

When performing a rollback from Rancher v2.13.0 to v2.12.3 using the backup and restore operator (BRO), the restore does not complete successfully. See #844. To work around this issue, you must scale down your Rancher deployment and uninstall the Webhook chart before performing the restore. For details, refer to this Knowledge Base article.

Rancher v2.7.7:

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.

Original source

[v2.14] tighten CN filtering on tls-rancher-internal to reject non-IP…

… CNs (#56309)

• tls: tighten CN filtering on tls-rancher-internal to reject non-IP CNs

Backport of a889302 from release/v2.15 work to release/v2.14, adapted to this branch's pkg/tls/podips.go (the Service-allowlist refactor into cnfilter.go/serviceIPTracker landed after this branch's fork point, so this backport only touches the pod-IP filter that exists here).

filterExistingCN previously passed through any non-IP CN unconditionally, reasoning that hostnames couldn't be positively classified as stale. In practice this meant any client reaching the :444 listener and controlling TLS SNI (or the HTTP Host header) could get arbitrary hostnames added to the live serving certificate's SAN list, persisting across pod restarts.

dynamiclistener's allowDefaultSANs wrapper already accepts the legitimate static default SANs (localhost, cluster IP, node IPs, etc.) upstream before this filter ever runs, so there is no legitimate hostname this filter needs to admit. Reject all non-IP CNs outright, both pre-sync and post-sync, keeping only live pod IPs.

Adds pkg/tls/podips_test.go (this branch had no test coverage for podIPTracker at all) with a regression test simulating 40 distinct externally-supplied SNI hostnames -- confirms none get through and a legitimate live pod IP is still preserved in the same call.

• tls: add localhost and rancher-internal.cattle-system.svc as default SANs

Backport of 2cba64c from the v2.15 fix branch to release/v2.14.

The tls-rancher-internal (:444) listener's default SANs (Config.SANs, fed by hostIPs) previously only ever contained IPs: node IPs (when the deployment uses hostPort) and the rancher-internal Service's ClusterIP. localhost and the Service's in-cluster DNS name (rancher-internal.cattle-system.svc) were both missing, even though the main :443 listener already includes localhost/127.0.0.1/rancher.cattle-system as defaults.

Add both. These are handled by dynamiclistener's allowDefaultSANs wrapper upstream of FilterCN, so they're unaffected by the CN-filtering fix already on this branch (still rejects any non-default hostname) and by the pod-IP filter -- they're always present regardless of pod churn.

As a side effect, this also ensures the internal listener always gets a TLSListenerConfig even in the edge case where clusterIP and getHostIPs both come back empty (previously that left serverOptions.TLSListenerConfig unset entirely).

• tls: also add 127.0.0.1 and the .svc.cluster.local FQDN as default SANs

Follow-up to 68baf4a: add 127.0.0.1 alongside the existing localhost entry, and the fully-qualified rancher-internal.cattle-system.svc.cluster.local form alongside the short rancher-internal.cattle-system.svc name, so both common in-cluster addressing conventions are covered by default.

Original source