Fix errors caused by PR#3566 (#3570)

* Revert "Revert "Merge master to staging""

* Fix PR#3566 errors

* Fix errors
This commit is contained in:
Billy Tat
2021-09-29 23:13:46 -07:00
committed by GitHub
parent 714c977c6b
commit a403b0a559
4 changed files with 64 additions and 7 deletions
@@ -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 | <a id="monitoring-ui-view"></a>_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:
@@ -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 dont 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:**
@@ -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
@@ -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 | <a id="monitoring-ui-view"></a>_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: