Continental Innovates with Rancher and Kubernetes
This section describes the expectations for RBAC for Rancher Monitoring.
By default, only those with the cluster-admin ClusterRole should be able to:
The rancher-monitoring chart installs the following three ClusterRoles. By default, they aggregate into the corresponding k8s ClusterRoles:
These ClusterRoles provide different levels of access to the Monitoring CRDs based on the actions that can be performed:
On a high level, the following permissions are assigned by default as a result.
Only those with the the cluster-admin, admin or edit ClusterRole should be able to:
Only those with who have some Kubernetes ClusterRole should be able to:
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.
Admins should use these roles to provide more fine-grained access to users:
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.
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:
In addition to these default Roles, the following additional Rancher project roles can be applied to members of your Cluster to provide additional access to Monitoring. These Rancher Roles will be tied to ClusterRoles deployed by the Monitoring chart:
* A User bound to the View Monitoring Rancher Role only has permissions to access external Monitoring UIs if provided links to those UIs. In order to access the Monitoring Pane on Cluster Explorer to get those links, the User must be a Project Member of at least one Project.
Users with the project-member or project-owners roles assigned will not be given access to either Prometheus or Grafana in Rancher 2.5.x since we only create Grafana or Prometheus on a cluster-level.
In addition, while project owners will still be only able to add ServiceMonitors / PodMonitors that scrape resources within their project’s namespace by default, PrometheusRules are not scoped to a single namespace / project. Therefore, any alert rules or recording rules created by project-owners within their project namespace will be applied across the entire cluster, although they will be unable to view / edit / delete any rules that were created outside the project’s namespace.
If cluster-admins would like to provide additional admin/edit access to users outside of the roles offered by the rancher-monitoring chart, the following table identifies the potential impact:
Rancher allows any users who are authenticated by Kubernetes and have access the Grafana service deployed by the Rancher Monitoring chart to access Grafana via the Rancher Dashboard UI. By default, all users who are able to access Grafana are given the Viewer role, which allows them to view any of the default dashboards deployed by Rancher.
However, users can choose to log in to Grafana as an Admin if necessary. The default Admin username and password for the Grafana instance will be admin/prom-operator, but alternative credentials can also be supplied on deploying or upgrading the chart.
To see the Grafana UI, install rancher-monitoring. Then go to the Cluster Explorer. In the top left corner, click Cluster Explorer > Monitoring. Then click **Grafana.
Cluster Compute Resources Dashboard in Grafana
Default Dashboards in Grafana