k8s认证与受权

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

1、访问控制概述

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

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

一、用户帐户与用户组

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服务器发出请求时进行身份验证，不然即被视为匿名用户。

二、认证、受权与准入控制基础

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

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

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

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

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

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

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