Kubernetes权限管理之RBAC （一）

k8s在启用基于角色管理的访问控制 RBAC（Role-based-Access-Control）的授权模式。相当于基于属性的访问控制ABAC（Attribute-based Access Control）,RBAC主要是引入了 角色（Role 权限的集合） 和角色绑定（RoleBinding）的抽象概念。在ABAC中，k8s集群中的访问策略只能跟用户直接关联；而RBAC中，访问策略可以跟某个角色关联，具体的用户再和某个角色或者多个角色关联。

RBAC有四个新的k8s顶级资源对象： 角色（Role）、集群角色（ClusterRole）、角色绑定（RoleBinding）、集群角色绑定（ClusterRoleBinding）。同其他API资源对象一样，用户可以使用kubectl或者API调用方式等操作这些资源对象。

 

 

RBAC具有如下优势。
1、对集群中的资源和非资源权限均有完整的覆盖。
2、整个RBAC完全由几个API对象完成，同其他API对象一样 ，可以用kubectl或API进行操作。
3、可以在运行时进行调整，无须重新启动 API Server。
4、要使用 RBAC 授权模式 ，则 需要在 API Server 的启动 参数中 加上--authorization-mode=RBAC。

 

 

1）角色( Role)

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权，下面例子中定义的角色具备读取Pod的权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default            //这里指的是default命名空间下的角色
  name: pod-reader
rules:
- apiGroups: [""]    # ""空字符串，表示核心API群
  resources: ["pods"]            //要操作的资源
  verbs: ["get", "watch", "list"]        //操作资源对应具体的权限

 

rules 中的参数说明如下：
apiGroups: 支持的API组列表，例如”apiVersion: batch/v1”、”apiVersion: extensions”、”apiVersion: apps”
resources: 支持的资源对象列表，例如 pods、deployments、secrets、jobs、configmaps、endpoints、persistentvolumeclaims、replicationcontrollers、statefulsets、namespaces等。
verbs: 对资源对象 的操作方法列表 ， 例如 get、 watch、 list、 delete、 replace、 patch 、create等

 

 

2）集群角色（ClusterRole）
集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的生效范围，还可以用于以下特殊元素的授权管理上：

集群范围的资源，如Node。

非资源型的路径，如”/healthz”。

包含全部命名空间的资源，例如pods（用于kubectl get pods –all-namespaces这样的操作授权）

下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets（视其绑定方式而定）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: my-cluster-role
  # ClusterRole不受限于命名空间，所以省略了namespace的定义
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

 

 

3）角色绑定（RoleBinding）和 集群角色绑定（ClusterRoleBinding）

首先角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定目标可以是User（用户）、Group（组）或者Service Account。使用RoleBinding可以为某个命名空间授权，使用ClusterRoleBinding可以为集群范围内授权。

RoleBinding可以引用Role进行授权。下例中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane，这一操作让jane可以读取default命名空间中的Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default        //角色绑定指定的命名空间
subjects:
- kind: User                //操作的类型是user
  name: jane                //user的名称
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                //权限绑定的类型是 role
  name: pod-reader            //对上述应角色名称
  apiGroup: rbac.authorization.k8s.io

 

 

RoleBinding也可以引用ClusterRole进行授权。

RoleBinding可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种很常用的做法就是，集群管理员为集群范围预定义好一组角色（ClusterRole），然后在多个命名空间中重复使用这些ClusterRole。这样可以大幅提高授权管理工作效率，也使得各个命名空间下的基础性授权规则与使用体验保持一致。

例如下面，虽然secret-reader是一个集群角色，但是因为使用了RoleBinding``，所以dave只能读取development命名空间``中的secret。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development   # 集群角色中，只有在development命名空间中的权限才能赋予dave
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 

ClusterRoleBinding，集群角色绑定中的角色只能是集群角色。用于进行集群级别或者对所有命名空间都生效的授权。
下面的例子中允许manager组的用户读取任意namespace中的secret：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 

下图展示了上述对Pod的get/watch/list操作进行授权的Role和RoleBinding逻辑关系。

 

 

4）对资源的引用方式

多数资源可以用其名称的字符串来表达，也就是Endpoint中的URL相对路径，例如pods。然而，某些k8s API包含下级资源，如pod的日志（logs）。pod日志的Endpoint是GET/api/v1/namespaces/{namespace}/pods/{pod_name}/log。

在这个例子中，Pod是一个命名空间内的资源，log就是一个下级资源。要在RBAC角色中体现，则需要用斜线 ‘/‘ 来区隔资源和下级资源。

若想授权让某个主体同时能够读取Pod和 Pod log，则可以配置resources为一个数组：

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

 

资源还可以通过名称（ResourceName） 进行引用（这里指的是资源实例的名字）。在指定ResourceName后，使用get、delete、update、patch动作的请求，就会被限制这个资源实例的范围内

如 声明让一个主体只能对一个configmap进行get 和update操作

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

 

resourceName 这种用法对list、watch、create、deletecollection操作是无效的，这是因为必须要通过URL进行鉴权，而资源名称在list、watch、create和deletecollection请求中只能请求Body数据的一部分。

由于内容较多，本期就先到这里，下期我们再来说说常用的角色实例、常用的角色绑定示例。下期再见~