Merge branch 'rancher:main' into update-api-sidebar

2026-09-25 20:48:11 +00:00 · 2024-03-11 15:12:55 -07:00
parent eafbafc1c5 4db4014a20
commit ae770c672f
111 changed files with 1727 additions and 354 deletions
@@ -29,6 +29,26 @@ Use `metadata.generateName` to ensure a unique project ID, but note that `kubect

 Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.

+If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  annotations: 
+  field.cattle.io/creatorId:
+    user-id
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+
 ### Creating a Project With a Resource Quota

 Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
@@ -111,3 +131,5 @@ Delete the project under the cluster namespace:
 ```bash
 kubectl --namespace c-m-abcde delete project p-vwxyz
 ```
+
+Note that this command doesn't delete the namespaces and resources that formerly belonged to the project. 
@@ -86,6 +86,8 @@ For more information, see the [Flannel GitHub Page](https://github.com/flannel-i

 #### Weave

+<DeprecationWeave />
+
 ![Weave Logo](/img/weave-logo.png)

 Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
@@ -184,8 +186,6 @@ The following table summarizes the different features available for each CNI net

 ## CNI Community Popularity

-import CNIPopularityTable from '/shared-files/_cni-popularity.md';
-
 <CNIPopularityTable />

 ## Which CNI Provider Should I Use?
@@ -28,10 +28,13 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
 Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)

 Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
+
 ### Helm Version

 The upgrade instructions assume you are using Helm 3.

+<DeprecationHelm2 />
+
 For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 ### For air-gapped installs: Populate private registry
@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu

 ### Install the Helm CLI

+<DeprecationHelm2 />
+
 Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:

 ```
@@ -3,6 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
 description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
 ---

+:::caution
+
+Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
+
+:::
+
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
 </head>
@@ -8,7 +8,9 @@ title: Helm Version Requirements

 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.

-> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+<DeprecationHelm2 />

 - Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
 - Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
    ```

+    <DeprecationHelm2 />
+    
    The Helm 2 command is as follows:

    ```plain
@@ -7,8 +7,5 @@ description: Deploy SUSE Rancher from the AWS Marketplace listing.
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
 </head>

-import YouTube from '@site/src/components/YouTube'
-
 You can quickly deploy Rancher Prime on Amazon Elastic Kubernetes Service (EKS.) To learn more, see the [instructions](https://suse-enceladus.github.io/marketplace-docs/rancher-prime/aws/?repository=rancher-payg-billing-adapter-llc-prd) under Usage Information in the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c). 

-# <YouTube id="9dznJ7Ons0M"/> 
@@ -40,8 +40,8 @@ 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. 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. In the left navigation bar, click **Role Templates**.
+1. Select **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.
@@ -11,6 +11,12 @@ One of the key features that Rancher adds to Kubernetes is centralized user auth

 This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account.

+:::warning
+
+The account used to enable the external provider will be granted admin permissions. If you use a test account or non-admin account, that account will still be granted admin-level permissions. See [External Authentication Configuration and Principal Users](#external-authentication-configuration-and-principal-users) to understand why.
+
+:::
+
 ## External vs. Local Authentication

 The Rancher authentication proxy integrates with the following external authentication services.
@@ -77,12 +83,14 @@ To set the Rancher access level for users in the authorization service, follow t

 ## External Authentication Configuration and Principal Users

-Configuration of external authentication requires:
+Configuring external authentication requires:

 - A local user assigned the administrator role, called hereafter the _local principal_.
 - An external user that can authenticate with your external authentication service, called hereafter the _external principal_.

-Configuration of external authentication affects how principal users are managed within Rancher. Follow the list below to better understand these effects.
+The configuration of external authentication also affects how principal users are managed within Rancher. Specifically, when a user account enables an external provider, it is granted admin-level permissions. This is because the local principal and external principal share the same user ID and access rights.
+
+The following instructions demonstrate these effects:

 1. Sign into Rancher as the local principal and complete configuration of external authentication.

@@ -82,4 +82,4 @@ The following features are available under **Global Configuration**:
 - **Global DNS Entries**
 - **Global DNS Providers**

-As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
+As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
@@ -11,7 +11,7 @@ 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.
+1. In the left navigation bar, click **Role Templates** and go to the **Cluster** or **Project/Namespaces** tab.

 ### Membership and Role Assignment

@@ -73,7 +73,7 @@ The following table lists the permissions available for the `Manage Nodes` 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. In the left navigation bar, click **Role Templates**.
 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.

@@ -220,7 +220,7 @@ 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. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 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.
@@ -31,7 +31,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
 The steps to add custom roles differ depending on the version of Rancher.

 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 1.  Select a tab to determine the scope of the role you're adding. The tabs are:

  - **Global:** The role is valid for allowing members to manage global scoped resources.
@@ -65,7 +65,7 @@ The custom role can then be assigned to a user or group so that the role takes e
 To create a custom role based on an existing role,

 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 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. In the **Inherit From** tab, select the role(s) that the custom role will inherit permissions from.
@@ -86,7 +86,7 @@ Custom roles can be deleted, but built-in roles cannot be deleted.
 To delete a custom role,

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

@@ -31,8 +31,8 @@ When you create a new local user, you assign them a global permission as you com
 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.
+1. In the left navigation bar, click **Role Templates**.
+1. The **Role Templates** 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)

@@ -43,8 +43,8 @@ When a user logs into Rancher using an external authentication provider for the
 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.
+1. In the left navigation bar, click **Role Templates**.
+1. The **Role Templates** 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)

