Merge branch 'staging' into 3460-new-rollback

2026-05-19 19:35:17 +00:00 · 2021-08-30 09:30:11 -07:00
parent ad4006c678 2067f40b84
commit 86aa7066de
280 changed files with 1725 additions and 2580 deletions
@@ -175,19 +175,6 @@ You can label nodes to be ignored by using a setting in the Rancher UI, or by us

 > **Note:** There is an [open issue](https://github.com/rancher/rancher/issues/24172) in which nodes labeled to be ignored can get stuck in an updating state.

-### Labeling Nodes to be Ignored with the Rancher UI
-
-To add a node that is ignored by Rancher,
-
-1. From the **Global** view, click the **Settings** tab.
-1. Go to the `ignore-node-name` setting and click **&#8942; > Edit.**
-1. Enter a name that Rancher will use to ignore nodes. All nodes with this name will be ignored.
-1. Click **Save.**
-
-**Result:** Rancher will not wait to register nodes with this name. In the UI, the node will displayed with a grayed-out status. The node is still part of the cluster and can be listed with `kubectl`.
-
-If the setting is changed afterward, the ignored nodes will continue to be hidden.
-
 ### Labeling Nodes to be Ignored with kubectl

 To add a node that will be ignored by Rancher, use `kubectl` to create a node that has the following label:
@@ -202,4 +189,4 @@ If the label is added before the node is added to the cluster, the node will not

 If the label is added after the node is added to a Rancher cluster, the node will not be removed from the UI.

-If you delete the node from the Rancher server using the Rancher UI or API, the node will not be removed from the cluster if the `nodeName` is listed in the Rancher settings under `ignore-node-name`.
+If you delete the node from the Rancher server using the Rancher UI or API, the node will not be removed from the cluster if the `nodeName` is listed in the Rancher settings in the Rancher API under `v3/settings/ignore-node-name`.
@@ -114,16 +114,18 @@ To give role-based access to your service principal,

 Use Rancher to set up and configure your Kubernetes cluster.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management.**

-1. Choose **Azure Kubernetes Service**.
+1. From the **Clusters** page, click **Create**.
+
+1. Choose **Azure AKS**.

 1. Enter a **Cluster Name**.

 1. 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.

-1. Use your subscription ID, tenant ID, app ID, and client secret to give your cluster access to AKS. If you don't have all of that information, you can retrieve it using these instructions:
-  - **App ID and tenant ID:** To get the app ID and tenant ID, you can go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations,** then click the name of the service principal. The app ID and tenant ID are both on the app registration detail page. 
+1. Use your subscription ID, client ID, and client secret to give your cluster access to AKS. If you don't have all of that information, you can retrieve it using these instructions:
+  - **Client ID:** To get the Client ID, you can go to the Azure Portal, then click **Azure Active Directory**, then click **Enterprise applications.** Click **All applications.** Select your application, click **Properties,** and copy the application ID.
  - **Client secret:** If you didn't copy the client secret when creating the service principal, you can get a new one if you go to the app registration detail page, then click **Certificates & secrets**, then click **New client secret.** 
  - **Subscription ID:** You can get the subscription ID is available in the portal from **All services > Subscriptions.**

@@ -49,7 +49,9 @@ For more detailed information on IAM policies for EKS, refer to the official [do

 Use Rancher to set up and configure your Kubernetes cluster.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management.**
+
+1. From the **Clusters** page, click **Create**.

 1. Choose **Amazon EKS**.

@@ -63,8 +63,9 @@ To get the project ID of an existing project, refer to the Google cloud document
 ### 2. Create the GKE Cluster
 Use Rancher to set up and configure your Kubernetes cluster.

-1. From the **Clusters** page, click **Add Cluster**.
-1. Under **With a hosted Kubernetes provider,** click **Google GKE**.
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. From the **Clusters** page, click **Create**.
+1. Click **Google GKE**.
 1. Enter a **Cluster Name**.
 1. Optional: 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.
 1. Optional: Add Kubernetes [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to the cluster.
@@ -36,8 +36,9 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I

 # Registering a Cluster

-1. From the **Clusters** page, click **Add Cluster**.
-2. Choose **Register**.
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. From the **Clusters** page, click **Import Existing**.
+2. Click the type of Kubernetes cluster you want to import.
 3. Enter a **Cluster Name**.
 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. For Rancher v2.5.6+, use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/rancher-agents/). 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.
@@ -23,8 +23,10 @@ The Cloud Provider Interface (CPI) should be installed first before installing t

 ### 1. Create a vSphere cluster

-1. On the Clusters page, click on **Add Cluster** and select the **vSphere** option or **Existing Nodes** option.
-1. Under **Cluster Options > Cloud Provider** select **External (Out-of-tree)**. This sets the cloud provider option on the Kubernetes cluster to `external` which sets your Kubernetes cluster up to be configured with an out-of-tree cloud provider. 
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. From the **Clusters** page, click **Create.**
+1. Click **VMWare vSphere.**
+1. Under **Cluster Options** in the **Cloud Provider** section, select **External (Out-of-tree)**. This sets the cloud provider option on the Kubernetes cluster to `external` which sets your Kubernetes cluster up to be configured with an out-of-tree cloud provider. 
 1. Finish creating your cluster.

 ### 2. Install the CPI plugin
@@ -44,38 +44,40 @@ Provision the host according to the [installation requirements]({{<baseurl>}}/ra

 Clusters won't begin provisioning until all three node roles (worker, etcd and controlplane) are present.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management.**

-2. Choose **Custom**.
+1. From the **Clusters** page, click **Create.**

-3. Enter a **Cluster Name**.
+1. Click **Custom.**

-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.
+1. Enter a **Cluster Name**.

-5. Use **Cluster Options** to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.**
+1. 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.
+
+1. Use **Cluster Options** to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.**

    >**Using Windows nodes as Kubernetes workers?**
    >
    >- See [Enable the Windows Support Option]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/).
    >- The only Network Provider available for clusters with Windows support is Flannel.
-6.	<a id="step-6"></a>Click **Next**.
+1.	<a id="step-6"></a>Click **Next**.

-7.	From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.]({{<baseurl>}}/rancher/v2.5/en/overview/concepts/#roles-for-nodes-in-kubernetes-clusters)
+1.	From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.]({{<baseurl>}}/rancher/v2.5/en/overview/concepts/#roles-for-nodes-in-kubernetes-clusters)

 	>**Notes:**
 	>
    >- Using Windows nodes as Kubernetes workers? See [this section]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/).
 	>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).

-8.	<a id="step-8"></a>**Optional**: Click **[Show advanced options]({{<baseurl>}}/rancher/v2.5/en/admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
+1.	<a id="step-8"></a>**Optional**: Click **[Show advanced options]({{<baseurl>}}/rancher/v2.5/en/admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.

-9. Copy the command displayed on screen to your clipboard.
+1. Copy the command displayed on screen to your clipboard.

-10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.

 	>**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.

-11. When you finish running the command(s) on your Linux host(s), click **Done**.
+1. When you finish running the command(s) on your Linux host(s), click **Done**.

 **Result:** 

@@ -100,8 +100,8 @@ When you create the node pool, you can specify the amount of time in minutes tha

 You can also enable node auto-replace after the cluster is created with the following steps:

-1. From the Global view, click the Clusters tab.
-1. Go to the cluster where you want to enable node auto-replace, click the vertical &#8942; **(…)**, and click **Edit.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the list of clusters, go to the cluster where you want to enable node auto-replace. Click the vertical &#8942; **(…)**, and click **Edit Config.**
 1. In the **Node Pools** section, go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter the number of minutes that Rancher should wait for a node to respond before replacing the node.
 1. Click **Save.**

@@ -111,8 +111,8 @@ You can also enable node auto-replace after the cluster is created with the foll

 You can disable node auto-replace from the Rancher UI with the following steps:

-1. From the Global view, click the Clusters tab.
-1. Go to the cluster where you want to enable node auto-replace, click the vertical &#8942; **(…)**, and click **Edit.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the list of clusters, go to the cluster where you want to enable node auto-replace. Click the vertical &#8942; **(…)**, and click **Edit Config.**
 1. In the **Node Pools** section, go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter 0.
 1. Click **Save.**

@@ -45,10 +45,11 @@ The creation of this service principal returns three pieces of identification in
 
 ### 1. Create your cloud credentials

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
-1. Click **Add Cloud Credential.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Cloud Credentials.**
+1. Click **Create.**
+1. Click **Azure.**
 1. Enter a name for the cloud credential.
-1. In the **Cloud Credential Type** field, select **Azure**.
 1. Enter your Azure credentials.
 1. Click **Create.**

@@ -58,7 +59,8 @@ The creation of this service principal returns three pieces of identification in

 Creating a [node template]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for Azure will allow Rancher to provision new nodes in Azure. Node templates can be reused for other clusters.

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Node Templates.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Node Templates.**
 1. Click **Add Template.**
 1. Fill out a node template for Azure. For help filling out the form, refer to [Azure Node Template Configuration.](./azure-node-template-config)

@@ -68,7 +70,8 @@ Use Rancher to create a Kubernetes cluster in Azure.

 Clusters won't begin provisioning until all three node roles (worker, etcd and controlplane) are present.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management**.
+1. Click **Create**.
 1. Choose **Azure**.
 1. Enter a **Cluster Name**.
 1. 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.
@@ -18,10 +18,11 @@ Then you will create a DigitalOcean cluster in Rancher, and when configuring the

 ### 1. Create your cloud credentials

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
-1. Click **Add Cloud Credential.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Cloud Credentials.**
+1. Click **Create.**
+1. Click **Digital Ocean.**
 1. Enter a name for the cloud credential.
-1. In the **Cloud Credential Type** field, select **DigitalOcean**.
 1. Enter your Digital Ocean credentials.
 1. Click **Create.**

@@ -31,15 +32,16 @@ Then you will create a DigitalOcean cluster in Rancher, and when configuring the

 Creating a [node template]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for DigitalOcean will allow Rancher to provision new nodes in DigitalOcean. Node templates can be reused for other clusters.

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Node Templates.**
-1. Click **Add Template.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Node Templates.**
 1. Fill out a node template for DigitalOcean. For help filling out the form, refer to [DigitalOcean Node Template Configuration.](./do-node-template-config)

 ### 3. Create a cluster with node pools using the node template

 Clusters won't begin provisioning until all three node roles (worker, etcd and controlplane) are present.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management**.
+1. Click **Create**.
 1. Choose **DigitalOcean**.
 1. Enter a **Cluster Name**.
 1. 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.
@@ -29,12 +29,13 @@ The steps to create a cluster differ based on your Rancher version.

 ### 1. Create your cloud credentials

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
-1. Click **Add Cloud Credential.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Cloud Credentials.**
+1. Click **Create.**
+1. Click **Amazon.**
 1. Enter a name for the cloud credential.
-1. In the **Cloud Credential Type** field, select **Amazon.**
-1. In the **Region** field, select the AWS region where your cluster nodes will be located.
 1. Enter your AWS EC2 **Access Key** and **Secret Key.**
+1. In the **Default Region** field, select the AWS region where your cluster nodes will be located.
 1. Click **Create.**

 **Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters. 
@@ -43,8 +44,8 @@ The steps to create a cluster differ based on your Rancher version.

 Creating a [node template]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for EC2 will allow Rancher to provision new nodes in EC2. Node templates can be reused for other clusters.

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Node Templates.**
-1. Click **Add Template.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Node Templates.**
 1. Fill out a node template for EC2. For help filling out the form, refer to [EC2 Node Template Configuration.](./ec2-node-template-config)

 ### 3. Create a cluster with node pools using the node template
@@ -53,7 +54,8 @@ Add one or more node pools to your cluster. For more information about node pool

 Clusters won't begin provisioning until all three node roles (worker, etcd and controlplane) are present.

-1. From the **Clusters** page, click **Add Cluster**.
+1. In the upper left corner, click **≡ > Cluster Management**.
+1. Click **Create**.
 1. Choose **Amazon EC2**.
 1. Enter a **Cluster Name**.
 1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools) 
@@ -71,6 +73,7 @@ You can access your cluster after its state is updated to **Active.**

 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
 ### Optional Next Steps

 After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
@@ -56,10 +56,10 @@ The a vSphere cluster is created in Rancher depends on the Rancher version.

 ### 1. Create your cloud credentials

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
-1. Click **Add Cloud Credential.**
-1. Enter a name for the cloud credential.
-1. In the **Cloud Credential Type** field, select **vSphere**.
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Cloud Credentials.**
+1. Click **Create.**
+1. Click **VMware vSphere.**
 1. Enter your vSphere credentials. For help, refer to **Account Access** in the [node template configuration reference.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/)
 1. Click **Create.**

@@ -69,8 +69,8 @@ The a vSphere cluster is created in Rancher depends on the Rancher version.

 Creating a [node template]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for vSphere will allow Rancher to provision new nodes in vSphere. Node templates can be reused for other clusters.

-1. In the Rancher UI, click the user profile button in the upper right corner, and click **Node Templates.**
-1. Click **Add Template.**
+1. In the upper left corner, click **≡ > Cluster Management.**
+1. In the left navigation menu, click **Node Templates.**
 1. Fill out a node template for vSphere. For help filling out the form, refer to the vSphere node template [configuration reference.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/).

 ### 3. Create a cluster with node pools using the node template
@@ -79,8 +79,9 @@ Use Rancher to create a Kubernetes cluster in vSphere.

 Clusters won't begin provisioning until all three node roles (worker, etcd and controlplane) are present.

-1. Navigate to **Clusters** in the **Global** view.
-1. Click **Add Cluster** and select the **vSphere** infrastructure provider.
+1. In the upper left corner, click **≡ > Cluster Management**.
+1. Click **Create**.
+1. Select the **VMware vSphere** infrastructure provider.
 1. Enter a **Cluster Name.**
 1. 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.
 1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options)
@@ -69,11 +69,9 @@ For information on configuring access to monitoring, see [this page.](./rbac)

 - [Enable monitoring](./guides/enable-monitoring)
 - [Uninstall monitoring](./guides/uninstall)
- [Monitoring Rancher apps](./guides/monitoring-rancher-apps)
 - [Monitoring workloads](./guides/monitoring-workloads)
 - [Customizing Grafana dashboards](./guides/customize-grafana)
 - [Persistent Grafana dashboards](./guides/persist-grafana)
- [Setting up metrics for horizontal pod autoscaling](./guides/hpa)
 - [Debugging high memory usage](./guides/memory-usage)
 - [Migrating from Monitoring V1 to V2](./guides/migrating)

@@ -9,11 +9,9 @@ This page captures some of the most important options for configuring Monitoring

 For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration. 

-This section assumes that you understand how the Prometheus Operator’s custom resources work together. For more information, see [this section.]
-
 # Setting Resource Limits and Requests

