Merge branch 'main' into release/v2.7.2

2026-09-25 20:48:11 +00:00 · 2023-04-10 16:17:10 -04:00
parent 401caeaa80 a5e3b54e32
commit ee9379eace
46 changed files with 7177 additions and 1124 deletions
@@ -32,7 +32,8 @@ The restore operation will work on a cluster that is not in a healthy or active

 :::note Prerequisites:

- The options below are available only for [Rancher-launched RKE Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters.](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-k3s-clusters)
+- The options below are available for [Rancher-launched Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters.](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-k3s-clusters).
+- The following options also apply to imported RKE2 clusters that you have registered. If you import a cluster from an external cloud platform but don't register it, you won't be able to upgrade the Kubernetes version from Rancher.
 - Before upgrading Kubernetes, [back up your cluster.](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md)

 :::
@@ -18,7 +18,7 @@ For this workload, you'll be deploying the application Rancher Hello-World.
 1. Click **Create**.
 1. Click **Deployment**.
 1. Enter a **Name** for your workload.
-1. From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive.
+1. From the **Container Image** field, enter `rancher/hello-world`. This field is case-sensitive.
 1. Click **Add Port** and `Cluster IP` for the `Service Type` and enter `80` in the **Private Container Port** field. You may leave the `Name` blank or specify any name that you wish. Adding a port enables access to the application inside and outside of the cluster. For more information, see [Services](../../../pages-for-subheaders/workloads-and-pods.md#services).
 1. Click **Create**.

@@ -122,7 +122,21 @@ In Rancher versions 2.6.7-2.6.10, you'll need to use `User.Read.All` and `Group.

 :::note

-Rancher doesn't validate the permissions you grant to the app in Azure. We only support the use of the `Directory.Read.All` application permission.
+Rancher doesn't validate the permissions you grant to the app in Azure. You're free to try any permissions you want, as long as they allow Rancher to work with AD users and groups.
+
+ Specifically, Rancher needs permissions that allow the following actions:
+ - Get a user.
+ - List all users.
+ - List groups of which a given user is a member.
+ - Get a group.
+ - List all groups.
+
+ Rancher performs these actions either to log in a user or to run a user/group search. Keep in mind that the permissions must be of type `Application`.
+
+ Here are a few examples of permission combinations that satisfy Rancher's needs:
+ - `Directory.Read.All`
+ - `User.Read.All` and `GroupMember.Read.All`
+ - `User.Read.All` and `Group.Read.All`

 :::

@@ -263,7 +277,7 @@ If you need to roll back your migration, please note the following:

 :::caution

-If you upgrade to Rancher v2.6.7+ with an existing Azure AD setup, and choose to disable the auth provider, you won't be able to restore the previous setup. You also won't be able to set up Azure AD anew using the old flow. You'll need to re-register with the new auth flow. Since Rancher now uses the Graph API, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
+If you upgrade to Rancher v2.6.7+ with an existing Azure AD setup, and choose to disable the auth provider, you won't be able to restore the previous setup. You also won't be able to set up Azure AD using the old flow. You'll need to re-register with the new auth flow. Since Rancher now uses the Graph API, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).

 :::

@@ -17,9 +17,7 @@ For more information on RKE node roles, see the [best practices.](../../../pages

 ### Permissions

-If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.
-
-In order to apply the privilege, you need to run:
+To register a cluster in Rancher, you must have `cluster-admin` privileges within that cluster. If you don't, grant these privileges to your user by running:

 ```plain
 kubectl create clusterrolebinding cluster-admin-binding \
@@ -29,7 +27,7 @@ kubectl create clusterrolebinding cluster-admin-binding \

 before running the `kubectl` command to register the cluster.

-By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
+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).

 If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)

@@ -142,15 +140,13 @@ When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. T
 - The ability to configure the maximum number of nodes that will be upgraded concurrently
 - The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster

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

-Registering an Amazon EKS cluster or GKE cluster allows Rancher to treat it as though it were created in Rancher.
+Rancher handles registered EKS, AKS, or GKE clusters similarly to clusters created in Rancher. However, Rancher doesn't destroy registered clusters when you delete them through the Rancher UI.

-Amazon EKS clusters and GKE clusters can now be registered in Rancher. For the most part, these registered clusters are treated the same way as clusters created in the Rancher UI, except for deletion.
+When you create an EKS, AKS, or GKE cluster in Rancher, then delete it, Rancher destroys the cluster. When you delete a registered cluster through Rancher, the Rancher server _disconnects_ from the cluster. The cluster remains live, although it's no longer in Rancher. You can still access the deregistered cluster in the same way you did before you registered it.

-When you delete an EKS cluster or GKE cluster that was created in Rancher, the cluster is destroyed. When you delete a cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
-
-The capabilities for registered clusters are listed in the table on [this page.](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)
+See [Cluster Management Capabilities by Cluster Type](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for more information about what features are available for managing registered clusters.

 ## Configuring K3s Cluster Upgrades

@@ -26,7 +26,6 @@ The Rancher authentication proxy integrates with the following external authenti
 | [Google OAuth](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-google-oauth.md)            |
 | [Shibboleth](configure-shibboleth-saml.md)           |

-<br/>
 However, Rancher also provides [local authentication](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/create-local-users.md).

 In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if your external authentication provider is unavailable or undergoing maintenance.
@@ -54,7 +54,7 @@ We provide two RPMs (Red Hat packages) that enable Rancher products to function

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

-The hardening guides provide prescriptive guidance for hardening a production installation of Rancher. See Rancher's guides for [Self Assessment of the CIS Kubernetes Benchmark](#the-cis-benchmark-and-self-sssessment) for the full list of security controls.
+The hardening guides provide prescriptive guidance for hardening a production installation of Rancher. See Rancher's guides for [Self Assessment of the CIS Kubernetes Benchmark](#the-cis-benchmark-and-self-assessment) for the full list of security controls.

 > The hardening guides describe how to secure the nodes in your cluster, and it is recommended to follow a hardening guide before installing Kubernetes.