@@ -92,7 +92,7 @@ The following table lists each built-in global permission and whether it is incl
 For details on which Kubernetes resources correspond to each global permission,

 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 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.

 :::note Notes:
@@ -221,7 +221,7 @@ Default roles are only assigned to users added from an external authentication p
 To change the default global permissions that are assigned to external users upon their first log in, follow these steps:

 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. In the left navigation bar, click **Role Templates**. On the **Role Templates** 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**.

@@ -234,7 +234,7 @@ To configure permission for a user,
 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. 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 **Role Templates** 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.
@@ -36,7 +36,7 @@ You can lock roles in two contexts:
 Cluster roles and project/namespace roles can be locked, but global roles cannot.

 1. In the upper left corner, click **☰ > Users & Authentication**.
-1. In the left navigation bar, click **Roles**.
+1. In the left navigation bar, click **Role Templates**.
 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**.
@@ -27,7 +27,8 @@ Since Rancher can be installed on any Kubernetes cluster, you can use this backu


 ### 1. Install the rancher-backup Helm chart
-Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
+
+Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):

  1. Add the Helm repository:

@@ -36,13 +37,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
     helm repo update
     ```

-  1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
+  1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
+
     ```bash
-     helm search repo --versions rancher-charts/rancher-backup
-     CHART_VERSION=<2.x.x>
+     CHART_VERSION=<chart-version>
     ```

  1. Install the charts:
+   
     ```bash
     helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
     helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
@@ -50,7 +52,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope

     :::note

-     The above assumes an environment with outbound connectivity to Docker Hub
+     The above assumes an environment with outbound connectivity to Docker Hub.

     For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.

@@ -74,9 +74,31 @@ Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) s

 From the left sidebar select _"Repositories"_.

-These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.

