基于角色的访问控制

概述

本文介绍了 RBAC 在 Rancher 监控中起到的作用。

集群管理员

默认情况下，只有那些拥有集群管理员 ClusterRole 权限的人应该能够：

• 在集群上安装 rancher-monitoring 应用程序，并在 chart 部署中执行所有其他相关配置
  • 例如，是否创建默认的仪表盘，哪些 exporter 被部署到集群上以收集指标，等等。
• 通过 Prometheus CRs 创建/修改/删除集群中的 Prometheus deployment
• 通过 Alertmanager CRs 创建/修改/删除集群中的 Alertmanager deployment
• 通过在适当的命名空间创建 ConfigMaps 来保留新的 Grafana 仪表盘或数据源
• 通过 cattle-monitoring-system 命名空间中的 Secret，将某些 Prometheus 指标暴露给 HPA 的 k8s Custom Metrics API。

拥有基于 Kubernetes ClusterRole 的权限的用户

rancher-monitoring chart 安装了以下三个 ClusterRole。默认情况下，它们会聚合到相应的 k8s ClusterRoles 中:

这些 ClusterRoles 根据可以执行的操作，提供对监控 CRD 的不同访问级别：

在较高级别上，默认情况下会分配以下权限。

具有 Kubernetes Admin/Edit 权限的用户

只有拥有 cluster-admin、admin 或编辑 ClusterRole 的用户才可以：

• 通过 ServiceMonitor 和 PodMonitor CRs 修改 Prometheus deployments 的抓取配置
• 通过 PrometheusRules CRs 修改 Prometheus deployments 的告警/记录规则。

具有 Kubernetes View 权限的用户

只有那些拥有 Kubernetes ClusterRole的用户才可以：

• 查看集群内部署的 Prometheuses 的配置
• 查看部署在集群中的 Alertmanagers 的配置
• 通过 ServiceMonitor 和 PodMonitor CRs 查看 Prometheus deployments 的抓取配置
• 通过 PrometheusRules CRs 查看 Prometheus deployments 的告警/记录规则

额外的监控角色

监控还创建了额外的 Roles，默认情况下不分配给用户，而是在集群内创建。它们可以通过部署一个引用它的 RoleBinding 来绑定到一个命名空间。要用 kubectl 而不是通过 Rancher 定义 RoleBinding，请点击[这里]（#用-kubectl-分配角色和集群角色）。

管理员应使用这些角色为用户提供更细粒度的访问权限：

额外的监控集群角色

监控还创建了额外的 ClusterRoles，这些角色默认不分配给用户，而是在集群内创建。 默认情况下，它们不会被聚合，但可以通过部署一个引用它的 RoleBinding 或 ClusterRoleBinding 来绑定到一个命名空间。要用 kubectl 而不是通过 Rancher 定义 RoleBinding，请点击这里。

用 kubectl 分配角色和集群角色

使用 Rancher 将 Role 或 ClusterRole 附加到用户或组的另一种方法是通过在你创建的 YAML 文件中定义绑定关系。你必须先用 YAML 文件配置 RoleBinding，然后通过运行 kubectl apply 命令来应用配置变化。

Roles：下面是一个 YAML 文件的例子，帮助你在 Kubernetes 中配置 RoleBindings 并附加到一个用户。你需要填写下面的名字，名字是区分大小写的。

# 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

Copy

kubectl：下面是一个 kubectl 命令的例子，用于应用你在 YAML 文件中创建的绑定。如前所述，你需要相应地填写你的 YAML 文件名。

• **kubectl apply -f monitoring-config-view-role-binding.yaml

具有基于 Rancher Cluster Manager 的权限的用户

Rancher Cluster Manager 部署的默认角色（即集群所有者、集群成员、项目所有者、项目成员）、默认的 Kubernetes 角色和 rancher-monitoring chart 部署的角色之间的关系详见下表：

默认的 Rancher 权限和对应的 Kubernetes 集群角色：

除了这些默认的角色，以下额外的 Rancher 项目角色可以应用于集群的成员，以提供对监控的额外访问。这些 Rancher 角色将与监控 chart 部署的 ClusterRoles 相关联：

非默认的 Rancher 权限和对应的 Kubernetes ClusterRoles：

* 绑定到View Monitoring Rancher 角色的用户只有在提供链接到外部监控 UI 时才有权限访问这些 UI。为了访问 Cluster Explorer 上的监控来获得这些链接，用户必须是至少一个项目的项目成员。

2.5.x 中的差异

在 Rancher 2.5.x 中，分配了 project-member 或 project-owners 角色的用户将无法访问 Prometheus 或 Grafana，因为我们只在集群级创建 Grafana 或 Prometheus。

此外，虽然项目所有者仍然能添加 ServiceMonitors/PodMonitors，默认情况下，在他们项目的命名空间内抓取资源，但 PrometheusRules 并不局限于单个命名空间/项目。因此，项目所有者在其项目命名空间内创建的任何告警规则或记录规则将应用于整个集群，尽管他们将无法查看/编辑/删除任何在项目命名空间以外创建的规则。

分配额外的访问权限

如果集群管理员想为 rancher-monitoring chart 提供的角色之外的用户提供额外的管理/编辑权限，下表列出了潜在的影响：

Grafana 的基于角色的访问控制

Rancher 允许任何通过 Kubernetes 认证并能访问 Rancher Monitoring chart 部署的 Grafana 服务的用户通过 Rancher 仪表盘 UI 访问 Grafana。默认情况下，所有能够访问 Grafana 的用户都被赋予 Viewer 角色，这允许他们查看 Rancher 部署的任何默认仪表盘。

然而，如果有必要，用户可以选择以管理员身份登录 Grafana。Grafana 实例的默认管理员用户名和密码将是admin/prom-operator，但在部署或升级 chart 时也可以提供其他凭证。

要查看 Grafana UI，请安装 rancher-monitoring。然后进入集群浏览器。在左上角，点击集群浏览器>监控。然后点击Grafana。

Grafana 中的集群计算资源仪表盘：

Grafana 中的默认仪表盘：