Kube-APIServer组件负责对外暴露资源的API，也包括自定义资源。外部访问和操作 Kubernetes 资源会经过哪些流程呢？下面介绍 KubernetesAPI 的访问控制。
2.3.1 KubernetesAPI访问控制
在Kubernetes集群中，Kube-APIServer是控制面的一个组件，它对外暴露Kubernetes的 API，通常这个服务使用6443端口。集群控制面之外的组件要访问这个服务有两种情况。
（1） 用户可以使用 Kubectl、客户端库或 REST风格的请求去访问 Kube-APIServer。
（2） 用户运行在集群中的服务使用 ServiceAccount去访问Kube-APIServer。一个请求到达API要经过多个阶段，如图 2-9所示。
图 2—9KubernetesAP请求处理步骤
1. 认证
如图 2-9中的步骤①，客户端（Kubectl工具、REST请求或集群中的 Pod等）在集群内应用访问Kube-APIServer的HTTP请求首先会进入认证这步。我们在创建集群时可以配置一个或者多个认证模块。
认证模块的工作过程：请求会依次通过每个认证模块，只要有一个模块通过则进入下一步。如果所有的认证模块都没有通过，就会给客户端返回一个 401的 HTTP状态码。认证通过后会解析认证信息中对应的用户，这个用户会作为后续步骤决策的依据。
需要注意的是，虽然Kubernetes通过用户来对访问Kube-APIServer的请求进行访问控制决策和访问日志记录，但 Kubernetes中没有用户这个对象，也没有在API中存储用户和用户相关的信息。
2. 鉴权
图2-9中的步骤②是根据上一步的用户对请求进行鉴权操作。鉴权过程是判断当前用户是否有权限去操作 HTTP 请中的资源对象，判断的依据是存储在集群中的策略声明。Kubernetes中支持多种鉴权模块，比如 ABAC、RBAC和 WebHook。鉴权模块是在创建集群时配置的，如果配置了多种鉴权模块，Kubernetes 会检查每个模块。如果有一个模块通过鉴权，那么该请求鉴权通过；如果所有的模块都拒绝了该请求，就会给客户端返回一个 403的 HTTP状态码。
3. 准入控制
请求经过认证和鉴权之后会被准入控制器拦截，如图2-9中的步骤③所示，准入控制器可以修改或拒绝请求。准入控制器只对创建、修改或删除对象的请求起作用，对只读请求不起作用。当配置了多个准入控制器时，会按照顺序进行调用。
与认证或鉴权模块不同的是，如果有任何一个准入控制器拒绝了请求，那么请求会立马被其他准入控制器拒绝。除了拒绝请求之外，准入控制器还可以为请求中的字段设置一些默认值。
一旦请求通过所有的准入控制器，就会使用相应的验证逻辑对 API对象进行验证，之后会将对象写入存储中，即图2-9中的步骤④。
