当前位置:网站首页>Kubernetes权限管理之RBAC (一)

Kubernetes权限管理之RBAC (一)

2020-11-09 16:56:28 睿江云计算

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数据的一部分。

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

版权声明
本文为[睿江云计算]所创,转载请带上原文链接,感谢
https://my.oschina.net/u/3691309/blog/4710176