k8s认证与授权

认证用于身份鉴别，而授权则实现权限分派。k8s以插件化的方式实现了这两种功能，且分别存在多种可用的插件。另外，它还支持准入控制机制，用于补充授权机制以实现更精细的访问控制功能。

一、访问控制概述

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

客户端认证操作由apiserver配置的一到多个认证插件完成。收到请求后，apiserver依次调用为其配置的认证插件来认证客户端身份，直到其中一个插件可以识别出请求者的身份为止。授权操作由一到多授权插件进行，它负责确定那些通过认证的用户是否有权限执行其发出的资源操作请求，如创建、删除或修改指定的对象等。随后，通过授权检测的用户所请求的修改相关的操作还要经由一到多个准入控制插件的遍历检测。

1、用户账户与用户组

k8s并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息，他们仅仅用于检测用户是否有权限执行其所请求的操作。客户端访问api服务的途径通常有三种：kubectl、客户端库或者直接使用rest接口进行请求，而可以执行此类请求的主体也被k8s分为两类：现实中的人和pod对象，它们的身份分别对应于常规用户和服务账号。

useraccount（用户账号）：一般是指由独立于k8s之外的其他服务管理的用户账号，例如由管理员分发的密钥、keystore一类的用户存储、甚至是包含用户名和密码列表的文件等。k8s中不存在表示此类用户账号的对象，因此不能被直接添加进k8s系统中。

serviceaccount（服务账号）：是指由k8sapi管理的账号，用于为pod之中的服务进程在访问k8sapi时提供身份标识。serviceaccount通常要绑定与特定的名称空间，它们由apiserver创建，或者通过api调用手动创建，附带着一组存储为secret的用于访问apiserver的凭据。

useraccount通常用于复杂的业务逻辑管控，它作用于系统全局，故其名称必须全局唯一。相比较来说，serviceaccount隶属于名称空间，仅用于实现某些特定的操作任务，因此要轻量得多。这两类账号都可以隶属于一个或多个用户组。用户组只是用户账号的逻辑集合，它本身并没有操作权限，但附加于组上的权限可由其内部的所有用户继承，以实现高效的授权管理机制。

system: unauthenticated:  未能通过任何一个授权插件检验的账号，即未通过认证测试的用户所属的组。

system:authenticated: 认证成功后的用户自动加入的一个组，用于快捷引用所有正常通过认证的用户账号。

system:serviceaccounts：当前系统上的所有service account对象。

system:serviceaccounts:<namespace>:特定名称空间内所有的serviceaccount对象。

api请求要么与普通用户或服务账户进行绑定，要么被视为匿名请求。这意味着集群内部或外部的每个进程，包括由人类用户使用的kubectl，到节点上的kubelet，再到控制平面的成员组件，必须在向api服务器发出请求时进行身份验证，否则即被视为匿名用户。

2、认证、授权与准入控制基础

api server处理请求的过程中，认证插件负责鉴定用户身份，授权插件用于操作权限许可鉴别，而准入控制则用于在资源对象的创建、删除、更新或连接操作时实现更精细的许可检查。

kubernetes使用身份验证插件对api请求进行身份验证，支持的认证方式包括客户端证书、承载令牌、身份验证代理或http basic认证等。api server接收到访问请求时，它将调用认证插件尝试将以下属性与访问请求相关联。

Username: 用户名，如kubernetes-admin等。

UID：用户的数字标签符，用于确保用户身份的唯一性。

Groups：用户所属组，用于权限指派和继承

Extra：键值数据类型的字符串，用于提供认证时需要用到的额外信息。

api server支持同时启用多种认证机制，但至少应该分别为service account和user account各自启用一个认证插件。同时启用多种认证机制时，认证过程会以串行的方式进行，直到一种认证机制成功完成即结束。若认证失败，则服务器会响应401状态码，反之，请求者就会被识别为某个具体的用户，并且随后的操作都将以此用户身份来进行。