Kubernetes 鉴权 - RBAC
当一个请求在完成 api-server 认证后，可以认为它是一个合法的用户，那么如何控制该用户在集群中的哪些 namespace 中访问哪些资源，对这些资源又能进行哪些操作呢？
这就由访问控制的第二步 Kubernetes 鉴权来完成。api-server 本身支持多种鉴权方式，在本小结中，我们主要介绍在安全上推荐的鉴权方式 RBAC。
RBAC 鉴权三要素
- 第一要素是 Subjects，也就是主体。可以是开发人员、集群管理员这样的自然人，也可以是系统组件进程，或者是 Pod 中的逻辑进程；
- 第二个要素是 API Resource，也就是请求对应的访问目标。在 Kubernetes 集群中也就是各类资源；
- 第三要素是 Verbs，对应为请求对象资源可以进行哪些操作，包括增删改查、list、get、watch 等。
这里举个例子，假设有个通过合法认证的用户 Bob，他请求 list 某个 namespace下的 Pods，改请求的鉴权语义记为：Can Bob list pods ？其中 Bob 即为请求中的 Subject，list 为对应的请求动作 Action，而 pods 为对应的请求资源 Resource。
RBAC 权限粒度
上面介绍了 RBAC 角色模型的三要素，在整个 RBAC 策略定义下，还需要将这个角色绑定到一个具体的控制域内。这就是 Kubernetes 大家熟悉的命名空间。通过 namespace 可以将 Kubernetes api 资源限定在不同的作用域内。从而帮助我们在一个多租户集群中，对用户进行逻辑上的隔离。
上面的事例可以改为 User A can create pods in namespace B。这里需要注意的是，如果不进行任何的权限绑定，RBAC 会拒绝所有访问。
通常 RBAC 会进行对 api-server 的细粒度访问控制，但是这个细粒度是个相对的概念，RBAC 是面向模型级别的绑定。它不能绑定到 namespace 中的一个具体的 object 实例，更不能绑定到指定资源的任意一个 field。
RBAC 对访问权限的控制粒度上，它可以细化到 Kubernetes api 的 subresources 级别。比如针对一个访问者，我们可以控制其在指定 namespace 下对 nodes/status 模型的访问。
RBAC - Role
接着介绍 RBAC 具体的绑定权限和对象。
首先是角色 Role，它定义了用户在指定的 Kubernetes 命名空间资源上可以进行哪些操作。比如可以定一个 namespace 中 pod 的只读权限，同时还可以定义一个 namespace 管理员权限，它具有对这个命名空间下所有对象资源的所有操作权限。
如上图所示，是一个 Role 的定义模板编排文件，其中 resource 字段定义了这个角色可以访问哪些资源，verbs 字段定义了这个角色有哪些操作的权限。在 apiGroups 中，需要指定目标资源的 apiGroups 名称，这里可以通过官方 API 文档查询，如果指定的 Group 是 core，那么在角色模板中的 apiGroups 可置为空。
RBAC - RoleBinding
当我们完成了一个 namespace 下的角色定义之后，还需要建立其与使用这个角色的主体之间在 namespace 下的绑定关系，这里需要一个 RoleBinding 模型。使用 RoleBinding 可以将 Role 对应的权限模型绑定到对应的 Subject 上。