k8s-RBAC授权-十六

一、简介

基于角色的访问控制（“RBAC”）

http://docs.kubernetes.org.cn/80.html

(1)

Kubernetes的授权是基于插件形式的，常用的授权插件有以下几种：

1. Node：node节点授权
2. ABAC：基于属性的访问控制
3. RBAC：基于角色的访问控制
4. Webhook：自定义http回调方法

RBAC：http://docs.kubernetes.org.cn/148.html

　　

基于角色的访问控制：如图，先让一个用户（Users）扮演一个角色（Role），让角色(Role)拥有权限，从而让用户拥有这样的权限，然后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制；

(2)Role和ClusterRole　

　　Role是一系列的权限的集合，例如一个Role可以包含读取 Pod 的权限和列出 Pod 的权限， ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

　　Role只能授予单个namespace 中资源的访问权限。

　　ClusterRole授权 >= Role授予（与Role类似），但ClusterRole属于集群级别对象：

• • 集群范围（cluster-scoped）的资源访问控制（如：节点访问权限）
  • 非资源类型（如“/ healthz”）
  • 所有namespaces 中的namespaced 资源（如 pod）

 (3)RoleBinding和ClusterRoleBinding

RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role，Role有了权限，用户也就有了权限。RoleBinding在某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

 　　RoleBinding可以引用相同namespace下定义的Role。

　　Role和ClusterRole、RoleBinding和ClusterRoleBinding关系如下图：

 　　

(4)

 使用RoleBinding去绑定ClusterRole：

如果有10个名称空间，每个名称空间都需要一个管理员，而这些管理员的权限都是一致的。那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得很麻烦。为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，而不是拥有所有名称空间的权限，所以此时只需要创建一个ClusterRole代替掉10个Role就解决了以上的需求。

 二、RBAC应用

 (1)Role --> User -->Rolebinding 

　　用法：

 　　

　　使用kubectl create进行创建角色(role)，指定角色名称，--verb指定权限，--resource指定资源或者资源组，--dry-run：此模式不会真的创建；

　　a、

 　　[root@master ~]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml　　#先用--dry-run模式看一下role的定义

 　　

　　b、生成资源定义清单

　　[root@master ~]# cd manifests/

　　#导出yaml文件，稍微编辑一下就能用了
　　[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml >role-demo.yaml

　　[root@master manifests]# vim role-demo.yaml

　　

　　c、创建

　　

(2)RoleBinding角色绑定　　

创建方法：

使用kubectl create进行创建角色绑定，指定角色绑定的名称，--role|--clusterrole指定绑定哪个角色，--user指定哪个用户；　　

　　a、导出rolebinding资源定义清单文件

　　[root@master manifests]# kubectl explain role　　#查看资源定义清单字段

　　[root@master manifests]# kubectl explain rolebinding　　#查看资源定义清单字段

　　[root@master manifests]# kubectl create rolebinding magedu-read-pods --role=pods-reader --user=magedu --dry-run -o yaml > rolebinding-demo.yaml

 　　

　　b、创建，将权限授权给用户magedu

　　[root@master manifests]# kubectl apply -f rolebinding-demo.yaml

　　

　　c、可见magedu已经绑定到了pods-reader角色上了；

　　

 　　d、切换用户访问

　　

　　现在magedu已经有权限访问了；

　　以上操作role和rolebinding都是只对当前名称空间生效；

 　　[root@master ~]# kubectl config use-context kubernetes-admin@kubernetes　　#切换回kubernetes-admin用户

(2)ClusterRole-->ClusterRoleBinding-->User

　　[root@master manifests]# kubectl explain clusterrole　　#查看资源定义清单字段

　　[root@master manifests]# kubectl explain clusterrolebinding　　#查看资源定义清单字段

　　a、导出clusterrole的资源定义清单文件

　　[root@master manifests]# kubectl create clusterrole cluster-read --verb=get,list,watch --resource=pods -o yaml >clusterrole-demo.yaml

　　[root@master manifests]# vim clusterrole-demo.yaml

　　

　　b、创建clusterrole

　　[root@master manifests]# kubectl apply -f clusterrole-demo.yaml 

 　　此时我们可以新建一个Linux系统账户，然后在这个系统账户下，将kubernetes的用户切换到magedu下，随后对magedu赋予clusterrole的权限；

　　

　　

　　c、此时我们删除之前创建的rolebinding 解除magedu的权限；

　　

　　可见此时magedu已经没有了权限；

　　

 　　d、创建clusterrolebinding

　　导出yaml资源定义清单文件：

　　[root@master ~]# kubectl create clusterrolebinding magedu-read-all-pods --clusterrole=cluster-read --user=magedu --dry-run -o yaml >manifests/clusterrolebinding-demo.yaml

　　[root@master manifests]# vim clusterrolebinding-demo.yaml

　　

　　创建，将magedu绑定到clusterrole：

　　[root@master manifests]# kubectl apply -f clusterrolebinding-demo.yaml

　　

　　查看，可见已经绑定到集群角色：

　　

　　

　　e、此时我们切换到系统用户为ik8s的窗口，并且kubernetes的用户为maedu

　　

　　查看其他namespace的pod, 也是可以的：

　　

　　但是，现在是不能删pod的，因为没有授权：

　　

以上可见，对用户magedu进行集群角色绑定，用户magedu将会获取对集群内所有资源的(namespace)对应权限。

 (3)clusterrole --> rolebinding --> user

　　将maedu通过rolebinding到集群角色clusterrole中，此时，magedu仅作用于当前名称空间的所有pods资源的权限;

　　a、删除之前的clusterrolebinding

　　

　　b、导出yaml资源定义清单文件

　　[root@master manifests]# kubectl create rolebinding magedu-read-pods --clusterrole=cluster-read --user=magedu --dry-run -o yaml >rolebinding-clusterrole-dmeo.yaml

　　[root@master manifests]# vim rolebinding-clusterrole-dmeo.yaml

　　

　　c、创建rolebinding，将magedu绑定到clusterrole

　　

　　查看rolebinding

　　

　　可见magedu已经绑定到集群角色clusterrole上了；

　　d、此时切换到系统用户ik8s的窗口

　　可见magedu可以访问当前namespace的pod，但是不能访问其他namespace的pod;

　　因为这种绑定方式，clusterrole是被降级的；

　　

 (4)RBAC的三种授权访问方式

RBAC不仅可以对user进行访问权限的控制，还可以通过group和serviceaccount进行访问权限控制。user即单个用户，group是对一个组内的user进行授权；

上一节学习了Pod可以通过 spec.serviceAccountName来定义其是以某个serviceaccount的身份进行运行，当我们通过RBAC对serviceaccount进行访问授权时，就可以实现Pod对其他资源的访问权限进行控制。也就是说，当我们对serviceaccount进行rolebinding或clusterrolebinding，会使创建Pod拥有对应角色的权限和apiserver进行通信。