diff --git a/.github/ISSUE_TEMPLATE/release-maintenance-checklist.md b/.github/ISSUE_TEMPLATE/release-maintenance-checklist.md new file mode 100644 index 00000000000..c61d1df02f1 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release-maintenance-checklist.md @@ -0,0 +1,15 @@ +--- +name: Release Maintenance Task Checklist +about: Track tasks that need to be done every release. +title: ' - Rancher Manager Release Maintenance Task Checklist' +--- + +This issue is to track tasks that need to be done every release regardless of whether the release has new feature content or not. + +- [ ] Update the [versions table](https://ranchermanager.docs.rancher.com/versions) +- [ ] Update the [Rancher:webhook version mapping table](https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook) +- [ ] Update the [CNI popularity table](https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers#cni-community-popularity) +- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix): +- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features): +- [ ] Create a new [release](https://github.com/rancher/rancher-docs/releases) +- [ ] Update Algolia search index diff --git a/.github/ISSUE_TEMPLATE/request-a-new-feature.md b/.github/ISSUE_TEMPLATE/request-a-new-feature.md index 902c8387d0f..1e57a0e52de 100644 --- a/.github/ISSUE_TEMPLATE/request-a-new-feature.md +++ b/.github/ISSUE_TEMPLATE/request-a-new-feature.md @@ -1,9 +1,6 @@ --- name: Request a New Feature about: For requesting new feature(s) to be added to the docs. -title: '' -labels: '' -assignees: '' --- ## Related Issues diff --git a/.github/ISSUE_TEMPLATE/request-an-update.md b/.github/ISSUE_TEMPLATE/request-an-update.md index 7a9b24fd7e5..c49d1b97a86 100644 --- a/.github/ISSUE_TEMPLATE/request-an-update.md +++ b/.github/ISSUE_TEMPLATE/request-an-update.md @@ -1,9 +1,6 @@ --- name: Request an Update about: For fixing docs errors/typos, adding needed/missing information, updating verbiage, deleting outdated info, etc. -title: '' -labels: '' -assignees: '' --- ## Related Issues diff --git a/.github/styles/suse-vale-styleguide b/.github/styles/suse-vale-styleguide deleted file mode 160000 index 419bd8a09a0..00000000000 --- a/.github/styles/suse-vale-styleguide +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 419bd8a09a06aefdc13142cd5c7794d190e64218 diff --git a/.github/styles/suse-vale-styleguide b/.github/styles/suse-vale-styleguide new file mode 100644 index 00000000000..c8bb5d55648 --- /dev/null +++ b/.github/styles/suse-vale-styleguide @@ -0,0 +1 @@ +f288d286db3b7c65e02cb6635d0c048f0f7a88fa \ No newline at end of file diff --git a/.github/workflows/create-issue.yml b/.github/workflows/create-issue.yml index 8782be3c627..e4a6b1aa19b 100644 --- a/.github/workflows/create-issue.yml +++ b/.github/workflows/create-issue.yml @@ -21,9 +21,11 @@ jobs: - name: Create issue env: GH_TOKEN: ${{ github.token }} + REPO_TYPE: ${{ contains( github.repository, 'product-docs') && 'Product' || 'Community' }} + PR_TITLE: ${{ github.event.pull_request.title }} run: | gh issue create \ - --repo rancher/rancher-docs \ - --title 'Port Community docs PR #${{github.event.pull_request.number}}: ${{github.event.pull_request.title}}' \ - --body 'Reference: https://github.com/${{github.repository}}/pull/${{github.event.pull_request.number}}' \ - --label port/community-product \ No newline at end of file + --repo ${{ github.repository }} \ + --title "Port $REPO_TYPE docs PR #${{ github.event.pull_request.number }}: $PR_TITLE" \ + --body "Reference: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}" \ + --label port/community-product \ No newline at end of file diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml index c16494a853b..e713d4aacde 100644 --- a/.github/workflows/deploy.yml +++ b/.github/workflows/deploy.yml @@ -6,6 +6,7 @@ on: - main paths-ignore: - '**/README.md' + - '**/.github/ISSUE_TEMPLATE/**' jobs: build: diff --git a/.github/workflows/test-deploy.yml b/.github/workflows/test-deploy.yml index 807286e11b6..f02e5094430 100644 --- a/.github/workflows/test-deploy.yml +++ b/.github/workflows/test-deploy.yml @@ -4,6 +4,7 @@ on: pull_request: paths-ignore: - '**/README.md' + - '**/.github/ISSUE_TEMPLATE/**' jobs: test-deploy: diff --git a/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md b/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md index 68ced560d4b..ad3db798c82 100644 --- a/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md +++ b/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md @@ -52,7 +52,7 @@ As an [administrator](../../../how-to-guides/advanced-user-guides/authentication > | 10252 | Controlplane | Kube controller manager | > | 2379 | Etcd | Etcd server | -> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md) +> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md) 1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring. diff --git a/docs/faq/deprecated-features.md b/docs/faq/deprecated-features.md index 1687b79592d..c0cc6b2f7a5 100644 --- a/docs/faq/deprecated-features.md +++ b/docs/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3) | Feb 27, 2025 | | [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 | | [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 | | [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 | diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 4556a3dfa5a..c7449e244b1 100644 --- a/docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index c291376354a..75c83dd7840 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -175,34 +175,6 @@ stringData: "loadBalancerSku": "standard", "excludeMasterFromStandardLB": false, } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount - name: azure-cloud-config - namespace: kube-system ``` ## Using the Out-of-tree Azure Cloud Provider @@ -212,109 +184,85 @@ roleRef: 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. -2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. - - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. -3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. -Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. - ```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: azure-cloud-controller-manager - namespace: kube-system -spec: - chart: cloud-provider-azure - repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo - targetNamespace: kube-system - bootstrap: true - valuesContent: |- - infra: - clusterName: - cloudControllerManager: - cloudConfigSecretName: azure-cloud-config - cloudConfig: null - clusterCIDR: null - enableDynamicReloading: 'true' - nodeSelector: - node-role.kubernetes.io/control-plane: 'true' - allocateNodeCidrs: 'false' - hostNetworking: true - caCertDir: /etc/ssl - configureCloudRoutes: 'false' - enabled: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/master - - effect: NoSchedule - key: node-role.kubernetes.io/control-plane - value: 'true' - - effect: NoSchedule - key: node.cloudprovider.kubernetes.io/uninitialized - value: 'true' ---- -apiVersion: v1 -kind: Secret -metadata: - name: azure-cloud-config - namespace: kube-system -type: Opaque -stringData: - cloud-config: |- - { - "cloud": "AzurePublicCloud", - "tenantId": "", - "subscriptionId": "", - "aadClientId": "", - "aadClientSecret": "", - "resourceGroup": "docker-machine", - "location": "westus", - "subnetName": "docker-machine", - "securityGroupName": "rancher-managed-kqmtsjgJ", - "securityGroupResourceGroup": "docker-machine", - "vnetName": "docker-machine-vnet", - "vnetResourceGroup": "docker-machine", - "primaryAvailabilitySetName": "docker-machine", - "routeTableResourceGroup": "docker-machine", - "cloudProviderBackoff": false, - "useManagedIdentityExtension": false, - "useInstanceMetadata": true, - "loadBalancerSku": "standard", - "excludeMasterFromStandardLB": false, - } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: name: azure-cloud-config namespace: kube-system - ``` + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` -4. Click **Create** to submit the form and create the cluster. +5. Click **Create** to submit the form and create the cluster. diff --git a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index ae1bcf2fcb2..0694c461321 100644 --- a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https: ## Creating a VMware vSphere Cluster +:::note + +User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines. + +::: + 1. [Create your cloud credentials](#1-create-your-cloud-credentials) 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials) 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template) @@ -111,4 +117,4 @@ After creating your cluster, you can access it through the Rancher UI. As a best - **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI. - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster. -- **Provision Storage:** For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../manage-clusters/provisioning-storage-examples/provisioning-storage-examples.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. For details, refer to [in-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md). \ No newline at end of file +- **Provision Storage:** For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../manage-clusters/provisioning-storage-examples/provisioning-storage-examples.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. For details, refer to [in-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md). diff --git a/docs/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/docs/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/docs/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/docs/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index 472dce754aa..4cca57cda83 100644 --- a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -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.3 | v105.0.0+up5.0.1 | | v2.10.2 | v105.0.0+up5.0.1 | | v2.10.1 | v105.0.0+up5.0.1 | | v2.10.0 | v105.0.0+up5.0.1 | diff --git a/docs/reference-guides/rancher-security/security-advisories-and-cves.md b/docs/reference-guides/rancher-security/security-advisories-and-cves.md index ebc21bd113b..413a8fe4a66 100644 --- a/docs/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/docs/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/docs/reference-guides/rancher-webhook.md b/docs/reference-guides/rancher-webhook.md index cc4c446ea81..d41b2bbc69e 100644 --- a/docs/reference-guides/rancher-webhook.md +++ b/docs/reference-guides/rancher-webhook.md @@ -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.3 | v0.6.4 | ✓ | ✓ | | v2.10.2 | v0.6.3 | ✓ | ✓ | | v2.10.1 | v0.6.2 | ✓ | ✓ | | v2.10.0 | v0.6.1 | ✗ | ✓ | diff --git a/docusaurus.config.js b/docusaurus.config.js index aa3aaad4863..dae048cca47 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -185,7 +185,7 @@ module.exports = { label: 'Latest', }, '2.11': { - label: 'v2.11 (Preview)', + label: 'v2.11 (Unreleased)', path: 'v2.11', banner: 'unreleased' }, diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index 0b6fc4bac45..fc3174b7ec7 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -109,3 +109,437 @@ Azure 订阅不支持以下账号类型： 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。 1. 单击**创建**按钮来提交表单并创建集群。 + +## Cloud Provider Configuration + +Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names. + +**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).** + +:::note +1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`. +2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB). +3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information. +::: + +Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret. + +Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret. + + ```yaml +# azure-cloud-config.yaml +apiVersion: v1 +kind: Secret +metadata: + name: azure-cloud-config + namespace: kube-system +type: Opaque +stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` + +## Using the Out-of-tree Azure Cloud Provider + + + + +1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. + +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. + +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. + + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. + +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: + name: azure-cloud-config + namespace: kube-system + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` + +5. Click **Create** to submit the form and create the cluster. + + + + + +1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components. + +2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui). + +Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager. + + + + +### Helm Chart Installation from CLI + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github. + +1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). + +```shell +kubectl apply -f azure-cloud-config.yaml +``` + +2. Add the Helm repository: + +```shell +helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo +helm repo update +``` + +3. Create a `values.yaml` file with the following contents to override the default `values.yaml`: + + + + +```yaml +# values.yaml +infra: + clusterName: +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +``` + + + + + +```yaml +# values.yaml +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/controlplane: 'true' + node-role.kubernetes.io/control-plane: null + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +infra: + clusterName: +``` + + + + +4. Install the Helm chart: + +```shell +helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml +``` + +Verify that the Helm chart installed successfully: + +```shell +helm status cloud-provider-azure -n kube-system +``` + +5. (Optional) Verify that the cloud controller manager update succeeded: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Helm Chart Installation from UI + +1. Click **☰**, then select the name of the cluster from the left navigation. + +2. Select **Apps** > **Repositories**. + +3. Click the **Create** button. + +4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field. + +5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart. + +6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**. + +7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading: + +```yaml + cloudConfigSecretName: azure-cloud-config + enableDynamicReloading: 'true' +``` + +8. Update the following fields as required: + +```yaml + allocateNodeCidrs: 'false' + configureCloudRoutes: 'false' + clusterCIDR: null +``` + + + + +9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector: +```yaml +nodeSelector: + node-role.kubernetes.io/control-plane: 'true' +``` + + + + +10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector: + +```yaml +tolerations: + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + - effect: NoSchedule + value: 'true' + key: node-role.kubernetes.io/controlplane +``` + +```yaml +nodeSelector: + node-role.kubernetes.io/controlplane: 'true' +``` + + + +11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Installing CSI Drivers + +Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively. + +The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md). + +::: note Important: + +Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. + +::: + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github. + +1. Add and update the helm repository: + +```shell +helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts +helm repo update azuredisk-csi-driver +``` + +1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration). + +```shell +helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true +``` + +2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: + +```shell +kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch +``` + +3. Provision an example Storage Class: + +```shell +cat <
The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md index 4f6461e85c6..37f8dc7513e 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md @@ -89,7 +89,7 @@ helm template rancher ./rancher-.tgz --output-dir . \ 升级后出现网络问题？ -请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 +请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 ::: diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md index b834e7f6e11..98fc3420220 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md @@ -139,7 +139,7 @@ helm rollback rancher 3 -n cattle-system ## 回滚到 Rancher 2.2-2.4 -要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。 +要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。 有关回滚 Docker 安装的 Rancher，请参见[本页](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)。 @@ -151,4 +151,4 @@ helm rollback rancher 3 -n cattle-system ## 回滚到 Rancher 2.0-2.1 -我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。 +我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md index b60d3ab748b..e19d19888f5 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md @@ -30,7 +30,7 @@ kubeconfig 也可以通过 `--kubeconfig` 标签（详情请参见 https://helm. -如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。 +如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。 ### 离线安装：推送镜像到私有镜像仓库 @@ -200,7 +200,7 @@ helm upgrade rancher-stable rancher-/rancher \ 升级后出现网络问题？ -请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 +请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 ::: diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md index 06a8d7adfa9..9232b9a6d02 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md @@ -380,7 +380,7 @@ docker run -d --volumes-from rancher-data \ :::note 升级后下游集群出现网络问题？ -请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 +请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。 ::: diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md index 9a1fc4d1078..239f7cc8350 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md @@ -4,7 +4,7 @@ title: Helm 版本要求 本文介绍 Helm 的要求。Helm 是用于把 Rancher 安装在高可用 Kubernetes 集群上的工具。 -> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3，可以使用这个说明安装。 +> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3，可以使用这个说明安装。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md index 5838ed66fed..24a4ae28b21 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md @@ -82,4 +82,4 @@ Rancher 包含一些默认处于实验性和/或禁用的功能，功能开关 - **全局 DNS 条目** - **全局 DNS 提供商** -由于这些是旧版特性，请参考 Rancher v2.0-v2.4 的[应用商店](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [全局 DNS 条目](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), 以及 [全局 DNS 提供商](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider)。 +由于这些是旧版特性，请参考 Rancher v2.0-v2.4 的[应用商店](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [全局 DNS 条目](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), 以及 [全局 DNS 提供商](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider)。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md index de3ce4d164a..c90a84dd62f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md @@ -16,7 +16,7 @@ Rancher 使用应用商店系统导入一系列的 charts 包到仓库里，然 ### Catalogs, Apps, Rancher UI -[在 Rancher v2.4 及更早版本中](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), 存储部署的应用程序的仓库被称为 "catalogs"。这些仓库是通过 UI 的 **Catalogs** 进行管理的。 +[在 Rancher v2.4 及更早版本中](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), 存储部署的应用程序的仓库被称为 "catalogs"。这些仓库是通过 UI 的 **Catalogs** 进行管理的。 Rancher v2.5 用新的 **Apps & Marketplace** 功能替代了之前的 **应用商店**。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index 0b6fc4bac45..5592df2578d 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -109,3 +109,438 @@ Azure 订阅不支持以下账号类型： 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。 1. 单击**创建**按钮来提交表单并创建集群。 + +## Cloud Provider Configuration + +Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names. + +**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).** + +:::note +1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`. +2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB). +3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information. +::: + +Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret. + +Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret. + + ```yaml +# azure-cloud-config.yaml +apiVersion: v1 +kind: Secret +metadata: + name: azure-cloud-config + namespace: kube-system +type: Opaque +stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + + ``` + +## Using the Out-of-tree Azure Cloud Provider + + + + +1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. + +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. + +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. + + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. + +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: + name: azure-cloud-config + namespace: kube-system + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` + +5. Click **Create** to submit the form and create the cluster. + + + + + +1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components. + +2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui). + +Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager. + + + + +### Helm Chart Installation from CLI + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github. + +1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). + +```shell +kubectl apply -f azure-cloud-config.yaml +``` + +2. Add the Helm repository: + +```shell +helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo +helm repo update +``` + +3. Create a `values.yaml` file with the following contents to override the default `values.yaml`: + + + + +```yaml +# values.yaml +infra: + clusterName: +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +``` + + + + + +```yaml +# values.yaml +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/controlplane: 'true' + node-role.kubernetes.io/control-plane: null + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +infra: + clusterName: +``` + + + + +4. Install the Helm chart: + +```shell +helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml +``` + +Verify that the Helm chart installed successfully: + +```shell +helm status cloud-provider-azure -n kube-system +``` + +5. (Optional) Verify that the cloud controller manager update succeeded: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Helm Chart Installation from UI + +1. Click **☰**, then select the name of the cluster from the left navigation. + +2. Select **Apps** > **Repositories**. + +3. Click the **Create** button. + +4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field. + +5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart. + +6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**. + +7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading: + +```yaml + cloudConfigSecretName: azure-cloud-config + enableDynamicReloading: 'true' +``` + +8. Update the following fields as required: + +```yaml + allocateNodeCidrs: 'false' + configureCloudRoutes: 'false' + clusterCIDR: null +``` + + + + +9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector: +```yaml +nodeSelector: + node-role.kubernetes.io/control-plane: 'true' +``` + + + + +10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector: + +```yaml +tolerations: + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + - effect: NoSchedule + value: 'true' + key: node-role.kubernetes.io/controlplane +``` + +```yaml +nodeSelector: + node-role.kubernetes.io/controlplane: 'true' +``` + + + +11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Installing CSI Drivers + +Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively. + +The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md). + +::: note Important: + +Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. + +::: + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github. + +1. Add and update the helm repository: + +```shell +helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts +helm repo update azuredisk-csi-driver +``` + +1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration). + +```shell +helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true +``` + +2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: + +```shell +kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch +``` + +3. Provision an example Storage Class: + +```shell +cat <
The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index 0b6fc4bac45..5592df2578d 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -109,3 +109,438 @@ Azure 订阅不支持以下账号类型： 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。 1. 单击**创建**按钮来提交表单并创建集群。 + +## Cloud Provider Configuration + +Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names. + +**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).** + +:::note +1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`. +2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB). +3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information. +::: + +Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret. + +Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret. + + ```yaml +# azure-cloud-config.yaml +apiVersion: v1 +kind: Secret +metadata: + name: azure-cloud-config + namespace: kube-system +type: Opaque +stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + + ``` + +## Using the Out-of-tree Azure Cloud Provider + + + + +1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. + +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. + +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. + + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. + +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: + name: azure-cloud-config + namespace: kube-system + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` + +5. Click **Create** to submit the form and create the cluster. + + + + + +1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components. + +2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui). + +Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager. + + + + +### Helm Chart Installation from CLI + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github. + +1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). + +```shell +kubectl apply -f azure-cloud-config.yaml +``` + +2. Add the Helm repository: + +```shell +helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo +helm repo update +``` + +3. Create a `values.yaml` file with the following contents to override the default `values.yaml`: + + + + +```yaml +# values.yaml +infra: + clusterName: +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +``` + + + + + +```yaml +# values.yaml +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/controlplane: 'true' + node-role.kubernetes.io/control-plane: null + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +infra: + clusterName: +``` + + + + +4. Install the Helm chart: + +```shell +helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml +``` + +Verify that the Helm chart installed successfully: + +```shell +helm status cloud-provider-azure -n kube-system +``` + +5. (Optional) Verify that the cloud controller manager update succeeded: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Helm Chart Installation from UI + +1. Click **☰**, then select the name of the cluster from the left navigation. + +2. Select **Apps** > **Repositories**. + +3. Click the **Create** button. + +4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field. + +5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart. + +6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**. + +7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading: + +```yaml + cloudConfigSecretName: azure-cloud-config + enableDynamicReloading: 'true' +``` + +8. Update the following fields as required: + +```yaml + allocateNodeCidrs: 'false' + configureCloudRoutes: 'false' + clusterCIDR: null +``` + + + + +9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector: +```yaml +nodeSelector: + node-role.kubernetes.io/control-plane: 'true' +``` + + + + +10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector: + +```yaml +tolerations: + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + - effect: NoSchedule + value: 'true' + key: node-role.kubernetes.io/controlplane +``` + +```yaml +nodeSelector: + node-role.kubernetes.io/controlplane: 'true' +``` + + + +11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Installing CSI Drivers + +Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively. + +The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md). + +::: note Important: + +Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. + +::: + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github. + +1. Add and update the helm repository: + +```shell +helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts +helm repo update azuredisk-csi-driver +``` + +1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration). + +```shell +helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true +``` + +2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: + +```shell +kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch +``` + +3. Provision an example Storage Class: + +```shell +cat <
The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index ff9bbd0e942..072df58ca60 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目、多集群应用以及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目、多集群应用以及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index aef1f3c08b4..a9ceeaba483 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -2,7 +2,7 @@ title: 将用户添加到集群 --- -如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。 +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index aef1f3c08b4..a9ceeaba483 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -2,7 +2,7 @@ title: 将用户添加到集群 --- -如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。 +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md index 8ded77ff3dc..10dba5dc286 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已 | ID | 描述 | 日期 | 解决 | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index 88944e339fc..6b81301e4ad 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -2,7 +2,7 @@ title: 将用户添加到集群 --- -如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。 +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md index 15c6fd4ce46..118b4c896c0 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已 | ID | 描述 | 日期 | 解决 | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 9d2a9590372..8661ceda051 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。 ## 用户和组 -Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 - :::note -本地认证不支持创建或管理组 +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。 + 更多信息，请查看[用户和组](manage-users-and-groups.md) ## Rancher 授权范围 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index 0b6fc4bac45..5592df2578d 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -109,3 +109,438 @@ Azure 订阅不支持以下账号类型： 1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。 1. 单击**创建**按钮来提交表单并创建集群。 + +## Cloud Provider Configuration + +Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names. + +**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).** + +:::note +1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`. +2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB). +3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information. +::: + +Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret. + +Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret. + + ```yaml +# azure-cloud-config.yaml +apiVersion: v1 +kind: Secret +metadata: + name: azure-cloud-config + namespace: kube-system +type: Opaque +stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + + ``` + +## Using the Out-of-tree Azure Cloud Provider + + + + +1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. + +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. + +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. + + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. + +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: + name: azure-cloud-config + namespace: kube-system + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` + +5. Click **Create** to submit the form and create the cluster. + + + + + +1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components. + +2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui). + +Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager. + + + + +### Helm Chart Installation from CLI + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github. + +1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration). + +```shell +kubectl apply -f azure-cloud-config.yaml +``` + +2. Add the Helm repository: + +```shell +helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo +helm repo update +``` + +3. Create a `values.yaml` file with the following contents to override the default `values.yaml`: + + + + +```yaml +# values.yaml +infra: + clusterName: +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +``` + + + + + +```yaml +# values.yaml +cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + configureCloudRoutes: 'false' + allocateNodeCidrs: 'false' + caCertDir: /etc/ssl + enabled: true + replicas: 1 + hostNetworking: true + nodeSelector: + node-role.kubernetes.io/controlplane: 'true' + node-role.kubernetes.io/control-plane: null + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' +infra: + clusterName: +``` + + + + +4. Install the Helm chart: + +```shell +helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml +``` + +Verify that the Helm chart installed successfully: + +```shell +helm status cloud-provider-azure -n kube-system +``` + +5. (Optional) Verify that the cloud controller manager update succeeded: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Helm Chart Installation from UI + +1. Click **☰**, then select the name of the cluster from the left navigation. + +2. Select **Apps** > **Repositories**. + +3. Click the **Create** button. + +4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field. + +5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart. + +6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**. + +7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading: + +```yaml + cloudConfigSecretName: azure-cloud-config + enableDynamicReloading: 'true' +``` + +8. Update the following fields as required: + +```yaml + allocateNodeCidrs: 'false' + configureCloudRoutes: 'false' + clusterCIDR: null +``` + + + + +9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector: +```yaml +nodeSelector: + node-role.kubernetes.io/control-plane: 'true' +``` + + + + +10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector: + +```yaml +tolerations: + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + - effect: NoSchedule + value: 'true' + key: node-role.kubernetes.io/controlplane +``` + +```yaml +nodeSelector: + node-role.kubernetes.io/controlplane: 'true' +``` + + + +11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully: + +```shell +kubectl rollout status deployment -n kube-system cloud-controller-manager +kubectl rollout status daemonset -n kube-system cloud-node-manager +``` + +12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID: + +```shell +kubectl describe nodes | grep "ProviderID" +``` + +### Installing CSI Drivers + +Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively. + +The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md). + +::: note Important: + +Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*. + +::: + +Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github. + +1. Add and update the helm repository: + +```shell +helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts +helm repo update azuredisk-csi-driver +``` + +1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration). + +```shell +helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true +``` + +2. (Optional) Verify that the azuredisk-csi-driver installation succeeded: + +```shell +kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch +``` + +3. Provision an example Storage Class: + +```shell +cat <
The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/shared-files/_cni-popularity.md b/shared-files/_cni-popularity.md index 397ba895f5d..917c38c3699 100644 --- a/shared-files/_cni-popularity.md +++ b/shared-files/_cni-popularity.md @@ -1,10 +1,10 @@ -The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in January 2025. +The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in February 2025. | Provider | Project | Stars | Forks | Contributors | | ---- | ---- | ---- | ---- | ---- | | Canal | https://github.com/projectcalico/canal | 719 | 100 | 20 | -| Flannel | https://github.com/flannel-io/flannel | 8.9k | 2.9k | 236 | -| Calico | https://github.com/projectcalico/calico | 6.2k | 1.4k | 365 | -| Weave | https://github.com/weaveworks/weave | 6.6k | 673 | 84 | -| Cilium | https://github.com/cilium/cilium | 20.7k | 3k | 877 | +| Flannel | https://github.com/flannel-io/flannel | 9k | 2.9k | 236 | +| Calico | https://github.com/projectcalico/calico | 6.2k | 1.4k | 369 | +| Weave | https://github.com/weaveworks/weave | 6.6k | 674 | 84 | +| Cilium | https://github.com/cilium/cilium | 21k | 3.1k | 896 | diff --git a/src/pages/versions.md b/src/pages/versions.md index 532afd5e0ed..53927ff7f45 100644 --- a/src/pages/versions.md +++ b/src/pages/versions.md @@ -18,9 +18,9 @@ Here you can find links to supporting documentation for the current released ver Community - v2.10.2 + v2.10.3 Documentation - Release Notes + Release Notes
N/A
✓
✓
@@ -39,9 +39,9 @@ Here you can find links to supporting documentation for the current released ver Community - v2.9.6 + v2.9.7 Documentation - Release Notes + Release Notes
N/A
✓
N/A
@@ -60,9 +60,9 @@ Here you can find links to supporting documentation for the current released ver Community - v2.8.12 + v2.8.13 Documentation - Release Notes + Release Notes
N/A
✓
N/A
@@ -82,6 +82,14 @@ Here you can find links to supporting documentation for previous versions of Ran Prime Community + + v2.10.2 + Documentation + Release Notes + Support Matrix +
✓
+
✓
+ v2.10.1 Documentation @@ -111,6 +119,14 @@ Here you can find links to supporting documentation for previous versions of Ran Prime Community + + v2.9.6 + Documentation + Release Notes + Support Matrix +
✓
+
N/A
+ v2.9.5 Documentation @@ -174,6 +190,14 @@ Here you can find links to supporting documentation for previous versions of Ran Prime Community + + v2.8.12 + Documentation + Release Notes + Support Matrix +
✓
+
N/A
+ v2.8.11 Documentation diff --git a/versioned_docs/version-2.10/faq/deprecated-features.md b/versioned_docs/version-2.10/faq/deprecated-features.md index 1687b79592d..c0cc6b2f7a5 100644 --- a/versioned_docs/version-2.10/faq/deprecated-features.md +++ b/versioned_docs/version-2.10/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3) | Feb 27, 2025 | | [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 | | [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 | | [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 | diff --git a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md index a3b48a0814d..e7ded014194 100644 --- a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md +++ b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md @@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded. Having network issues following upgrade? -See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). +See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). ::: diff --git a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md index e5334e94708..1845618a5bf 100644 --- a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md +++ b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md @@ -142,7 +142,7 @@ helm rollback rancher 3 -n cattle-system ## Rolling Back to Rancher v2.2-v2.4+ -To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot. +To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot. For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md) @@ -154,4 +154,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran ## Rolling Back to Rancher v2.0-v2.1 -Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible. +Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible. diff --git a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md index e0db870bdc3..21de590a028 100644 --- a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md +++ b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md @@ -35,7 +35,7 @@ The upgrade instructions assume you are using Helm 3. -For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible. +For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible. ### For air-gapped installs: Populate private registry @@ -203,7 +203,7 @@ Log into Rancher to confirm that the upgrade succeeded. Having network issues following upgrade? -See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). +See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). ::: diff --git a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md index 03a7b0cbba2..c4618be475f 100644 --- a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md +++ b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md @@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis :::note Having network issues in your user clusters following upgrade? -See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). +See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md). ::: diff --git a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md index 8ee5618076c..0fb1fb54a82 100644 --- a/versioned_docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md +++ b/versioned_docs/version-2.10/getting-started/installation-and-upgrade/resources/helm-version-requirements.md @@ -8,7 +8,7 @@ title: Helm Version Requirements This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster. -> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible. +> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible. diff --git a/versioned_docs/version-2.10/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.10/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/versioned_docs/version-2.10/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.10/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 4556a3dfa5a..c7449e244b1 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md index 9271d232ff2..80383e56601 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-permissions-and-global-configuration.md @@ -90,4 +90,4 @@ The following features are available under **Global Configuration**: - **Global DNS Entries** - **Global DNS Providers** -As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details. \ No newline at end of file +As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details. \ No newline at end of file diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md index ed6a0faa143..3d5025a8c43 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md @@ -16,7 +16,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories ### Catalogs, Apps, and the Rancher UI -[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. +[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI. Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature. diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index c291376354a..52f9f72a2c1 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -175,34 +175,7 @@ stringData: "loadBalancerSku": "standard", "excludeMasterFromStandardLB": false, } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount - name: azure-cloud-config - namespace: kube-system + ``` ## Using the Out-of-tree Azure Cloud Provider @@ -212,109 +185,85 @@ roleRef: 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. -2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. - - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. -3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. -Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. - ```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: azure-cloud-controller-manager - namespace: kube-system -spec: - chart: cloud-provider-azure - repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo - targetNamespace: kube-system - bootstrap: true - valuesContent: |- - infra: - clusterName: - cloudControllerManager: - cloudConfigSecretName: azure-cloud-config - cloudConfig: null - clusterCIDR: null - enableDynamicReloading: 'true' - nodeSelector: - node-role.kubernetes.io/control-plane: 'true' - allocateNodeCidrs: 'false' - hostNetworking: true - caCertDir: /etc/ssl - configureCloudRoutes: 'false' - enabled: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/master - - effect: NoSchedule - key: node-role.kubernetes.io/control-plane - value: 'true' - - effect: NoSchedule - key: node.cloudprovider.kubernetes.io/uninitialized - value: 'true' ---- -apiVersion: v1 -kind: Secret -metadata: - name: azure-cloud-config - namespace: kube-system -type: Opaque -stringData: - cloud-config: |- - { - "cloud": "AzurePublicCloud", - "tenantId": "", - "subscriptionId": "", - "aadClientId": "", - "aadClientSecret": "", - "resourceGroup": "docker-machine", - "location": "westus", - "subnetName": "docker-machine", - "securityGroupName": "rancher-managed-kqmtsjgJ", - "securityGroupResourceGroup": "docker-machine", - "vnetName": "docker-machine-vnet", - "vnetResourceGroup": "docker-machine", - "primaryAvailabilitySetName": "docker-machine", - "routeTableResourceGroup": "docker-machine", - "cloudProviderBackoff": false, - "useManagedIdentityExtension": false, - "useInstanceMetadata": true, - "loadBalancerSku": "standard", - "excludeMasterFromStandardLB": false, - } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: name: azure-cloud-config namespace: kube-system - ``` + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` -4. Click **Create** to submit the form and create the cluster. +5. Click **Create** to submit the form and create the cluster. diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index ae1bcf2fcb2..ba57f07ddb1 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https: ## Creating a VMware vSphere Cluster +:::note + +User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines. + +::: + 1. [Create your cloud credentials](#1-create-your-cloud-credentials) 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials) 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template) diff --git a/versioned_docs/version-2.10/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.10/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.10/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.10/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.10/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/versioned_docs/version-2.10/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index 472dce754aa..4cca57cda83 100644 --- a/versioned_docs/version-2.10/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/versioned_docs/version-2.10/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -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.3 | v105.0.0+up5.0.1 | | v2.10.2 | v105.0.0+up5.0.1 | | v2.10.1 | v105.0.0+up5.0.1 | | v2.10.0 | v105.0.0+up5.0.1 | diff --git a/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md b/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md index 9125e8536b1..e8b2e4c67d1 100644 --- a/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md +++ b/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md @@ -118,4 +118,4 @@ For more information on configuring PrometheusRules in Rancher, see [this page.] ## Legacy UI -For information on the dashboards available in v2.2 to v2.4 of Rancher, before the introduction of the `rancher-monitoring` application, see the [Rancher v2.0—v2.4 docs](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md). +For information on the dashboards available in v2.2 to v2.4 of Rancher, before the introduction of the `rancher-monitoring` application, see the [Rancher v2.0—v2.4 docs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md). diff --git a/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md b/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md index 79b243cb78d..27575406971 100644 --- a/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md +++ b/versioned_docs/version-2.10/integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md @@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni Introduced in Rancher v2.5, the application is powered by [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/grafana/), [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), and the [Prometheus adapter.](https://github.com/DirectXMan12/k8s-prometheus-adapter) -For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md). +For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md). Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster. diff --git a/versioned_docs/version-2.10/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md b/versioned_docs/version-2.10/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md index 612d323c0f9..43258e491c4 100644 --- a/versioned_docs/version-2.10/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md +++ b/versioned_docs/version-2.10/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md @@ -198,7 +198,7 @@ The node operating system image. For more information for the node image options :::note -The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image. +The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image. ::: diff --git a/versioned_docs/version-2.10/reference-guides/rancher-security/security-advisories-and-cves.md b/versioned_docs/version-2.10/reference-guides/rancher-security/security-advisories-and-cves.md index ebc21bd113b..413a8fe4a66 100644 --- a/versioned_docs/version-2.10/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/versioned_docs/version-2.10/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/versioned_docs/version-2.10/reference-guides/rancher-webhook.md b/versioned_docs/version-2.10/reference-guides/rancher-webhook.md index da79ead873d..c5758046d73 100644 --- a/versioned_docs/version-2.10/reference-guides/rancher-webhook.md +++ b/versioned_docs/version-2.10/reference-guides/rancher-webhook.md @@ -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.3 | v0.6.4 | ✓ | ✓ | | v2.10.2 | v0.6.3 | ✓ | ✓ | | v2.10.1 | v0.6.2 | ✓ | ✓ | | v2.10.0 | v0.6.1 | ✗ | ✓ | diff --git a/versioned_docs/version-2.11/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.11/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/versioned_docs/version-2.11/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.11/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 4556a3dfa5a..c7449e244b1 100644 --- a/versioned_docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.11/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/versioned_docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index c291376354a..52f9f72a2c1 100644 --- a/versioned_docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/versioned_docs/version-2.11/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -175,34 +175,7 @@ stringData: "loadBalancerSku": "standard", "excludeMasterFromStandardLB": false, } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount - name: azure-cloud-config - namespace: kube-system + ``` ## Using the Out-of-tree Azure Cloud Provider @@ -212,109 +185,85 @@ roleRef: 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. -2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. - - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. -3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. -Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. - ```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: azure-cloud-controller-manager - namespace: kube-system -spec: - chart: cloud-provider-azure - repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo - targetNamespace: kube-system - bootstrap: true - valuesContent: |- - infra: - clusterName: - cloudControllerManager: - cloudConfigSecretName: azure-cloud-config - cloudConfig: null - clusterCIDR: null - enableDynamicReloading: 'true' - nodeSelector: - node-role.kubernetes.io/control-plane: 'true' - allocateNodeCidrs: 'false' - hostNetworking: true - caCertDir: /etc/ssl - configureCloudRoutes: 'false' - enabled: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/master - - effect: NoSchedule - key: node-role.kubernetes.io/control-plane - value: 'true' - - effect: NoSchedule - key: node.cloudprovider.kubernetes.io/uninitialized - value: 'true' ---- -apiVersion: v1 -kind: Secret -metadata: - name: azure-cloud-config - namespace: kube-system -type: Opaque -stringData: - cloud-config: |- - { - "cloud": "AzurePublicCloud", - "tenantId": "", - "subscriptionId": "", - "aadClientId": "", - "aadClientSecret": "", - "resourceGroup": "docker-machine", - "location": "westus", - "subnetName": "docker-machine", - "securityGroupName": "rancher-managed-kqmtsjgJ", - "securityGroupResourceGroup": "docker-machine", - "vnetName": "docker-machine-vnet", - "vnetResourceGroup": "docker-machine", - "primaryAvailabilitySetName": "docker-machine", - "routeTableResourceGroup": "docker-machine", - "cloudProviderBackoff": false, - "useManagedIdentityExtension": false, - "useInstanceMetadata": true, - "loadBalancerSku": "standard", - "excludeMasterFromStandardLB": false, - } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: name: azure-cloud-config namespace: kube-system - ``` + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` -4. Click **Create** to submit the form and create the cluster. +5. Click **Create** to submit the form and create the cluster. diff --git a/versioned_docs/version-2.11/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.11/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index ae1bcf2fcb2..ba57f07ddb1 100644 --- a/versioned_docs/version-2.11/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.11/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https: ## Creating a VMware vSphere Cluster +:::note + +User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines. + +::: + 1. [Create your cloud credentials](#1-create-your-cloud-credentials) 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials) 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template) diff --git a/versioned_docs/version-2.11/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.11/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.11/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.11/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.11/reference-guides/rancher-security/security-advisories-and-cves.md b/versioned_docs/version-2.11/reference-guides/rancher-security/security-advisories-and-cves.md index ebc21bd113b..413a8fe4a66 100644 --- a/versioned_docs/version-2.11/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/versioned_docs/version-2.11/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/versioned_docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index 808e3532bbe..22dde6d320c 100644 --- a/versioned_docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -94,7 +94,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 2e2a500e849..7a6b7f7c0dd 100644 --- a/versioned_docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.6/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.7/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.7/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/versioned_docs/version-2.7/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.7/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.7/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md b/versioned_docs/version-2.7/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md index e544e3b5ce1..02930f889a6 100644 --- a/versioned_docs/version-2.7/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md +++ b/versioned_docs/version-2.7/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md @@ -6,7 +6,7 @@ title: Continuous Delivery -[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet.md) comes preinstalled in Rancher and can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag. +[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md) comes preinstalled in Rancher and can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag. To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](enable-experimental-features.md) diff --git a/versioned_docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 74bb1f242aa..0f64cebf4e6 100644 --- a/versioned_docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.7/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.7/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md b/versioned_docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md index 03721cb9754..59ce5ddefbd 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,7 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/versioned_docs/version-2.8/faq/deprecated-features.md b/versioned_docs/version-2.8/faq/deprecated-features.md index f10347c69f9..56bd48d4d40 100644 --- a/versioned_docs/version-2.8/faq/deprecated-features.md +++ b/versioned_docs/version-2.8/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | Feb 27, 2025 | | [2.8.12](https://github.com/rancher/rancher/releases/tag/v2.8.12) | Jan 29, 2025 | | [2.8.11](https://github.com/rancher/rancher/releases/tag/v2.8.11) | Dec 18, 2024 | | [2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10) | Nov 18, 2024 | diff --git a/versioned_docs/version-2.8/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.8/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/versioned_docs/version-2.8/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.8/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index b93e4377fa5..f3ecd1f9dc3 100644 --- a/versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -42,14 +42,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index d7835c437a8..0694c461321 100644 --- a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https: ## Creating a VMware vSphere Cluster +:::note + +User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines. + +::: + 1. [Create your cloud credentials](#1-create-your-cloud-credentials) 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials) 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template) diff --git a/versioned_docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.8/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.8/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/versioned_docs/version-2.8/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index ee809e3c4b1..2c47b56bea6 100644 --- a/versioned_docs/version-2.8/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/versioned_docs/version-2.8/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers | Rancher Version | Adapter Version | |-----------------|------------------| +| v2.8.13 | v103.0.1+up3.0.1 | | v2.8.12 | v103.0.1+up3.0.1 | | v2.8.11 | v103.0.1+up3.0.1 | | v2.8.10 | v103.0.1+up3.0.1 | diff --git a/versioned_docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md b/versioned_docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md index ebc21bd113b..413a8fe4a66 100644 --- a/versioned_docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/versioned_docs/version-2.8/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/versioned_docs/version-2.8/reference-guides/rancher-webhook.md b/versioned_docs/version-2.8/reference-guides/rancher-webhook.md index a0c146202a5..c69ddb50c45 100644 --- a/versioned_docs/version-2.8/reference-guides/rancher-webhook.md +++ b/versioned_docs/version-2.8/reference-guides/rancher-webhook.md @@ -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.8.13 | v0.4.15 | ✓ | ✗ | | v2.8.12 | v0.4.15 | ✓ | ✗ | | v2.8.11 | v0.4.14 | ✓ | ✗ | | v2.8.10 | v0.4.13 | ✓ | ✗ | diff --git a/versioned_docs/version-2.9/faq/deprecated-features.md b/versioned_docs/version-2.9/faq/deprecated-features.md index d634127ee75..a3f98dba68f 100644 --- a/versioned_docs/version-2.9/faq/deprecated-features.md +++ b/versioned_docs/version-2.9/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) | Feb 27, 2025 | | [2.9.6](https://github.com/rancher/rancher/releases/tag/v2.9.6) | Jan 29, 2025 | | [2.9.5](https://github.com/rancher/rancher/releases/tag/v2.9.5) | Dec 19, 2024 | | [2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | Nov 18, 2024 | diff --git a/versioned_docs/version-2.9/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.9/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index fc63b5900c1..c69037a16a0 100644 --- a/versioned_docs/version-2.9/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.9/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -95,7 +95,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. ## Install Rancher with Helm -Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed. +Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm](https://helm.sh/docs/intro/install/) installed. :::note diff --git a/versioned_docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md b/versioned_docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md index 4c3ea2d72c1..d861f84c492 100644 --- a/versioned_docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md +++ b/versioned_docs/version-2.9/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md @@ -43,14 +43,15 @@ In most cases, you should use an external authentication service over local auth ## Users and Groups -Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). - :::note -Local authentication does not support creating or managing groups. +- Local authentication does not support creating or managing groups. +- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider. ::: +Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md). + For more information, see [Users and Groups](manage-users-and-groups.md) ## Scope of Rancher Authorization diff --git a/versioned_docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md b/versioned_docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md index c291376354a..52f9f72a2c1 100644 --- a/versioned_docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md +++ b/versioned_docs/version-2.9/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/azure.md @@ -175,34 +175,7 @@ stringData: "loadBalancerSku": "standard", "excludeMasterFromStandardLB": false, } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount - name: azure-cloud-config - namespace: kube-system + ``` ## Using the Out-of-tree Azure Cloud Provider @@ -212,109 +185,85 @@ roleRef: 1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section. -2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. - - Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. +2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. -3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`. +3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster. -Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. - ```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: azure-cloud-controller-manager - namespace: kube-system -spec: - chart: cloud-provider-azure - repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo - targetNamespace: kube-system - bootstrap: true - valuesContent: |- - infra: - clusterName: - cloudControllerManager: - cloudConfigSecretName: azure-cloud-config - cloudConfig: null - clusterCIDR: null - enableDynamicReloading: 'true' - nodeSelector: - node-role.kubernetes.io/control-plane: 'true' - allocateNodeCidrs: 'false' - hostNetworking: true - caCertDir: /etc/ssl - configureCloudRoutes: 'false' - enabled: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/master - - effect: NoSchedule - key: node-role.kubernetes.io/control-plane - value: 'true' - - effect: NoSchedule - key: node.cloudprovider.kubernetes.io/uninitialized - value: 'true' ---- -apiVersion: v1 -kind: Secret -metadata: - name: azure-cloud-config - namespace: kube-system -type: Opaque -stringData: - cloud-config: |- - { - "cloud": "AzurePublicCloud", - "tenantId": "", - "subscriptionId": "", - "aadClientId": "", - "aadClientSecret": "", - "resourceGroup": "docker-machine", - "location": "westus", - "subnetName": "docker-machine", - "securityGroupName": "rancher-managed-kqmtsjgJ", - "securityGroupResourceGroup": "docker-machine", - "vnetName": "docker-machine-vnet", - "vnetResourceGroup": "docker-machine", - "primaryAvailabilitySetName": "docker-machine", - "routeTableResourceGroup": "docker-machine", - "cloudProviderBackoff": false, - "useManagedIdentityExtension": false, - "useInstanceMetadata": true, - "loadBalancerSku": "standard", - "excludeMasterFromStandardLB": false, - } ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRole -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -rules: - - apiGroups: [""] -resources: ["secrets"] -resourceNames: ["azure-cloud-config"] -verbs: - - get ---- -apiVersion: rbac.authorization.k8s.io/v1beta1 -kind: ClusterRoleBinding -metadata: - labels: - kubernetes.io/cluster-service: "true" - name: system:azure-cloud-provider-secret-getter -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: system:azure-cloud-provider-secret-getter - subjects: - - kind: ServiceAccount +4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**. +Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/). + + Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli). + + ```yaml + apiVersion: helm.cattle.io/v1 + kind: HelmChart + metadata: + name: azure-cloud-controller-manager + namespace: kube-system + spec: + chart: cloud-provider-azure + repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo + targetNamespace: kube-system + bootstrap: true + valuesContent: |- + infra: + clusterName: + cloudControllerManager: + cloudConfigSecretName: azure-cloud-config + cloudConfig: null + clusterCIDR: null + enableDynamicReloading: 'true' + nodeSelector: + node-role.kubernetes.io/control-plane: 'true' + allocateNodeCidrs: 'false' + hostNetworking: true + caCertDir: /etc/ssl + configureCloudRoutes: 'false' + enabled: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + - effect: NoSchedule + key: node-role.kubernetes.io/control-plane + value: 'true' + - effect: NoSchedule + key: node.cloudprovider.kubernetes.io/uninitialized + value: 'true' + --- + apiVersion: v1 + kind: Secret + metadata: name: azure-cloud-config namespace: kube-system - ``` + type: Opaque + stringData: + cloud-config: |- + { + "cloud": "AzurePublicCloud", + "tenantId": "", + "subscriptionId": "", + "aadClientId": "", + "aadClientSecret": "", + "resourceGroup": "docker-machine", + "location": "westus", + "subnetName": "docker-machine", + "securityGroupName": "rancher-managed-kqmtsjgJ", + "securityGroupResourceGroup": "docker-machine", + "vnetName": "docker-machine-vnet", + "vnetResourceGroup": "docker-machine", + "primaryAvailabilitySetName": "docker-machine", + "routeTableResourceGroup": "docker-machine", + "cloudProviderBackoff": false, + "useManagedIdentityExtension": false, + "useInstanceMetadata": true, + "loadBalancerSku": "standard", + "excludeMasterFromStandardLB": false, + } + ``` -4. Click **Create** to submit the form and create the cluster. +5. Click **Create** to submit the form and create the cluster. diff --git a/versioned_docs/version-2.9/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.9/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index ae1bcf2fcb2..ba57f07ddb1 100644 --- a/versioned_docs/version-2.9/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.9/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -52,6 +52,12 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https: ## Creating a VMware vSphere Cluster +:::note + +User-data.iso files may have become orphaned upon node deletion due to a vSphere node driver or custom clusters created before v2.9.1. While [this issue](https://github.com/rancher/rancher/issues/25073) is resolved, no automatic cleanup exists for these previously orphaned files. vSphere administrators can manually remove orphaned files, but be careful not to remove files being used by existing machines, as this may cause outages for downstream virtual machines. + +::: + 1. [Create your cloud credentials](#1-create-your-cloud-credentials) 2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials) 3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template) diff --git a/versioned_docs/version-2.9/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md b/versioned_docs/version-2.9/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md index ebb64045d5c..dae224a37b2 100644 --- a/versioned_docs/version-2.9/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md +++ b/versioned_docs/version-2.9/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md @@ -6,7 +6,7 @@ title: Adding Users to Clusters -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. +To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members. :::tip diff --git a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index 84c55322412..74372a81517 100644 --- a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -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.7 | v104.0.0+up4.0.0 | | v2.9.6 | v104.0.0+up4.0.0 | | v2.9.5 | v104.0.0+up4.0.0 | | v2.9.4 | v104.0.0+up4.0.0 | diff --git a/versioned_docs/version-2.9/reference-guides/rancher-security/security-advisories-and-cves.md b/versioned_docs/version-2.9/reference-guides/rancher-security/security-advisories-and-cves.md index 8e29a56692b..aac0b9d126f 100644 --- a/versioned_docs/version-2.9/reference-guides/rancher-security/security-advisories-and-cves.md +++ b/versioned_docs/version-2.9/reference-guides/rancher-security/security-advisories-and-cves.md @@ -10,7 +10,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| -| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | +| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue.

This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig).

Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) | +| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | | [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). | | [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | | [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | diff --git a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md index 4b8216e3ea6..717474efaff 100644 --- a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md +++ b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md @@ -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.7 | v0.5.7 | ✓ | ✗ | | v2.9.6 | v0.5.6 | ✓ | ✗ | | v2.9.5 | v0.5.5 | ✓ | ✗ | | v2.9.4 | v0.5.4 | ✓ | ✗ |