Kubernetes学习之RBAC

一、访问控制概述
　　API Server作为Kubernetes集群系统的网关，是访问及管理资源对象的唯一入口，余下所有需要访问集群资源的组件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集群基础组件、CoreDNS等集群的附加组件以及此前使用的kubelet命令等都要经由网关进行集群访问和管理。这些客户端均要经由API Server访问或改变集群状态并完成数据存储，并由它对每一次的访问请求进行合法性校验，包括用户身份鉴别、操作权限验证以及操作是否符合全局规范的约束等等。所有检查均正常完成且对象配置信息合法性校验无误之后才能访问或存入数据于后端存储系统etcd中。

　　客户端认证操作由API Server配置的一到多个认证插件完成。收到请求后，API Server依次调用为其配置的认证插件来认证客户端身份，直到其中一个插件可以识别出请求者的身份为止。授权操作由一到多个授权插件进行，它负责确定那些通过认证的用户是否有权限执行其发出的资源操作请求，如创建、读取、删除或修改指定的对象等等。随后，通过授权检测的用户所请求的修改相关的操作还要经由一到多个准入控制器插件的遍历检测，例如使用默认值补足要创建的目标资源对象中未定义的各字段、检查目标Namespace资源对象是否存在、检查是否违反系统资源限制等等，而其中任何的检查失败都可能会导致写入操作失败。

二、用户账号与用户组
　　Kubernetes并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息，它们仅仅用于校验用户是否有权限执行其所请求的操作。客户端访问API服务的途径通常有三种：kubelet、客户端库或者直接使用REST接口进行请求，而可以执行此类请求的主体也被Kubernetes分为两类：现实中的"人"和Pod对象，它们的用户身份分别对应于常规用户（User Account）和服务账号（Service Account）。
　　User Account（用户账号）：一般是指由独立于Kubernetes之外的其他服务管理的用户账号，例如由管理员分发的密钥、Keystone一类的用户存储（账号库）、甚至是包含有用户名和密码列表的文件等等。Kubernetes中不存在表示此类用户账号的对象，因此不能被直接添加进Kubernetes系统中。
　　Service Account（服务账号）：是指由Kubernetes API管理的账号，用于为Pod之中的服务进程在访问Kubernetes API时提供身份标识（identity）。Service Account通常要绑定于特定的名称空间，它们由API Servcie创建，或者通过API调用手动创建，附带着一组存储为Secret的用于访问API Server的凭据。
　　User Account通常用于复杂的业务逻辑管控，它作用于系统全局，故其名称必须全局唯一。相比较来说，Service Account隶属于名称空间，仅用于实现某些特定的操作任务，因此要轻量的多。这两类账号都可以隶属于一个或多个用户组。用户组只是用户账号的逻辑集合，它本身并没有操作权限，但附加于组上的权限可由其内部的所有用户继承，以实现高效的授权管理机制。Kubernetes有着以下几个内建的用户特殊目的的组：
　　system:unauthenticated：未能通过任何一个授权插件检验的账号，即未通过认证测试的用户所属的组。
　　system:authenticated：认证成功后的用户自动加入的一个组，用于快速引用所有正常通过认证的用户账号。
　　system:serviceaccounts：当前系统上的所有Service Account对象。
　　system:serviceaccounts:<namespace>：特定名称空间内所有的Servcie Account对象。
　　API请求要么与普通用户或服务账号进行绑定，要么被视为匿名请求。这意味着集群内部或外部的每个进程，包括由人类用户使用的kubelet，到节点上的kubelet，再到控制平面的成员组件，必须向API服务器发出请求时进行身份验证，否则即被视为匿名用户。

三、角色访问控制（RBAC）
　　RBAC（Role-Based Access Control，基于角色的访问控制）是一种新型、灵活且使用广泛的访问控制机制，它将权限授予"角色"（role）之上，这一点有别于传统访问控制机制中将权限直接赋予给使用者的方式。
　　在RBAC中，用户（User）就是一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体（Subject）。角色是指一个组织或任务中的工作或者位置，它代表了一种权利、资源和责任。许可（Permission）就是允许对一个或多个客体（Object）执行的操作。一个用户可经授权而拥有多个角色，一个角色可由多个用户构成；每个角色可拥有多种许可，每个许可也可授权给多个不同的角色。每个操作可施加于多个客体（受控对象），每个客体也可以接受多个操作。
　　
　　RBAC的基于"角色"（role）这一核心组件实现了权限委派，具体体现中，它为账号赋予一到多个角色从而让其具有角色之上的权限，其中的账号可以是用户账号、用户组、服务账号及其相关的组等等；而同时关联至多个角色的账号所拥有的权限是多个角色之上的权限集合。RBAC中的用户、角色及权限的关系如下图：
　　
　　RBAC是一种操作授权机制，用于界定"谁"（subject）能够或不能够"操作"（verb）哪个或哪类"对象"（object）。动作的发起者即"主体"，通常以"账号"为载体，它既可以是常规用户（User Account），也可以是服务账号（Service Account）。“操作”（verb）用于表明要执行的具体操作，包括创建、删除、修改和查看等等，对应于kubectl来说，它通常由create、delete、apply、update、patch、edit和get等子命令来给出。而"客体"则是指操作施加于的目标实体，对Kubernetes API来说主要是指各类的资源对象以及非资源性URL。
　　
　　RBAC授权插件支持Role和ClusterRole两类角色，其中Role作用于名称空间级别，用于定义名称空间内的资源集合，ClusterRole则用于组织集群级别的资源权限集合，它们都是标准的API资源类型。一般来说，ClusterRole的许可授权作用于整个集群，因此常用于控制Role无法生效的资源类型，这包括集群级别的资源（如Node）、非资源类型的端点（如/healthz）和作用于所有名称空间的资源（例如，跨名称空间获取任何资源的权限）。
　　对着两类角色进行赋予的操作则是需要用到RoleBinding和ClusterRoleBinding两种资源类型。RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上，它隶属于且仅能作用于一个名称空间。绑定时，可以引用同一名称空间中的Role，也可以引用集群级别的ClusterRole。而ClusterRoleBinging则把ClusterRole中定义的许可权限绑定在一个或一组用户之上，它仅可以引用集群级别的ClusterRole。Role、RoleBinding、ClusterRole、ClusterRoleBinding的关系如下图：