mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 13:08:11 +00:00
Merge branch 'rancher:main' into update-directories
This commit is contained in:
Sunil Singh
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Extension API Server
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/extension-apiserver"/>
|
||||
</head>
|
||||
|
||||
Rancher extends Kubernetes with additional APIs by registering an extension API server using the [Kubernetes API Aggregation Layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
|
||||
## Disabling the extension API server
|
||||
|
||||
The [aggregation layer must be configured](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) on the local Kubernetes cluster for the `imperative-api-extension` feature to be enabled and to work correctly. The feature assumes this is configured and is enabled by default. If it is not possible to configure the aggregation layer for your local Kubernetes cluster, then you must disable the feature. The `imperative-api-extension` feature flag can be disabled by either using the [Rancher UI](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-ui) or [Rancher API](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md#disabling-features-with-the-rancher-api).
|
||||
|
||||
It will still be possible to access the additional APIs when the feature is disabled. The additional APIs are available at `https://<rancher url>/ext` and they are compatible with the Kubernetes apiserver. This means you can use `curl` or `kubectl` to interact with the APIs.
|
||||
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
| [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | Apr 24, 2025 |
|
||||
| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | Mar 31, 2025 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
@@ -91,11 +91,11 @@ The UI consists of static files, and works based on responses of the API. That m
|
||||
|
||||
## The IP address of a node changed, how can I recover?
|
||||
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and add it again. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
|
||||
When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.
|
||||
|
||||
When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
|
||||
When the node is removed from the cluster, and the node is cleaned, you can add the node to the cluster.
|
||||
|
||||
## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
|
||||
+1
-1
@@ -35,7 +35,7 @@ The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
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 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
|
||||
|
||||
|
||||
@@ -18,8 +18,6 @@ In this section,
|
||||
- **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
|
||||
- **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
Note the `restrictedAdmin` Helm chart option available for **the Rancher Server**. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)
|
||||
|
||||
## Overview of Installation Options
|
||||
|
||||
Rancher can be installed on these main architectures:
|
||||
|
||||
+7
-1
@@ -16,11 +16,14 @@ Some feature flags require a restart of the Rancher container. Features that req
|
||||
|
||||
:::
|
||||
|
||||
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [Cluster Role Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md) for more information.
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
|
||||
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
|
||||
- `imperative-api-extension`: Enables Rancher's [extension API server](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) to register new APIs to Kubernetes. This flag is enabled by default. See the [Extension API Server](../../../api/extension-apiserver.md) page for more information.
|
||||
- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
|
||||
- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
|
||||
- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
|
||||
@@ -37,11 +40,14 @@ The following table shows the availability and default values for some feature f
|
||||
|
||||
| Feature Flag Name | Default Value | Status | Available As Of | Additional Information |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
|
||||
| `aggregated-roletemplates` | `false` | Highly experimentatl | v2.11.0 | This flag value is locked on install and can't be changed. |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 | |
|
||||
| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
|
||||
| `fleet` | `true` | Can no longer be disabled | v2.6.0 | |
|
||||
| `fleet` | `true` | GA | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `imperative-api-extension` | `true` | GA | v2.11.0 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
|
||||
| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
|
||||
|
||||
-1
@@ -59,7 +59,6 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
| `rancherImageTag` | same as chart version | `string` - rancher/rancher image tag |
|
||||
| `replicas` | 3 | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster. |
|
||||
| `resources` | {} | `map` - rancher pod resource requests & limits |
|
||||
| `restrictedAdmin` | `false` | `bool` - When this option is set to `true`, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin). |
|
||||
| `systemDefaultRegistry` | "" | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations. |
|
||||
|
||||
+3
-1
@@ -6,6 +6,8 @@ title: Upgrading Kubernetes without Upgrading Rancher
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
|
||||
|
||||
:::note
|
||||
@@ -87,7 +89,7 @@ After new Kubernetes versions are loaded into the Rancher setup, additional step
|
||||
To download the system images for the private registry:
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Click **About** at the bottom of the left navigation.
|
||||
1. At the bottom of the left navigation, click the Rancher version number.
|
||||
1. Download the OS specific image lists for Linux or Windows.
|
||||
1. Download `rancher-images.txt`.
|
||||
1. Prepare the private registry using the same steps during the [air gap install](other-installation-methods/air-gapped-helm-cli-install/publish-images.md), but instead of using the `rancher-images.txt` from the releases page, use the one obtained from the previous steps.
|
||||
|
||||
@@ -27,15 +27,13 @@ This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- An [Equinix Metal account](https://metal.equinix.com/developers/docs/accounts/users/)
|
||||
- An [Equinix Metal project](https://metal.equinix.com/developers/docs/accounts/projects/)
|
||||
- An [Equinix Metal account](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
|
||||
- An [Equinix Metal project](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)
|
||||
|
||||
|
||||
### 1. Provision a Equinix Metal Host
|
||||
|
||||
Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://metal.equinix.com/developers/docs/deploy/on-demand/). You can find additional documentation on Equinix Metal server types and prices below:
|
||||
- [Equinix Metal Server Types](https://metal.equinix.com/developers/docs/servers/about/)
|
||||
- [Equinix Metal Pricing](https://metal.equinix.com/developers/docs/servers/server-specs/)
|
||||
Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://deploy.equinix.com/developers/docs/metal/deploy/on-demand/). You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).
|
||||
|
||||
:::note Notes:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -20,12 +20,13 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
|
||||
- At least 4GB of free RAM.
|
||||
|
||||
### Note
|
||||
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
|
||||
:::note
|
||||
|
||||
`vagrant plugin install vagrant-vboxmanage`
|
||||
Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands:
|
||||
- `vagrant plugin install vagrant-vboxmanage`
|
||||
- `vagrant plugin install vagrant-vbguest`
|
||||
|
||||
`vagrant plugin install vagrant-vbguest`
|
||||
:::
|
||||
|
||||
## Getting Started
|
||||
|
||||
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: Enabling Cluster Agent Scheduling Customization
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-cluster-agent-scheduling-customization"/>
|
||||
</head>
|
||||
|
||||
The `cattle-cluster-agent` allows enabling automatic deployment of a Priority Class and Pod Disruption Budget.
|
||||
|
||||
When this feature is enabled, all newly provisioned Node Driver, Custom, and Imported RKE2 and K3s clusters will automatically deploy a Priority Class and Pod Disruption Budget during the provisioning process. Existing clusters can be gradually updated with this new behavior using the [Rancher UI or by setting a specific annotation](#updating-existing-clusters) on cluster objects.
|
||||
|
||||
This feature is disabled by default.
|
||||
|
||||
## Enabling Cluster Agent Scheduling Customization
|
||||
|
||||
:::info
|
||||
Enabling or disabling this feature only impacts new clusters. Existing downstream clusters will not be automatically updated. See [_Updating Existing Clusters_](#updating-existing-clusters).
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**
|
||||
1. Select **Feature Flags**
|
||||
1. Find the `cluster-agent-scheduling-customization` feature and click **⋮ > Activate**
|
||||
|
||||
## Configuring the Global Settings
|
||||
|
||||
You can customize the default Priority Class (PC) and Pod Disruption Budget (PDB) by updating the `cluster-agent-default-priority-class` and `cluster-agent-default-pod-disruption-budget` global settings in the Rancher UI. Note that both the Priority Class and Pod Disruption Budget have configuration restrictions:
|
||||
|
||||
+ The `Value` set for the default PC cannot be less than negative 1 billion, or greater than 1 billion.
|
||||
+ The `PreemptionPolicy` set for the PC must be equal to `PreemptLowerPriority` or `Never`.
|
||||
+ You cannot configure the PDB `minAvailable` and `maxUnavailable` fields to both have a non-zero value.
|
||||
+ The PDB `minAvailable` must either be a non-negative whole number integer, or a non-negative whole number percent (e.g. `1` or `100%`).
|
||||
+ The PDB `maxUnavailable` must either be a non-negative whole number integer, or a non-negative whole number percent (e.g. `1` or `100%`).
|
||||
|
||||
|
||||
## Updating Existing Clusters
|
||||
|
||||
:::info
|
||||
When this feature is disabled, you cannot modify the cluster agent scheduling customization fields for existing clusters. However, you can always remove the configuration, regardless of the feature's status.
|
||||
:::
|
||||
|
||||
After enabling this feature, you can configure scheduling customization for existing clusters in two ways:
|
||||
|
||||
+ **Using the Rancher UI**
|
||||
+ Edit the desired cluster and navigate to the **Cluster Agent** tab within the **Cluster Configuration** section.
|
||||
+ Enable the `Prevent Rancher cluster agent pod eviction` checkbox.
|
||||
+ The necessary fields on the associated `clusters.provisioning.cattle.io` or `clusters.management.cattle.io` object will be automatically configured using the values set in the global settings.
|
||||
+ Save the cluster.
|
||||
+ **Using an annotation**
|
||||
+ The `provisioning.cattle.io/enable-scheduling-customization` annotation can be used to update clusters without requiring the use of the Rancher UI. This annotation will be automatically removed from the cluster after the Priority Class and Pod Disruption Budget are configured.
|
||||
+ The value of this annotation can be either `true` or `false`, to add or remove scheduling customization automatically.
|
||||
+ For Node Driver Provisioned and Custom clusters, apply this annotation on the associated `clusters.provisioning.cattle.io` object.
|
||||
+ For Imported clusters, apply the annotation on the associated `clusters.management.cattle.io` object.
|
||||
|
||||
## Applying Updated Global Settings
|
||||
|
||||
In order to prevent unexpected changes in scheduler behavior, Rancher does not update existing downstream clusters when the `cluster-agent-default-priority-class` and `cluster-agent-default-pod-disruption-budget` global settings are changed. There are two ways to update existing clusters to use the most recent global settings:
|
||||
|
||||
+ **Using the Rancher UI**
|
||||
+ When configuring a cluster, an additional checkbox will be shown in the **Cluster Agent** tab within the **Cluster Configuration** section. Checking the `Apply global settings for Priority Class and Pod Disruption Budget` checkbox will automatically update the Priority Class and Pod Disruption Budget to match the global settings once the cluster is saved.
|
||||
+ **Adjusting the cluster yaml**
|
||||
+ You may manually adjust the relevant fields in the cluster object using `kubectl` or the Rancher UI 'Edit As Yaml' feature. Scheduling customization can be found in the `spec.ClusterAgentDeploymentCustomization.SchedulingCustomization` section of the cluster object.
|
||||
+ Alternatively, the `provisioning.cattle.io/enable-scheduling-customization` annotation can be used to remove and re-add the updated scheduling customization fields set on a specific cluster.
|
||||
|
||||
## Downstream Objects
|
||||
|
||||
When this feature is enabled for a given cluster, two downstream resources will be automatically created by Rancher:
|
||||
|
||||
+ A Pod Disruption Budget will be automatically created in the `cattle-system` namespace, named `cattle-cluster-agent-pod-disruption-budget`.
|
||||
+ A Priority Class will be automatically created, named `cattle-cluster-agent-priority-class`.
|
||||
|
||||
These objects are maintained by Rancher and must not be modified or deleted. The Rancher server will automatically update these objects to match the configuration set on the Cluster object and remove them when they are no longer needed.
|
||||
|
||||
### RBAC considerations
|
||||
|
||||
Before enabling this feature on a downstream cluster, cluster administrators should assess their current RBAC configuration to prevent common access to the `cattle-cluster-agent-priority-class`. In cases where external users have access to a cluster, such as when offering clusters as a service, it is recommended to limit access to the `cattle-cluster-agent-priority-class` object to prevent changes or deletion.
|
||||
|
||||
Similar considerations do not need to be made for the `cattle-cluster-agent-pod-disruption-budget` object, as Pod Disruption Budgets are namespaced objects. Rancher will create the `cattle-cluster-agent-pod-disruption-budget` in the privileged `cattle-system` namespace.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: ClusterRole Aggregation
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation"/>
|
||||
</head>
|
||||
|
||||
:::caution
|
||||
ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11. It is expected to be available as a beta for users in v2.12 with a prospective GA in Rancher v2.13.
|
||||
:::
|
||||
|
||||
ClusterRole aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
|
||||
|
||||
| Environment Variable Key | Default Value | Description |
|
||||
| --- | --- | --- |
|
||||
| `aggregated-roletemplates` | `false` | [Experimental] Make RoleTemplates use aggregation for generated RBAC roles. |
|
||||
|
||||
The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
|
||||
@@ -6,6 +6,14 @@ title: Enable Istio in the Cluster
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-cluster"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Enable Istio in a Namespace
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-namespace"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
You will need to manually enable Istio in each namespace that you want to be tracked or controlled by Istio. When Istio is enabled in a namespace, the Envoy sidecar proxy will be automatically injected into all new workloads that are deployed in the namespace.
|
||||
|
||||
This namespace setting will only affect new workloads in the namespace. Any preexisting workloads will need to be re-deployed to leverage the sidecar auto injection.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Generate and View Traffic from Istio
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
## The Kiali Traffic Graph
|
||||
|
||||
The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you can view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Istio Setup Guides
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
This section describes how to enable Istio and start using it in your projects.
|
||||
|
||||
If you use Istio for traffic management, you will need to allow external traffic to the cluster. In that case, you will need to follow all of the steps below.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Set up the Istio Gateway
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
The gateway to each cluster can have its own port or load balancer, which is unrelated to a service mesh. By default, each Rancher-provisioned cluster has one NGINX ingress controller allowing traffic into the cluster.
|
||||
|
||||
You can use the Nginx Ingress controller with or without Istio installed. If this is the only gateway to your cluster, Istio will be able to route traffic from service to service, but Istio will not be able to receive traffic from outside the cluster.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Set up Istio's Components for Traffic Management
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
A central advantage of traffic management in Istio is that it allows dynamic request routing. Some common applications for dynamic request routing include canary deployments and blue/green deployments. The two key resources in Istio traffic management are *virtual services* and *destination rules*.
|
||||
|
||||
- [Virtual services](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/) intercept and direct traffic to your Kubernetes services, allowing you to divide percentages of traffic from a request to different services. You can use them to define a set of routing rules to apply when a host is addressed.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Add Deployments and Services with the Istio Sidecar
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/use-istio-sidecar"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
To enable Istio for a workload, the cluster and namespace must have the Istio app installed.
|
||||
|
||||
@@ -31,6 +31,14 @@ Following project creation, you can add users as project members so that they ca
|
||||
1. In the **Members** tab, click **Add**.
|
||||
1. Search for the user or group that you want to add to the project.
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
|
||||
If external authentication is configured:
|
||||
|
||||
- Rancher returns users from your external authentication source as you type.
|
||||
@@ -63,4 +71,4 @@ Following project creation, you can add users as project members so that they ca
|
||||
**Result:** The chosen users are added to the project.
|
||||
|
||||
- To revoke project membership, select the user and click **Delete**. This action deletes membership, not the user.
|
||||
- To modify a user's roles in the project, delete them from the project, and then re-add them with modified roles.
|
||||
- To modify a user's roles in the project, delete them from the project, and then re-add them with modified roles.
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: About RKE1 Templates
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
RKE templates are designed to allow DevOps and security teams to standardize and simplify the creation of Kubernetes clusters.
|
||||
|
||||
RKE is the [Rancher Kubernetes Engine,](https://rancher.com/docs/rke/latest/en/) which is the tool that Rancher uses to provision Kubernetes clusters.
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Creating and Revising RKE Templates
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This section describes how to manage RKE templates and revisions. You an create, share, update, and delete templates from the **Cluster Management** view under **RKE1 Configuration > RKE Templates**.
|
||||
|
||||
Template updates are handled through a revision system. When template owners want to change or update a template, they create a new revision of the template. Individual revisions cannot be edited. However, if you want to prevent a revision from being used to create a new cluster, you can disable it.
|
||||
|
||||
+4
-3
@@ -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
|
||||
|
||||
+114
-76
@@ -3,7 +3,7 @@ title: Configure Keycloak (OIDC)
|
||||
description: Create a Keycloak OpenID Connect (OIDC) client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-keycloak-oidc"/>
|
||||
</head>
|
||||
|
||||
@@ -17,55 +17,88 @@ If you have an existing configuration using the SAML protocol and want to switch
|
||||
|
||||
- On Rancher, Keycloak (SAML) is disabled.
|
||||
- You must have a [Keycloak IdP Server](https://www.keycloak.org/guides#getting-started) configured.
|
||||
- In Keycloak, create a [new OIDC client](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients), with the settings below. See the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients) for help.
|
||||
- Follow the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#proc-creating-oidc-client_server_administration_guide) to create a new OIDC client with the settings below.
|
||||
|
||||
Setting | Value
|
||||
------------|------------
|
||||
`Client ID` | <CLIENT_ID> (e.g. `rancher`)
|
||||
`Name` | <CLIENT_NAME> (e.g. `rancher`)
|
||||
`Client Protocol` | `openid-connect`
|
||||
`Access Type` | `confidential`
|
||||
`Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Client ID` | <client-id> (e.g. `rancher`) |
|
||||
| `Name` | <client-name> (e.g. `rancher`) |
|
||||
| `Client type` | `OpenID Connect` |
|
||||
| `Client authentication` | `ON` |
|
||||
| `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth` |
|
||||
|
||||
- In the new OIDC client, create [Mappers](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers) to expose the users fields.
|
||||
- Create a new "Groups Mapper" with the settings below.
|
||||
1. In the navigation menu, click **Clients**.
|
||||
1. Click the **Clients list** tab.
|
||||
1. Find and click the client you created.
|
||||
1. Click the **Client scopes** tab.
|
||||
1. Find and click the link labeled `<client-name>-dedicated`. For example, if you named your client `rancher`, look for the link named `rancher-dedicated`.
|
||||
1. Click the **Mappers** tab.
|
||||
1. Click **Configure a new mapper**. If you already have existing mappers configured, click the arrow next to **Add mapper** and select **By configuration**. Repeat this process and create these mappers:
|
||||
- From the mappings table, select **Group Membership** and configure a new "Groups Mapper" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
Setting | Value
|
||||
------------|------------
|
||||
`Name` | `Groups Mapper`
|
||||
`Mapper Type` | `Group Membership`
|
||||
`Token Claim Name` | `groups`
|
||||
`Full group path` | `OFF`
|
||||
`Add to ID token` | `OFF`
|
||||
`Add to access token` | `OFF`
|
||||
`Add to user info` | `ON`
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Full group path` | `OFF` |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `OFF` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- Create a new "Client Audience" with the settings below.
|
||||
- From the mappings table, select **Audience** and configure a new "Client Audience" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
Setting | Value
|
||||
------------|------------
|
||||
`Name` | `Client Audience`
|
||||
`Mapper Type` | `Audience`
|
||||
`Included Client Audience` | <CLIENT_NAME>
|
||||
`Add to ID token` | `OFF`
|
||||
`Add to access token` | `ON`
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Client Audience` |
|
||||
| `Mapper Type` | `Audience` |
|
||||
| `Included Client Audience` | <client-name> |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `ON` |
|
||||
|
||||
- Create a new "Groups Path" with the settings below.
|
||||
- From the mappings table, select **Group Membership** and configure a new "Groups Path" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
Setting | Value
|
||||
------------|------------
|
||||
`Name` | `Group Path`
|
||||
`Mapper Type` | `Group Membership`
|
||||
`Token Claim Name` | `full_group_path`
|
||||
`Full group path` | `ON`
|
||||
`Add to ID token` | `ON`
|
||||
`Add to access token` | `ON`
|
||||
`Add to user info` | `ON`
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Group Path` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `full_group_path` |
|
||||
| `Full group path` | `ON` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- Go to **Role Mappings > Client Roles > realm-management** and add the following Role Mappings to all users or groups that need to query the Keycloak users.
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
- Add the following role mappings to all users or groups that need to query the Keycloak users.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Users">
|
||||
|
||||
1. In the navigation menu, click **Users**.
|
||||
1. Click the user you want to add role mappings to.
|
||||
1. Click the **Role mapping** tab.
|
||||
1. Click **Assign role**.
|
||||
1. Select the following roles:
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
1. Click **Assign**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Groups">
|
||||
|
||||
1. In the navigation menu, click **Groups**.
|
||||
1. Click the group you want to add role mappings to.
|
||||
1. Click the **Role mapping** tab.
|
||||
1. Click **Assign role**.
|
||||
1. Select the following roles:
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
1. Click **Assign**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Configuring Keycloak in Rancher
|
||||
|
||||
@@ -73,6 +106,13 @@ If you have an existing configuration using the SAML protocol and want to switch
|
||||
1. In the left navigation bar, click **Auth Provider**.
|
||||
1. Select **Keycloak (OIDC)**.
|
||||
1. Complete the **Configure a Keycloak OIDC account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
|
||||
|
||||
:::note
|
||||
|
||||
When configuring the **Endpoints** section using the **Generate** option, Rancher includes `/auth` as part of the context path in the **Issuer** and **Auth Endpoint** fields, which is only valid for Keycloak 16 or older. You must configure endpoints using the **Specify** option for [Keycloak 17](https://www.keycloak.org/docs/latest/release_notes/index.html#keycloak-17-0-0) and newer, which have [migrated to Quarkus](https://www.keycloak.org/migration/migrating-to-quarkus).
|
||||
|
||||
:::
|
||||
|
||||
1. After you complete the **Configure a Keycloak OIDC account** form, click **Enable**.
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
|
||||
@@ -83,7 +123,7 @@ If you have an existing configuration using the SAML protocol and want to switch
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with Keycloak using the OIDC protocol. Your users can now sign into Rancher using their Keycloak logins.
|
||||
**Result:** Rancher is configured to work with Keycloak using the OIDC protocol. Your users can now sign in to Rancher using their Keycloak logins.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
@@ -103,37 +143,19 @@ If you have an existing configuration using the SAML protocol and want to switch
|
||||
|
||||
This section describes the process to transition from using Rancher with Keycloak (SAML) to Keycloak (OIDC).
|
||||
|
||||
### Reconfigure Keycloak
|
||||
1. Reconfigure Keycloak.
|
||||
1. Configure a new `OpenID Connect` client according to the [Prerequisites](#prerequisites). Ensure the same `Valid Redirect URIs` are set.
|
||||
1. Configure mappers for the new client according to the [Prerequisites](#prerequisites).
|
||||
1. Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled.
|
||||
1. In the Rancher UI, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Auth Provider**.
|
||||
1. Select **Keycloak (SAML)**.
|
||||
1. Click **Disable**.
|
||||
1. Follow the steps in [Configuring Keycloak in Rancher](#configuring-keycloak-in-rancher).
|
||||
|
||||
1. Change the existing client to use the OIDC protocol. In the Keycloak console, select **Clients**, select the SAML client to migrate, select the **Settings** tab, change `Client Protocol` from `saml` to `openid-connect`, and click **Save**
|
||||
:::caution
|
||||
|
||||
1. Verify the `Valid Redirect URIs` are still valid.
|
||||
|
||||
1. Select the **Mappers** tab and create a new Mapper with the settings below.
|
||||
|
||||
Setting | Value
|
||||
------------|------------
|
||||
`Name` | `Groups Mapper`
|
||||
`Mapper Type` | `Group Membership`
|
||||
`Token Claim Name` | `groups`
|
||||
`Add to ID token` | `ON`
|
||||
`Add to access token` | `ON`
|
||||
`Add to user info` | `ON`
|
||||
|
||||
### Reconfigure Rancher
|
||||
|
||||
Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled.
|
||||
|
||||
1. In the Rancher UI, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Auth Provider**.
|
||||
1. Select **Keycloak (SAML)**.
|
||||
1. Click **Disable**.
|
||||
|
||||
Configure Rancher to use Keycloak (OIDC) by following the steps in [this section](#configuring-keycloak-in-rancher).
|
||||
|
||||
:::note
|
||||
|
||||
After configuration is completed, Rancher user permissions will need to be reapplied as they are not automatically migrated.
|
||||
After configuration is completed, Rancher user permissions need to be reapplied as they are not automatically migrated.
|
||||
|
||||
:::
|
||||
|
||||
@@ -141,18 +163,34 @@ After configuration is completed, Rancher user permissions will need to be reapp
|
||||
|
||||
If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration options of your OIDC client. You may also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
|
||||
|
||||
All Keycloak related log entries will be prepended with either `[generic oidc]` or `[keycloak oidc]`.
|
||||
All Keycloak related log entries are prepended with either `[generic oidc]` or `[keycloak oidc]`.
|
||||
|
||||
### You are not redirected to Keycloak
|
||||
|
||||
When you fill the **Configure a Keycloak OIDC account** form and click on **Enable**, you are not redirected to your IdP.
|
||||
When you fill the **Configure a Keycloak OIDC account** form and click **Enable**, you are not redirected to your IdP.
|
||||
|
||||
* Verify your Keycloak client configuration.
|
||||
Verify your Keycloak client configuration.
|
||||
|
||||
### The generated `Issuer` and `Auth Endpoint` are incorrect
|
||||
|
||||
* On the **Configure a Keycloak OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` and `Auth Endpoint` values. To find the values, go to the Keycloak console and select **Realm Settings**, select the **General** tab, and click **OpenID Endpoint Configuration**. The JSON output will display values for `issuer` and `authorization_endpoint`.
|
||||
On the **Configure a Keycloak OIDC account** form, change **Endpoints** to `Specify (advanced)` and override the `Issuer` and `Auth Endpoint` values. To find the values, go to the Keycloak console and select **Realm Settings**, select the **General** tab, and click **OpenID Endpoint Configuration**. The JSON output displays values for `issuer` and `authorization_endpoint`.
|
||||
|
||||
### Keycloak Error: "Invalid grant_type"
|
||||
|
||||
* In some cases, this error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
|
||||
In some cases, this error message may be misleading and is caused by setting the `Valid Redirect URI` incorrectly.
|
||||
|
||||
### Unable to See Groups When Assigning Global Roles
|
||||
|
||||
If you use a user that is not part of any groups for initial setup, then you cannot search for groups when trying to assign a global role.
|
||||
To resolve this, you can either:
|
||||
|
||||
1. Manually edit the `authconfig/keycloakoidc` object to enable group search.
|
||||
|
||||
1. On the Rancher server:
|
||||
```bash
|
||||
kubectl edit authconfigs.management.cattle.io keycloakoidc
|
||||
```
|
||||
2. Set `groupSearchEnabled: true`.
|
||||
3. Save your changes.
|
||||
|
||||
2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
|
||||
|
||||
+1
-1
@@ -168,7 +168,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
|
||||
When you click on **Authenticate with Keycloak**, you are not redirected to your IdP.
|
||||
|
||||
* Verify your Keycloak client configuration.
|
||||
* Make sure `Force Post Binding` set to `OFF`.
|
||||
* Make sure `Force Post Binding` is set to `OFF`.
|
||||
|
||||
|
||||
### Forbidden message displayed after IdP login
|
||||
|
||||
+3
-2
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-
|
||||
|
||||
## First Log In
|
||||
|
||||
After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
|
||||
After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
|
||||
|
||||
:::danger
|
||||
|
||||
@@ -90,4 +90,5 @@ 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](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.
|
||||
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.
|
||||
|
||||
|
||||
+1
-79
@@ -8,12 +8,10 @@ title: Global Permissions
|
||||
|
||||
_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.
|
||||
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Restricted Admin`,`Standard User` and `User-base`.
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Standard User` and `User-base`.
|
||||
|
||||
- **Administrator:** These users have full control over the entire Rancher system and all clusters within it.
|
||||
|
||||
- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
|
||||
- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
|
||||
|
||||
- **User-Base:** User-Base users have login-access only.
|
||||
@@ -286,79 +284,3 @@ To refresh group memberships,
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
:::warning Deprecated
|
||||
|
||||
The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
|
||||
|
||||
:::
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
|
||||
The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
|
||||
|
||||
A new setting was added to Rancher to set the initial bootstrapped administrator to have the `restricted-admin` role. This applies to the first user created when the Rancher server is started for the first time. If the environment variable is set, then no global administrator would be created, and it would be impossible to create the global administrator through Rancher.
|
||||
|
||||
To bootstrap Rancher with the `restricted-admin` as the initial user, the Rancher server should be started with the following environment variable:
|
||||
|
||||
```
|
||||
CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
```
|
||||
### List of `restricted-admin` Permissions
|
||||
|
||||
The following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
|
||||
|
||||
| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
|
||||
| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
|
||||
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
|
||||
| | Create Projects/namespaces | Yes | No | No | |
|
||||
| | Add cluster/project members | Yes | No | No | |
|
||||
| | Global DNS | Yes | No | No | |
|
||||
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
|
||||
| | Save as RKE Template | Yes | No | No | |
|
||||
| Security | | | | | |
|
||||
| Enable auth | Configure Authentication | Yes | No | Yes | |
|
||||
| Roles | Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
|
||||
| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| Users | Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
|
||||
| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
|
||||
| | Refresh Groups | Yes | No | Yes | |
|
||||
| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
|
||||
| Tools | | | | | |
|
||||
| | Manage RKE Templates | Yes | No | Yes | |
|
||||
| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
|
||||
| | Cluster Drivers | Yes | No | Yes | |
|
||||
| | Node Drivers | Yes | No | Yes | |
|
||||
| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
|
||||
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
|
||||
| Settings | | | | | |
|
||||
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
|
||||
| User | | | | | |
|
||||
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
|
||||
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
|
||||
| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
|
||||
| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
|
||||
| | Edit Cluster | Yes | Yes | Yes | |
|
||||
| | Rotate Certificates | Yes | | Yes | |
|
||||
| | Snapshot Now | Yes | | Yes | |
|
||||
| | Restore Snapshot | Yes | | Yes | |
|
||||
| | Save as RKE Template | Yes | No | Yes | |
|
||||
| | Run CIS Scan | Yes | Yes | Yes | |
|
||||
| | Add Members | Yes | Yes | Yes | |
|
||||
| | Create Projects | Yes | Yes | Yes | |
|
||||
| Feature Charts since v2.5 | | | | | |
|
||||
| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
|
||||
| | Deploy EKS cluster | Yes | Yes | Yes | |
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
+4
@@ -8,6 +8,10 @@ title: Pod Security Admission (PSA) Configuration Templates
|
||||
|
||||
[Pod Security admission (PSA)](./pod-security-standards.md) configuration templates are a Rancher custom-defined resource (CRD), available in Rancher v2.7.2 and above. The templates provide pre-defined security configurations that you can apply to a cluster:
|
||||
|
||||
:::info important
|
||||
The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#exempting-required-rancher-namespaces) that won't be used within your environments.
|
||||
:::
|
||||
|
||||
- `rancher-privileged`: The most permissive configuration. It doesn't restrict the behavior of any pods. This allows for known privilege escalations. This policy has no exemptions.
|
||||
- `rancher-restricted`: A heavily restricted configuration that follows current best practices for hardening pods. You must make [namespace-level exemptions](./pod-security-standards.md#rancher-on-psa-restricted-clusters) for Rancher components.
|
||||
|
||||
|
||||
+1
-1
@@ -82,7 +82,7 @@ This section outlines the guidelines for the proper usage of the Rancher Backups
|
||||
### Restores
|
||||
|
||||
- A restore refers to restoring a backup to the same cluster it was taken from. This can be with Rancher installed (**prune must be enabled**) or with it not installed (no special instructions).
|
||||
- One thing to note when restoring is that you may find yourself needing to “wipe” the cluster of any Rancher resources. This can be done by deploying the [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) script as a job to the cluster. This allows you to install Rancher Backups again and restore to a completely fresh cluster.
|
||||
- One thing to note when restoring is that you may find yourself needing to “wipe” the cluster of any Rancher resources. This can be done by deploying the [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) as a job to the cluster. This allows you to install Rancher Backups again and restore to a completely fresh cluster.
|
||||
- Make sure to use kubectl to deploy the scripts.
|
||||
|
||||
### Migrations
|
||||
|
||||
+22
-2
@@ -52,10 +52,10 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the following Helm value to pull the `backup-restore-operator` image from your private registry when you install the rancher-backup Helm chart.
|
||||
For an **air-gapped environment**, use the following Helm values to pull the `backup-restore-operator` and `kubectl` images from your private registry when you install the rancher-backup Helm chart.
|
||||
|
||||
```bash
|
||||
--set image.repository <registry>/rancher/backup-restore-operator
|
||||
--set image.repository <registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -140,6 +140,26 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
|
||||
|
||||
1. Once the Restore resource has the status `Completed`, you can continue the cert-manager and Rancher installation.
|
||||
|
||||
:::note Important:
|
||||
|
||||
When migrating Rancher between any two different Kubernetes distributions (e.g. from K3s to RKE2), the object representing the local cluster has to be modified to allow Rancher to detect the new distribution. After the restoration is completed, and **before** bringing up Rancher on the new cluster, edit the local cluster object:
|
||||
|
||||
```bash
|
||||
kubectl edit clusters.management.cattle.io local
|
||||
```
|
||||
|
||||
1. Change the value of `status.driver` to `imported`.
|
||||
1. Remove `status.provider`.
|
||||
1. Remove the entire `status.version` map.
|
||||
1. Remove the label with the key `provider.cattle.io` in `metadata.labels`.
|
||||
1. Remove the annotation with the key `management.cattle.io/current-cluster-controllers-version` in `metadata.annotations`.
|
||||
1. Remove the entire `spec.rke2Config` or `spec.k3sConfig` map, if present.
|
||||
1. Save the changes.
|
||||
|
||||
Note that removing `spec.rke2Config` or `spec.k3sConfig` will erase your distribution-specific upgrade configuration for the local cluster. It can be [reconfigured](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) if the new distribution is configurable for the local cluster.
|
||||
|
||||
:::
|
||||
|
||||
### 3. Install cert-manager
|
||||
|
||||
Follow the steps to [install cert-manager](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
|
||||
|
||||
@@ -18,7 +18,7 @@ Rancher supports two different types of charts: Helm charts and Rancher charts.
|
||||
|
||||
### Helm Charts
|
||||
|
||||
Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you' can provide the chart's parameter values in a YAML editor.
|
||||
Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you can provide the chart's parameter values in a YAML editor.
|
||||
|
||||
### Rancher Charts
|
||||
|
||||
|
||||
@@ -164,12 +164,6 @@ spec:
|
||||
|
||||
### Add Custom OCI Chart Repositories
|
||||
|
||||
:::caution
|
||||
|
||||
This feature is currently experimental and is not officially supported in Rancher.
|
||||
|
||||
:::
|
||||
|
||||
Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means you can deploy apps that are stored as OCI artifacts. For more information, see [Using OCI Helm Chart Repositories](./oci-repositories.md).
|
||||
|
||||
### Helm Compatibility
|
||||
|
||||
@@ -6,12 +6,6 @@ title: Using OCI-Based Helm Chart Repositories
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/oci-registries"/>
|
||||
</head>
|
||||
|
||||
:::caution
|
||||
|
||||
This feature is currently experimental and is not officially supported in Rancher.
|
||||
|
||||
:::
|
||||
|
||||
Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means that you can deploy apps that are stored as OCI artifacts.
|
||||
|
||||
## Add an OCI-Based Helm Chart Repository
|
||||
|
||||
@@ -6,6 +6,8 @@ title: Setting up Infrastructure for a High Availability RKE Kubernetes Cluster
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This tutorial is intended to help you create a high-availability RKE cluster that can be used to install a Rancher server.
|
||||
|
||||
:::note Important:
|
||||
|
||||
@@ -6,6 +6,8 @@ title: Setting up a High-availability RKE Kubernetes Cluster
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This section describes how to install a Kubernetes cluster. This cluster should be dedicated to run only the Rancher server.
|
||||
|
||||
:::note
|
||||
|
||||
+55
-15
@@ -31,11 +31,13 @@ kubectl create clusterrolebinding cluster-admin-binding \
|
||||
|
||||
Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-admin` role, you must run these commands on GKE clusters before you can register them. To learn more about role-based access control for GKE, please see [the official Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
|
||||
|
||||
### Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)
|
||||
### Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)
|
||||
|
||||
To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group.
|
||||
To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group.
|
||||
|
||||
EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher.
|
||||
AKS clusters can only be imported if local accounts are enabled. If a cluster is configured to use Microsoft Entra ID for authentication, Rancher will not be able to import the cluster and report an error.
|
||||
|
||||
EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher.
|
||||
|
||||
GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison) for more information about the differences between GKE modes.
|
||||
|
||||
@@ -45,9 +47,10 @@ GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard
|
||||
2. On the **Clusters** page, **Import Existing**.
|
||||
3. Choose the type of cluster.
|
||||
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
5. If you are importing a generic Kubernetes cluster in Rancher, perform the following steps for setup:<br/>
|
||||
a. Click **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent](../launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.<br/>
|
||||
b. Enable Project Network Isolation to ensure the cluster supports Kubernetes `NetworkPolicy` resources. Users can select the **Project Network Isolation** option under the **Advanced Options** dropdown to do so.
|
||||
5. If you are importing a generic Kubernetes cluster in Rancher, perform the following steps for setup:
|
||||
1. Click **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent](../launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
1. Enable Project Network Isolation to ensure the cluster supports Kubernetes `NetworkPolicy` resources. Users can select the **Project Network Isolation** option under the **Advanced Options** dropdown to do so.
|
||||
1. [Configure the version management feature for imported RKE2 and K3s clusters](#configuring-version-management-for-rke2-and-k3s-clusters).
|
||||
6. Click **Create**.
|
||||
7. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite.
|
||||
8. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher.
|
||||
@@ -122,18 +125,16 @@ After registering a cluster, the cluster owner can:
|
||||
### Additional Features for Registered RKE2 and K3s Clusters
|
||||
|
||||
[K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution for edge installations.
|
||||
|
||||
[RKE2](https://docs.rke2.io) is Rancher's next-generation Kubernetes distribution for datacenter and cloud installations.
|
||||
|
||||
When an RKE2 or K3s cluster is registered in Rancher, Rancher will recognize it. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster:
|
||||
When an RKE2 or K3s cluster is registered in Rancher, Rancher will recognize it.
|
||||
The Rancher UI will expose features available to [all registered clusters](#features-for-all-registered-clusters), along with the following options for editing and upgrading the cluster:
|
||||
|
||||
- The ability to [upgrade the Kubernetes version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
|
||||
:::danger
|
||||
|
||||
After a cluster has been imported into Rancher, upgrades should be performed using Rancher. Upgrading an imported cluster outside of Rancher is **not** supported.
|
||||
|
||||
:::
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
- Enable or disable [version management](#configuring-version-management-for-rke2-and-k3s-clusters)
|
||||
- [Upgrade the Kubernetes version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md) when version management is enabled
|
||||
- Configure the [upgrade strategy](#configuring-rke2-and-k3s-cluster-upgrades) when version management is enabled
|
||||
- View a read-only version of the cluster’s configuration arguments and environment variables used to launch each node
|
||||
|
||||
### Additional Features for Registered EKS, AKS, and GKE Clusters
|
||||
|
||||
@@ -143,6 +144,24 @@ When you create an EKS, AKS, or GKE cluster in Rancher, then delete it, Rancher
|
||||
|
||||
See [Cluster Management Capabilities by Cluster Type](kubernetes-clusters-in-rancher-setup.md) for more information about what features are available for managing registered clusters.
|
||||
|
||||
## Configuring Version Management for RKE2 and K3s Clusters
|
||||
|
||||
:::danger
|
||||
|
||||
When version management is enabled for an imported cluster, upgrading it outside of Rancher may lead to unexpected consequences.
|
||||
|
||||
:::
|
||||
|
||||
The version management feature for imported RKE2 and K3s clusters can be configured using one of the following options:
|
||||
|
||||
- **Global default** (default): Inherits behavior from the global **imported-cluster-version-management** setting.
|
||||
- **True**: Enables version management, allowing users to control the Kubernetes version and upgrade strategy of the cluster through Rancher.
|
||||
- **False**: Disables version management, enabling users to manage the cluster’s Kubernetes version independently, outside of Rancher.
|
||||
|
||||
You can define the default behavior for newly created clusters or existing ones set to "Global default" by modifying the **imported-cluster-version-management** setting.
|
||||
|
||||
Changes to the global **imported-cluster-version-management** setting take effect during the cluster’s next reconciliation cycle.
|
||||
|
||||
## Configuring RKE2 and K3s Cluster Upgrades
|
||||
|
||||
:::tip
|
||||
@@ -178,8 +197,12 @@ The current status of the plans can be viewed with this command:
|
||||
kubectl get plans -A -o yaml
|
||||
```
|
||||
|
||||
:::tip
|
||||
|
||||
If the cluster becomes stuck in upgrading, restart the `system-upgrade-controller`.
|
||||
|
||||
:::
|
||||
|
||||
To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed.
|
||||
|
||||
## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
|
||||
@@ -286,3 +309,20 @@ To annotate a registered cluster,
|
||||
6. Click **Save**.
|
||||
|
||||
**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
This section lists some of the most common errors that may occur when importing a cluster and provides steps to troubleshoot them.
|
||||
|
||||
### AKS
|
||||
|
||||
- The following error may occur if local accounts are disabled in your cluster.
|
||||
```sh
|
||||
Error: Getting static credential is not allowed because this cluster is set to disable local accounts.
|
||||
```
|
||||
|
||||
To resolve this issue, enable local accounts before attempting to [import the cluster](#registering-a-cluster) again.
|
||||
|
||||
```sh
|
||||
az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts
|
||||
```
|
||||
|
||||
+73
-125
@@ -175,34 +175,6 @@ stringData:
|
||||
"loadBalancerSku": "standard",
|
||||
"excludeMasterFromStandardLB": false,
|
||||
}
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
labels:
|
||||
kubernetes.io/cluster-service: "true"
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["secrets"]
|
||||
resourceNames: ["azure-cloud-config"]
|
||||
verbs:
|
||||
- get
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
labels:
|
||||
kubernetes.io/cluster-service: "true"
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
```
|
||||
|
||||
## Using the Out-of-tree Azure Cloud Provider
|
||||
@@ -212,109 +184,85 @@ roleRef:
|
||||
|
||||
1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
|
||||
|
||||
2. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
|
||||
- Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
|
||||
2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
|
||||
|
||||
3. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
|
||||
3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
|
||||
|
||||
Note that the chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below. Modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
|
||||
Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
|
||||
|
||||
4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
|
||||
Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
|
||||
|
||||
Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
metadata:
|
||||
name: azure-cloud-controller-manager
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: cloud-provider-azure
|
||||
repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
|
||||
targetNamespace: kube-system
|
||||
bootstrap: true
|
||||
valuesContent: |-
|
||||
infra:
|
||||
clusterName: <cluster-name>
|
||||
cloudControllerManager:
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
cloudConfig: null
|
||||
clusterCIDR: null
|
||||
enableDynamicReloading: 'true'
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
allocateNodeCidrs: 'false'
|
||||
hostNetworking: true
|
||||
caCertDir: /etc/ssl
|
||||
configureCloudRoutes: 'false'
|
||||
enabled: true
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/master
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
cloud-config: |-
|
||||
{
|
||||
"cloud": "AzurePublicCloud",
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
"securityGroupName": "rancher-managed-kqmtsjgJ",
|
||||
"securityGroupResourceGroup": "docker-machine",
|
||||
"vnetName": "docker-machine-vnet",
|
||||
"vnetResourceGroup": "docker-machine",
|
||||
"primaryAvailabilitySetName": "docker-machine",
|
||||
"routeTableResourceGroup": "docker-machine",
|
||||
"cloudProviderBackoff": false,
|
||||
"useManagedIdentityExtension": false,
|
||||
"useInstanceMetadata": true,
|
||||
"loadBalancerSku": "standard",
|
||||
"excludeMasterFromStandardLB": false,
|
||||
}
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
labels:
|
||||
kubernetes.io/cluster-service: "true"
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["secrets"]
|
||||
resourceNames: ["azure-cloud-config"]
|
||||
verbs:
|
||||
- get
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
labels:
|
||||
kubernetes.io/cluster-service: "true"
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system:azure-cloud-provider-secret-getter
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
metadata:
|
||||
name: azure-cloud-controller-manager
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: cloud-provider-azure
|
||||
repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
|
||||
targetNamespace: kube-system
|
||||
bootstrap: true
|
||||
valuesContent: |-
|
||||
infra:
|
||||
clusterName: <cluster-name>
|
||||
cloudControllerManager:
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
cloudConfig: null
|
||||
clusterCIDR: null
|
||||
enableDynamicReloading: 'true'
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
allocateNodeCidrs: 'false'
|
||||
hostNetworking: true
|
||||
caCertDir: /etc/ssl
|
||||
configureCloudRoutes: 'false'
|
||||
enabled: true
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/master
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
cloud-config: |-
|
||||
{
|
||||
"cloud": "AzurePublicCloud",
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
"securityGroupName": "rancher-managed-kqmtsjgJ",
|
||||
"securityGroupResourceGroup": "docker-machine",
|
||||
"vnetName": "docker-machine-vnet",
|
||||
"vnetResourceGroup": "docker-machine",
|
||||
"primaryAvailabilitySetName": "docker-machine",
|
||||
"routeTableResourceGroup": "docker-machine",
|
||||
"cloudProviderBackoff": false,
|
||||
"useManagedIdentityExtension": false,
|
||||
"useInstanceMetadata": true,
|
||||
"loadBalancerSku": "standard",
|
||||
"excludeMasterFromStandardLB": false,
|
||||
}
|
||||
```
|
||||
|
||||
4. Click **Create** to submit the form and create the cluster.
|
||||
5. Click **Create** to submit the form and create the cluster.
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ description: Configuring an Ingress
|
||||
|
||||
For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.
|
||||
|
||||
Because of this change to the controller, the default RKE1 behavior no longer sets `hostNetwork` to `true`. However, you must set `hostNetwork` to `true` for TCP- and UDP-based Services to work. To do so, [edit](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#editing-clusters-with-yaml) the cluster's YAML and follow the steps in the [official RKE1 doccumention](https://rke.docs.rancher.com/config-options/add-ons/ingress-controllers#configuring-network-options).
|
||||
Because of this change to the controller, the default RKE1 behavior no longer sets `hostNetwork` to `true`. However, you must set `hostNetwork` to `true` for TCP- and UDP-based Services to work. To do so, [edit](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#editing-clusters-with-yaml) the cluster's YAML and follow the steps in the [official RKE1 documentation](https://rke.docs.rancher.com/config-options/add-ons/ingress-controllers#configuring-network-options).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Behavior Differences Between RKE1 and RKE2
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/rke1-vs-rke2-differences"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
RKE2, also known as RKE Government, is a Kubernetes distribution that focuses on security and compliance for U.S. Federal Government entities. It is considered the next iteration of the Rancher Kubernetes Engine, now known as RKE1.
|
||||
|
||||
RKE1 and RKE2 have several slight behavioral differences to note, and this page will highlight some of these at a high level.
|
||||
|
||||
+2
-2
@@ -35,7 +35,7 @@ The packages that need to be installed on the template are listed below. These w
|
||||
* cloud-init
|
||||
* cloud-guest-utils
|
||||
* cloud-image-utils
|
||||
* growpart
|
||||
* growpart (part of cloud-guest-utils)
|
||||
* cloud-initramfs-growroot
|
||||
* open-iscsi
|
||||
* openssh-server
|
||||
@@ -131,7 +131,7 @@ cloud-init clean -s -l
|
||||
|
||||
### Windows Preparation
|
||||
|
||||
Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:
|
||||
Windows has a utility called [sysprep](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation?view=windows-11) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:
|
||||
|
||||
```PowerShell
|
||||
sysprep.exe /generalize /shutdown /oobe
|
||||
|
||||
+7
-1
@@ -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).
|
||||
- **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).
|
||||
|
||||
+9
-1
@@ -6,7 +6,7 @@ title: Adding Users to Clusters
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters"/>
|
||||
</head>
|
||||
|
||||
If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
|
||||
To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.
|
||||
|
||||
:::tip
|
||||
|
||||
@@ -33,6 +33,14 @@ Cluster administrators can edit the membership for a cluster, controlling which
|
||||
1. In the **Member Roles** tab, click **Add Member**.
|
||||
1. Search for the user or group that you want to add to the cluster.
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
|
||||
If external authentication is configured:
|
||||
|
||||
- Rancher returns users from your [external authentication](../../authentication-permissions-and-global-configuration/authentication-config/authentication-config.md) source as you type.
|
||||
|
||||
+1
-1
@@ -42,7 +42,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl
|
||||
|
||||
### About the kube-api-auth Authentication Webhook
|
||||
|
||||
The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
|
||||
The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint). When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
|
||||
|
||||
During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.
|
||||
|
||||
|
||||
@@ -184,6 +184,12 @@ for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }'
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
:::note
|
||||
|
||||
For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Rancher, see the [official RKE2 documentation](https://docs.rke2.io/install/uninstall) on uninstalling clusters.
|
||||
|
||||
:::
|
||||
|
||||
You need to remove the following components from Rancher-provisioned RKE2 nodes:
|
||||
|
||||
* The rancher-system-agent, which connects to Rancher and installs and manages RKE2.
|
||||
|
||||
@@ -52,12 +52,6 @@ In this section, you'll learn how to add the cluster template to the `local` clu
|
||||
|
||||
**Result:** The cluster template available from the **Apps** in Rancher's `local` cluster. It can now be used to deploy clusters.
|
||||
|
||||
:::note Restricted Admin access:
|
||||
|
||||
If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
|
||||
|
||||
:::
|
||||
|
||||
## Creating a Cluster from a Cluster Template
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
@@ -168,7 +168,15 @@ By default, your user is added as the project `Owner`.
|
||||
To add members:
|
||||
|
||||
1. In the **Members** tab, click **Add**.
|
||||
1. From the **Select Member** field, search for a user or group that you want to assign project access. Note: You can only search for groups if external authentication is enabled.
|
||||
1. From the **Select Member** field, search for a user or group that you want to assign project access. You can only search for groups if external authentication is enabled.
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
1. In the **Project Permissions** section, choose a role. For more information, refer to the [documentation on project roles.](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
|
||||
|
||||
### 4. Optional: Add Resource Quotas
|
||||
|
||||
+2
-1
@@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
| v2.11.1 | v106.0.0+up6.0.0 |
|
||||
| v2.11.0 | v106.0.0+up6.0.0 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -9,6 +9,6 @@ title: Cluster API (CAPI) with Rancher Turtles
|
||||
[Rancher Turtles](https://turtles.docs.rancher.com/) is a [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/#operators-in-kubernetes) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:
|
||||
|
||||
- Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
|
||||
- Configure the [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values).
|
||||
- Configure the [CAPI Operator](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html#cluster-api-operator-values).
|
||||
|
||||
The [Overview](./overview.md) section outlines installation options, Rancher Turtles architecture, and a brief demo. For more details, see the [Rancher Turtles documentation](https://turtles.docs.rancher.com/).
|
||||
|
||||
@@ -16,7 +16,7 @@ Below is a visual representation of the key components of Rancher Turtles and th
|
||||
|
||||
As defined by [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/spec/v1.0/about), SLSA is a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. The specification set by SLSA is useful for both software producers and consumers: producers can follow SLSA’s guidelines to make their software supply chain more secure, and consumers can use SLSA to make decisions about whether to trust a software package.
|
||||
|
||||
Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/security/slsa) document.
|
||||
Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/turtles/next/en/security/slsa.html) document.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -92,7 +92,7 @@ By adding the Turtles repository via the Rancher UI, Rancher can process the ins
|
||||
1. Click **Rancher Turtles - the Cluster API Extension**.
|
||||
1. Click **Install > Next > Install**.
|
||||
|
||||
This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values).
|
||||
This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html).
|
||||
|
||||
The installation may take a few minutes and after completing you can see the following new deployments in the cluster:
|
||||
|
||||
@@ -115,7 +115,7 @@ There are two ways to install Rancher Turtles with Helm, depending on whether yo
|
||||
|
||||
The CAPI Operator is required for installing Rancher Turtles. You can choose whether you want to take care of this dependency yourself or let the Rancher Turtles Helm chart manage it for you. [Installing Turtles as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency) is simpler, but your best option depends on your specific configuration.
|
||||
|
||||
The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/tasks/capi-operator/installing_core_provider) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).
|
||||
The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/turtles/next/en/tasks/capi-operator/installing_core_provider.html) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).
|
||||
|
||||
#### Installing Rancher Turtles with `Cluster API (CAPI) Operator` as a Helm dependency
|
||||
|
||||
@@ -177,7 +177,7 @@ stringData:
|
||||
|
||||
:::info
|
||||
|
||||
For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
|
||||
For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html)
|
||||
|
||||
:::
|
||||
|
||||
@@ -185,7 +185,7 @@ For detailed information on the values supported by the chart and their usage, r
|
||||
|
||||
:::note
|
||||
|
||||
Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/contributing/install_capi_operator) in the Rancher Turtles documentation for assistance.
|
||||
Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/turtles/next/en/contributing/install_capi_operator.html) in the Rancher Turtles documentation for assistance.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -15,4 +15,4 @@ To learn more and get started with Rancher Prime, please visit [this page](https
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';
|
||||
|
||||
<DocCardList items={useCurrentSidebarCategory().items.slice(0,9)} />
|
||||
<DocCardList items={useCurrentSidebarCategory().items.slice(0,10)} />
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Configuration Options
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
### Egress Support
|
||||
|
||||
By default the Egress gateway is disabled, but can be enabled on install or upgrade through the values.yaml or via the [overlay file](#overlay-file).
|
||||
|
||||
+8
@@ -6,6 +6,14 @@ title: Additional Steps for Installing Istio on RKE2 and K3s Clusters
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
When installing or upgrading the Istio Helm chart through **Apps,**
|
||||
|
||||
1. If you are installing the chart, click **Customize Helm options before install** and click **Next**.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Enable Istio with Pod Security Policies
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options/pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.
|
||||
|
||||
The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Additional Steps for Project Network Isolation
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options/project-network-isolation"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
In clusters where:
|
||||
|
||||
- You are using the Canal network plugin with Rancher before v2.5.8, or you are using Rancher v2.5.8+ with an any RKE network plug-in that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin
|
||||
|
||||
+8
@@ -6,6 +6,14 @@ title: Selectors and Scrape Configs
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`, which enables monitoring across all namespaces by default.
|
||||
|
||||
This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label.
|
||||
|
||||
@@ -6,6 +6,14 @@ title: CPU and Memory Allocations
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/cpu-and-memory-allocations"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
This section describes the minimum recommended computing resources for the Istio components in a cluster.
|
||||
|
||||
The CPU and memory allocations for each component are [configurable.](#configuring-resource-allocations)
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Disabling Istio
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/disable-istio"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.
|
||||
|
||||
## Uninstall Istio in a Cluster
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Istio
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
[Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, secure, control, and troubleshoot the traffic within a complex network of microservices.
|
||||
|
||||
As a network of microservices changes and grows, the interactions between them can become increasingly difficult to manage and understand. In such a situation, it is useful to have a service mesh as a separate infrastructure layer. Istio's service mesh lets you manipulate traffic between microservices without changing the microservices directly.
|
||||
@@ -55,7 +63,7 @@ For Istio installations `103.1.0+up1.19.6` and later, Kiali uses a token value f
|
||||
|
||||
Our Istio installer includes a quick-start, all-in-one installation of [Jaeger,](https://www.jaegertracing.io/) a tool used for tracing distributed systems.
|
||||
|
||||
Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/latest/operator/#production-strategy)
|
||||
Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/1.65/operator/#production-strategy)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
@@ -6,6 +6,14 @@ title: Role-based Access Control
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio/rbac-for-istio"/>
|
||||
</head>
|
||||
|
||||
:::warning
|
||||
|
||||
[Rancher-Istio](https://github.com/rancher/charts/tree/release-v2.11/charts/rancher-istio) will be deprecated in Rancher v2.12.0; turn to the [SUSE Rancher Application Collection](https://apps.rancher.io) build of Istio for enhanced security (included in SUSE Rancher Prime subscriptions).
|
||||
|
||||
Detailed information can be found in [this announcement](https://forums.suse.com/t/deprecation-of-rancher-istio/45043).
|
||||
|
||||
:::
|
||||
|
||||
This section describes the permissions required to access Istio features.
|
||||
|
||||
The rancher istio chart installs three `ClusterRoles`
|
||||
|
||||
@@ -25,6 +25,24 @@ Select the first option to perform a one-time backup, or select the second optio
|
||||
| `schedule` | Provide the cron string for scheduling recurring backups. |
|
||||
| `retentionCount` | Provide the number of backup files to be retained. |
|
||||
|
||||
## ResourceSet
|
||||
|
||||
While you can create your own ResourceSets to back up custom applications, two ResourceSets specifically for backing up Rancher are officially maintained and created by default by the `rancher-backup` operator. We refer to these as `rancher-resource-set-basic` and `rancher-resource-set-full`. The difference between them is whether they include secrets or not in the backups.
|
||||
|
||||
`rancher-resource-set-basic` does not include any secrets in the backup files to safeguard confidential information. You are responsible for recording any secrets and redeploying them safely.
|
||||
|
||||
`rancher-resource-set-full` includes all essential secrets in the backup files to ensure Rancher continues running smoothly after a restore or migration. To avoid storing sensitive information in plain text, we strongly advise you to enable encryption with a strong key.
|
||||
|
||||
:::note Important:
|
||||
|
||||
`rancher-resource-set` is also included by default with the `rancher-backup` operator. However, this ResourceSet is deprecated and is only being kept for backwards compatibility reasons. `rancher-resource-set` will be removed in Rancher v2.12. Please update your Backup custom resources to use either `rancher-resource-set-full` or `rancher-resource-set-basic`.
|
||||
|
||||
:::
|
||||
|
||||
| YAML Directive Name | Description |
|
||||
| ---------------- | ---------------- |
|
||||
| `resourceSetName` | Provide the name of the ResourceSet to define which resources will be included in this backup. |
|
||||
|
||||
## Encryption
|
||||
|
||||
The rancher-backup gathers resources by making calls to the kube-apiserver. Objects returned by apiserver are decrypted, so even if [encryption at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) is enabled, even the encrypted objects gathered by the backup will be in plaintext.
|
||||
|
||||
@@ -26,7 +26,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-location-encrypted-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -38,7 +38,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-location-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-basic
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
```
|
||||
@@ -51,7 +51,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-enc-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 3
|
||||
@@ -72,7 +72,7 @@ spec:
|
||||
bucketName: rancherbackups
|
||||
endpoint: minio.xip.io
|
||||
endpointCA: <base64-encoded-cert>
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -92,7 +92,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -112,7 +112,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
@@ -134,7 +134,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
|
||||
+1
-1
@@ -66,7 +66,7 @@ In general, you want to scrape data from all the workloads running in your clust
|
||||
|
||||
### About Prometheus Exporters
|
||||
|
||||
Many 3rd party workloads, such as databases, queues, and web-servers, already support exposing metrics in a Prometheus format, or offer exporters that translate between the tool's metrics and a format that Prometheus understands. You can usually add these exporters as additional sidecar containers to the workload's Pods. Many Helm charts already include options to deploy the correct exporter. You can find a curated list of exports by SysDig on [promcat.io](https://promcat.io/) and on [ExporterHub](https://exporterhub.io/).
|
||||
Many 3rd party workloads, such as databases, queues, and web-servers, already support exposing metrics in a Prometheus format, or offer exporters that translate between the tool's metrics and a format that Prometheus understands. You can usually add these exporters as additional sidecar containers to the workload's Pods. Many Helm charts already include options to deploy the correct exporter. You can find a curated list of exports on [ExporterHub](https://exporterhub.io/).
|
||||
|
||||
### Prometheus support in Programming Languages and Frameworks
|
||||
|
||||
|
||||
-2
@@ -48,7 +48,6 @@ Etcd is the backing database for Kubernetes and for Rancher. The database may ev
|
||||
This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
@@ -73,7 +72,6 @@ Predicting how many `RoleBinding` objects a given configuration will create is c
|
||||
* `Ua` is the average number of users with a membership on a cluster.
|
||||
* `P` is the total number of projects.
|
||||
* `Pa` is the average number of users with a membership on a project.
|
||||
* The Restricted Admin role follows a different formula, as every user with this role results in at least `7C + 2P + 2` additional `RoleBinding` objects.
|
||||
* The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.
|
||||
|
||||
### Using New Apps Over Legacy Apps
|
||||
|
||||
@@ -14,7 +14,7 @@ The Rancher CLI (Command Line Interface) is a unified tool that you can use to i
|
||||
The binary can be downloaded directly from the UI.
|
||||
|
||||
1. In the upper left corner, click **☰**.
|
||||
1. At the bottom of the navigation sidebar menu, click **About**.
|
||||
1. At the bottom of the navigation sidebar menu, click the Rancher version number.
|
||||
1. Under the **CLI Downloads section**, there are links to download the binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.
|
||||
|
||||
## Requirements
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: AKS Cluster Configuration Reference
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher.
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If RBAC is disabled in the AKS cluster, the cluster cannot be registered or imported into Rancher. In practice, this means that local accounts must be enabled in order to register or import an AKS cluster.
|
||||
|
||||
Rancher can configure member roles for AKS clusters in the same way as any other cluster. For more information, see the section on [role-based access control.](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)
|
||||
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE Cluster Configuration Reference
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
When Rancher installs Kubernetes, it uses [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) or [RKE2](https://docs.rke2.io/) as the Kubernetes distribution.
|
||||
|
||||
This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.
|
||||
|
||||
@@ -12,7 +12,7 @@ See the official prometheus-operator GitHub repo for an example [ServiceMonitor]
|
||||
|
||||
## PodMonitor
|
||||
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/developer/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.
|
||||
|
||||
## PrometheusRule
|
||||
|
||||
@@ -20,7 +20,7 @@ A PrometheusRule contains the alerting and recording rules that you would usuall
|
||||
|
||||
For a more fine-grained approach, the `ruleSelector` field on a Prometheus resource can select which PrometheusRules should be loaded onto Prometheus, based on the labels attached to the PrometheusRules resources.
|
||||
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/alerting/) for an example PrometheusRule.
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/developer/alerting/) for an example PrometheusRule.
|
||||
|
||||
## Alertmanager Config
|
||||
|
||||
|
||||
+2
-2
@@ -24,7 +24,7 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio
|
||||
|
||||
When a ServiceMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the ServiceMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the ServiceMonitor.
|
||||
|
||||
Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) provided by Prometheus Operator.
|
||||
Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#servicemonitor) provided by Prometheus Operator.
|
||||
|
||||
For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)
|
||||
|
||||
@@ -34,4 +34,4 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio
|
||||
|
||||
When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the PodMonitor.
|
||||
|
||||
Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec) provided by Prometheus Operator.
|
||||
Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#podmonitor) provided by Prometheus Operator.
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: RKE Hardening Guides
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
+7
-5
@@ -1,10 +1,12 @@
|
||||
---
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.24 - K8s v1.24
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
|
||||
</head>
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
|
||||
+7
-5
@@ -1,10 +1,12 @@
|
||||
---
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
|
||||
</head>
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
|
||||
@@ -10,11 +10,19 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[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) |
|
||||
[CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **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) |
|
||||
[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-22031](https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m) | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the `BackingNampespace`, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. <br/><br/> The field is populated automatically during project creation and is formatted as `<clusterID>-<project.Name>`. For example, if your project is named `project-abc123` in a cluster with ID `cluster-xyz789`, then the project will have the `BackingNampespace`: `cluster-xyz789-project-abc123`. <br/><br/> If the `BackingNampespace` field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via `kubectl` the `BackingNampespace` will also be listed as a column. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-32198](https://github.com/rancher/steve/security/advisories/GHSA-95fc-g4gj-mqmx) | A vulnerability was found where users with permission to create a service in the Kubernetes cluster where Rancher is deployed can take over the Rancher UI, display their own UI, and gather sensitive information. This is only possible when the setting `ui-offline-preferred` is set to `remote`. This release introduces a patch, and the malicious user can no longer serve their own UI. If users can't upgrade, please make sure that only trustable users have access to create a service in the local cluster. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) and [v2.8.15](https://github.com/rancher/rancher/releases/tag/v2.8.15) |
|
||||
| [CVE-2025-23391](https://github.com/rancher/rancher/security/advisories/GHSA-8p83-cpfg-fj3g) | A vulnerability has been identified within Rancher where a Restricted Administrator can change the password of Administrators and take over their accounts. A Restricted Administrator should not be allowed to change the password of more privileged users unless it contains the Manage Users permissions. A new validation has been added to block a user from editing or deleting another user with more permissions than themselves. Rancher deployments where the Restricted Administrator role is not being used are not affected by this CVE. | 31 Mar 2025 | Rancher [v2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0), [v2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4), [v2.9.8](https://github.com/rancher/rancher/releases/tag/v2.9.8) and [v2.8.14](https://github.com/rancher/rancher/releases/tag/v2.8.14) |
|
||||
| [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. <br/><br/> 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. <br/><br/> 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). <br/><br/> 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) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **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) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
|
||||
@@ -20,7 +20,8 @@ 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.0 | v0.6.1 | ✗ | ✓ |
|
||||
| v2.11.1 | v0.7.1 | ✓ | ✓ |
|
||||
| v2.11.0 | v0.7.0 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
|
||||
@@ -6,6 +6,8 @@ title: RKE1 Example YAML
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rke1-template-example-yaml"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
Below is an example RKE template configuration file for reference.
|
||||
|
||||
The YAML in the RKE template uses the same customization that is used when you create an RKE cluster. However, since the YAML is within the context of a Rancher provisioned RKE cluster, the customization from the RKE docs needs to be nested under the `rancher_kubernetes_engine` directive.
|
||||
|
||||
@@ -100,7 +100,7 @@ If you want to check resolving of domain names on all of the hosts, execute the
|
||||
- image: busybox:1.28
|
||||
imagePullPolicy: Always
|
||||
name: alpine
|
||||
command: ["sh", "-c", "tail -f /dev/null"]
|
||||
command: ["sleep", "infinity"]
|
||||
terminationMessagePath: /dev/termination-log
|
||||
```
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
|
||||
- image: rancherlabs/swiss-army-knife
|
||||
imagePullPolicy: Always
|
||||
name: overlaytest
|
||||
command: ["sh", "-c", "tail -f /dev/null"]
|
||||
command: ["sleep", "infinity"]
|
||||
terminationMessagePath: /dev/termination-log
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user