k8s-RBAC授权-十六
一、简介
基于角色的访问控制（“RBAC”）
http://docs.kubernetes.org.cn/80.html
(1)
Kubernetes的授权是基于插件形式的，常用的授权插件有以下几种：
- Node：node节点授权
- ABAC：基于属性的访问控制
- RBAC：基于角色的访问控制
- 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进行通信。