-To add a private CA for Helm Chart repositories:
+#### Add Custom Git Repositories
+
+Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.
+
+You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
+
+Whenever you add a chart repository to Rancher, it becomes available immediately.
+
+#### Add Custom Helm Chart Repositories
+
+You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.
+
+For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).
+
+To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.
+
+#### Add Private Git/Helm Chart Repositories
+
+You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.
+
+#### Add a Private CA to Repositories
+
+To add a private CA to Helm chart repositories:

 - **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
    ```
@@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni

 Introduced in Rancher v2.5, the application is powered by [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/grafana/),  [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), and the [Prometheus adapter.](https://github.com/DirectXMan12/k8s-prometheus-adapter) 

-For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md), [alerting](/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md), [notifiers](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](/versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md).
+For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).

 Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.

@@ -55,7 +55,13 @@ For a list of monitoring components exposed in the Rancher UI, along with common

 ## Role-based Access Control

-For information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
+For more information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
+
+:::note
+
+Rancher and Project read permissions don't necessarily apply to monitoring resources. See [monitoring-ui-view](rbac-for-monitoring.md#additional-monitoring-clusterroles) for more details.
+
+:::

 ## Guides

@@ -112,7 +112,7 @@ Monitoring also creates additional `ClusterRoles` that aren't assigned to users

 | Role | Purpose  |
 | ------------------------------| ---------------------------|
-| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. |
+| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |

 :::note

@@ -216,7 +216,11 @@ In addition to these default roles, the following Rancher project roles can be a
 |--------------------------|-------------------------------|-------|------|
 | View Monitoring* | [monitoring-ui-view](#additional-monitoring-clusterroles)    |    2.4.8+    |  9.4.204+ |

-\* A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project. 
+:::note
+
+A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
+
+:::

 ### Differences in 2.5.x

@@ -6,6 +6,8 @@ title: OPA Gatekeeper
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
 </head>

+<DeprecationOPAGatekeeper link="kubewarden" />
+
 To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.

 OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
@@ -68,18 +68,24 @@ The following commands are available for use in Rancher CLI.
 | `catalog`  | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md).  |
 | `clusters, [cluster]`  | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).  |
 | `context`  | Switches between Rancher [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection).  |
+| `globaldns`  | Performs operations on global DNS providers and entries.  |
 | `inspect [OPTIONS] [RESOURCEID RESOURCENAME]`  | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID.  |
-| `kubectl`  |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations).   |
+| `kubectl`  | Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations).   |
 | `login, [l]`  | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication).  |
-| `namespaces, [namespace]`  |Performs operations on namespaces.   |
-| `nodes, [node]`  |Performs operations on nodes.   |
+| `machines, [machine]`  | Performs operations on machines.  |
+| `multiclusterapps, [multiclusterapp mcapps mcapp]`  | Performs operations with multi-cluster apps.  |
+| `namespaces, [namespace]`  | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md).  |
+| `nodes, [node]`  | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md).  |
 | `projects, [project]`  | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md).  |
 | `ps`  | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project.  |
+| `server`  | Performs operations for the server.  |
 | `settings, [setting]`  | Shows the current settings for your Rancher Server.  |
 | `ssh`  | Connects to one of your cluster nodes using the SSH protocol.  |
+| `up`  | Applies compose config.  |
+| `wait`  | Waits for resources cluster, app, project, multiClusterApp.  |
+| `token`  | Authenticates and generates new kubeconfig token.  |
 | `help, [h]`  | Shows a list of commands or help for one command.  |

-
 ### Rancher CLI Help

 Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
@@ -1,5 +1,5 @@
 ---
-title: EKS Cluster Configuration Reference | 2.6
+title: EKS Cluster Configuration Reference
 ---

 <head>
@@ -147,6 +147,25 @@ The following settings are also configurable. All of these except for the "Node
 | Labels | Kubernetes labels applied to the nodes in the managed node group. |
 | Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |

+### Self-managed Amazon Linux Nodes
+
+You can register an EKS cluster containing self-managed Amazon Linux nodes. You must configure this type of cluster according to the instructions in the official AWS documentation for [launching self-managed Amazon Linux nodes](https://docs.aws.amazon.com/eks/latest/userguide/launch-workers.html). EKS clusters containing self-managed Amazon Linux nodes are usually operated by the [Karpenter](https://karpenter.sh/docs/) project. After you provision an EKS cluster containing self-managed Amazon Linux nodes, [register the cluster](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md) so it can be managed by Rancher. However, the nodes won't be visible in the Rancher UI.
+
+### IAM Roles for Service Accounts
+
+An Applications Deployment running on an EKS cluster can make requests to AWS services via IAM permissions. These applications must sign their requests with AWS credentials. IAM roles for service accounts manage these credentials using an AWS OIDC endpoint. Rather than distributing AWS credentials to containers or relying on an EC2 instance's role, you can link an [IAM role to a Kubernetes service account](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) and configure your Pods to use this account.
+
+:::note
+
+Linking to an IAM role is not supported for Rancher pods in an EKS cluster.
+
+:::
+
+To enable IAM roles for service accounts:
+1. [Create an IAM OIDC provider for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)
+1. [Configure a Kubernetes service account to assume an IAM role](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)
+1. [Configure Pods to use a Kubernetes service account](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html)
+1. [Use a supported AWS SDK](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html)

 ### Configuring the Refresh Interval

@@ -204,7 +204,7 @@ The node operating system image. For more information for the node image options

 :::note

-The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
+The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.

 :::

@@ -78,6 +78,8 @@ Out of the box, Rancher is compatible with the following network providers:
 - [Calico](https://docs.projectcalico.org/v3.11/introduction/)
 - [Weave](https://github.com/weaveworks/weave)

+<DeprecationWeave />
+
 :::note Notes on Weave:

 When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File](#rke-cluster-config-file-reference) and the [Weave Network Plug-in Options](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
@@ -24,8 +24,6 @@ This section assumes familiarity with how monitoring components work together. F

 :::

-To create notification receivers in the Rancher UI,
-
 <Tabs>
 <TabItem value="Rancher v2.6.5+">

@@ -152,24 +150,20 @@ The Teams receiver is not a native receiver and must be enabled before it can be
 1. Select the **Teams** option and click **Install**.
 1. Take note of the namespace used as it will be required in a later step.

-### Configure the Teams Receiver
+### Configuring the Teams Receiver

-The Teams receiver can be configured by updating its ConfigMap. For example, the following is a minimal Teams receiver configuration.
+1. To configure the Teams receiver, update its ConfigMap. The following example is a minimal Teams receiver configuration:

-```yaml
-[Microsoft Teams]
-teams-instance-1: https://your-teams-webhook-url
-```
+    ```yaml
+    [Microsoft Teams]
+    connector: https://your-teams-webhook-url
+    ```

-When configuration is complete, add the receiver using the steps in [this section](#creating-receivers-in-the-rancher-ui).
+2. After you update the configuration, follow the instructions in [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) to add the receiver. Use the example below to form your URL. Make sure to replace `<namespace>` with the namespace of the `rancher-alerting-drivers` app:

-Use the example below as the URL where:
-
- `ns-1` is replaced with the namespace where the `rancher-alerting-drivers` app is installed
-
-```yaml
-url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
-```
+    ```yaml
+    url: http://rancher-alerting-drivers-prom2teams.<namespace>.svc:8089/v2/connector
+    ```

 <!-- https://github.com/idealista/prom2teams -->

@@ -187,7 +181,7 @@ The SMS receiver is not a native receiver and must be enabled before it can be u
 1. Select the **SMS** option and click **Install**.
 1. Take note of the namespace used as it will be required in a later step.

-### Configure the SMS Receiver
+### Configuring the SMS Receiver

 The SMS receiver can be configured by updating its ConfigMap. For example, the following is a minimal SMS receiver configuration.

@@ -41,8 +41,11 @@ For more information, refer to the monitoring documentation [here.](../integrati
 Rancher's integration with Istio was improved in Rancher v2.5.

 For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
+
 ## OPA Gatekeeper

+<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
+
 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)

 ## CIS Scans
@@ -10,6 +10,7 @@ Rancher is committed to informing the community of security issues in our produc

 | ID | Description | Date | Resolution |
 |----|-------------|------|------------|
+| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | A vulnerability was discovered in Rancher's and Fleet's agents, currently deemed a medium to high severity CVE, that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker would need to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the server-url of the Rancher cluster). At the moment there is no fix available and it affects all supported versions of Rancher. Customers and users are advised to follow the recommendations and best practices described in our [blog post](https://www.suse.com/c/rancher-security-update/). | 16 Feb 2024 | Pending |
 | [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Norman). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
 | [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Apiserver). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
 | [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, in which sensitive data may be leaked into Rancher's audit logs. | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
@@ -9,7 +9,7 @@ title: Rancher Webhook
 Rancher-Webhook is an essential component of Rancher that works in conjunction with Kubernetes to enhance security and enable critical features for Rancher-managed clusters. 

 It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom, Rancher-specific validation and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration`, and will override any manual edits.
-Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release.
+Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release. To safely modify these values see [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration).

 Each Rancher version is designed to be compatible with a single version of the webhook. The compatible versions are provided below for convenience.

@@ -17,11 +17,11 @@ Each Rancher version is designed to be compatible with a single version of the w

 <!-- releaseTask -->

-| Rancher Version | Webhook Version |
-|-----------------|:---------------:|
-| v2.8.0          |     v0.4.2      |
-| v2.8.1          |     v0.4.2      |
-| v2.8.2          |     v0.4.2      |
+| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
+|-----------------|-----------------|-----------------------|---------------------------|
+| v2.8.2          |     v0.4.2      | &check;               | &check;                   |
+| v2.8.1          |     v0.4.2      | &check;               | &check;                   |
+| v2.8.0          |     v0.4.2      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -49,20 +49,59 @@ To bypass the webhook, impersonate both the `rancher-webhook-sudo` service accou
 kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
 ```

+## Customizing Rancher-Webhook Configuration
+
+You can add custom Helm values when you install Rancher-Webhook via Helm. During a Helm install of the Rancher-Webhook chart, Rancher checks for custom Helm values. These custom values must be defined in a ConfigMap named `rancher-config`, in the `cattle-system` namespace, under the data key, `rancher-webhook`. The value of this key must be valid YAML.
+``` yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: rancher-config
+  namespace: cattle-system
+  labels:
+    app.kubernetes.io/part-of: "rancher"
+data:
+  rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
+
+```
+
+Rancher redeploys the Rancher-Webhook chart when changes to the ConfigMap values are detected.
+
+### Customizing Rancher-Webhook During Rancher Installation
+
+When you use Helm to install the Rancher chart, you can add custom Helm values to the Rancher-Webhook of the local cluster. All values in the Rancher-Webhook chart are accessible as nested variables under the `webhook` name.
+These values are synced to the `rancher-config` ConfigMap during installation.
+
+```bash
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  ... 
+  --set webhook.port=9553 \
+  --set webhook.priorityClassName="system-node-critical"
+```
+
 ## Common Issues

 ### EKS Cluster with Calico CNI

 Users running an EKS cluster with Calico CNI may run into errors when the Kubernetes API server attempts to contact the Rancher-Webhook. 
-One workaround for this issue [documented by Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks#install-eks-with-calico-networking) involves setting `hostNetwork=true` for the webhook deployment. Users can change this using the Helm commands below on the affected clusters.
+One workaround for this issue, as [documented by Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks#install-eks-with-calico-networking) involves setting `hostNetwork=true` for the webhook deployment. You can change this value by adding the Helm value `global.hostNetwork=true` to the `rancher-config` ConfigMap. See [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration) for more info.

 ``` bash
-helm repo add rancher-charts https://charts.rancher.io 
-helm upgrade --reuse-values rancher-webhook rancher-charts/rancher-webhook  -n cattle-system --set global.hostNetwork=true
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: rancher-config
+  namespace: cattle-system
+  labels:
+    app.kubernetes.io/part-of: "rancher"
+data:
+  rancher-webhook: '{"global": {"hostNetwork": true}}'
 ```
+
 **Note:** This temporary workaround may violate an environment's security policy. This workaround also requires that port 9443 is unused on the host network.

-**Note:** Helm uses secrets by default. This is a datatype that some webhook versions validate to store information. In these cases, directly update the deployment with the hostNetwork=true value using kubectl, then run the Helm commands listed above to prevent drift between the Helm configuration and the actual state of the cluster.
+**Note:** By default, Helm stores information as secrets. Secrets are a resource that some webhook versions validate. In these cases, directly update the deployment with the `hostNetwork=true` value using kubectl, then update the webhook configuration as specified above.

 ### Private GKE Cluster