我们知道在k8s上APIserver是整个集群的访问入口，etcd是保存整个集群所有资源状态配置信息的kv键值存储数据库，一旦etcd宕机，k8s整个集群将无法正常工作，为此我们需要对etcd做高可用；除此之外为了保证etcd中的数据安全，k8s只允许APIserver去访问/操作etcd;这也是APIserver为什么是整个集群的访问入口的原因；简单讲etcd的客户端只有APIserver，我们用客户端想要查看对应资源的状态或者修改对应资源属性等等操作，都需要把请求发送给APIserver，由APIserver再把客户端的请求代理到etcd上，从而实现客户端访问/操作etcd中对应资源的状态或属性信息；这样一来APIserver就承担了整个etcd的数据访问安全；一旦APIserver出现问题，把恶意请求放进来，对应etcd的中的数据安全将无从保证；为此APIserver就必须拥有一套对客户端请求进行验证管控的机制；如下图

[图片]

　　1、用户认证

　　首先APIserver要验证客户端是否是合法客户端，在k8s上我们用kubectl工具去管理k8s集群，APIserver首先要验证kubectl客户端的证书，同时kubectl也要验证对应APIserver的证书；这个过程我们叫k8s用户认证的过程；在k8s上除了有通过证书方式认证客户端，还有其他机制，比如用户名和密码，利用token机制去验证对应客户端；其中利用token机制中有明文token（plain token）和引导token（bootstrap token）；不管是用户名密码还是token方式认证用户，在发送给APIserver时都是通过把对应的信息转化成http协议头部信息传递给APIserver；对应APIserver收到对应客户端请求，就会把对应头部信息检索下来，进行验证；不同的是plain token主要用于验证对应客户端是否合法，是否能够登陆APIserver；而对应bootstrap token是用来验证对应节点是否能够加入到k8s集群，如果bootstrap认证通过后，对应APIserver会调用ca给对应节点上的kubelet和kubeproxy颁发证书；此后kubelet和kubeproxy就可以通过APIserver认可的ca颁发的证书到APIserver认证，访问对应资源的信息了；

　　用户认证只是验证对应客户端是否是合法客户端，这里的验证的机制是一票通过的机制；所谓一票通过是指在APIserver上有多种验证机制（方法），它会从上至下依次进行验证，如果对应验证方法没有明确拒绝，接着它会用下一个验证方法，直到有一个机制通过以后，余下的就不验证了；比如，在k8s上有证书验证，用户名密码验证，token验证，如果此时有一个客户端拿着一个token来登陆APIserver，此时APIserver就会先用证书验证的方法验证客户端，如果对应验证方法没有明确拒绝，说明此方法不识别对应的客户端信息，接着它会用用户名密码的方法进行验证，如果对应方法也没有明确拒绝，接着它会用token方法进行验证，如果对应方法通过了，那么接下来的其他方法验证就不会再进行下去；如果所有验证方法都没有拒绝，说明该客户端提供的认证信息在k8s上不适配，此时apiserver 就会把对应客户端归纳为匿名用户；当然此类用户虽然登陆到APIserver上，但它没有权限操作资源；

　　2、验证授权

　　只有验证通过的客户端，才会有机会进行权限验证，所谓权限验证是指验证对应客户端是否拥有对应k8s上的资源访问/操作权限；验证权限也是一票通过的机制；只要对应客户端有对应资源的操作/访问权限，则其他资源的权限验证就不会再进行下去；如果没有对应资源访问/操作权限，此时APIserver就直接响应对应的客户端请求没有权限访问；如果对应客户端有对资源的访问/操作操作权限，此时客户端请求会进入到下一个步骤，准入控制；

　　3、准入控制

　　所谓准入控制是指检查对应客户端的请求是否符合对应请求/操作API规范；传递参数是否是正确的；比如我们要想k8s上创建一个pod，此时准入控制会检查我们提交的信息是否符合创建对应资源的规范，如果符合规范就创建，不符合规范就拒绝；准入控制这个环节是使用的一票否决的机制，所谓一票否决是指只要有一项不通过，则整个请求都将是拒绝的，即便余下的检查都是通过的；当然只要有一项没有通过，余下的验证就不会再进行；除了检查对应客户端提交的信息是否符合对应API资源的规范，准入控制还会帮助我们把我们没有明确指定的字段信息，通过默认值的方式把对应的字段填充到客户端请求中；然后把填充好的信息一并由APIserver把客户端请求更新到对应资源在etcd中的对应信息上；