基于角色的权限控制：RBAC

什么是RBAC?

我们知道，Kubernetes中所有的API对象都保存在etcd里。可是，对这些API对象的操作一定是

通过访问kube-apiserver实现的。其中一个非常重要的原因是，需要API server来帮忙做授权工作。而在Kubernetes项目中，负责完成授权工作的机制是RBAC。

通过下面这两张图，让我们简单了解一下“k8s的安全架构”和“RBAC用户授权的逻辑”

基本概念

我们在学习RBAC的时候，需要了解3个基本概念：

1. Role：角色，它其实是一组规则，定义了一组对Kubernetes API对象的操作权限。
2. Subject：被作用者，即可是“人”，也可以是“机器”（如ServiceAccount），也可以是你在Kubernetes里定义的“用户”
3. RoleBinding：定义了“被作用者：和“角色”间的绑定关系。它指定了哪些Subject（被作用者）将被赋予某个Role（角色）的权限。

1.Role

Role（角色）：代表着一组定义在资源上的可操作动作（权限）的集合，一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。Role实际上本身就是一个Kubernetes的API对象，定义如下所示：

kind：Role
apiVersion：rbac.authorization.k8s.io/v1
metedata:
  namespace: mynamespace
  name: example-role
rules: 
- apiGroups: [""]            #支持的API组列表，例如：apiVersion：batch/v1。"" 空字符串，表示核心API组
  resources: ["pods"]        #支持的资源对象列表，例如pods、deployments等
  verbs: ["get", "watch", "list"]     

首先，这个Role对象指定了它能产生作用的Namespace是：mynamespace。Namespace是Kubernetes项目里的一个逻辑管理单位。不同Namespace的API对象在通过kubectl命令进行操作时是相互隔离的。
注意，这里我们需要知道Role的权限规则仅在其定义的命名空间内有效。然后我们可以看到这个Role对象下面的rules字段就是它所定义的权限规则。在上面的例子里，这条规则的含义就是：允许“被作用者”对mynamespace下面的Pod对象进行GET、WATCH、LIST操作。

综上所述，Role是kubernetes RBAC中用于定义命名空间级别资源访问规则的重要API对象，那么问题来了，这个具体的“被作用者”是如何指定的呢？这就需要通过我们接下来要讲的RoleBinding来实现了

2.RoleBinding

RoleBinding（角色绑定）：RoleBinding定义了用户和角色的绑定关系。它指定了哪些Subject（被作用者）将被赋予某个Role（角色）的权限。RoleBinding的权限限制规则同样仅在其定义的命名空间内有效，其本身也是一个Kubernetes的API对象，定义如下所示：

kind：RoleBinding
apiVersion：rbac.authorization.k8s.io/v1
metedata:
  namespace: mynamespace
  name: example-rolebinding
subjects：
- kind： User
  name：example-user
  apiGroup： rbac.authorization.k8s.io
roleRef: 
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io

可以看到，这个RoleBinding对象里定义了一个subjects字段，即“被作用者”。它的类型是User，即Kubernetes里的用户。这个用户的名字是example-user。

实际上，Kubernetes里的“User”，即“用户”，只是授权系统里的一个逻辑概念。他需要通过外部认证服务（比如Keystone）来提供。或者你也可以直接给API server指定一个用户名、密码文件。那么Kubernetes的授权系统就能够从这个文件里找到对应的“用户”了。当然，在大多数私有的使用环境中，使用Kubernetes提供的内置“用户”就足够了，稍后会介绍这些内容。

接下来，我们可以看到roleRef字段。正式通过该字段，RoleBinding对象可以直接通过名字来引用前面定义的Role对象“example-role”，从而定义了“被作用者”和“角色”之间的绑定关系

需要再次提醒一下各位看官，Role和RoleBinding对象都是Namespace对象，它们对权限的限制规则仅在它们自己的Namespace内有效，roleRef也只能引用当前Namespace里的Role对象
那么，对于非Namespace对象（比如Node），或者某个Role相作用于所有Namespace时，又该如何授权呢？此时就必须使用接下来要讲的ClusterRole和ClusterRoleBinding这两个组合了。

3.ClusterRole和ClusterRoleBinding

看官耐心等待，持续更新码字中…