diff --git a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md index 4c703ba37fe..4bc0e009c2a 100644 --- a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md +++ b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md @@ -16,7 +16,6 @@ This section describes the expectations for RBAC for Rancher Monitoring. - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions) - [Additional Monitoring Roles](#additional-monitoring-roles) - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles) -- [Additional Monitoring Roles](#additional-monitoring-roles) - [Users with Rancher Cluster Manager Based Permissions](#users-with-rancher-cluster-manager-based-permissions) - [Differences in 2.5.x](#differences-in-2-5-x) - [Assigning Additional Access](#assigning-additional-access) @@ -70,7 +69,7 @@ Only those with who have some Kubernetes `ClusterRole` should be able to: ### Additional Monitoring Roles -Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a RoleBinding that references it. +Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a `RoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl). Admins should use these roles to provide more fine-grained access to users: @@ -85,12 +84,40 @@ Admins should use these roles to provide more fine-grained access to users: ### Additional Monitoring ClusterRoles -Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a RoleBinding that references it. +Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a `RoleBinding` or `ClusterRoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl). | Role | Purpose | | ------------------------------| ---------------------------| | monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ Provides read-only access to external Monitoring UIs by giving a user permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. | +### Assigning Roles and ClusterRoles with kubectl + +An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command. + + +* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes to attach to a user. You will need to fill in the name below, and name is case-sensitive. + +``` +# monitoring-config-view-role-binding.yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: monitoring-config-view + namespace: cattle-monitoring-system +roleRef: + kind: Role + name: monitoring-config-view + apiGroup: rbac.authorization.k8s.io +subjects: +- kind: User + name: u-b4qkhsnliz # this can be found via `kubectl get users -A` + apiGroup: rbac.authorization.k8s.io +``` + +* **kubectl**: Below is an example of a `kubectl` command used to apply the binding you've created in the YAML file. As noted, you will need to fill in your YAML filename accordingly. + + * **`kubectl apply -f monitoring-config-view-role-binding.yaml` + # Users with Rancher Cluster Manager Based Permissions The relationship between the default roles deployed by Rancher Cluster Manager (i.e. cluster-owner, cluster-member, project-owner, project-member), the default k8s roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below: diff --git a/content/rancher/v2.6/en/admin-settings/cluster-templates/_index.md b/content/rancher/v2.6/en/admin-settings/cluster-templates/_index.md index 9173fe65f45..ae050be8a8f 100644 --- a/content/rancher/v2.6/en/admin-settings/cluster-templates/_index.md +++ b/content/rancher/v2.6/en/admin-settings/cluster-templates/_index.md @@ -56,6 +56,8 @@ In this section, you'll learn how to add the cluster template to the `local` clu **Result:** The cluster template available from the **Apps & Marketplace** in Rancher's `local` cluster. It can now be used to deploy clusters. +> * **Restricted Admin access:** If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template. + # Creating a Cluster from a Cluster Template > **Prerequisites:** diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md index b2bd82c1e1a..907fbfb3aea 100644 --- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md @@ -91,7 +91,7 @@ Option to set environment variables for [Rancher agents](https://rancher.com/doc #### Automatic Snapshots -Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots). +Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster. #### Metrics diff --git a/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md b/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md index cca1942fff3..ba487525225 100644 --- a/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md +++ b/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md @@ -11,7 +11,6 @@ This section describes the expectations for RBAC for Rancher Monitoring. - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions) - [Additional Monitoring Roles](#additional-monitoring-roles) - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles) -- [Additional Monitoring Roles](#additional-monitoring-roles) - [Users with Rancher Based Permissions](#users-with-rancher-based-permissions) - [Differences in 2.5.x](#differences-in-2-5-x) - [Assigning Additional Access](#assigning-additional-access) @@ -65,7 +64,7 @@ Only those with who have some Kubernetes `ClusterRole` should be able to: ### Additional Monitoring Roles -Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a RoleBinding that references it. +Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a `RoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl). Admins should use these roles to provide more fine-grained access to users: @@ -80,12 +79,41 @@ Admins should use these roles to provide more fine-grained access to users: ### Additional Monitoring ClusterRoles -Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a RoleBinding that references it. +Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a `RoleBinding` or `ClusterRoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl). | Role | Purpose | | ------------------------------| ---------------------------| | monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ Provides read-only access to external Monitoring UIs by giving a user permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. | +### Assigning Roles and ClusterRoles with kubectl + +An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command. + + +* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive. + +``` +# monitoring-config-view-role-binding.yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: monitoring-config-view + namespace: cattle-monitoring-system +roleRef: + kind: Role + name: monitoring-config-view + apiGroup: rbac.authorization.k8s.io +subjects: +- kind: User + name: u-b4qkhsnliz # this can be found via `kubectl get users -A` + apiGroup: rbac.authorization.k8s.io +``` + +* **kubectl**: Below is an example of a `kubectl` command used to apply the binding you've created in the YAML file. As noted, you will need to fill in your YAML filename accordingly. + + * **`kubectl apply -f monitoring-config-view-role-binding.yaml` + + # Users with Rancher Based Permissions The relationship between the default roles deployed by Rancher (i.e. cluster-owner, cluster-member, project-owner, project-member), the default Kubernetes roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below: