Kubernetes RBAC

最近在使用kube-prometheus时，需要自定义监控，然后遇到了跟RBAC相关的错误，导致监控失败，虽然通过搜索解决了，但还是需要对RBAC进行一个深入学习才行。

RBAC：全称Role-Based Access Control，基于角色的权限控制，通过使用rbac.authorization.k8s.ioAPI组执行授权决定，允许管理员通过Kubernetes API动态配置权限

API概览

RBAC API包含了4个顶级类型的资源对象，用户可以像创建其他资源一样来创建RBAC资源，例如：kubectl create -f (resource).yml

Role和ClusterRole

Role里边包含有规则，这些规则代表一组权限。权限只能纯粹的增加（这里没有禁止相关的规则）。Role可以定义在一个namespace中，对应集群的是ClusterRole

一个Role只能授予给一个namespace资源访问权限，下边是一个例子

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole可以像Role一样授予同样的权限，但因为是集群级的，所以对应的资源也不一样，ClusterRole可以用于：

• 集群资源（比如：nodes）
• 非资源型endpoints（比如：/healethz）
• 所有命名空间资源（比如：pods）

下述是一个ClusterRole的相关例子：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Note: ClusterRole因为是集群级的，不需要定义namespace

RoleBinding和ClusterRoleBinding

规则定义好之后，还需要将这些规则绑定给一个用户或是一组用户。这些用户对象在kubernetes中有：users, groups, service accounts

RoleBinding会引用同一个命名空间下的Role。下述的RoleBinding是在 “default” 命名空间内将 “pod-reader” 的role赋予给 “jane” 用户

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subject:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding同样可以引用ClusterRole对当前命名空间内的用户、用户组或Service Account授予权限。这样就允许管理员定义一系列相同的规则，然后在不同的命名空间内使用

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development
subject:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secert-reader
  apiGroup: rbac.authorization.k8s.io

例子中RoleBinding应用secret-reader的ClusterRole，但是 dave 还是只能读取 development 命名空间下的 secret，因为RoleBinding应用在 development 这个命名空间下

ClusterRoleBinding对整个集群的命名空间授权

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subject:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secert-reader
  apiGroup: rbac.authorization.k8s.io

一个例子

配置一个名字为test-sa的ServiceAccount，限定在test命名空间内，但是能操作test命令空间的所有资源

1. 配置ServiceAccount

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: test-sa
    namespace: test

1. 定义role

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    namespace: test
    name: all-priviledges-roles
  rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

*表示所有

1. 定义RoleBinding

  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: all-priviledges-rolebinding
    namespace: test
  roleRef:
    kind: Role
    name: all-priviledges-roles
    apiGroup: rbac.authorization.k8s.io
  subjects:
  - kind: ServiceAccount
    name: test-sa
    namespace: test

没创建一个ServiceAccount时，都会创建一个对应的secret，保存有token，可以使用这个token值登录kubernetes dashboard，所有的操作被限制在test这个命名空间下。

查看token命令：

kubectl describe serviceaccount <serviceaccount name>
kubectl describe secret <secret name>

简单总结

Role和ClusterRole是角色，这些角色拥有不同的权限，我们可以控制这些角色的权限

RoleBinding和ClusterRoleBinding将角色赋予给用户，使用户拥有这个角色的权限，从而可以对集群的资源进行操作

参考

• 官方文档
• Kubernetes RBAC