-The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](./resource-limits)
+The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](./helm-chart-options/#configuring-resource-limits-and-requests)

 # Prometheus Configuration

@@ -24,38 +22,27 @@ Instead, to configure Prometheus to scrape custom metrics, you will only need to

 ### ServiceMonitor and PodMonitor Configuration

-For details, see [this page.](./)
+For details, see [this page.](./servicemonitor-podmonitor)

 ### Advanced Prometheus Configuration

-Link to ‘how monitoring works’ for the section about the Prometheus CR. 
-
 For more information about directly editing the Prometheus custom resource, which may be helpful in advanced use cases, see [this page.](./advanced/prometheus)

 # Alertmanager Configuration

 The Alertmanager custom resource usually doesn't need to be edited directly. For most common use cases, you can manage alerts by updating Routes and Receivers.

-Routes and receivers are part of the configuration of the alertmanager custom resource. In the Rancher UI, Routes and Receivers are not true custom resources, but pseudo-custom resources that are mapped to sections within the Alertmanager custom resource.
-
-When routes and receivers are updated, the monitoring application will automatically update Alertmanager to reflect those changes.
+Routes and receivers are part of the configuration of the alertmanager custom resource. In the Rancher UI, Routes and Receivers are not true custom resources, but pseudo-custom resources that the Prometheus Operator uses to synchronize your configuration with the Alertmanager custom resource. When routes and receivers are updated, the monitoring application will automatically update Alertmanager to reflect those changes.

 For some advanced use cases, you may want to configure alertmanager directly. For more information, refer to [this page.](./advanced/alertmanager)

-
-
 ### Receivers

-[link to section of how monitoring works that explains receivers]
-
-For details on how to configure receivers, see [this page.](./receiver)
+Receivers are used to set up notifications. For details on how to configure receivers, see [this page.](./receiver)
 ### Routes
-[link to section of how monitoring works that explains routes]

-The route needs to refer to a receiver that has already been configured.
+Routes filter notifications before they reach receivers. Each route needs to refer to a receiver that has already been configured. For details on how to configure routes, see [this page.](./route)

 ### Advanced

-Link to ‘how monitoring works’ for the section about the alertmanager CR.
-
 For more information about directly editing the Alertmanager custom resource, which may be helpful in advanced use cases, see [this page.](./advanced/alertmanager)
@@ -1,4 +1,16 @@
 ---
 title: Advanced Configuration
-weight: 5
---
+weight: 500
+---
+
+### Alertmanager
+
+For information on configuring the Alertmanager custom resource, see [this page.](./alertmanager)
+
+### Prometheus
+
+For information on configuring the Prometheus custom resource, see [this page.](./prometheus)
+
+### PrometheusRules
+
+For information on configuring the Prometheus custom resource, see [this page.](./prometheusrules)
@@ -7,7 +7,7 @@ It is usually not necessary to directly edit the Alertmanager custom resource. F

 When Receivers and Routes are updated, the monitoring application will automatically update the Alertmanager custom resource to be consistent with those changes.

-> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
+> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../how-monitoring-works/#how-alertmanager-works)

 # About the Alertmanager Custom Resource

@@ -8,14 +8,12 @@ aliases:
 ---

 It is usually not necessary to directly edit the Prometheus custom resource because the monitoring application automatically updates it based on changes to ServiceMonitors and PodMonitors.
-
-> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
-
-
-
+> This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../../how-monitoring-works/)

 # About the Prometheus Custom Resource
- when the Prometheus operator observes it, it creates prometheus-rancher-monitoring-prometheus, which is the prometheus deployment that is created based on the configuration in the Prometheus CR.
- This is where we configure details like what Alertmanagers are connected to Prometheus, what are the external URLs, and other details that prometheus needs. Rancher builds this CR for you. It has fields for pod monitor and service monitor selectors - technically you can filter that to include only the ones in a certain namespace.
- monitoring v2 only supports one prometheus per cluster because we haven’t supported project level monitoring. But you might want to edit prometheus Cr if you want to limit the namespaces.
- prometheus also has the rules and routes in it.
+
+The Prometheus CR defines a desired Prometheus deployment. The Prometheus Operator observes the Prometheus CR. When the CR changes, the Prometheus Operator creates `prometheus-rancher-monitoring-prometheus`, a Prometheus deployment based on the CR configuration.
+
+The Prometheus CR specifies details such as rules and what Alertmanagers are connected to Prometheus. Rancher builds this CR for you.
+
+Monitoring V2 only supports one Prometheus per cluster. However, you might want to edit the Prometheus CR if you want to limit monitoring to certain namespaces.
@@ -1,9 +1,8 @@
 ---
 title: Examples
-weight: 5
+weight: 400
 ---

-
 ### ServiceMonitor

 An example ServiceMonitor custom resource can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) 
@@ -12,7 +12,7 @@ aliases:

 The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.

-> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
+> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)

 - [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui)
 - [Receiver Configuration](#receiver-configuration)
@@ -10,7 +10,7 @@ When a Route is changed, the Prometheus Operator regenerates the Alertmanager cu

 For more information about configuring routes, refer to the [official Alertmanager documentation.](https://www.prometheus.io/docs/alerting/latest/configuration/#route)

-> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
+> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)

 - [Route Restrictions](#route-restrictions)
 - [Route Configuration](#route-configuration)
@@ -20,13 +20,13 @@ For more information about configuring routes, refer to the [official Alertmanag

 # Route Restrictions

-	- Alertmanager proxies alerts for Prometheus based on a configuration. It has receivers and a routing tree.
-		- Receivers: One or more notification providers (Slack, PagerDuty, etc.) to send alerts to.
-		- Routing tree: A set of routes that filter alerts to certain receivers based on labels.
-		- Alerting drivers proxy alerts for Alertmanager to non-native receivers, such as Microsoft Teams and SMS.
-		- can configure a routing tree to send and then continue. We only support routing trees with one root and then a depth of one more, for a depth two tree. But technically a ‘continue’ route lets you make the tree deeper.
-		- the receiver is for one or more notification providers. So if you know every alert for slack should also go to pager duty, you can put both configs in the same receiver.
-		- we now support broad SMS, not just Aliyun. 
+Alertmanager proxies alerts for Prometheus based on its receivers and a routing tree that filters alerts to certain receivers based on labels.
+
+Alerting drivers proxy alerts for Alertmanager to non-native receivers, such as Microsoft Teams and SMS.
+
+In the Rancher UI for configuring routes and receivers, you can configure routing trees with one root and then a depth of one more level, for a tree with a depth of two. But if you use a `continue` route when configuring Alertmanager directly, you can make the tree deeper.
+
+Each receiver is for one or more notification providers. So if you know that every alert for Slack should also go to PagerDuty, you can configure both in the same receiver.

 # Route Configuration

@@ -10,7 +10,7 @@ These configuration objects declaratively specify the endpoints that Prometheus

 ServiceMonitors are more commonly used than PodMonitors, and we recommend them for most use cases.

-> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
+> This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../how-monitoring-works/)

 ### ServiceMonitors

@@ -6,10 +6,8 @@ weight: 4

 - [Enable monitoring](./enable-monitoring)
 - [Uninstall monitoring](./uninstall)
- [Monitoring Rancher apps](./monitoring-rancher-apps)
 - [Monitoring workloads](./monitoring-workloads)
 - [Customizing Grafana dashboards](./customize-grafana)
 - [Persistent Grafana dashboards](./persist-grafana)
- [Setting up metrics for horizontal pod autoscaling](./hpa)
 - [Debugging high memory usage](./memory-usage)
 - [Migrating from Monitoring V1 to V2](./migrating)
@@ -25,28 +25,17 @@ To see the links to the external monitoring UIs, including Grafana dashboards, y
 For any panel, you can click the title and click **Explore** to get the PromQL queries powering the graphic.

 For this example, we would like to get the CPU usage for the Alertmanager container, so we click **CPU Utilization > Inspect.**
-1. The **Data** tab shows the underlying data as a time series, with the time in first column and the PromQL query result in the second column. Copy the PromQL query.
+
+The **Data** tab shows the underlying data as a time series, with the time in first column and the PromQL query result in the second column. Copy the PromQL query.
    
    ```
 	(1 - (avg(irate({__name__=~"node_cpu_seconds_total|windows_cpu_time_total",mode="idle"}[5m])))) * 100

 	```

-### Modifying an Existing Grafana Panel
+You can then modify the query in the Grafana panel or create a new Grafana panel using the query. 

-1. Open the Grafana dashboard. 
+See also:

-
-### Creating a New Grafana Panel in a Dashboard
-
-
- let’s say you want metrics that apply only for the container alertmanager.
- link to the promql queries used to make grafana dashboards. To get those queries, 
- go to grafana 
-	- right click on a graphic and click explore
-	- it shows you the PromQL queries that are embedded in it
-
-	- can modify it
-	- grafana shows you updated based on your modifications to the query
-
-	- also link to persisting grafana dashboards section
+- [Grafana docs on editing a panel](https://grafana.com/docs/grafana/latest/panels/panel-editor/)
+- [Grafana docs on adding a panel to a dashboard](https://grafana.com/docs/grafana/latest/panels/add-a-panel/)
@@ -1,31 +0,0 @@
---
-title: Setting up Metrics for HPA
-weight: 7
---
-
-The monitoring app installs a Prometheus adapter that can be used for making the metrics from monitoring available from the Kubernetes API. This is useful for horizontal pod autoscaling based on custom metrics.
-
-
- kube-state-metrics: monitors internal K8s components
- 
-For HPA it’s important to talk about kubernetes metrics APIs. For every rke cluster, metrics server is added on. HPA can hit that, can scale up or down based on pod or node usage. 
-
-We package Prometheus Adapter. It implements a k8s metrics api, says I want to expose these metrics in the k8s api so it can be used for HPA.
-
-
- kubernetes metrics APIs are implemented as adapters.
- the default adapter that has been implemented for a long time is the resource metrics API. This is why when you deploy RKE, the default API that is added on is metrics server.
- Metrics server is a kubernetes project that is an adapter that implements the resource metrics API. It collects different node metrics and stores it in a way that is accessible by HPA.
- If you want prometheus metrics to be stored on the Kubernetes API for you to be able to do HPA on, then the relevant way to configure that is by using Prometheus Adapter. It is packaged by default in monitoring v2, but not v1.
-	- if you want to do the custom metrics API, there is a secret for Prometheus Adapter that you can modify that will start exposing selected metrics from Prometheus onto those APIs, which can then be consumed by HPA.
- resource metrics: implemented by metrics-server, deployed as an RKE add-on
- custom metrics Api: implemented by Prometheus Adapter, exposed for use within the cluster (e.g. HPA)
- External Metrics API: implemented by Prometheus Adapter, exposed for use outside the cluster.
-
-
-Kubernetes metrics API
- for HPA, how do I query prometheus to use that?
- prometheus stores data within its own time series database
- there are times when you also want to expose that within kubernetes itself, so that things like HPA can use it.
- k8s has metrics apis that are implemented as adapters
- big one is metrics API
@@ -1,20 +0,0 @@
---
-title: Monitoring Rancher Apps
-weight: 3
---
-
-
-A common pattern for Rancher apps is to package a ServiceMonitor in the Helm chart for the application. The ServiceMonitor contains a preconfigured Prometheus target for monitoring.
-
-When the ServiceMonitor is enabled and monitoring is also enabled, Prometheus will be able to scrape metrics from the Rancher application.
-
-
-
-CIS application has a flag that lets you deploy a service monitor in it. As a general practice we expose charts for prometheus metrics to have that service monitor definition. The moment it’s deployed into the cluster, the prometheus scrape configuration will automatically be updated to reflect the service monitors that it has access to.
-
-In logging v2 they will deploy a service monitor and we will just absorb it.
-
-
-question: someone found out from looking through rancher helm charts that some of them already have a service monitor defined that you might have to turn on, and if you do, those metrics are prepackaged for Prometheus in the right format. 
-
-It's a common pattern to have service monitor packaged inside. That’s how we do it for cis scans.
@@ -8,36 +8,20 @@ weight: 4

 If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default.

+The steps for setting up monitoring for workloads depend on whether you want basic metrics such as CPU and memory for the workload, or whether you want to scrape custom metrics from the workload.

+If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. The resource usage time series data is in Prometheus's local time series database.

-
-The steps for setting up monitoring for workloads depends on whether you want basic metrics such as CPU and memory for the workload, or whether you want to scrape custom metrics from the workload.
-
-If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. The resource usage time series data is in Prometheus's local time series database. Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section.](https://rancher.com/docs/rancher/v2.5/en/monitoring-alerting/configuration/expression/#workload-metrics)
+Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section.](https://rancher.com/docs/rancher/v2.5/en/monitoring-alerting/configuration/expression/#workload-metrics)

 To set up custom metrics for your workload, you will need to set up an exporter and create a new ServiceMonitor custom resource to configure Prometheus to scrape metrics from your exporter.

-For more information, see [this section.](./monitoring-workloads)
-
-
-
-
-
-explain how some applications come with a servicemonitor packaged within them
-
-for example, some rancher applications come with servicemonitors (link to section)
-
 ### Display CPU and Memory Metrics for a Workload

 By default, the monitoring application already scrapes CPU and memory.

 To get some fine-grained detail for a particular workload, you can customize a Grafana dashboard to display the metrics for a particular workload.

- there’s already a wealth of information provided by kube-state-metrics. Cpu utilization, memory utilization for different things across namespaces. If you just want resource metrics for prod, you don’t need to create a new ServiceMonitor for it. All you need to do is go to the prometheus UI and do a PromQL query to get the information.
-
-For more information on customizing Grafana to show the workload metrics, see this section. (Link)
-
-
 ### Setting up Metrics Beyond CPU and Memory

 For custom metrics, you will need to expose the metrics on your application in a format supported by Prometheus.
@@ -45,12 +29,3 @@ For custom metrics, you will need to expose the metrics on your application in a
 Then we recommend that you should create a new ServiceMonitor custom resource. When this resource is created, the Prometheus custom resource will be automatically updated so that its scrape configuration includes the new custom metrics endpoint. Then Prometheus will begin scraping metrics from the endpoint.

 You can also create a PodMonitor to expose the custom metrics endpoint, but ServiceMonitors are more appropriate for the majority of use cases.
-
- let’s say we expose metrics at a particular endpoint. Let’s take rancher-monitoring-kube-state-metrics. For example they have a container port where they expose metrics from. 
-	- the approach I would take - although we don’t have a clean UI from it - is to create it from YAML.
-	- for something like for grafana we’d create it like this - like for rancher-monitoring-grafana - where the basic details we need to provide are:
-		- what is the actual endpoint that you want to hit (spec.endpoints, path and port) - what’s the HTTP path that you want to hit and what’s the port.
-		- namespaceSelector: what namespaces does that particular deployment exist in within Kubernetes, and use matchNames to select them.
-		- you can also use selector.matchLabels.
-		- That’s what it takes to add monitoring if a serviceMonitor is not already defined.
-		- example: use the rancher-monitoring-grafana YAML
@@ -19,7 +19,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
 - Run unit tests.  
 - Run regression tests.

->**Note: Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
+>**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.

 This section covers the following topics:

@@ -1,12 +1,6 @@
 ---
 title: Authentication, Permissions and Global Configuration
 weight: 6
-aliases:
-  - /rancher/v2.6/en/concepts/global-configuration/
-  - /rancher/v2.6/en/tasks/global-configuration/
-  - /rancher/v2.6/en/concepts/global-configuration/server-url/
-  - /rancher/v2.6/en/tasks/global-configuration/server-url/
-  - /rancher/v2.6/en/admin-settings/log-in/
 ---

 After installation, the [system administrator]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) should configure Rancher to configure authentication, authorization, security, default settings, security policies, drivers and global DNS entries.
@@ -1,9 +1,6 @@
 ---
 title: Authentication
 weight: 10
-aliases:
-    - /rancher/v2.6/en/concepts/global-configuration/authentication/
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/
 ---

 One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters.
@@ -12,7 +9,7 @@ This centralized user authentication is accomplished using the Rancher authentic

 ## External vs. Local Authentication

-The Rancher authentication proxy integrates with the following external authentication services. The following table lists the first version of Rancher each service debuted.
+The Rancher authentication proxy integrates with the following external authentication services.

 | Auth Service                                                                                     |
 | ------------------------------------------------------------------------------------------------ |
@@ -54,13 +51,11 @@ After you configure Rancher to allow sign on using an external authentication se

 To set the Rancher access level for users in the authorization service, follow these steps:

-1. From the **Global** view, click **Security > Authentication.**
-
-1. Use the **Site Access** options to configure the scope of user authorization. The table above explains the access level for each option.
-
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Auth Provider**.
+1. After setting up the configuration details for an auth provider, use the **Site Access** options to configure the scope of user authorization. The table above explains the access level for each option.
 1. Optional: If you choose an option other than **Allow any valid Users,** you can add users to the list of authorized users and organizations by searching for them in the text field that appears.
-
-1. Click **Save.**
+1. Click **Save**.

 **Result:** The Rancher access configuration settings are applied.

@@ -1,8 +1,6 @@
 ---
 title: Configuring Active Directory (AD)
 weight: 1112
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/active-directory/
 ---

 If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI.
@@ -23,14 +21,17 @@ Note however, that in some locked-down Active Directory configurations this defa

 > **Using TLS?**
 >
-> If the certificate used by the AD server is self-signed or not from a recognised certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.
+> If the certificate used by the AD server is self-signed or not from a recognized certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.

 ## Configuration Steps
 ### Open Active Directory Configuration

 1. Log into the Rancher UI using the initial local `admin` account.
-2. From the **Global** view, navigate to **Security** > **Authentication**
-3. Select **Active Directory**. The **Configure an AD server** form will be displayed.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **ActiveDirectory**. The **Authentication Provider: ActiveDirectory** form will be displayed.
+1. Fill out the form. For help, refer to the details on configuration options below.
+1. Click **Enable**.

 ### Configure Active Directory Server Settings

@@ -1,8 +1,6 @@
 ---
 title: Configuring Azure AD
 weight: 1115
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/azure-ad/
 ---

 If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
@@ -180,10 +178,10 @@ From the Rancher UI, enter information about your AD instance hosted in Azure to

 Enter the values that you copied to your [text file](#tip).

-1. Log into Rancher. From the **Global** view, select **Security > Authentication**.
-
-1. Select **Azure AD**.
-
+1. Log into Rancher.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **AzureAD**.
 1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).

    >**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
@@ -202,6 +200,6 @@ Enter the values that you copied to your [text file](#tip).
    | Token Endpoint     | OAuth 2.0 Token Endpoint              |
    | Auth Endpoint      | OAuth 2.0 Authorization Endpoint      |

-1. Click **Authenticate with Azure**.
+1. Click **Enable**.

 **Result:** Azure Active Directory authentication is configured.
@@ -1,8 +1,6 @@
 ---
 title: Configuring FreeIPA
 weight: 1114
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/freeipa/
 ---

 If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials.
@@ -14,12 +12,10 @@ If your organization uses FreeIPA for user authentication, you can configure Ran
 >- Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

 1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
-
-2.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-3.	Select **FreeIPA**.
-
-4.	Complete the **Configure an FreeIPA server** form.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **FreeIPA**.
+1.	Complete the **Configure an FreeIPA server** form.

 	You may need to log in to your domain controller to find the information requested in the form.

@@ -34,7 +30,7 @@ If your organization uses FreeIPA for user authentication, you can configure Ran
 	>* If your users and groups are in the same search base, complete only the User Search Base.
 	>* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.

-5.	If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
+1.	If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.

 	>**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
 	>
@@ -46,7 +42,8 @@ If your organization uses FreeIPA for user authentication, you can configure Ran
 	>
 	> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.

-6.	Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication.
+1.	Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication.
+1. Click **Enable**.

 **Result:**

@@ -1,8 +1,6 @@
 ---
 title: Configuring GitHub
 weight: 1116
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/github/
 ---

 In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials.
@@ -10,12 +8,10 @@ In environments using GitHub, you can configure Rancher to allow sign on using G
 >**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

 1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
-
-2.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-3.	Select **GitHub**.
-
-4.	Follow the directions displayed to **Setup a GitHub Application**. Rancher redirects you to GitHub to complete registration.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **GitHub**.
+1.	Follow the directions displayed to set up a GitHub Application. Rancher redirects you to GitHub to complete registration.

 	>**What's an Authorization Callback URL?**
 	>
@@ -23,15 +19,15 @@ In environments using GitHub, you can configure Rancher to allow sign on using G

 	>When you use external authentication, authentication does not actually take place in your application. Instead, authentication takes place externally (in this case, GitHub). After this external authentication completes successfully, the Authorization Callback URL is the location where the user re-enters your application.

-5. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
+1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.

 	>**Where do I find the Client ID and Client Secret?**
 	>
 	>From GitHub, select Settings > Developer Settings > OAuth Apps. The Client ID and Client Secret are displayed prominently.

-6.	Click **Authenticate with GitHub**.
+1.	Click **Authenticate with GitHub**.

-7.	Use the **Site Access** options to configure the scope of user authorization.
+1.	Use the **Site Access** options to configure the scope of user authorization.

 	-	**Allow any valid Users**

@@ -45,7 +41,7 @@ In environments using GitHub, you can configure Rancher to allow sign on using G

 		Only GitHub users or groups added to the Authorized Users and Organizations can log in to Rancher.
 		<br/>
-8.	Click **Save**.
+1.	Click **Enable**.

 **Result:**

@@ -1,5 +1,6 @@
 ---
 title: Configuring Google OAuth
+weight: 10
 ---

 If your organization uses G Suite for user authentication, you can configure Rancher to allow your users to log in using their G Suite credentials.
@@ -9,6 +10,7 @@ Only admins of the G Suite domain have access to the Admin SDK. Therefore, only
 Within Rancher, only administrators or users with the **Manage Authentication** [global role]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) can configure authentication.

 # Prerequisites
+
 - You must have a [G Suite admin account](https://admin.google.com) configured.
 - G Suite requires a [top private domain FQDN](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) as an authorized domain. One way to get an FQDN is by creating an A-record in Route53 for your Rancher server. You do not need to update your Rancher Server URL setting with that record, because there could be clusters using that URL.
 - You must have the Admin SDK API enabled for your G Suite domain. You can enable it using the steps on [this page.](https://support.google.com/a/answer/60757?hl=en)
@@ -17,6 +19,7 @@ After the Admin SDK API is enabled, your G Suite domain's API screen should look
 ![Enable Admin APIs]({{<baseurl>}}/img/rancher/Google-Enable-APIs-Screen.png)

 # Setting up G Suite for OAuth with Rancher
+
 Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following:

 1. [Add Rancher as an authorized domain in G Suite](#1-adding-rancher-as-an-authorized-domain)
@@ -25,8 +28,9 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit
 1. [Register the service account key as an OAuth Client](#4-register-the-service-account-key-as-an-oauth-client)

 ### 1. Adding Rancher as an Authorized Domain
+
 1. Click [here](https://console.developers.google.com/apis/credentials) to go to credentials page of your Google domain.
-1. Select your project and click **OAuth consent screen.**
+1. Select your project and click **OAuth consent screen**.
 ![OAuth Consent Screen]({{<baseurl>}}/img/rancher/Google-OAuth-consent-screen-tab.png)
 1. Go to **Authorized Domains** and enter the top private domain of your Rancher server URL in the list. The top private domain is the rightmost superdomain. So for example, www.foo.co.uk a top private domain of foo.co.uk. For more information on top-level domains, refer to [this article.](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains)
 1. Go to **Scopes for Google APIs** and make sure **email,** **profile** and **openid** are enabled.
@@ -34,16 +38,17 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit
 **Result:** Rancher has been added as an authorized domain for the Admin SDK API.

 ### 2. Creating OAuth2 Credentials for the Rancher Server
+
 1. Go to the Google API console, select your project, and go to the [credentials page.](https://console.developers.google.com/apis/credentials)
 ![Credentials]({{<baseurl>}}/img/rancher/Google-Credentials-tab.png)
-1. On the **Create Credentials** dropdown, select **OAuth client ID.**
-1. Click **Web application.**
+1. On the **Create Credentials** dropdown, select **OAuth client ID**.
+1. Click **Web application**.
 1. Provide a name.
-1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step.
+1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs**. Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step.
 - Under **Authorized JavaScript origins,** enter your Rancher server URL.
 - Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`.
-1. Click on **Create.**
-1. After the credential is created, you will see a screen with a list of your credentials. Choose the credential you just created, and in that row on rightmost side, click **Download JSON.** Save the file so that you can provide these credentials to Rancher.
+1. Click on **Create**.
+1. After the credential is created, you will see a screen with a list of your credentials. Choose the credential you just created, and in that row on rightmost side, click **Download JSON**. Save the file so that you can provide these credentials to Rancher.

 **Result:** Your OAuth credentials have been successfully created.

@@ -60,8 +65,8 @@ This section describes how to:
 - Create a key for the service account and download the credentials as JSON

 1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials.
-1. Click on **Create Service Account.**
-1. Enter a name and click **Create.**
+1. Click on **Create Service Account**.
+1. Enter a name and click **Create**.
 ![Service account creation Step 1]({{<baseurl>}}/img/rancher/Google-svc-acc-step1.png)
 1. Don't provide any roles on the **Service account permissions** page and click **Continue**
 ![Service account creation Step 2]({{<baseurl>}}/img/rancher/Google-svc-acc-step2.png)
@@ -76,7 +81,7 @@ You will need to grant some permissions to the service account you created in th

 Using the Unique ID of the service account key, register it as an Oauth Client using the following steps:

-1. Get the Unique ID of the key you just created. If it's not displayed in the list of keys right next to the one you created, you will have to enable it. To enable it, click **Unique ID** and click **OK.** This will add a **Unique ID** column to the list of service account keys. Save the one listed for the service account you created. NOTE: This is a numeric key, not to be confused with the alphanumeric field **Key ID.**
+1. Get the Unique ID of the key you just created. If it's not displayed in the list of keys right next to the one you created, you will have to enable it. To enable it, click **Unique ID** and click **OK**. This will add a **Unique ID** column to the list of service account keys. Save the one listed for the service account you created. NOTE: This is a numeric key, not to be confused with the alphanumeric field **Key ID**.

 	![Service account Unique ID]({{<baseurl>}}/img/rancher/Google-Select-UniqueID-column.png)
 1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients)
@@ -85,14 +90,16 @@ Using the Unique ID of the service account key, register it as an Oauth Client u
 	```
 	openid,profile,email,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly
 	```
-1. Click **Authorize.**
+1. Click **Authorize**.

 **Result:** The service account is registered as an OAuth client in your G Suite account.

 # Configuring Google OAuth in Rancher
+
 1. Sign into Rancher using a local user assigned the [administrator]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions) role. This user is also called the local principal.
-1.	From the **Global** view, click **Security > Authentication** from the main menu.
-1. Click **Google.** The instructions in the UI cover the steps to set up authentication with Google OAuth.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **Google**. The instructions in the UI cover the steps to set up authentication with Google OAuth.
 	1. Admin Email: Provide the email of an administrator account from your GSuite setup. In order to perform user and group lookups, google apis require an administrator's email in conjunction with the service account key.
 	1. Domain: Provide the domain on which you have configured GSuite. Provide the exact domain and not any aliases.
 	1. Nested Group Membership: Check this box to enable nested group memberships. Rancher admins can disable this at any time after configuring auth.
@@ -100,6 +107,6 @@ Using the Unique ID of the service account key, register it as an Oauth Client u
   - For **Step Two,** provide the OAuth credentials JSON that you downloaded after completing [this section.](#2-creating-oauth2-credentials-for-the-rancher-server) You can upload the file or paste the contents into the **OAuth Credentials** field.
   - For **Step Three,** provide the service account credentials JSON that downloaded at the end of [this section.](#3-creating-service-account-credentials) The credentials will only work if you successfully [registered the service account key](#4-register-the-service-account-key-as-an-oauth-client) as an OAuth client in your G Suite account.
 1.	Click **Authenticate with Google**.
-1.	Click **Save**.
+1.	Click **Enable**.

 **Result:** Google authentication is successfully configured.
@@ -56,12 +56,10 @@ If you have an existing configuration using the SAML protocol and want to switch

 ## Configuring Keycloak in Rancher

-1. In the Rancher UI, click **☰ > Users & Authentication > Auth Provider**.
-
+1. In the Rancher UI, click **☰ > Users & Authentication**.
+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).
-
 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.
@@ -109,10 +107,9 @@ This section describes the process to transition from using Rancher with Keycloa

 Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled. 

-1. In the Rancher UI, click **☰ > Users & Authentication > Auth Provider**.
-
+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).
@@ -57,13 +57,11 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
 ## Configuring Keycloak in Rancher


-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **Keycloak**.
-
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **Keycloak SAML**.
 1.	Complete the **Configure Keycloak Account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
-
-1. After you complete the **Configure Keycloak Account** form, click **Authenticate with Keycloak**, which is at the bottom of the page.
+1. After you complete the **Configure a Keycloak 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.

@@ -1,8 +1,6 @@
 ---
 title: Local Authentication
 weight: 1111
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/local-authentication/
 ---

 Local authentication is the default until you configure an external authentication provider. Local authentication is where Rancher stores the user information, i.e. names and passwords, of who can log in to Rancher. By default, the `admin` user that logs in to Rancher for the first time is a local user.
@@ -11,6 +9,8 @@ Local authentication is the default until you configure an external authenticati

 Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if your external authentication service encounters issues.

-1.	From the **Global** view, select **Users** from the navigation bar.
-
-2.	Click **Add User**. Then complete the **Add User** form. Click **Create** when you're done.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Users**.
+1. Click **Create**.
+1.	Complete the **Add User** form.
+1. Click **Create**.
@@ -7,7 +7,7 @@ Before configuring Rancher to support AD FS users, you must add Rancher as a [re

 1. Log into your AD server as an administrative user.

-1. Open the **AD FS Management** console. Select **Add Relying Party Trust...** from the **Actions** menu and click **Start**.
+1. Open the **AD FS Management** console. Select **Add Relying Party Trust..**. from the **Actions** menu and click **Start**.
  
    {{< img "/img/rancher/adfs/adfs-overview.png" "">}}

@@ -49,11 +49,11 @@ Before configuring Rancher to support AD FS users, you must add Rancher as a [re
    {{< img "/img/rancher/adfs/adfs-add-rpt-10.png" "">}}

  
-1. Select **Open the Edit Claim Rules...** and click **Close**.
+1. Select **Open the Edit Claim Rules..**. and click **Close**.
  
    {{< img "/img/rancher/adfs/adfs-add-rpt-11.png" "">}}
  
-1. On the **Issuance Transform Rules** tab, click **Add Rule...**.
+1. On the **Issuance Transform Rules** tab, click **Add Rule..**..
  
    {{< img "/img/rancher/adfs/adfs-edit-cr.png" "">}}
  
@@ -5,27 +5,17 @@ weight: 1205

 After you complete [Configuring Microsoft AD FS for Rancher]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/), enter your AD FS information into Rancher to allow AD FS users to authenticate with Rancher.

->**Important Notes For Configuring Your AD FS Server:**
+>**Important Notes For Configuring Your ADFS Server:**
 > 
 >- The SAML 2.0 WebSSO Protocol Service URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
 >- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
 >- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`

-
-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **Microsoft Active Directory Federation Services**.
-
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **ADFS**.
 1.	Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The [configuration section below](#configuration) describe how you can map AD attributes to fields within Rancher.
-
-    
-    
-
-    
-
-
- 
-1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.
+1. After you complete the **Configure AD FS Account** form, click **Enable**.

    Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.

@@ -18,10 +18,9 @@ Setting | Value

 ## Configuring Okta in Rancher

-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **Okta**.
-
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **Okta**.
 1.	Complete the **Configure Okta Account** form. The examples below describe how you can map Okta attributes from attribute statements to fields within Rancher.

    | Field                     | Description                                                                   |
@@ -40,7 +39,7 @@ Setting | Value



-1. After you complete the **Configure Okta Account** form, click **Authenticate with Okta**, which is at the bottom of the page.
+1. After you complete the **Configure Okta Account** form, click **Enable**.

    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.

@@ -1,8 +1,6 @@
 ---
 title: Configuring OpenLDAP
 weight: 1113
-aliases:
-    - /rancher/v2.6/en/tasks/global-configuration/authentication/openldap/
 ---

 If your organization uses LDAP for user authentication, you can configure Rancher to communicate with an OpenLDAP server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the organisation's central user repository, while allowing end-users to authenticate with their LDAP credentials when logging in to the Rancher UI. 
@@ -21,9 +19,10 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli

 > Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

-1. Log into the Rancher UI using the initial local `admin` account.
-2. From the **Global** view, navigate to **Security** > **Authentication**
-3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **OpenLDAP**. Fill out the **Configure an OpenLDAP server** form.
+1. Click **Enable**.

 ### Test Authentication

@@ -17,9 +17,9 @@ For further details on configuring OpenLDAP, refer to the [official documentatio

 ## Background: OpenLDAP Authentication Flow 
 
-1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. 
-2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. 
-3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. 
+1. When a user attempts to login with LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. 
+2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings.
+3. Once the user has been found, they are authenticated with another LDAP bind request using the user's DN and provided password. 
 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute.

 # OpenLDAP Server Configuration
@@ -14,11 +14,10 @@ Assertion Consumer Service (ACS) URL: `https://<rancher-server>/v1-saml/ping/sam
 Note that these URLs will not return valid data until the authentication configuration is saved in Rancher.
 >- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).

-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **PingIdentity**.
-
-1.	Complete the **Configure Ping Account** form. Ping IdP lets you specify what data store you want to use. You can either add a database or use an existing ldap server. For example, if you select your Active Directory (AD) server, the examples below describe how you can map AD attributes to fields within Rancher.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **Ping Identity**.
+1.	Complete the **Configure a Ping Account** form. Ping IdP lets you specify what data store you want to use. You can either add a database or use an existing ldap server. For example, if you select your Active Directory (AD) server, the examples below describe how you can map AD attributes to fields within Rancher.

    1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `displayName`).

@@ -40,7 +39,7 @@ Note that these URLs will not return valid data until the authentication configu
    1. **IDP-metadata**: The `metadata.xml` file that you [exported from your IdP server](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).


-1. After you complete the **Configure Ping Account** form, click **Authenticate with Ping**, which is at the bottom of the page.
+1. After you complete the **Configure Ping Account** form, click **Enable**.

    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Ping IdP to validate your Rancher PingIdentity configuration.

@@ -33,12 +33,12 @@ Assertion Consumer Service (ACS) URL: `https://<rancher-server>/v1-saml/shibbole
 >- Export a `metadata.xml` file from your IdP Server. For more information, see the [Shibboleth documentation.](https://wiki.shibboleth.net/confluence/display/SP3/Home)

 ### Configure Shibboleth in Rancher
+
 If your organization uses Shibboleth for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.

-1.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-1.	Select **Shibboleth**.
-
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **Shibboleth**.
 1.	Complete the **Configure Shibboleth Account** form. Shibboleth IdP lets you specify what data store you want to use. You can either add a database or use an existing ldap server. For example, if you select your Active Directory (AD) server, the examples below describe how you can map AD attributes to fields within Rancher.

    1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `displayName`).
@@ -61,7 +61,7 @@ If your organization uses Shibboleth for user authentication, you can configure
    1. **IDP-metadata**: The `metadata.xml` file that you exported from your IdP server.


-1. After you complete the **Configure Shibboleth Account** form, click **Authenticate with Shibboleth**, which is at the bottom of the page.
+1. After you complete the **Configure Shibboleth Account** form, click **Enable**.

    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Shibboleth IdP to validate your Rancher Shibboleth configuration.

@@ -99,8 +99,9 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli
 > Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

 1. Log into the Rancher UI using the initial local `admin` account.
-2. From the **Global** view, navigate to **Security** > **Authentication**
-3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.
+1.	In the top left corner, click **☰ > Users & Authentication**.
+1. In the left navigation menu, click **Auth Provider**.
+1. Click **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.

 # Troubleshooting

@@ -11,7 +11,7 @@ Access to clusters, projects, multi-cluster apps, and global DNS providers and e

 When adding a user or group to a resource, you can search for users or groups by beginning to type their name. The Rancher server will query the authentication provider to find users and groups that match what you've entered. Searching is limited to the authentication provider that you are currently logged in with. For example, if you've enabled GitHub authentication but are logged in using a [local]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/local/) user account, you will not be able to search for GitHub users or groups.

-All users, whether they are local users or from an authentication provider, can be viewed and managed. From the **Global** view, click on **Users**.
+All users, whether they are local users or from an authentication provider, can be viewed and managed. In the upper left corner, click **☰ > Users & Authentication**. In the left navigation bar, click **Users**.

 {{< saml_caveats >}}

@@ -23,7 +23,9 @@ Whenever a user logs in to the UI using an authentication provider, Rancher auto

 ### Automatically Refreshing User Information

-Rancher will periodically refresh the user information even before a user logs in through the UI. You can control how often Rancher performs this refresh.  From the **Global** view, click on **Settings**. Two settings control this behavior:
+Rancher will periodically refresh the user information even before a user logs in through the UI. You can control how often Rancher performs this refresh. 
+
+Two settings control this behavior:

 - **`auth-user-info-max-age-seconds`**

@@ -33,6 +35,10 @@ Rancher will periodically refresh the user information even before a user logs i

    This setting controls a recurring schedule for resyncing authentication provider information for all users. Regardless of whether a user has logged in or used the API recently, this will cause the user to be refreshed at the specified interval. This setting defaults to `0 0 * * *`, i.e. once a day at midnight. See the [Cron documentation](https://en.wikipedia.org/wiki/Cron) for more information on valid values for this setting.

+To change these settings,
+
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to the setting you want to configure and click **⋮ > Edit Setting**.

 > **Note:** Since SAML does not support user lookup, SAML-based authentication providers do not support periodically refreshing user information. User information will only be refreshed when the user logs into the Rancher UI.

@@ -40,9 +46,8 @@ Rancher will periodically refresh the user information even before a user logs i

 If you are not sure the last time Rancher performed an automatic refresh of user information, you can perform a manual refresh of all users.

-1. From the **Global** view, click on **Users** in the navigation bar.
-
-1. Click on **Refresh Group Memberships**.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. On the **Users** page, click on **Refresh Group Memberships**.

 **Results:** Rancher refreshes the user information for all users. Requesting this refresh will update which users can access Rancher as well as all the groups that each user belongs to.

@@ -53,8 +58,8 @@ If you are not sure the last time Rancher performed an automatic refresh of user

 The default length (TTL) of each user session is adjustable. The default session length is 16 hours.

-1. From the **Global** view, click on **Settings**.
-1. In the **Settings** page, find **`auth-user-session-ttl-minutes`** and click **Edit.**
-1. Enter the amount of time in minutes a session length should last and click **Save.**
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to **`auth-user-session-ttl-minutes`** and click **⋮ > Edit Setting**.
+1. Enter the amount of time in minutes a session length should last and click **Save**.

 **Result:** Users are automatically logged out of Rancher after the set number of minutes.
@@ -7,7 +7,7 @@ Rancher v2.6 introduced the ability to customize Rancher’s branding and naviga

 - [Changing Brand Settings](#changing-brand-settings)
 - [Brand Configuration](#brand-configuration)
- [Custom Navigation Links in Cluster Explorer](#custom-navigation-links-in-cluster-explorer)
+- [Custom Navigation Links](#custom-navigation-links)
 - [Link Configuration](#link-configuration)
 - [Link Examples](#link-examples)

@@ -17,7 +17,7 @@ Rancher v2.6 introduced the ability to customize Rancher’s branding and naviga

 To configure the brand settings, 

-1. Click **≡ > Global settings**.
+1. Click **☰ > Global settings**.
 2. Click **Branding**.

 # Brand Configuration
@@ -42,9 +42,12 @@ You can override the primary color used throughout the UI with a custom color of

 Display a custom fixed banner in the header, footer, or both.

-# Custom Navigation Links in Cluster Explorer
+# Custom Navigation Links

-The links in the left navigation menu in Cluster Explorer can be customized.
+In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard, 
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want custom navigation links and click **Explore**.

 It can be useful to add a link for quick access to services installed on a cluster. For example, you could add a link to the Kiali UI for clusters with Istio installed, or you could add a link to the Grafana UI for clusters with Rancher monitoring installed.

@@ -56,17 +59,18 @@ Links can be created at the top level and multiple links can be grouped together

 > **Prerequisite:** You will need to have at least cluster member or project member permissions.

-1. In Rancher, go to the Cluster Explorer view where you would like to add custom navigation links.
+1. Click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you would like to add custom navigation links and click **Explore**.
 2. In the top navigation menu, click **🔍 (Resource Search)**.
 3. Type **Nav** and click **Nav Links**.
-4. Click **Create from YAML.**
+4. Click **Create from YAML**.
 5. The simplest way to create a navigation link is to add these fields:

        name: linkname
        toURL: https://example.com

    For more details on setting up links, including optional fields, see [Link Configuration.](#link-configuration)
-6. Click **Create.**
+6. Click **Create**.

 # Link Configuration

@@ -1,10 +1,9 @@
 ---
 title: Configuring a Global Default Private Registry
 weight: 40
-aliases:
 ---

-You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the Docker images that are used in your clusters.
+You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.

 There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.

@@ -17,28 +16,23 @@ If your private registry requires credentials, it cannot be used as the default
 # Setting a Private Registry with No Credentials as the Default Registry

 1. Log into Rancher and configure the default administrator password.
-
-1. Go into the **Settings** view.
-
-    {{< img "/img/rancher/airgap/settings.png" "Settings" >}}
-
-1. Look for the setting called `system-default-registry` and choose **Edit**.
-
-    {{< img "/img/rancher/airgap/edit-system-default-registry.png" "Edit" >}}
-
+1. Click **☰ > Global Settings**.
+1. Go to the setting called `system-default-registry` and choose **⋮ > Edit Setting**.
 1. Change the value to your registry (e.g. `registry.yourdomain.com:port`). Do not prefix the registry with `http://` or `https://`.

-    {{< img "/img/rancher/airgap/enter-system-default-registry.png" "Save" >}}
-
 **Result:** Rancher will use your private registry to pull system images.

 # Setting a Private Registry with Credentials when Deploying a Cluster

-You can follow these steps to configure a private registry when you provision a cluster with Rancher:
+You can follow these steps to configure a private registry when you create a cluster:

-1. When you create a cluster through the Rancher UI, go to the **Cluster Options** section and click **Show Advanced Options.**
-1. In the <b>Enable Private Registries</b> section, click **Enabled.**
-1. Enter the registry URL and credentials.
-1. Click **Save.**
+1. Click **☰ > Cluster Management**.
+1. On the **Clusters** page, click **Create**.
+1. Choose a cluster type.
+1. In the **Cluster Configuration** go to the **Registries** tab and click **Pull images for Rancher from a private registry**.
+1. Enter the registry hostname and credentials.
+1. Click **Create**.

 **Result:** The new cluster will be able to pull images from the private registry.
+
+The private registry cannot be configured after the cluster is created.
@@ -18,23 +18,20 @@ If there are specific cluster drivers that you do not want to show your users, y

 By default, Rancher only activates drivers for the most popular cloud providers, Google GKE, Amazon EKS and Azure AKS. If you want to show or hide any node driver, you can change its status.

-1.  From the **Global** view, choose **Tools > Drivers** in the navigation bar.
+1. In the upper left corner, click **☰ > Cluster Management**.

-2.  From the **Drivers** page, select the **Cluster Drivers** tab.
+2.  In the left navigation menu, click **Drivers**.

-3.  Select the driver that you wish to **Activate** or **Deactivate** and select the appropriate icon.
+3.  On the **Cluster Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.

 ## Adding Custom Cluster Drivers

 If you want to use a cluster driver that Rancher doesn't support out-of-the-box, you can add the provider's driver in order to start using them to create _hosted_ kubernetes clusters.

-1.  From the **Global** view, choose **Tools > Drivers** in the navigation bar.
-
-2.  From the **Drivers** page select the **Cluster Drivers** tab.
-
-3.  Click **Add Cluster Driver**.
-
-4.  Complete the **Add Cluster Driver** form. Then click **Create**.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **Drivers**.
+1.  On the **Cluster Drivers** tab, click **Add Cluster Driver**.
+1.  Complete the **Add Cluster Driver** form. Then click **Create**.


 ### Developing your own Cluster Driver
@@ -1,9 +1,6 @@
 ---
 title: Node Drivers
 weight: 2
-aliases:
-  - /rancher/v2.6/en/concepts/global-configuration/node-drivers/
-  - /rancher/v2.6/en/tasks/global-configuration/node-drivers/
 ---

 Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
@@ -21,19 +18,20 @@ If there are specific node drivers that you don't want to show to your users, yo

 By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean and vSphere. If you want to show or hide any node driver, you can change its status.

-1.  From the **Global** view, choose **Tools > Drivers** in the navigation bar. From the **Drivers** page, select the **Node Drivers** tab.
+1. In the upper left corner, click **☰ > Cluster Management**.

-2.	Select the driver that you wish to **Activate** or **Deactivate** and select the appropriate icon.
+2.  In the left navigation menu, click **Drivers**.
+
+2.	On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.

 ## Adding Custom Node Drivers

 If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add that provider's driver in order to start using them to create node templates and eventually node pools for your Kubernetes cluster.

-1.  From the **Global** view, choose **Tools > Drivers** in the navigation bar. From the **Drivers** page, select the **Node Drivers** tab.
-
-2.	Click **Add Node Driver**.
-
-3.	Complete the **Add Node Driver** form. Then click **Create**.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **Drivers**.
+1. On **Node Drivers** tab, click **Add Node Driver**.
+1.	Complete the **Add Node Driver** form. Then click **Create**.

 ### Developing your own node driver

@@ -7,7 +7,7 @@ The RKE metadata feature allows you to provision clusters with new versions of K

 > **Note:** The Kubernetes API can change between minor versions. Therefore, we don't support introducing minor Kubernetes versions, such as introducing v1.15 when Rancher currently supports v1.14. You would need to upgrade Rancher to add support for minor Kubernetes versions.

-Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates.** Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
+Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates**. Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.

 This table below describes the CRDs that are affected by the periodic data sync. 

@@ -29,7 +29,11 @@ Administrators might configure the RKE metadata settings to do the following:

 The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/)

-To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner. 
+To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **Drivers**.
+1. Click **Refresh Kubernetes Metadata**.

 You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.

@@ -43,16 +47,18 @@ The way that the metadata is configured depends on the Rancher version.

 To edit the metadata config in Rancher,

-1. Go to the **Global** view and click the **Settings** tab.
-1. Go to the **rke-metadata-config** section. Click the **&#8942;** and click **Edit.**
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to the **rke-metadata-config** section. Click  **⋮ > Edit Setting**.
 1. You can optionally fill in the following parameters:

- - `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
- - `url`: This is the HTTP path that Rancher fetches data from. The path must be a direct path to a JSON file. For example, the default URL for Rancher v2.4 is `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`.
+  - `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
+  - `url`: This is the HTTP path that Rancher fetches data from. The path must be a direct path to a JSON file. For example, the default URL for Rancher v2.4 is `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`.
+1. Click **Save**.

 If you don't have an air gap setup, you don't need to specify the URL where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)

 However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
+
 ### Air Gap Setups

 Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)
@@ -1,10 +1,6 @@
 ---
 title: Pod Security Policies
 weight: 60
-aliases:
-    - /rancher/v2.6/en/concepts/global-configuration/pod-security-policies/
-    - /rancher/v2.6/en/tasks/global-configuration/pod-security-policies/
-    - /rancher/v2.6/en/tasks/clusters/adding-a-pod-security-policy/
 ---

 _Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges).
@@ -65,14 +61,12 @@ We recommend adding PSPs during cluster and project creation instead of adding i

 ### Creating PSPs in the Rancher UI

-1.	From the **Global** view, select **Security** > **Pod Security Policies** from the main menu. Then click **Add Policy**.
-
-	**Step Result:** The **Add Policy** form opens.
-
-2. Name the policy.
-
-3. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
-
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation bar, click **Pod Security Policies**.
+1. Click **Add policy**.
+1. Name the policy.
+1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
+1. Click **Create**.

 # Configuration

@@ -1,8 +1,6 @@
 ---
 title: Role-Based Access Control (RBAC)
 weight: 20
-aliases:
-    - /rancher/v2.6/en/concepts/global-configuration/users-permissions-roles/
 ---

 Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/), users can either be local or external.
@@ -3,7 +3,12 @@ title: Cluster and Project Roles
 weight: 1127
 ---

-Cluster and project roles define user authorization inside a cluster or project. You can manage these roles from the **Global > Security > Roles** page.
+Cluster and project roles define user authorization inside a cluster or project.
+
+To manage these roles, 
+
+1. Click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles** and go to the **Cluster** or **Project/Namespaces** tab.

 ### Membership and Role Assignment

@@ -58,7 +63,12 @@ The following table lists the permissions available for the `Manage Nodes` role
 ***In RKE2, you must have permission to edit a cluster to be able to scale clusters up and down.**  
 <br />          

-For details on how each cluster role can access Kubernetes resources, you can go to the **Global** view in the Rancher UI. Then click **Security > Roles** and go to the **Clusters** tab. If you click an individual role, you can refer to the **Grant Resources** table to see all of the operations and resources that are permitted by the role.
+For details on how each cluster role can access Kubernetes resources, you can look them up in the Rancher UI:
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. Click the **Cluster** tab.
+1. Click the name of an individual role. The table shows all of the operations and resources that are permitted by the role.

 > **Note:**
 >When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
@@ -71,16 +81,21 @@ To assign a custom role to a new cluster member, you can use the Rancher UI. To

 To assign the role to a new cluster member,

-1. Go to the **Cluster** view, then go to the **Members** tab.
-1. Click **Add Member.** Then in the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
-1. Click **Create.**
+1. Click **☰ > Cluster Management**.
+1. Go to the cluster where you want to assign a role to a member and click **Explore**.
+1. Click **RBAC > Cluster Members**.
+1. Click **Add**.
+1. In the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
+1. Click **Create**.

 **Result:** The member has the assigned role.

 To assign any custom role to an existing cluster member,

-1. Go to the member you want to give the role to. Click the **&#8942; > View in API.**
-1. In the **roleTemplateId** field, go to the drop-down menu and choose the role you want to assign to the member. Click **Show Request** and **Send Request.**
+1. Click **☰ > Users & Authentication**.
+1. Go to the member you want to give the role to. Click the **⋮ > Edit Config**.
+1. If you have added custom roles, they will show in the **Custom** section. Choose the role you want to assign to the member.
+1. Click **Save**.

 **Result:** The member has the assigned role.

@@ -167,24 +182,17 @@ There are two methods for changing default cluster/project roles:

 You can change the cluster or project role(s) that are automatically assigned to the creating user.

-1. From the **Global** view, select **Security > Roles** from the main menu. Select either the **Cluster** or **Project** tab.
-
-1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **&#8942; > Edit**.
-
-1. Enable the role as default.
-{{% accordion id="cluster" label="For Clusters" %}}
-1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. Click the **Cluster** or **Project/Namespaces** tab.
+1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **⋮ > Edit Config**.
+1. In the **Cluster Creator Default** or **Project Creator Default** section, enable the role as the default.
 1. Click **Save**.
-{{% /accordion %}}
-{{% accordion id="project" label="For Projects" %}}
-1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
-1. Click **Save**.
-{{% /accordion %}}
-
-1. If you want to remove a default role, edit the permission and select **No** from the default roles option.

 **Result:** The default roles are configured based on your changes. Roles assigned to cluster/project creators display a check in the **Cluster/Project Creator Default** column.

+If you want to remove a default role, edit the permission and select **No** from the default roles option.
+
 ### Cluster Membership Revocation Behavior

 When you revoke the cluster membership for a standard user that's explicitly assigned membership to both the cluster _and_ a project within the cluster, that standard user [loses their cluster roles](#clus-roles) but [retains their project roles](#proj-roles). In other words, although you have revoked the user's permissions to access the cluster and its nodes, the standard user can still:
@@ -1,8 +1,6 @@
 ---
 title: Custom Roles
 weight: 1128
-aliases:
-  - /rancher/v2.6/en/tasks/global-configuration/roles/
 ---

 Within Rancher, _roles_ determine what actions a user can make within a cluster or project.
@@ -14,36 +12,35 @@ Note that _roles_ are different from _permissions_, which determine what cluster
 This section covers the following topics:

 - [Prerequisites](#prerequisites)
- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project)
- [Creating a custom global role](#creating-a-custom-global-role)
- [Deleting a custom global role](#deleting-a-custom-global-role)
- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group)
+- [Creating a custom role](#creating-a-custom-role)
+- [Creating a custom role that inherits from another role](#creating-a-custom-role-that-inherits-from-another-role)
+- [Deleting a custom role](#deleting-a-custom-role)
+- [Assigning a custom role to a group](#assigning-a-custom-role-to-a-group)
 - [Privilege escalation](#privilege-escalation)

-## Prerequisites
+# Prerequisites

 To complete the tasks on this page, one of the following permissions are required:

 - [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/).
 - [Custom Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Roles]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) role assigned.

-## Creating A Custom Role for a Cluster or Project
+# Creating A Custom Role

 While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher.

 The steps to add custom roles differ depending on the version of Rancher.

-1.  From the **Global** view, select **Security > Roles** from the main menu.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1.  Select a tab to determine the scope of the role you're adding. The tabs are:

-1.  Select a tab to determine the scope of the roles you're adding. The tabs are:
-
-  - **Cluster:** The role is valid for assignment when adding/managing members to _only_ clusters.
-  - **Project:** The role is valid for assignment when adding/managing members to _only_ projects.
-
-1.  Click **Add Cluster/Project Role.**
-
-1.  **Name** the role.
+  - **Global:** The role is valid for allowing members to manage global scoped resources.
+  - **Cluster:** The role is valid for assignment when adding/managing members to clusters.
+  - **Project/Namespaces:** The role is valid for assignment when adding/managing members to projects or namespaces.

+1.  Click **Create Global Role,** **Create Cluster Role** or **Create Project/Namespaces Role,** depending on the scope.
+1. Enter a **Name** for the role.
 1.  Optional: Choose the **Cluster/Project Creator Default** option to assign this role to a user when they create a new cluster or project. Using this feature, you can expand or restrict the default roles for cluster/project creators.

    > Out of the box, the Cluster Creator Default and the Project Creator Default roles are `Cluster Owner` and `Project Owner` respectively.
@@ -56,65 +53,51 @@ The steps to add custom roles differ depending on the version of Rancher.

    You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.

-1.  Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. Note: When a custom role inherits from a parent role, the parent role cannot be deleted until the child role is deleted.
+1.  Use the **Inherit from** options to assign individual Rancher roles to your custom roles. Note: When a custom role inherits from a parent role, the parent role cannot be deleted until the child role is deleted.

 1.  Click **Create**.

-# Creating a Custom Global Role
+# Creating a Custom Role that Inherits from Another Role

-### Creating a Custom Global Role that Copies Rules from an Existing Role
+If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role.

-If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role.
+The custom role can then be assigned to a user or group so that the role takes effect the first time the user or users sign into Rancher.

-The custom global role can then be assigned to a user or group so that the custom global role takes effect the first time the user or users sign into Rancher.
+To create a custom role based on an existing role,

-To create a custom global role based on an existing role,
-
-1. Go to the **Global** view and click **Security > Roles.**
-1. On the **Global** tab, go to the role that the custom global role will be based on. Click **&#8942; (…) > Clone.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. Click the **Cluster** or **Project/Namespaces** tab. Click **Create Cluster Role** or **Create Project/Namespaces Role** depending on the scope. Note: Only cluster roles and project/namespace roles can inherit from another role.
 1. Enter a name for the role.
-1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.**
-1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
+1. In the **Inherit From** tab, select the role(s) that the custom role will inherit permissions from.
+1. In the **Grant Resources** tab, select the Kubernetes resource operations that will be enabled for users with the custom role.

    > The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
+1. Optional: Assign the role as default.
+1. Click **Create**.

-1. Click **Save.**
+# Deleting a Custom Role

-### Creating a Custom Global Role that Does Not Copy Rules from Another Role
+When deleting a custom role, all global role bindings with this custom role are deleted.

-Custom global roles don't have to be based on existing roles. To create a custom global role by choosing the specific Kubernetes resource operations that should be allowed for the role, follow these steps:
+If a user is only assigned one custom role, and the role is deleted, the user would lose access to Rancher. For the user to regain access, an administrator would need to edit the user and apply new global permissions.

-1. Go to the **Global** view and click **Security > Roles.**
-1. On the **Global** tab, click **Add Global Role.**
-1. Enter a name for the role.
-1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.**
-1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
+Custom roles can be deleted, but built-in roles cannot be deleted.

-    > The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
-    
-1. Click **Save.**
+To delete a custom role,

-# Deleting a Custom Global Role
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+2. Go to the custom global role that should be deleted and click **⋮ (…) > Delete**.
+3. Click **Delete**.

-When deleting a custom global role, all global role bindings with this custom role are deleted.
+# Assigning a Custom Role to a Group

-If a user is only assigned one custom global role, and the role is deleted, the user would lose access to Rancher. For the user to regain access, an administrator would need to edit the user and apply new global permissions.
-
-Custom global roles can be deleted, but built-in roles cannot be deleted.
-
-To delete a custom global role,
-
-1. Go to the **Global** view and click **Security > Roles.**
-2. On the **Global** tab, go to the custom global role that should be deleted and click **&#8942; (…) > Delete.**
-3. Click **Delete.**
-
-# Assigning a Custom Global Role to a Group
-
-If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher.
+If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher.

 When a user in the group logs in, they get the built-in Standard User global role by default. They will also get the permissions assigned to their groups.

-If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role.
+If a user is removed from the external authentication provider group, they would lose their permissions from the custom role that was assigned to the group. They would continue to have their individual Standard User role.

 > **Prerequisites:** You can only assign a global role to a group if:
 >
@@ -122,16 +105,16 @@ If a user is removed from the external authentication provider group, they would
 > * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
 > * You have already set up at least one user group with the authentication provider

-To assign a custom global role to a group, follow these steps:
+To assign a custom role to a group, follow these steps:

-1. From the **Global** view, go to **Security > Groups.**
-1. Click **Assign Global Role.**
-1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role.
-1. In the **Custom** section, choose any custom global role that will be assigned to the group.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Groups**.
+1. Go to the existing group that will be assigned the custom role and click **⋮ > Edit Config**.
+1. If you have created roles, they will show in the **Custom** section. Choose any custom role that will be assigned to the group.
 1. Optional: In the **Global Permissions** or **Built-in** sections, select any additional permissions that the group should have.
-1. Click **Create.**
+1. Click **Save.**.

-**Result:** The custom global role will take effect when the users in the group log into Rancher.
+**Result:** The custom role will take effect when the users in the group log into Rancher.

 # Privilege Escalation

@@ -112,13 +112,25 @@ Global permissions for local users are assigned differently than users who log i

 When you create a new local user, you assign them a global permission as you complete the **Add User** form.

-To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all  default global permissions that are marked as checked in this column. You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
+To see the default permissions for new users,
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **Global** tab, in the **New User Default** column, the permissions given to new users by default are indicated with a checkmark.
+
+You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)

 ### Global Permissions for Users with External Authentication

 When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the  **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.

-To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column, and you can [change them to meet your needs.](#configuring-default-global-permissions)
+To see the default permissions for new users, 
+
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **New User Default** column on each page, the permissions given to new users by default are indicated with a checkmark.
+
+You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)

 Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)

@@ -157,14 +169,13 @@ The following table lists each custom global permission available and whether it
 | Manage Settings                    | ✓             |               |           |
 | Manage Users                       | ✓             |               |           |
 | Use Catalog Templates              | ✓             | ✓             |           |
-| User Base\* (Basic log-in access)  | ✓             | ✓             |           |
+| User-Base (Basic log-in access)  | ✓             | ✓             |           |

-> \*This role has two names:
->
-> - When you go to the <b>Users</b> tab and edit a user's global role, this role is called <b>Login Access</b> in the custom global permissions list.
-> - When you go to the <b>Security</b> tab and edit the roles from the roles page, this role is called <b>User Base.</b>
+For details on which Kubernetes resources correspond to each global permission,

-For details on which Kubernetes resources correspond to each global permission, you can go to the **Global** view in the Rancher UI. Then click **Security > Roles** and go to the **Global** tab. If you click an individual role, you can refer to the **Grant Resources** table to see all of the operations and resources that are permitted by the role.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1.  If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.

 > **Notes:**
 >
@@ -179,13 +190,10 @@ If you want to restrict the default permissions for new users, you can remove th

 To change the default global permissions that are assigned to external users upon their first log in, follow these steps:

-1. From the **Global** view, select **Security > Roles** from the main menu. Make sure the **Global** tab is selected.
-
-1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **&#8942; > Edit**.
-
-1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**.
-
-1. If you want to remove a default permission, edit the permission and select **No** from **New User Default**.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**. On the **Roles** page, make sure the **Global** tab is selected.
+1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit Config**.
+1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**. If you want to remove a default permission, edit the permission and select **No**.

 **Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.

@@ -193,15 +201,11 @@ To change the default global permissions that are assigned to external users upo

 To configure permission for a user,

-1. Go to the **Users** tab.
-
-1. On this page, go to the user whose access level you want to change and click **&#8942; > Edit.**
-
-1. In the **Global Permissions** section, click **Custom.**
-
-1. Check the boxes for each subset of permissions you want the user to have access to.
-
-1. Click **Save.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Go to the user whose access level you want to change and click **⋮ > Edit Config**.
+1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Roles** page, they will appear in the **Custom** section and you can choose from them as well.
+1. Click **Save**.

 > **Result:** The user's global permissions have been updated.

@@ -215,7 +219,7 @@ For existing users, the new permissions will take effect when the users log out

 For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)

-If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
+If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.

 > **Prerequisites:** You can only assign a global role to a group if:
 >
@@ -225,11 +229,11 @@ If a user is removed from the external authentication provider group, they would

 To assign a custom global role to a group, follow these steps:

-1. From the **Global** view, go to **Security > Groups.**
-1. Click **Assign Global Role.**
-1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Groups**.
+1. Go to the group you want to assign a custom global role to and click **⋮ > Edit Config**.
 1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
-1. Click **Create.**
+1. Click **Create**.

 **Result:** The custom global role will take effect when the users in the group log into Rancher.

@@ -243,7 +247,8 @@ An administrator might also want to refresh group memberships if a user is remov

 To refresh group memberships,

-1. From the **Global** view, click **Security > Users.**
-1. Click **Refresh Group Memberships.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Click **Refresh Group Memberships**.

 **Result:** Any changes to the group members' permissions will take effect.
@@ -3,7 +3,7 @@ title: Locked Roles
 weight: 1129
 ---

-You can set roles to a status of `locked`. Locking roles prevent them from being assigned users in the future.
+You can set roles to a status of `locked`. Locking roles prevent them from being assigned to users in the future.

 Locked roles:

@@ -30,8 +30,10 @@ You can lock roles in two contexts:
 - When you're [adding a custom role]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/default-custom-roles/).
 - When you editing an existing role (see below).

-1. From the **Global** view, select **Security** > **Roles**.
+Cluster roles and project/namespace roles can be locked, but global roles cannot.

-2. From the role that you want to lock (or unlock), select **&#8942;** > **Edit**.
-
-3. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. Go to the **Cluster** tab or the **Project/Namespaces** tab.
+1. From the role that you want to lock (or unlock), select **⋮ > Edit Config**.
+1. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.
@@ -67,7 +67,7 @@ Some of the example scenarios include the following:

 # Template Management

-When you create an RKE template, it is available in the Rancher UI from the **Global** view under **Tools > RKE Templates.** When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public.
+When you create an RKE template, it is available in the Rancher UI from the **Cluster Management** view under **RKE Templates**. When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public.

 Administrators can turn on template enforcement to require users to always use RKE templates when creating a cluster. This allows administrators to guarantee that Rancher always provisions clusters with specific settings.

@@ -122,4 +122,4 @@ Some things you could do with add-ons include:
 - Install plugins on nodes that are deployed with a Kubernetes daemonset
 - Automatically set up namespaces, service accounts, or role binding

-The RKE template configuration must be nested within the `rancher_kubernetes_engine_config` directive. To set add-ons, when creating the template, you will click **Edit as YAML.** Then use the `addons` directive to add a manifest, or the `addons_include` directive to set which YAML files are used for the add-ons. For more information on custom add-ons, refer to the [user-defined add-ons documentation.]({{<baseurl>}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/)
+The RKE template configuration must be nested within the `rancher_kubernetes_engine_config` directive. To set add-ons, when creating the template, you will click **Edit as YAML**. Then use the `addons` directive to add a manifest, or the `addons_include` directive to set which YAML files are used for the add-ons. For more information on custom add-ons, refer to the [user-defined add-ons documentation.]({{<baseurl>}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/)
@@ -21,13 +21,13 @@ This section covers the following topics:

 To add a cluster [hosted by an infrastructure provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters) using an RKE template, use these steps:

-1. From the **Global** view, go to the **Clusters** tab.
-1. Click **Add Cluster** and choose the infrastructure provider.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, click **Create** and choose the infrastructure provider.
 1. Provide the cluster name and node template details as usual.
-1. To use an RKE template, under the **Cluster Options**, check the box for **Use an existing RKE template and revision.**
-1. Choose an existing template and revision from the dropdown menu.
+1. To use an RKE template, under the **Cluster Options**, check the box for **Use an existing RKE template and revision**.
+1. Choose an RKE template and revision from the dropdown menu.
 1. Optional: You can edit any settings that the RKE template owner marked as **Allow User Override** when the template was created. If there are settings that you want to change, but don't have the option to, you will need to contact the template owner to get a new revision of the template. Then you will need to edit the cluster to upgrade it to the new revision.
-1. Click **Save** to launch the cluster.
+1. Click **Create** to launch the cluster.

 ### Updating a Cluster Created with an RKE Template

@@ -50,9 +50,9 @@ RKE templates cannot be applied to existing clusters, except if you save an exis

 To convert an existing cluster to use an RKE template,

-1. From the **Global** view in Rancher, click the **Clusters** tab.
-1. Go to the cluster that will be converted to use an RKE template. Click **&#8942;** > **Save as RKE Template.**
-1. Enter a name for the template in the form that appears, and click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster that will be converted to use an RKE template. Click **⋮  > Save as RKE Template**.
+1. Enter a name for the template in the form that appears, and click **Create**.

 **Results:**

@@ -1,9 +1,9 @@
 ---
-title: Creating and Revising Templates
+title: Creating and Revising RKE Templates
 weight: 32
 ---

-This section describes how to manage RKE templates and revisions. You an create, share, update, and delete templates from the **Global** view under **Tools > RKE Templates.**
+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.

@@ -34,8 +34,9 @@ You can revise, share, and delete a template if you are an owner of the template

 ### Creating a Template

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Click **Add Template.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Click **RKE1 configuration > Node Templates**.
+1. Click **Add Template**.
 1. Provide a name for the template. An auto-generated name is already provided for the template' first version, which is created along with this template.
 1. Optional: Share the template with other users or groups by [adding them as members.]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rke-templates/template-access-and-sharing/#sharing-templates-with-specific-users-or-groups) You can also make the template public to share with everyone in the Rancher setup.
 1. Then follow the form on screen to save the cluster configuration parameters as part of the template's revision. The revision can be marked as default for this template.
@@ -50,9 +51,10 @@ You can't edit individual revisions. Since you can't edit individual revisions o

 When new template revisions are created, clusters using an older revision of the template are unaffected.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template that you want to edit and click the **&#8942; > Edit.**
-1. Edit the required information and click **Save.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE Templates**.
+1. Go to the template that you want to edit and click the **⋮ > Edit**.
+1. Edit the required information and click **Save**.
 1. Optional: You can change the default revision of this template and also change who it is shared with.

 **Result:** The template is updated. To apply it to a cluster using an older version of the template, refer to the section on [upgrading a cluster to use a new revision of a template.](#upgrading-a-cluster-to-use-a-new-template-revision)
@@ -61,9 +63,10 @@ When new template revisions are created, clusters using an older revision of the

 When you no longer use an RKE template for any of your clusters, you can delete it.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the RKE template that you want to delete and click the **&#8942; > Delete.**
-1. Confirm the deletion when prompted.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Click **RKE1 configuration > RKE Templates**.
+1. Go to the RKE template that you want to delete and click the **⋮ > Delete**.
+1. Confirm the deletion.

 **Result:** The template is deleted.

@@ -71,8 +74,9 @@ When you no longer use an RKE template for any of your clusters, you can delete

 You can clone the default template revision and quickly update its settings rather than creating a new revision from scratch. Cloning templates saves you the hassle of re-entering the access keys and other parameters needed for cluster creation.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the RKE template that you want to clone and click the **&#8942; > New Revision From Default.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE Templates**.
+1. Go to the RKE template that you want to clone and click the **⋮ > New Revision from Default**.
 1. Complete the rest of the form to create a new revision.

 **Result:** The RKE template revision is cloned and configured.
@@ -81,8 +85,9 @@ You can clone the default template revision and quickly update its settings rath

 When creating new RKE template revisions from your user settings, you can clone an existing revision and quickly update its settings rather than creating a new one from scratch. Cloning template revisions saves you the hassle of re-entering the cluster parameters.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template revision you want to clone. Then select **&#8942; > Clone Revision.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Under **RKE1 configuration**, click **RKE Templates**.
+1. Go to the template revision you want to clone. Then select **⋮ > Clone Revision**.
 1. Complete the rest of the form.

 **Result:** The RKE template revision is cloned and configured. You can use the RKE template revision later when you provision a cluster. Any existing cluster using this RKE template can be upgraded to this new revision.
@@ -93,8 +98,9 @@ When you no longer want an RKE template revision to be used for creating new clu

 You can disable the revision if it is not being used by any cluster.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template revision you want to disable. Then select **&#8942; > Disable.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE Templates**.
+1. Go to the template revision you want to disable. Then select **⋮ > Disable**.

 **Result:** The RKE template revision cannot be used to create a new cluster.

@@ -102,8 +108,9 @@ You can disable the revision if it is not being used by any cluster.

 If you decide that a disabled RKE template revision should be used to create new clusters, you can re-enable it.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template revision you want to re-enable. Then select **&#8942; > Enable.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Under **RKE1 configuration**, click **RKE Templates**.
+1. Go to the template revision you want to re-enable. Then select **⋮ > Enable**.

 **Result:** The RKE template revision can be used to create a new cluster.

@@ -113,8 +120,9 @@ When end users create a cluster using an RKE template, they can choose which rev

 To set an RKE template revision as default,

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the RKE template revision that should be default and click the **&#8942; > Set as Default.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE templates**.
+1. Go to the RKE template revision that should be default and click the **⋮ > Set as Default**.

 **Result:** The RKE template revision will be used as the default option when clusters are created with the template.

@@ -124,8 +132,9 @@ You can delete all revisions of a template except for the default revision.

 To permanently delete a revision,

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the RKE template revision that should be deleted and click the **&#8942; > Delete.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE templates**.
+1. Go to the RKE template revision that should be deleted and click the **⋮ > Delete**.

 **Result:** The RKE template revision is deleted.

@@ -136,10 +145,10 @@ To permanently delete a revision,

 To upgrade a cluster to use a new template revision,

-1. From the **Global** view in Rancher, click the **Clusters** tab.
-1. Go to the cluster that you want to upgrade and click **&#8942; > Edit.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Go to the cluster that you want to upgrade and click **⋮ > Edit Config**.
 1. In the **Cluster Options** section, click the dropdown menu for the template revision, then select the new template revision.
-1. Click **Save.**
+1. Click **Save**.

 **Result:** The cluster is upgraded to use the settings defined in the new template revision.

@@ -151,9 +160,9 @@ This exports the cluster's settings as a new RKE template, and also binds the cl

 To convert an existing cluster to use an RKE template,

-1. From the **Global** view in Rancher, click the **Clusters** tab.
-1. Go to the cluster that will be converted to use an RKE template. Click **&#8942;** > **Save as RKE Template.**
-1. Enter a name for the template in the form that appears, and click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Go to the cluster that will be converted to use an RKE template and **⋮ > Save as RKE Template**.
+1. Enter a name for the RKE template in the form that appears, and click **Create**.

 **Results:**

@@ -9,7 +9,7 @@ For more information on administrator permissions, refer to the [documentation o

 # Giving Users Permission to Create Templates

-Templates can only be created by users who have the global permission **Create RKE Templates.**
+Templates can only be created by users who have the global permission **Create RKE Templates**.

 Administrators have the global permission to create templates, and only administrators can give that permission to other users.

@@ -24,8 +24,11 @@ Administrators can give users permission to create RKE templates in two ways:

 An administrator can individually grant the role **Create RKE Templates** to any existing user by following these steps:

-1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **&#8942; > Edit.**
-1. In the **Global Permissions** section, choose **Custom** and select the **Create RKE Templates** role along with any other roles the user should have. Click **Save.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Choose the user you want to edit and click **⋮ > Edit Config**.
+1. In the **Built-in** section, check the box for **Create new RKE Cluster Templates** role along with any other roles the user should have. You may want to also check the box for **Create RKE Template Revisions**.
+1. Click **Save**.

 **Result:** The user has permission to create RKE templates.

@@ -33,18 +36,23 @@ An administrator can individually grant the role **Create RKE Templates** to any

 Alternatively, the administrator can give all new users the default permission to create RKE templates by following the following steps. This will not affect the permissions of existing users.

-1. From the **Global** view, click **Security > Roles.**
-1. Under the **Global** roles tab, go to the role **Create RKE Templates** and click the **&#8942; > Edit**.
-1. Select the option **Yes: Default role for new users** and click **Save.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Roles**.
+1. Go to the role named **Create new RKE Cluster Templates and click **⋮ > Edit Config**.
+1. Select the option **Yes: Default role for new users**.
+1. Click **Save**.
+1. If you would like new users to also be able to create RKE template revisions, enable that role as default as well.

 **Result:** Any new user created in this Rancher installation will be able to create RKE templates. Existing users will not get this permission.

 ### Revoking Permission to Create Templates

-Administrators can remove a user's permission to create templates with the following steps:
+Administrators can remove a user's permission to create templates with the following steps. Note: Administrators have full control over all resources regardless of whether fine-grained permissions are selected.

-1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **&#8942; > Edit.**
-1. In the **Global Permissions** section, un-check the box for **Create RKE Templates**. In this section, you can change the user back to a standard user, or give the user a different set of custom permissions.
-1. Click **Save.**
+1. In the upper left corner, click **☰ > Users & Authentication**.
+1. In the left navigation bar, click **Users**.
+1. Choose the user you want to edit permissions for and click **⋮ > Edit Config**.
+1. In the **Built-in** section, un-check the box for **Create RKE Templates** and **Create RKE Template Revisions,** if applicable. In this section, you can change the user back to a standard user, or give the user a different set of permissions.
+1. Click **Save**.

 **Result:** The user cannot create RKE templates.
@@ -21,9 +21,9 @@ You might want to require new clusters to use a template to ensure that any clus

 To require new clusters to use an RKE template, administrators can turn on RKE template enforcement with the following steps:

-1. From the **Global** view, click the **Settings** tab.
-1. Go to the `cluster-template-enforcement` setting. Click the vertical **&#8942;** and click **Edit.**
-1. Set the value to **True** and click **Save.**
+1. Click **☰ > Global Settings**.
+1. Go to the `cluster-template-enforcement` setting. Click **⋮ > Edit Setting**.
+1. Set the value to **True** and click **Save**.

 **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.

@@ -31,8 +31,8 @@ To require new clusters to use an RKE template, administrators can turn on RKE t

 To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps:

-1. From the **Global** view, click the **Settings** tab.
-1. Go to the `cluster-template-enforcement` setting. Click the vertical **&#8942;** and click **Edit.**
-1. Set the value to **False** and click **Save.**
+1. Click **☰ > Global Settings**.
+1. Go to the `cluster-template-enforcement` setting. Click **⋮ > Edit Setting**.
+1. Set the value to **False** and click **Save**.

 **Result:** When clusters are provisioned by Rancher, they don't need to use a template.
@@ -52,7 +52,7 @@ The template owner has several options for allowing the cluster creators to upgr

 - **Specify Kubernetes v1.15 on the template:** The template owner can create a new template revision that specifies Kubernetes v1.15. Then the owner of each cluster that uses that template can upgrade their cluster to a new revision of the template. This template upgrade allows the cluster creator to upgrade Kubernetes to v1.15 on their cluster.
 - **Allow any Kubernetes version on the template:** When creating a template revision, the template owner can also mark the the Kubernetes version as **Allow User Override** using the switch near that setting on the Rancher UI. This will allow clusters that upgrade to this template revision to use any version of Kubernetes.
- **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades).** This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed.
+- **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades)**. This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed.

 # Allowing Other Users to Control and Share a Template

@@ -3,9 +3,9 @@ title: Overriding Template Settings
 weight: 33
 ---

-When a user creates an RKE template, each setting in the template has a switch in the Rancher UI that indicates if users can override the setting. This switch marks those settings as **Allow User Override.**
+When a user creates an RKE template, each setting in the template has a switch in the Rancher UI that indicates if users can override the setting. This switch marks those settings as **Allow User Override**.

-After a cluster is created with a template, end users can't update any of the settings defined in the template unless the template owner marked them as **Allow User Override.** However, if the template is [updated to a new revision]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rke-templates/creating-and-revising) that changes the settings or allows end users to change them, the cluster can be upgraded to a new revision of the template and the changes in the new revision will be applied to the cluster.
+After a cluster is created with a template, end users can't update any of the settings defined in the template unless the template owner marked them as **Allow User Override**. However, if the template is [updated to a new revision]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rke-templates/creating-and-revising) that changes the settings or allows end users to change them, the cluster can be upgraded to a new revision of the template and the changes in the new revision will be applied to the cluster.

 When any parameter is set as **Allow User Override** on the RKE template, it means that end users have to fill out those fields during cluster creation and they can edit those settings afterward at any time.

@@ -27,20 +27,23 @@ There are several ways to share templates:

 To allow users or groups to create clusters using your template, you can give them the basic **User** access level for the template.

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template that you want to share and click the **&#8942; > Edit.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Under **RKE1 configuration**, click **RKE Templates**.
+1. Go to the template that you want to share and click the **⋮ > Edit**.
 1. In the **Share Template** section, click on **Add Member**.
 1. Search in the **Name** field for the user or group you want to share the template with.
 1. Choose the **User** access type.
-1. Click **Save.**
+1. Click **Save**.

 **Result:** The user or group can create clusters using the template.

 ### Sharing Templates with All Users

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the template that you want to share and click the **&#8942; > Edit.**
-1. Under **Share Template,** click **Make Public (read-only).** Then click **Save.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **RKE1 Configuration > RKE Templates**.
+1. Go to the template that you want to share and click the **⋮ > Edit**.
+1. Under **Share Template,** check the box for **Make Public (read-only)**.
+1. Click **Save**.

 **Result:** All users in the Rancher setup can create clusters using the template.

@@ -52,10 +55,11 @@ In that case, you can give users the Owner access type, which allows another use

 To give Owner access to a user or group,

-1. From the **Global** view, click **Tools > RKE Templates.**
-1. Go to the RKE template that you want to share and click the **&#8942; > Edit.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. Under **RKE1 configuration**, click **RKE Templates**.
+1. Go to the RKE template that you want to share and click the **⋮ > Edit**.
 1. Under **Share Template**, click on **Add Member** and search in the **Name** field for the user or group you want to share the template with.
-1. In the **Access Type** field, click **Owner.**
-1. Click **Save.**
+1. In the **Access Type** field, click **Owner**.
+1. Click **Save**.

 **Result:** The user or group has the Owner access type, and can modify, share, or delete the template.
@@ -1,8 +1,6 @@
 ---
 title: API Tokens
 weight: 1
-aliases:
-  - /rancher/v2.6/en/cluster-admin/api/api-tokens/
 ---

 By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
@@ -16,7 +14,7 @@ To delete a token,

 1. Access the token you want to delete by its ID. For example, `https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`

-1. Click **Delete.**
+1. Click **Delete**.

 Here is the complete list of tokens that are generated with `ttl=0`:

@@ -1,8 +1,6 @@
 ---
 title: Backups and Disaster Recovery
 weight: 5
-aliases:
-  - /rancher/v2.6/en/backups/v2.6
 ---

 In this section, you'll learn how to create backups of Rancher, how to restore Rancher from backup, and how to migrate Rancher to a new Kubernetes cluster. 
@@ -51,28 +49,19 @@ The `rancher-backup` operator can be installed from the Rancher UI, or with the

 ### Installing rancher-backup with the Rancher UI

-1. In the Rancher UI's Cluster Manager, choose the cluster named **local**
-1. On the upper-right click on the **Cluster Explorer.**
-1. Click **Apps.**
-1. Click the `rancher-backup` operator.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the `local` cluster and click **Explore**.
+1. In the left navigation bar, **Apps & Marketplace > Charts**.
+1. Click **Rancher Backups**.
+1. Click **Install**.
 1. Optional: Configure the default storage location. For help, refer to the [configuration section.](./configuration/storage-config)
+1. Click **Install**.

 **Result:** The `rancher-backup` operator is installed.

-From the **Cluster Explorer,** you can see the `rancher-backup` operator listed under **Deployments.**
+From the **Cluster Dashboard,** you can see the `rancher-backup` operator listed under **Deployments**.

-To configure the backup app in Rancher, click **Cluster Explorer** in the upper left corner and click **Rancher Backups.**
-
-### Installing rancher-backup with the Helm CLI
-
-Install the backup app as a Helm chart:
-
-```
-helm repo add rancher-charts https://charts.rancher.io
-helm repo update
-helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace
-helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system
-```
+To configure the backup app in Rancher, go to the left navigation menu and click **Rancher Backups**.

 ### RBAC

@@ -1,8 +1,6 @@
 ---
 title: Backing up Rancher
 weight: 1
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/back-up-rancher
 ---

 In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{<baseurl>}}/rancher/v2.6/en/backups/v2.5/docker-installs/docker-backups)
@@ -11,28 +9,33 @@ The backup-restore operator needs to be installed in the local cluster, and only

 ### Prerequisites

-Rancher version must be v2.5.0 and up
+The Rancher version must be v2.5.0 and up.

-### 1. Install the `rancher-backup` operator
+### 1. Install the Rancher Backups operator

-The backup storage location is an operator-level setting, so it needs to be configured when `rancher-backup` is installed or upgraded.
+The backup storage location is an operator-level setting, so it needs to be configured when the Rancher Backups application is installed or upgraded.

 Backups are created as .tar.gz files. These files can be pushed to S3 or Minio, or they can be stored in a persistent volume.

-1. In the Rancher UI, go to the **Cluster Explorer** view for the local cluster.
-1. Click **Apps.**
-1. Click **Rancher Backups.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the `local` cluster and click **Explore**. The `local` cluster runs the Rancher server.
+1. Click **Apps & Marketplace > Charts**.
+1. Click **Rancher Backups**.
+1. Click **Install**.
 1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
+1. Click **Install**.

 ### 2. Perform a Backup

 To perform a backup, a custom resource of type Backup must be created.

-1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
-1. Click **Backup.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the `local` cluster and click **Explore**.
+1. In the left navigation bar, click **Rancher Backups > Backups**.
+1. Click **Create**.
 1. Create the Backup with the form, or with the YAML editor.
 1. For configuring the Backup details using the form, click **Create** and refer to the [configuration reference](../configuration/backup-config) and to the [examples.](../examples/#backup)
-1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Backup YAML. This example Backup custom resource would create encrypted recurring backups in S3. The app uses the `credentialSecretNamespace` value to determine where to look for the S3 backup secret:
+1. For using the YAML editor, we can click **Create > Create from YAML**. Enter the Backup YAML. This example Backup custom resource would create encrypted recurring backups in S3. The app uses the `credentialSecretNamespace` value to determine where to look for the S3 backup secret:

    ```yaml
    apiVersion: resources.cattle.io/v1
@@ -59,7 +62,7 @@ To perform a backup, a custom resource of type Backup must be created.
    For help configuring the Backup, refer to the [configuration reference](../configuration/backup-config) and to the [examples.](../examples/#backup)    

    > **Important:** The `rancher-backup` operator doesn't save the EncryptionConfiguration file. The contents of the EncryptionConfiguration file must be saved when an encrypted backup is created, and the same file must be used when restoring from this backup.
-1. Click **Create.**
+1. Click **Create**.

 **Result:** The backup file is created in the storage location configured in the Backup custom resource. The name of this file is used when performing a restore.

@@ -2,8 +2,6 @@
 title: Rancher Backup Configuration Reference
 shortTitle: Configuration
 weight: 4
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/configuration
 ---

 - [Backup configuration](./backup-config)
@@ -2,14 +2,10 @@
 title: Backup Configuration
 shortTitle: Backup
 weight: 1
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/configuration/backup-config
 ---

 The Backup Create page lets you configure a schedule, enable encryption and specify the storage location for your backups.

-{{< img "/img/rancher/backup_restore/backup/backup.png" "">}}
-
 - [Schedule](#schedule)
 - [Encryption](#encryption)
 - [Storage Location](#storage-location)
@@ -20,7 +16,6 @@ The Backup Create page lets you configure a schedule, enable encryption and spec
  - [IAM Permissions for EC2 Nodes to Access S3](#iam-permissions-for-ec2-nodes-to-access-s3)
 - [Examples](#examples)

-
 # Schedule

 Select the first option to perform a one-time backup, or select the second option to schedule recurring backups. Selecting **Recurring Backups** lets you configure following two fields:
@@ -30,8 +25,6 @@ Select the first option to perform a one-time backup, or select the second optio
  - Descriptors, such as `"@midnight"` or `"@every 1h30m"`
 -  **Retention Count**: This value specifies how many backup files must be retained. If files exceed the given retentionCount,  the oldest files will be deleted. The default value is 10.

-{{< img "/img/rancher/backup_restore/backup/schedule.png" "">}}
-
 | YAML Directive Name | Description |
 | ---------------- | ---------------- |
 | `schedule` |  Provide the cron string for scheduling recurring backups.  |
@@ -75,8 +68,6 @@ In the example command above, the name `encryptionconfig` can be changed to anyt

 # Storage Location

-{{< img "/img/rancher/backup_restore/backup/storageLocation.png" "">}}
-
 If the StorageLocation is specified in the Backup, the operator will retrieve the backup location from that particular S3 bucket. If not specified, the operator will try to find this file in the default operator-level S3 store, and in the operator-level PVC store. The default storage location is configured during the deployment of the `rancher-backup` operator.

 Selecting the first option stores this backup in the storage location configured while installing the rancher-backup chart. The second option lets you configure a different S3 compatible storage provider for storing the backup.
@@ -2,8 +2,6 @@
 title: Restore Configuration
 shortTitle: Restore
 weight: 2
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/configuration/restore-config
 ---

 The Restore Create page lets you provide details of the backup to restore from
@@ -2,8 +2,6 @@
 title: Backup Storage Location Configuration
 shortTitle: Storage
 weight: 3
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/configuration/storage-config
 ---

 Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible object store.
@@ -2,9 +2,6 @@
 title: Backup and Restore for Rancher Installed with Docker
 shortTitle: Docker Installs
 weight: 10
-aliases:
-  - /rancher/v2.6/en/installation/backups-and-restoration/single-node-backup-and-restoration/
-  - /rancher/v2.6/en/backups/v2.5/docker-installs
 ---

 - [Backups](./docker-backups)
@@ -2,12 +2,6 @@
 title: Backing up Rancher Installed with Docker
 shortTitle: Backups
 weight: 3
-aliases:
-  - /rancher/v2.6/en/installation/after-installation/single-node-backup-and-restoration/
-  - /rancher/v2.6/en/installation/after-installation/single-node-backup-and-restoration/
-  - /rancher/v2.6/en/backups/backups/single-node-backups/
-  - /rancher/v2.6/en/backups/legacy/backup/single-node-backups/
-  - /rancher/v2.6/en/backups/v2.5/docker-installs/docker-backups/
 ---


@@ -2,10 +2,6 @@
 title: Restoring Backups—Docker Installs
 shortTitle: Restores
 weight: 3
-aliases:
-  - /rancher/v2.6/en/installation/after-installation/single-node-backup-and-restoration/
-  - /rancher/v2.6/en/backups/restorations/single-node-restoration
-  - /rancher/v2.6/en/backups/v2.5/docker-installs/docker-restores
 ---

 If you encounter a disaster scenario, you can restore your Rancher Server to your most recent backup.
@@ -1,8 +1,6 @@
 ---
 title: Examples
 weight: 5
-aliases:
-  - /rancher/v2.6/en/backups/v2.5/examples
 ---

 This section contains examples of Backup and Restore custom resources.
@@ -1,9 +1,6 @@
 ---
 title: Restoring Rancher
 weight: 2
-aliases:
-  - /rancher/v2.x/en/installation/backups/restores
-  - /rancher/v2.x/en/backups/restoring-rancher
 ---

 A restore is performed by creating a Restore custom resource. 
@@ -25,10 +22,12 @@ A restore is performed by creating a Restore custom resource.

 ### Create the Restore Custom Resource

-1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
-1. Click **Restore.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the `local` cluster and click **Explore**. The `local` cluster runs the Rancher server.
+1. In the left navigation bar, click **Rancher Backups > Restores**.
+1. Click **Create**.
 1. Create the Restore with the form, or with YAML.  For creating the Restore resource using form, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.6/en/backups/examples)
-1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML.
+1. For using the YAML editor, we can click **Create > Create from YAML**. Enter the Restore YAML.

    ```yaml
    apiVersion: resources.cattle.io/v1
@@ -50,7 +49,7 @@ A restore is performed by creating a Restore custom resource.

      For help configuring the Restore, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.6/en/backups/examples)

-1. Click **Create.**
+1. Click **Create**.

 **Result:** The rancher-operator scales the rancher deployment back up once the restore completes. The resources are restored in this order:

@@ -1,8 +1,6 @@
 ---
 title: Best Practices Guide
 weight: 4
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5
 ---

 The purpose of this section is to consolidate best practices for Rancher implementations. This also includes recommendations for related technologies, such as Kubernetes, Docker, containers, and more. The objective is to improve the outcome of a Rancher implementation using the operational experience of Rancher and its customers.
@@ -2,8 +2,6 @@
 title: Best Practices for Rancher Managed Clusters
 shortTitle: Rancher Managed Clusters
 weight: 2
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-managed
 ---

 ### Logging
@@ -1,9 +1,6 @@
 ---
 title: Tips for Setting Up Containers
 weight: 100
-aliases:
-  - /rancher/v2.6/en/best-practices/containers
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-managed/containers
 ---

 Running well-built containers can greatly impact the overall performance and security of your environment.
@@ -1,8 +1,6 @@
 ---
 title: Logging Best Practices
 weight: 1
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.6/rancher-managed/logging
 ---
 In this guide, we recommend best practices for cluster-level logging and application logging.

@@ -1,8 +1,6 @@
 ---
 title: Best Practices for Rancher Managed vSphere Clusters
 shortTitle: Rancher Managed Clusters in vSphere
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-managed/managed-vsphere
 ---

 This guide outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -1,8 +1,6 @@
 ---
 title: Monitoring Best Practices
 weight: 2
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-managed/monitoring
 ---

 Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
@@ -2,8 +2,6 @@
 title: Best Practices for the Rancher Server
 shortTitle: Rancher Server
 weight: 1
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-server
 ---

 This guide contains our recommendations for running the Rancher server, and is intended to be used in situations in which Rancher manages downstream Kubernetes clusters.
@@ -1,8 +1,6 @@
 ---
 title: Rancher Deployment Strategy
 weight: 100
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-server/deployment-strategies
 ---

 There are two recommended deployment strategies for a Rancher server that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case:
@@ -1,9 +1,6 @@
 ---
 title: Tips for Running Rancher
 weight: 100
-aliases:
-  - /rancher/v2.6/en/best-practices/deployment-types
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-server/deployment-types
 ---

 This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
@@ -2,8 +2,6 @@
 title: Installing Rancher in a vSphere Environment
 shortTitle: On-Premises Rancher in vSphere
 weight: 3
-aliases:
-  - /rancher/v2.6/en/best-practices/v2.5/rancher-server/rancher-in-vsphere
 ---

 This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -1,8 +1,6 @@
 ---
 title: CIS Scans
 weight: 17
-aliases:
-  - /rancher/v2.6/en/cis-scans/v2.6
 ---

 Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark. The CIS scans can run on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE.
@@ -16,8 +14,8 @@ The `rancher-cis-benchmark` app leverages <a href="https://github.com/aquasecuri
 - [Roles-based Access Control](./rbac)
 - [Configuration](./configuration)
 - [How-to Guides](#how-to-guides)
-  - [Installing rancher-cis-benchmark](#installing-rancher-cis-benchmark)
-  - [Uninstalling rancher-cis-benchmark](#uninstalling-rancher-cis-benchmark)
+  - [Installing CIS Benchmark](#installing-cis-benchmark)
+  - [Uninstalling CIS Benchmark](#uninstalling-cis-benchmark)
  - [Running a Scan](#running-a-scan)
  - [Running a Scan Periodically on a Schedule](#running-a-scan-periodically-on-a-schedule)
  - [Skipping Tests](#skipping-tests)
@@ -131,21 +129,21 @@ For more information about configuring the custom resources for the scans, profi
 - [Enabling Alerting for rancher-cis-benchmark](#enabling-alerting-for-rancher-cis-benchmark)
 - [Configuring Alerts for a Periodic Scan on a Schedule](#configuring-alerts-for-a-periodic-scan-on-a-schedule)
 - [Creating a Custom Benchmark Version for Running a Cluster Scan](#creating-a-custom-benchmark-version-for-running-a-cluster-scan)
-### Installing rancher-cis-benchmark
+### Installing CIS Benchmark

-1. In the Rancher UI, go to the **Cluster Explorer.**
-1. Click **Apps.**
-1. Click `rancher-cis-benchmark`.
-1. Click **Install.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to install CIS Benchmark and click **Explore**.
+1. In the left navigation bar, click **Apps & Marketplace > Charts**.
+1. Click **CIS Benchmark**
+1. Click **Install**.

 **Result:** The CIS scan application is deployed on the Kubernetes cluster.

-### Uninstalling rancher-cis-benchmark
+### Uninstalling CIS Benchmark

-1. From the **Cluster Explorer,** go to the top left dropdown menu and click **Apps & Marketplace.**
-1. Click **Installed Apps.**
+1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps & Marketplace > Installed Apps**.
 1. Go to the `cis-operator-system` namespace and check the boxes next to `rancher-cis-benchmark-crd` and `rancher-cis-benchmark`.
-1. Click **Delete** and confirm **Delete.**
+1. Click **Delete** and confirm **Delete**.

 **Result:** The `rancher-cis-benchmark` application is uninstalled.

@@ -157,23 +155,26 @@ Note: There is currently a limitation of running only one CIS scan at a time for

 To run a scan,

-1. Go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Scans** section, click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
+1. Click **CIS Benchmark > Scan**.
+1. Click **Create**.
 1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
-1. Click **Create.**
+1. Click **Create**.

 **Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
 ### Running a Scan Periodically on a Schedule

 To run a ClusterScan on a schedule,

-1. Go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Scans** section, click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
+1. Click **CIS Benchmark > Scan**.
 1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
-1. Choose the option **Run scan on a schedule.**
-1. Enter a valid <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">cron schedule expression</a> in the field **Schedule.**
+1. Choose the option **Run scan on a schedule**.
+1. Enter a valid <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">cron schedule expression</a> in the field **Schedule**.
 1. Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
-1. Click **Create.**
+1. Click **Create**.

 **Result:** The scan runs and reschedules to run according to the cron schedule provided. The **Next Scan** value indicates the next time this scan will run again. 

@@ -187,9 +188,10 @@ CIS scans can be run using test profiles with user-defined skips.

 To skip tests, you will create a custom CIS scan profile. A profile contains the configuration for the CIS scan, which includes the benchmark versions to use and any specific tests to skip in that benchmark.

-1. In the **Cluster Explorer,** go to the top-left dropdown menu and click **CIS Benchmark.**
-1. Click **Profiles.**
-1. From here, you can create a profile in multiple ways. To make a new profile, click **Create** and fill out the form in the UI. To make a new profile based on an existing profile, go to the existing profile, click the three vertical dots, and click **Clone as YAML.**  If you are filling out the form, add the tests to skip using the test IDs, using the relevant CIS Benchmark as a reference. If you are creating the new test profile as YAML, you will add the IDs of the tests to skip in the `skipTests` directive. You will also give the profile a name:
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
+1. Click **CIS Benchmark > Profile**.
+1. From here, you can create a profile in multiple ways. To make a new profile, click **Create** and fill out the form in the UI. To make a new profile based on an existing profile, go to the existing profile and click **⋮ Clone**.  If you are filling out the form, add the tests to skip using the test IDs, using the relevant CIS Benchmark as a reference. If you are creating the new test profile as YAML, you will add the IDs of the tests to skip in the `skipTests` directive. You will also give the profile a name:

    ```yaml
    apiVersion: cis.cattle.io/v1
@@ -207,7 +209,7 @@ To skip tests, you will create a custom CIS scan profile. A profile contains the
        - "1.1.20"
        - "1.1.21"
    ```
-1. Click **Create.**
+1. Click **Create**.

 **Result:** A new CIS scan profile is created.

@@ -217,7 +219,9 @@ When you [run a scan](#running-a-scan) that uses this profile, the defined tests

 To view the generated CIS scan reports,

-1. In the **Cluster Explorer,** go to the top left dropdown menu and click **Cluster Explorer > CIS Benchmark.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
+1. Click **CIS Benchmark > Scan**.
 1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.

 One can download the report from the Scans list or from the scan detail page.
@@ -232,7 +236,7 @@ Alerts can be configured to be sent out for a scan that runs on a schedule.
 >
 > While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/v2.5/configuration/alertmanager/#example-route-config-for-cis-scan-alerts)

-While installing or upgrading the `rancher-cis-benchmark` application, set the following flag to `true` in the `values.yaml`:
+While installing or upgrading the `rancher-cis-benchmark` Helm chart, set the following flag to `true` in the `values.yaml`:

 ```yaml
 alerts:
@@ -247,7 +251,7 @@ A scheduled scan can also specify if you should receive alerts when the scan com

 Alerts are supported only for a scan that runs on a schedule.

-The `rancher-cis-benchmark` application supports two types of alerts:
+The CIS Benchmark application supports two types of alerts:

 - Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
 - Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.
@@ -261,14 +265,16 @@ The `rancher-cis-benchmark` application supports two types of alerts:
 To configure alerts for a scan that runs on a schedule,

 1. Please enable alerts on the `rancher-cis-benchmark` application (#enabling-alerting-for-rancher-cis-benchmark)
-1. Go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Scans** section, click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
+1. Click **CIS Benchmark > Scan**.
+1. Click **Create**.
 1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
-1. Choose the option **Run scan on a schedule.**
-1. Enter a valid [cron schedule expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) in the field **Schedule.**
-1. Check the boxes next to the Alert types under **Alerting.**
-1. Optional: Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
-1. Click **Create.**
+1. Choose the option **Run scan on a schedule**.
+1. Enter a valid [cron schedule expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) in the field **Schedule**.
+1. Check the boxes next to the Alert types under **Alerting**.
+1. Optional: Choose a **Retention Count**, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
+1. Click **Create**.

 **Result:** The scan runs and reschedules to run according to the cron schedule provided. Alerts are sent out when the scan finishes if routes and receiver are configured under `rancher-monitoring` application.

@@ -1,13 +1,15 @@
 ---
 title: Configuration
 weight: 3
-aliases:
-  - /rancher/v2.6/en/cis-scans/v2.5/configuration
 ---

 This configuration reference is intended to help you manage the custom resources created by the `rancher-cis-benchmark` application. These resources are used for performing CIS scans on a cluster, skipping tests, setting the test profile that will be used during a scan, and other customization.

-To configure the custom resources, go to the **Cluster Explorer** in the Rancher UI. In dropdown menu in the top left corner, click **Cluster Explorer > CIS Benchmark.**
+To configure the custom resources, go to the **Cluster Dashboard** To configure the CIS scans,
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to configure CIS scans and click **Explore**.
+1. In the left navigation bar, click **CIS Benchmark**.

 ### Scans

@@ -1,8 +1,6 @@
 ---
 title: Creating a Custom Benchmark Version for Running a Cluster Scan
 weight: 4
-aliases:
-  - /rancher/v2.6/en/cis-scans/v2.5/custom-benchmark
 ---

 Each Benchmark Version defines a set of test configuration files that define the CIS tests to be run by the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool.
@@ -48,25 +46,27 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom

 ### 2. Add a Custom Benchmark Version to a Cluster

-1. Once the ConfigMap has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI. 
-1. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Benchmark Versions** section, click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
+1. In the left navigation bar, click **CIS Benchmark > Benchmark Version**.
+1. Click **Create**.
 1. Enter the **Name** and a description for your custom benchmark version.
 1. Choose the cluster provider that your benchmark version applies to.
 1. Choose the ConfigMap you have uploaded from the dropdown.
 1. Add the minimum and maximum Kubernetes version limits applicable, if any.
-1. Click **Create.**
+1. Click **Create**.

 ### 3. Create a New Profile for the Custom Benchmark Version

 To run a scan using your custom benchmark version, you need to add a new Profile pointing to this benchmark version.

-1. Once the custom benchmark version has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI. 
-1. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Profiles** section, click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
+1. In the left navigation bar, click **CIS Benchmark > Profile**.
+1. Click **Create**.
 1. Provide a **Name** and description. In this example, we name it `foo-profile`.
-1. Choose the Benchmark Version `foo` from the dropdown.
-1. Click **Create.**
+1. Choose the Benchmark Version from the dropdown.
+1. Click **Create**.

 ### 4. Run a Scan Using the Custom Benchmark Version

@@ -74,9 +74,11 @@ Once the Profile pointing to your custom benchmark version `foo` has been create

 To run a scan,

-1. Go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
-1. In the **Scans** section, click **Create.**
-1. Choose the new cluster scan profile `foo-profile`.
-1. Click **Create.**
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
+1. In the left navigation bar, click **CIS Benchmark > Scan**.
+1. Click **Create**.
+1. Choose the new cluster scan profile.
+1. Click **Create**.

 **Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
@@ -2,9 +2,6 @@
 title: Roles-based Access Control
 shortTitle: RBAC
 weight: 3
-aliases:
-  - /rancher/v2.6/en/cis-scans/rbac
-  - /rancher/v2.6/en/cis-scans/v2.5/rbac
 ---

 This section describes the permissions required to use the rancher-cis-benchmark App.
@@ -1,9 +1,6 @@
 ---
 title: Skipped and Not Applicable Tests
 weight: 3
-aliases:
-  - /rancher/v2.6/en/cis-scans/skipped-tests
-  - /rancher/v2.6/en/cis-scans/v2.5/skipped-tests
 ---

 This section lists the tests that are skipped in the permissive test profile for RKE.
@@ -4,8 +4,6 @@ description: The Rancher CLI is a unified tool that you can use to interact with
 metaTitle: "Using the Rancher Command Line Interface "
 metaDescription: "The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI"
 weight: 21
-aliases:
-  - /rancher/v2.6/en/cluster-admin/cluster-access/cli
 ---

 The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
@@ -13,12 +13,6 @@ This page covers the following topics:

 > This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.

-## Switching between Clusters
-
-To switch between clusters, use the drop-down available in the navigation bar.
-
-Alternatively, you can switch between projects and clusters directly in the navigation bar. Open the **Global** view and select **Clusters** from the main menu. Then select the name of the cluster you want to open.
-
 ## Managing Clusters in Rancher

 After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster. 
@@ -100,9 +100,9 @@ In the **Advanced Cluster Options** section, there are several options available

 In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure.

-1. In the **Global** view, navigate to the cluster that you want to take a one-time snapshot.
-
-2. Click the **&#8942; > Snapshot Now**.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, navigate to the cluster where you want to take a one-time snapshot.
+1. Click **⋮ > Take Snapshot**.

 **Result:** Based on your [snapshot backup target](#snapshot-backup-targets), a one-time snapshot will be taken and saved in the selected backup target.

@@ -149,9 +149,9 @@ The `S3` backup target supports using IAM authentication to AWS API in addition

 The list of all available snapshots for the cluster is available in the Rancher UI.

-1. In the **Global** view, navigate to the cluster that you want to view snapshots.
-
-2. Click **Tools > Snapshots** from the navigation bar to view the list of saved snapshots. These snapshots include a timestamp of when they were created.
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the **Clusters** page, go to the cluster where you want to view the snapshots and click its name.
+1. Click the **Snapshots** tab to view the list of saved snapshots. These snapshots include a timestamp of when they were created.

 # Safe Timestamps

@@ -2,8 +2,6 @@
 title: Removing Kubernetes Components from Nodes
 description: Learn about cluster cleanup when removing nodes from your Rancher-launched Kubernetes cluster. What is removed, how to do it manually
 weight: 2055
-aliases:
-  - /rancher/v2.6/en/faq/cleaning-cluster-nodes/
 ---

 This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
@@ -1,8 +1,6 @@
 ---
 title: Cloning Clusters
 weight: 2035
-aliases:
-  - /rancher/v2.6/en/cluster-provisioning/cloning-clusters/
 ---

 If you have a cluster in Rancher that you want to use as a template for creating similar clusters, you can use Rancher CLI to clone the cluster's configuration, edit it, and then use it to quickly launch the cloned cluster.
@@ -98,4 +96,4 @@ Move `cluster-template.yml` into the same directory as the Rancher CLI binary. T

    ./rancher up --file cluster-template.yml

-**Result:** Your cloned cluster begins provisioning. Enter `./rancher cluster ls` to confirm. You can also log into the Rancher UI and open the **Global** view to watch your provisioning cluster's progress.
+**Result:** Your cloned cluster begins provisioning. Enter `./rancher cluster ls` to confirm.
@@ -1,11 +1,6 @@
 ---
 title: Adding Users to Clusters
 weight: 2020
-aliases:
-  - /rancher/v2.6/en/tasks/clusters/adding-managing-cluster-members/
-  - /rancher/v2.6/en/k8s-in-rancher/cluster-members/
-  - /rancher/v2.6/en/cluster-admin/cluster-members
-  - /rancher/v2.6/en/cluster-provisioning/cluster-members/
 ---

 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.
@@ -26,11 +21,10 @@ There are two contexts where you can add cluster members:

 Cluster administrators can edit the membership for a cluster, controlling which Rancher users can access the cluster and what features they can use.

-1. From the **Global** view, open the cluster that you want to add members to.
-
-2. From the main menu, select **Members**. Then click **Add Member**.
-
-3. Search for the user or group that you want to add to the cluster.
+1. Click **☰ > Cluster Management**.
+1. Go to the cluster you want to add members to and click **⋮ > Edit Config**.
+1. In the **Member Roles** tab, click **Add Member**.
+1. Search for the user or group that you want to add to the cluster.

 	If external authentication is configured:

@@ -43,7 +37,7 @@ Cluster administrators can edit the membership for a cluster, controlling which

 		>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

-4. Assign the user or group **Cluster** roles.  
+1. Assign the user or group **Cluster** roles.  

 	[What are Cluster Roles?]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/)

@@ -2,12 +2,6 @@
 title: "Access a Cluster with Kubectl and kubeconfig"
 description: "Learn how you can access and manage your Kubernetes clusters using kubectl with kubectl Shell or with kubectl CLI and kubeconfig file. A kubeconfig file is used to configure access to Kubernetes. When you create a cluster with Rancher, it automatically creates a kubeconfig for your cluster."
 weight: 2010
-aliases:
-  - /rancher/v2.6/en/k8s-in-rancher/kubectl/
-  - /rancher/v2.6/en/cluster-admin/kubectl
-  - /rancher/v2.6/en/concepts/clusters/kubeconfig-files/
-  - /rancher/v2.6/en/k8s-in-rancher/kubeconfig/
-  - /rancher/2.x/en/cluster-admin/kubeconfig
 ---

 This section describes how to manipulate your downstream Kubernetes cluster with kubectl from the Rancher UI or from your workstation.
@@ -26,9 +20,9 @@ For more information on using kubectl, see [Kubernetes Documentation: Overview o

 You can access and manage your clusters by logging into Rancher and opening the kubectl shell in the UI. No further configuration necessary.

-1. From the **Global** view, open the cluster that you want to access with kubectl.
-
-2. Click **Launch kubectl**. Use the window that opens to interact with your Kubernetes cluster.
+1. Click **☰ > Cluster Management**.
+1. Go to the cluster you want to access with kubectl and click **Explore**.
+1. In the top navigation menu, click the **Kubectl Shell** button. Use the window that opens to interact with your Kubernetes cluster.

 ### Accessing Clusters with kubectl from Your Workstation

@@ -38,10 +32,10 @@ This alternative method of accessing the cluster allows you to authenticate with

 > **Prerequisites:** These instructions assume that you have already created a Kubernetes cluster, and that kubectl is installed on your workstation. For help installing kubectl, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/tasks/tools/install-kubectl/)

-1. Log into Rancher. From the **Global** view, open the cluster that you want to access with kubectl.
-1. Click **Kubeconfig File**.
-1. Copy the contents displayed to your clipboard.
-1. Paste the contents into a new file on your local computer. Move the file to `~/.kube/config`. Note: The default location that kubectl uses for the kubeconfig file is `~/.kube/config`, but you can use any directory and specify it using the `--kubeconfig` flag, as in this command:
+1. Log into Rancher. Click **☰ > Cluster Management**.
+1. Go to the cluster that you want to access with kubectl and click **Explore**.
+1. In the top navigation bar, click **Download KubeConfig** button.
+1. Save the YAML file on your local computer. Move the file to `~/.kube/config`. Note: The default location that kubectl uses for the kubeconfig file is `~/.kube/config`, but you can use any directory and specify it using the `--kubeconfig` flag, as in this command:
  ```
  kubectl --kubeconfig /custom/path/kube.config get pods
  ```
@@ -1,8 +1,6 @@
 ---
 title: Cluster Configuration
 weight: 2025
-aliases:
-  - /rancher/v2.6/en/k8s-in-rancher/editing-clusters
 ---

 After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster.
@@ -27,7 +27,7 @@ To get the tenant ID, go to the Azure Portal, then click **Azure Active Director

 ### Subscription ID

-To get the subscription ID, click **All Services** in the left navigation bar. Then click **Subscriptions.** Go to the name of the subscription that you want to associate with your Kubernetes cluster and copy the **Subscription ID.**
+To get the subscription ID, click **All Services** in the left navigation bar. Then click **Subscriptions**. Go to the name of the subscription that you want to associate with your Kubernetes cluster and copy the **Subscription ID**.

 ### Client ID

@@ -39,7 +39,7 @@ You can't retrieve the client secret value after it is created, so if you don't

 To get a new client secret, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations,** then click the name of the service principal.

-Then click **Certificates & secrets** and click **New client secret.** Click **Add.** Then copy the **Value** of the new client secret.
+Then click **Certificates & secrets** and click **New client secret**. Click **Add**. Then copy the **Value** of the new client secret.

 ### Environment

--- a/Show More
+++ b/Show More