mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Merge branch 'main' into rke2
This commit is contained in:
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10) | September 25, 2025 |
|
||||
| [2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) | August 27, 2025 |
|
||||
| [2.10.8](https://github.com/rancher/rancher/releases/tag/v2.10.8) | July 30, 2025 |
|
||||
| [2.10.7](https://github.com/rancher/rancher/releases/tag/v2.10.7) | June 25, 2025 |
|
||||
|
||||
+1
-1
@@ -212,7 +212,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
|
||||
|
||||
## 3. Install RKE2
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
|
||||
- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
|
||||
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
|
||||
- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
|
||||
- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
|
||||
- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
|
||||
- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
|
||||
- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
@@ -48,7 +48,7 @@ See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Lino
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
- For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.
|
||||
|
||||
- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
|
||||
- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/noble/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Global Permissions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
<PermissionsWarning />
|
||||
|
||||
_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`.
|
||||
|
||||
+6
@@ -18,6 +18,12 @@ While restoring Rancher on the same setup, the operator will scale down the Ranc
|
||||
|
||||
:::
|
||||
|
||||
:::note Warning for Fleet users
|
||||
You must consider how to handle Kubernetes API server availability and paused GitRepos when restoring a Rancher setup
|
||||
that is running Fleet workloads. See the [Fleet
|
||||
documentation](http://fleet.rancher.io/gitrepo-add#backing-up-and-restoring) for more details.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
|
||||
+2
-2
@@ -159,7 +159,7 @@ stringData:
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
@@ -245,7 +245,7 @@ Note that this chart reads the Cloud Provider Config from the secret in the `kub
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.10.10 | v105.0.0+up5.0.1 |
|
||||
| v2.10.9 | v105.0.0+up5.0.1 |
|
||||
| v2.10.8 | v105.0.0+up5.0.1 |
|
||||
| v2.10.7 | v105.0.0+up5.0.1 |
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ Monitoring the availability and performance of all your internal workloads is vi
|
||||
|
||||
In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) which check if the cluster is configured according to security best practices.
|
||||
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/products/kubernetes-security/), [SysDig](https://sysdig.com/).
|
||||
|
||||
## Setting up Alerts
|
||||
|
||||
|
||||
+2
-2
@@ -171,7 +171,7 @@ Option to set environment variables for [Rancher agents](../../../how-to-guides/
|
||||
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/datastore/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
##### Metrics
|
||||
|
||||
@@ -235,7 +235,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det
|
||||
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
|
||||
|
||||
#### Upgrade Strategy
|
||||
|
||||
|
||||
-6
@@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
|
||||
|
||||
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
|
||||
|
||||
+64
@@ -28,3 +28,67 @@ You should protect the following ports behind an [external load balancer](../../
|
||||
- **RKE and RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
|
||||
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
|
||||
|
||||
## Rancher Username Policy
|
||||
|
||||
By default, Kubernetes does not provide enforcement mechanisms for baseline username policies. In Rancher, this means that any enforcement of username formats, naming conventions, or baseline policies is expected to be handled by the external identity provider's policies, if such policies are in place.
|
||||
|
||||
In Rancher, `admin` is the default username for the Administrator user, as highlighted [here](../../getting-started/installation-and-upgrade/resources/bootstrap-password.md)
|
||||
|
||||
Examples of potential baseline policies include:
|
||||
|
||||
- Requiring usernames to follow an organizational convention (e.g., `firstname.lastname`)
|
||||
- Enforcing minimum or maximum length requirements
|
||||
- Disallowing certain special characters
|
||||
- Preventing impersonation by disallowing reserved names (e.g., `admin`, `root`)
|
||||
|
||||
Without these controls at the identity provider layer, there is a risk of inconsistent or insecure username practices, which can complicate access audits and lead to privilege escalation attempts.
|
||||
|
||||
:::note Important
|
||||
|
||||
Rancher currently enforces only a [minimum password length](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length).
|
||||
|
||||
:::
|
||||
|
||||
**Recommendation:**
|
||||
We strongly advice that customers:
|
||||
|
||||
- Review and configure username baseline policies directly in their external identity providers (e.g., LDAP, Active Directory, SAML, or OIDC).
|
||||
- Ensure that those policies align with the organization’s security and compliance requirements.
|
||||
- Regularly audit user accounts to detect naming inconsistencies or policy violations.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
|
||||
- [OWASP Identity Management](https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication)
|
||||
|
||||
## WAF Rules
|
||||
|
||||
Rancher is designed to support a wide range of deployment scenarios, including environments where customers may programmatically automate the creation or provisioning of large numbers of clusters. Imposing strict application-level limits within Rancher itself could interfere with legitimate workloads that require dynamic scaling.
|
||||
|
||||
For example:
|
||||
|
||||
- CI/CD pipelines may create and tear down clusters frequently.
|
||||
- Self-service portals could provision clusters on-demand for developers.
|
||||
- Test environments may generate high volumes of API calls.
|
||||
|
||||
**Risk:**
|
||||
Without appropriate rate limiting, adversaries could exploit unauthenticated or authenticated endpoints to:
|
||||
|
||||
- Exhaust resources (Denial of Service).
|
||||
- Inflate storage costs.
|
||||
- Degrade performance for legitimate users.
|
||||
|
||||
**Recommendation:**
|
||||
The most effective way to mitigate this risk is to implement rate limiting and abuse protection at the infrastructure or Web Application Firewall (WAF) layer. This approach allows thresholds to be tuned for each environment's expected usage and scaling characteristics. Some examples of controls can be:
|
||||
|
||||
- Configuring a Web Application Firewall or API Gateway to enforce rate limits on sensitive operations, such as cluster creation and provisioning.
|
||||
- Defining thresholds based on baseline workload expectations (e.g., max requests per minute per client).
|
||||
- Monitoring logs and alerting on anomalies to detect potential abuse.
|
||||
- Apply a resource quota, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [Project Resource Quotas](../../how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [OWASP API Security Top 10 - API4:2019 - Lack of Resources & Rate Limiting](https://owasp.org/API-Security/editions/2023/en/0xa4-lack-of-resources-rate-limiting/)
|
||||
- [OWASP Cheat Sheet: Rate Limiting](https://cheatsheetseries.owasp.org/cheatsheets/Rate_Limiting_Cheat_Sheet.html)
|
||||
+3
@@ -10,6 +10,9 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58259](https://github.com/rancher/rancher/security/advisories/GHSA-4h45-jpvh-6p5j) | POSTs to the Rancher API endpoints are now limited to 1 Mi; this is configurable through the settings if you need a larger limit. The Rancher authentication endpoints are configured independently of the main public API (as you might need bigger payloads in the other API endpoints). Suppose you need to increase the maximum allowed payload for authentication. In that case, you can set the environment variable `CATTLE_AUTH_API_BODY_LIMIT` to a quantity, e.g., 2 Mi, which would allow larger payloads for the authentication endpoints. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5), [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) and [v2.9.11](https://github.com/rancher/rancher/releases/tag/v2.9.11) |
|
||||
| [CVE-2024-52284](https://github.com/rancher/fleet/security/advisories/GHSA-6h9x-9j5v-7w9h) | Following a recent [change](https://github.com/rancher/fleet/pull/3403) excluding Helm values files from bundles, an edge case subsisted where the values files referenced in `fleet.yaml` with your directory name (e.g., `my-dir/values.yaml` instead of `values.yaml`) would not be excluded, which would potentially expose confidential data in bundle resources. Helm values files are now excluded from bundle resources regardless of how you reference them. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) and [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) |
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
|
||||
@@ -20,6 +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.10 | v0.6.11 | ✓ | ✗ |
|
||||
| v2.10.9 | v0.6.10 | ✓ | ✗ |
|
||||
| v2.10.8 | v0.6.9 | ✓ | ✗ |
|
||||
| v2.10.7 | v0.6.8 | ✓ | ✗ |
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6) | September 25, 2025 |
|
||||
| [2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) | August 28, 2025 |
|
||||
| [2.11.4](https://github.com/rancher/rancher/releases/tag/v2.11.4) | July 30, 2025 |
|
||||
| [2.11.3](https://github.com/rancher/rancher/releases/tag/v2.11.3) | June 25, 2025 |
|
||||
|
||||
+1
-1
@@ -212,7 +212,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
|
||||
|
||||
## 3. Install RKE2
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
|
||||
- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
|
||||
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
|
||||
- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
|
||||
- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
|
||||
- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
|
||||
- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
|
||||
- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
@@ -48,7 +48,7 @@ See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Lino
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
- For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.
|
||||
|
||||
- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
|
||||
- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/noble/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Global Permissions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
<PermissionsWarning />
|
||||
|
||||
_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`, `Standard User` and `User-base`.
|
||||
|
||||
+6
@@ -18,6 +18,12 @@ While restoring Rancher on the same setup, the operator will scale down the Ranc
|
||||
|
||||
:::
|
||||
|
||||
:::note Warning for Fleet users
|
||||
You must consider how to handle Kubernetes API server availability and paused GitRepos when restoring a Rancher setup
|
||||
that is running Fleet workloads. See the [Fleet
|
||||
documentation](http://fleet.rancher.io/gitrepo-add#backing-up-and-restoring) for more details.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
|
||||
+2
-2
@@ -159,7 +159,7 @@ stringData:
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
@@ -245,7 +245,7 @@ Note that this chart reads the Cloud Provider Config from the secret in the `kub
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.11.6 | v106.0.0+up6.0.0 |
|
||||
| v2.11.5 | v106.0.0+up6.0.0 |
|
||||
| v2.11.4 | v106.0.0+up6.0.0 |
|
||||
| v2.11.3 | v106.0.0+up6.0.0 |
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ Monitoring the availability and performance of all your internal workloads is vi
|
||||
|
||||
In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) which check if the cluster is configured according to security best practices.
|
||||
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/products/kubernetes-security/), [SysDig](https://sysdig.com/).
|
||||
|
||||
## Setting up Alerts
|
||||
|
||||
|
||||
+2
-2
@@ -171,7 +171,7 @@ Option to set environment variables for [Rancher agents](../../../how-to-guides/
|
||||
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/datastore/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
##### Metrics
|
||||
|
||||
@@ -235,7 +235,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det
|
||||
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
|
||||
|
||||
#### Upgrade Strategy
|
||||
|
||||
|
||||
-6
@@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
|
||||
|
||||
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
|
||||
|
||||
+64
@@ -28,3 +28,67 @@ You should protect the following ports behind an [external load balancer](../../
|
||||
- **RKE and RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
|
||||
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
|
||||
|
||||
## Rancher Username Policy
|
||||
|
||||
By default, Kubernetes does not provide enforcement mechanisms for baseline username policies. In Rancher, this means that any enforcement of username formats, naming conventions, or baseline policies is expected to be handled by the external identity provider's policies, if such policies are in place.
|
||||
|
||||
In Rancher, `admin` is the default username for the Administrator user, as highlighted [here](../../getting-started/installation-and-upgrade/resources/bootstrap-password.md)
|
||||
|
||||
Examples of potential baseline policies include:
|
||||
|
||||
- Requiring usernames to follow an organizational convention (e.g., `firstname.lastname`)
|
||||
- Enforcing minimum or maximum length requirements
|
||||
- Disallowing certain special characters
|
||||
- Preventing impersonation by disallowing reserved names (e.g., `admin`, `root`)
|
||||
|
||||
Without these controls at the identity provider layer, there is a risk of inconsistent or insecure username practices, which can complicate access audits and lead to privilege escalation attempts.
|
||||
|
||||
:::note Important
|
||||
|
||||
Rancher currently enforces only a [minimum password length](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length).
|
||||
|
||||
:::
|
||||
|
||||
**Recommendation:**
|
||||
We strongly advice that customers:
|
||||
|
||||
- Review and configure username baseline policies directly in their external identity providers (e.g., LDAP, Active Directory, SAML, or OIDC).
|
||||
- Ensure that those policies align with the organization’s security and compliance requirements.
|
||||
- Regularly audit user accounts to detect naming inconsistencies or policy violations.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
|
||||
- [OWASP Identity Management](https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication)
|
||||
|
||||
## WAF Rules
|
||||
|
||||
Rancher is designed to support a wide range of deployment scenarios, including environments where customers may programmatically automate the creation or provisioning of large numbers of clusters. Imposing strict application-level limits within Rancher itself could interfere with legitimate workloads that require dynamic scaling.
|
||||
|
||||
For example:
|
||||
|
||||
- CI/CD pipelines may create and tear down clusters frequently.
|
||||
- Self-service portals could provision clusters on-demand for developers.
|
||||
- Test environments may generate high volumes of API calls.
|
||||
|
||||
**Risk:**
|
||||
Without appropriate rate limiting, adversaries could exploit unauthenticated or authenticated endpoints to:
|
||||
|
||||
- Exhaust resources (Denial of Service).
|
||||
- Inflate storage costs.
|
||||
- Degrade performance for legitimate users.
|
||||
|
||||
**Recommendation:**
|
||||
The most effective way to mitigate this risk is to implement rate limiting and abuse protection at the infrastructure or Web Application Firewall (WAF) layer. This approach allows thresholds to be tuned for each environment's expected usage and scaling characteristics. Some examples of controls can be:
|
||||
|
||||
- Configuring a Web Application Firewall or API Gateway to enforce rate limits on sensitive operations, such as cluster creation and provisioning.
|
||||
- Defining thresholds based on baseline workload expectations (e.g., max requests per minute per client).
|
||||
- Monitoring logs and alerting on anomalies to detect potential abuse.
|
||||
- Apply a resource quota, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [Project Resource Quotas](../../how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [OWASP API Security Top 10 - API4:2019 - Lack of Resources & Rate Limiting](https://owasp.org/API-Security/editions/2023/en/0xa4-lack-of-resources-rate-limiting/)
|
||||
- [OWASP Cheat Sheet: Rate Limiting](https://cheatsheetseries.owasp.org/cheatsheets/Rate_Limiting_Cheat_Sheet.html)
|
||||
+3
@@ -10,6 +10,9 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58259](https://github.com/rancher/rancher/security/advisories/GHSA-4h45-jpvh-6p5j) | POSTs to the Rancher API endpoints are now limited to 1 Mi; this is configurable through the settings if you need a larger limit. The Rancher authentication endpoints are configured independently of the main public API (as you might need bigger payloads in the other API endpoints). Suppose you need to increase the maximum allowed payload for authentication. In that case, you can set the environment variable `CATTLE_AUTH_API_BODY_LIMIT` to a quantity, e.g., 2 Mi, which would allow larger payloads for the authentication endpoints. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5), [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) and [v2.9.11](https://github.com/rancher/rancher/releases/tag/v2.9.11) |
|
||||
| [CVE-2024-52284](https://github.com/rancher/fleet/security/advisories/GHSA-6h9x-9j5v-7w9h) | Following a recent [change](https://github.com/rancher/fleet/pull/3403) excluding Helm values files from bundles, an edge case subsisted where the values files referenced in `fleet.yaml` with your directory name (e.g., `my-dir/values.yaml` instead of `values.yaml`) would not be excluded, which would potentially expose confidential data in bundle resources. Helm values files are now excluded from bundle resources regardless of how you reference them. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) and [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) |
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
|
||||
@@ -20,6 +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.11.6 | v0.7.6 | ✓ | ✗ |
|
||||
| v2.11.5 | v0.7.5 | ✓ | ✗ |
|
||||
| v2.11.4 | v0.7.4 | ✓ | ✗ |
|
||||
| v2.11.3 | v0.7.3 | ✓ | ✓ |
|
||||
|
||||
@@ -16,9 +16,10 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | September 25, 2025 |
|
||||
| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | August 28, 2025 |
|
||||
| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 30, 2025 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
|
||||
In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
|
||||
|
||||
+1
-1
@@ -212,7 +212,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
|
||||
|
||||
## 3. Install RKE2
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
|
||||
- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
|
||||
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
|
||||
- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
|
||||
- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
|
||||
- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
|
||||
- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
|
||||
- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
@@ -48,7 +48,7 @@ See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Lino
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
- For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.
|
||||
|
||||
- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
|
||||
- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
|
||||
+1
@@ -59,6 +59,7 @@ Additionally, the following limitations are present when the feature is enabled.
|
||||
- `State` column sort and filter features work on the resources `metadata.state.name` field instead of one deduced locally by the UI.
|
||||
- Updates are shown every 5 seconds, rather than instantly.
|
||||
- Cluster Explorer:
|
||||
- Project/Namespace filter does not support filtering namespaces by all namespaces not in a project via the `Not in a Project` entry.
|
||||
- `Cluster` group --> `Nodes` page
|
||||
- The following columns are not sortable or filterable: `Roles`, `External/Internal IP`, `CPU`, `RAM` (logic to determine their value is calculated in the browser)
|
||||
- `Workloads` list:
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/noble/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Global Permissions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
<PermissionsWarning />
|
||||
|
||||
_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`, `Standard User` and `User-base`.
|
||||
|
||||
+6
@@ -18,6 +18,12 @@ While restoring Rancher on the same setup, the operator will scale down the Ranc
|
||||
|
||||
:::
|
||||
|
||||
:::note Warning for Fleet users
|
||||
You must consider how to handle Kubernetes API server availability and paused GitRepos when restoring a Rancher setup
|
||||
that is running Fleet workloads. See the [Fleet
|
||||
documentation](http://fleet.rancher.io/gitrepo-add#backing-up-and-restoring) for more details.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
|
||||
+2
-2
@@ -159,7 +159,7 @@ stringData:
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
@@ -244,7 +244,7 @@ Note that this chart reads the Cloud Provider Config from the secret in the `kub
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.12.2 | 107.0.0+up7.0.0 |
|
||||
| v2.12.1 | 107.0.0+up7.0.0 |
|
||||
| v2.12.0 | 107.0.0+up7.0.0 |
|
||||
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ Monitoring the availability and performance of all your internal workloads is vi
|
||||
|
||||
In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [Compliance Scans](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) which check if the cluster is configured according to security best practices.
|
||||
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/products/kubernetes-security/), [SysDig](https://sysdig.com/).
|
||||
|
||||
## Setting up Alerts
|
||||
|
||||
|
||||
+2
-2
@@ -171,7 +171,7 @@ Option to set environment variables for [Rancher agents](../../../how-to-guides/
|
||||
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/datastore/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
##### Metrics
|
||||
|
||||
@@ -235,7 +235,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det
|
||||
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
|
||||
|
||||
#### Upgrade Strategy
|
||||
|
||||
|
||||
-6
@@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
|
||||
|
||||
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
|
||||
|
||||
+64
@@ -28,3 +28,67 @@ You should protect the following ports behind an [external load balancer](../../
|
||||
- **RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
|
||||
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
|
||||
|
||||
## Rancher Username Policy
|
||||
|
||||
By default, Kubernetes does not provide enforcement mechanisms for baseline username policies. In Rancher, this means that any enforcement of username formats, naming conventions, or baseline policies is expected to be handled by the external identity provider's policies, if such policies are in place.
|
||||
|
||||
In Rancher, `admin` is the default username for the Administrator user, as highlighted [here](../../getting-started/installation-and-upgrade/resources/bootstrap-password.md)
|
||||
|
||||
Examples of potential baseline policies include:
|
||||
|
||||
- Requiring usernames to follow an organizational convention (e.g., `firstname.lastname`)
|
||||
- Enforcing minimum or maximum length requirements
|
||||
- Disallowing certain special characters
|
||||
- Preventing impersonation by disallowing reserved names (e.g., `admin`, `root`)
|
||||
|
||||
Without these controls at the identity provider layer, there is a risk of inconsistent or insecure username practices, which can complicate access audits and lead to privilege escalation attempts.
|
||||
|
||||
:::note Important
|
||||
|
||||
Rancher currently enforces only a [minimum password length](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length).
|
||||
|
||||
:::
|
||||
|
||||
**Recommendation:**
|
||||
We strongly advice that customers:
|
||||
|
||||
- Review and configure username baseline policies directly in their external identity providers (e.g., LDAP, Active Directory, SAML, or OIDC).
|
||||
- Ensure that those policies align with the organization’s security and compliance requirements.
|
||||
- Regularly audit user accounts to detect naming inconsistencies or policy violations.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
|
||||
- [OWASP Identity Management](https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication)
|
||||
|
||||
## WAF Rules
|
||||
|
||||
Rancher is designed to support a wide range of deployment scenarios, including environments where customers may programmatically automate the creation or provisioning of large numbers of clusters. Imposing strict application-level limits within Rancher itself could interfere with legitimate workloads that require dynamic scaling.
|
||||
|
||||
For example:
|
||||
|
||||
- CI/CD pipelines may create and tear down clusters frequently.
|
||||
- Self-service portals could provision clusters on-demand for developers.
|
||||
- Test environments may generate high volumes of API calls.
|
||||
|
||||
**Risk:**
|
||||
Without appropriate rate limiting, adversaries could exploit unauthenticated or authenticated endpoints to:
|
||||
|
||||
- Exhaust resources (Denial of Service).
|
||||
- Inflate storage costs.
|
||||
- Degrade performance for legitimate users.
|
||||
|
||||
**Recommendation:**
|
||||
The most effective way to mitigate this risk is to implement rate limiting and abuse protection at the infrastructure or Web Application Firewall (WAF) layer. This approach allows thresholds to be tuned for each environment's expected usage and scaling characteristics. Some examples of controls can be:
|
||||
|
||||
- Configuring a Web Application Firewall or API Gateway to enforce rate limits on sensitive operations, such as cluster creation and provisioning.
|
||||
- Defining thresholds based on baseline workload expectations (e.g., max requests per minute per client).
|
||||
- Monitoring logs and alerting on anomalies to detect potential abuse.
|
||||
- Apply a resource quota, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [Project Resource Quotas](../../how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [OWASP API Security Top 10 - API4:2019 - Lack of Resources & Rate Limiting](https://owasp.org/API-Security/editions/2023/en/0xa4-lack-of-resources-rate-limiting/)
|
||||
- [OWASP Cheat Sheet: Rate Limiting](https://cheatsheetseries.owasp.org/cheatsheets/Rate_Limiting_Cheat_Sheet.html)
|
||||
+3
@@ -10,5 +10,8 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58259](https://github.com/rancher/rancher/security/advisories/GHSA-4h45-jpvh-6p5j) | POSTs to the Rancher API endpoints are now limited to 1 Mi; this is configurable through the settings if you need a larger limit. The Rancher authentication endpoints are configured independently of the main public API (as you might need bigger payloads in the other API endpoints). Suppose you need to increase the maximum allowed payload for authentication. In that case, you can set the environment variable `CATTLE_AUTH_API_BODY_LIMIT` to a quantity, e.g., 2 Mi, which would allow larger payloads for the authentication endpoints. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5), [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) and [v2.9.11](https://github.com/rancher/rancher/releases/tag/v2.9.11) |
|
||||
| [CVE-2024-52284](https://github.com/rancher/fleet/security/advisories/GHSA-6h9x-9j5v-7w9h) | Following a recent [change](https://github.com/rancher/fleet/pull/3403) excluding Helm values files from bundles, an edge case subsisted where the values files referenced in `fleet.yaml` with your directory name (e.g., `my-dir/values.yaml` instead of `values.yaml`) would not be excluded, which would potentially expose confidential data in bundle resources. Helm values files are now excluded from bundle resources regardless of how you reference them. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) and [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) |
|
||||
|
||||
@@ -20,6 +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.12.2 | v0.8.2 | ✓ | ✓ |
|
||||
| v2.12.1 | v0.8.1 | ✓ | ✓ |
|
||||
| v2.12.0 | v0.8.0 | ✗ | ✓ |
|
||||
|
||||
|
||||
+1
-1
@@ -212,7 +212,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
|
||||
|
||||
## 3. Install RKE2
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
|
||||
- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
|
||||
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
|
||||
- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
|
||||
- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
|
||||
- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
|
||||
- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
|
||||
- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
@@ -48,7 +48,7 @@ Deploying to Linode will incur charges.
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
- For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.
|
||||
|
||||
- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
|
||||
- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/jammy/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Global Permissions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
<PermissionsWarning />
|
||||
|
||||
_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`.
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ Monitoring the availability and performance of all your internal workloads is vi
|
||||
|
||||
In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) which check if the cluster is configured according to security best practices.
|
||||
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/products/kubernetes-security/), [SysDig](https://sysdig.com/).
|
||||
|
||||
## Setting up Alerts
|
||||
|
||||
|
||||
+2
-2
@@ -175,7 +175,7 @@ Option to set environment variables for [Rancher agents](../../../how-to-guides/
|
||||
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/datastore/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
##### Metrics
|
||||
|
||||
@@ -239,7 +239,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det
|
||||
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
|
||||
|
||||
#### Upgrade Strategy
|
||||
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) | September 25, 2025 |
|
||||
| [2.9.11](https://github.com/rancher/rancher/releases/tag/v2.9.11) | August 27, 2025 |
|
||||
| [2.9.10](https://github.com/rancher/rancher/releases/tag/v2.9.10) | May 22, 2025 |
|
||||
| [2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) | Apr 24, 2025 |
|
||||
|
||||
+1
-1
@@ -212,7 +212,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/private_registry)
|
||||
|
||||
## 3. Install RKE2
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
|
||||
- [IAM Policy created](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start): Defines the permissions an account attached with this policy has.
|
||||
- Install [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
|
||||
- Install [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Amazon AWS.
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Microsoft Azure.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
|
||||
- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to DigitalOcean.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ Deploying to Google GCP will incur charges.
|
||||
- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
|
||||
- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Google GCP.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run.
|
||||
- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster to Hetzner.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
- [Linode Account](https://www.linode.com/): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://techdocs.akamai.com/cloud-computing/docs/manage-personal-access-tokens): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
@@ -48,7 +48,7 @@ See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Lino
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
- For a complete list of plans, see the [official Plan Types page](https://techdocs.akamai.com/cloud-computing/docs/compute-instance-plan-types).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Deploying to Outscale will incur charges.
|
||||
|
||||
- [Outscale Account](https://en.outscale.com/): You will require an account on Outscale as this is where the server and cluster will run.
|
||||
- [Outscale Access Key](https://docs.outscale.com/en/userguide/About-Access-Keys.html): Use these instructions to create an Outscale Access Key if you don't have one.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Outscale.
|
||||
- [Terraform](https://developer.hashicorp.com/terraform/install): Used to provision the server and cluster in Outscale.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Vagrant](https://developer.hashicorp.com/vagrant): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/noble/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Global Permissions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
<PermissionsWarning />
|
||||
|
||||
_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`.
|
||||
|
||||
+6
@@ -18,6 +18,12 @@ While restoring Rancher on the same setup, the operator will scale down the Ranc
|
||||
|
||||
:::
|
||||
|
||||
:::note Warning for Fleet users
|
||||
You must consider how to handle Kubernetes API server availability and paused GitRepos when restoring a Rancher setup
|
||||
that is running Fleet workloads. See the [Fleet
|
||||
documentation](http://fleet.rancher.io/gitrepo-add#backing-up-and-restoring) for more details.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
|
||||
+2
-2
@@ -159,7 +159,7 @@ stringData:
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
@@ -245,7 +245,7 @@ Note that this chart reads the Cloud Provider Config from the secret in the `kub
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"aadClientSecret": "<client-secret>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.9.12 | v104.0.0+up4.0.0 |
|
||||
| v2.9.11 | v104.0.0+up4.0.0 |
|
||||
| v2.9.10 | v104.0.0+up4.0.0 |
|
||||
| v2.9.9 | v104.0.0+up4.0.0 |
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ Monitoring the availability and performance of all your internal workloads is vi
|
||||
|
||||
In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) which check if the cluster is configured according to security best practices.
|
||||
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/).
|
||||
For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/products/kubernetes-security/), [SysDig](https://sysdig.com/).
|
||||
|
||||
## Setting up Alerts
|
||||
|
||||
|
||||
+2
-2
@@ -171,7 +171,7 @@ Option to set environment variables for [Rancher agents](../../../how-to-guides/
|
||||
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/datastore/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
##### Metrics
|
||||
|
||||
@@ -235,7 +235,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det
|
||||
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
|
||||
|
||||
#### Upgrade Strategy
|
||||
|
||||
|
||||
+73
@@ -19,3 +19,76 @@ See [OWASP Web Application Security Testing - Enumerate Infrastructure and Appli
|
||||
Some environments may require additional security controls for session management. For example, you may want to limit users' concurrent active sessions or restrict which geolocations those sessions can be initiated from. Such features are not supported by Rancher out of the box.
|
||||
|
||||
If you require such features, combine Layer 7 firewalls with [external authentication providers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md#external-vs-local-authentication).
|
||||
|
||||
## Use External Load Balancers to Protect Vulnerable Ports
|
||||
|
||||
You should protect the following ports behind an [external load balancer](../../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#layer-4-load-balancer) that has SSL offload enabled:
|
||||
|
||||
- **K3s:** Port 6443, used by the Kubernetes API.
|
||||
- **RKE and RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
|
||||
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
|
||||
|
||||
## Rancher Username Policy
|
||||
|
||||
By default, Kubernetes does not provide enforcement mechanisms for baseline username policies. In Rancher, this means that any enforcement of username formats, naming conventions, or baseline policies is expected to be handled by the external identity provider's policies, if such policies are in place.
|
||||
|
||||
In Rancher, `admin` is the default username for the Administrator user, as highlighted [here](../../getting-started/installation-and-upgrade/resources/bootstrap-password.md)
|
||||
|
||||
Examples of potential baseline policies include:
|
||||
|
||||
- Requiring usernames to follow an organizational convention (e.g., `firstname.lastname`)
|
||||
- Enforcing minimum or maximum length requirements
|
||||
- Disallowing certain special characters
|
||||
- Preventing impersonation by disallowing reserved names (e.g., `admin`, `root`)
|
||||
|
||||
Without these controls at the identity provider layer, there is a risk of inconsistent or insecure username practices, which can complicate access audits and lead to privilege escalation attempts.
|
||||
|
||||
:::note Important
|
||||
|
||||
Rancher currently enforces only a [minimum password length](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length).
|
||||
|
||||
:::
|
||||
|
||||
**Recommendation:**
|
||||
We strongly advice that customers:
|
||||
|
||||
- Review and configure username baseline policies directly in their external identity providers (e.g., LDAP, Active Directory, SAML, or OIDC).
|
||||
- Ensure that those policies align with the organization’s security and compliance requirements.
|
||||
- Regularly audit user accounts to detect naming inconsistencies or policy violations.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
|
||||
- [OWASP Identity Management](https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication)
|
||||
|
||||
## WAF Rules
|
||||
|
||||
Rancher is designed to support a wide range of deployment scenarios, including environments where customers may programmatically automate the creation or provisioning of large numbers of clusters. Imposing strict application-level limits within Rancher itself could interfere with legitimate workloads that require dynamic scaling.
|
||||
|
||||
For example:
|
||||
|
||||
- CI/CD pipelines may create and tear down clusters frequently.
|
||||
- Self-service portals could provision clusters on-demand for developers.
|
||||
- Test environments may generate high volumes of API calls.
|
||||
|
||||
**Risk:**
|
||||
Without appropriate rate limiting, adversaries could exploit unauthenticated or authenticated endpoints to:
|
||||
|
||||
- Exhaust resources (Denial of Service).
|
||||
- Inflate storage costs.
|
||||
- Degrade performance for legitimate users.
|
||||
|
||||
**Recommendation:**
|
||||
The most effective way to mitigate this risk is to implement rate limiting and abuse protection at the infrastructure or Web Application Firewall (WAF) layer. This approach allows thresholds to be tuned for each environment's expected usage and scaling characteristics. Some examples of controls can be:
|
||||
|
||||
- Configuring a Web Application Firewall or API Gateway to enforce rate limits on sensitive operations, such as cluster creation and provisioning.
|
||||
- Defining thresholds based on baseline workload expectations (e.g., max requests per minute per client).
|
||||
- Monitoring logs and alerting on anomalies to detect potential abuse.
|
||||
- Apply a resource quota, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [Project Resource Quotas](../../how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [OWASP API Security Top 10 - API4:2019 - Lack of Resources & Rate Limiting](https://owasp.org/API-Security/editions/2023/en/0xa4-lack-of-resources-rate-limiting/)
|
||||
- [OWASP Cheat Sheet: Rate Limiting](https://cheatsheetseries.owasp.org/cheatsheets/Rate_Limiting_Cheat_Sheet.html)
|
||||
+3
@@ -10,6 +10,9 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
|
||||
| [CVE-2024-58259](https://github.com/rancher/rancher/security/advisories/GHSA-4h45-jpvh-6p5j) | POSTs to the Rancher API endpoints are now limited to 1 Mi; this is configurable through the settings if you need a larger limit. The Rancher authentication endpoints are configured independently of the main public API (as you might need bigger payloads in the other API endpoints). Suppose you need to increase the maximum allowed payload for authentication. In that case, you can set the environment variable `CATTLE_AUTH_API_BODY_LIMIT` to a quantity, e.g., 2 Mi, which would allow larger payloads for the authentication endpoints. | 28 Aug 2025 | Rancher [v2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1), [v2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5), [v2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) and [v2.9.11](https://github.com/rancher/rancher/releases/tag/v2.9.11) |
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2024-22031](https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m) | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the `BackingNampespace`, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. <br/><br/> The field is populated automatically during project creation and is formatted as `<clusterID>-<project.Name>`. For example, if your project is named `project-abc123` in a cluster with ID `cluster-xyz789`, then the project will have the `BackingNampespace`: `cluster-xyz789-project-abc123`. <br/><br/> If the `BackingNampespace` field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via `kubectl` the `BackingNampespace` will also be listed as a column. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
|
||||
@@ -20,6 +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.9.12 | v0.5.12 | ✓ | ✗ |
|
||||
| v2.9.11 | v0.5.11 | ✓ | ✗ |
|
||||
| v2.9.10 | v0.5.9 | ✓ | ✗ |
|
||||
| v2.9.9 | v0.5.9 | ✓ | ✗ |
|
||||
|
||||
Reference in New Issue
Block a user