前言
文章目录
RBAC
RBAC是Role-Based Access Control的简称，是基于角色的访问控制的意思，是实施面向企业安全策略的一种有效的访问控制方式。其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合，每一种角色对应一组相应的权限。
一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。
RBAC 使⽤ rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 KubernetesAPI 动态配置策略，要启⽤ RBAC ，需要在 apiserver 中添加参数 --authorization-mode=RBAC ，如果使⽤的 kubeadm 安装的集群，1.6 版本以上的都默认开启了 RBAC ，可以通过查看 Master 节点上apiserver 的静态 Pod 定义⽂件：
$ cat /etc/kubernetes/manifests/kube-apiserver.yaml
...
- --authorization-mode=Node,RBAC
...
如果是⼆进制的⽅式搭建的集群，添加这个参数过后，记得要重启 apiserver 服务。
RBAC API 对象
Kubernetes 有⼀个很基本的特性就是它的所有资源对象都是模型化的 API 对象，允许执⾏CRUD(Create、Read、Update、Delete)操作(也就是我们常说的增、删、改、查操作)，⽐如下⾯的这些资源：
- Pods
- ConfigMaps
- Deployments
- Nodes
- Secrets
- Namespaces
上⾯这些资源对象的可能存在的操作有：
- create
- get
- delete
- list
- update
- edit
- watch
- exec
在更上层，这些资源和 API Group 进⾏关联，⽐如 Pods 属于 Core API Group，⽽ Deployements 属于 apps API Group，要在 Kubernetes 中进⾏ RBAC 的管理，除了上⾯的这些资源和操作以外，我们还需要另外的⼀些对象：
-
Rule：，规则是⼀组属于不同 API Group 资源上的⼀组操作的集合
-
Role 和 ClusterRole：，这两个对象都包含上⾯的 Rules 元素，⼆者的区别在于，在 Role 中，定义的规则只适⽤于单个命名空间，也就是和 namespace 关联的，⽽ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外 Role 和 ClusterRole在 Kubernetes 中都被定义为集群内部的 API 资源，和我们前⾯学习过的 Pod、ConfigMap 这些类似，都是我们集群的资源对象，所以同样的可以使⽤我们前⾯的
kubectl相关的命令来进⾏操作。 -
Subject：，对应在集群中尝试操作的对象，集群中定义了3种类型的主题资源：
- User Account：，这是有外部独⽴服务进⾏管理的，管理员进⾏私钥的分配，⽤户可以使⽤ KeyStone或者 Goolge 帐号，甚⾄⼀个⽤户名和密码的⽂件列表也可以。对于⽤户的管理集群内部没有⼀个关联的资源对象，所以⽤户不能通过集群内部的 API 来进⾏管理
- Group：组，这是⽤来关联多个账户的，集群中有⼀些默认创建的组，⽐如
cluster-admin - Service Account：，通过 Kubernetes API 来管理的⼀些⽤户帐号，和 namespace进⾏关联的，适⽤于集群内部运⾏的应⽤程序，需要通过 API 来完成权限认证，所以在集群内部进⾏权限操作，我们都需要使⽤到 ServiceAccount，这也是我们这节课的重点
-
RoleBinding 和 ClusterRoleBinding：，简单来说就是把声明的 Subject和我们的 Role 进⾏绑定的过程(给某个⽤户绑定上操作的权限)，⼆者的区别也是作⽤范围的区别：RoleBinding 只会影响到当前namespace 下⾯的资源操作权限，⽽ ClusterRoleBinding 会影响到所有的 namespace。
接下来的文章中我会通过⼏个示例来演示 RBAC 的配置⽅法。