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 / edit ClusterRole should be able to:
Only those with who have some k8s ClusterRole should be able to:
Monitoring also creates six additional Roles that are not assigned to users by default but are created within the cluster. Admins should use these roles to provide more fine-grained access to users:
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:
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: