简介
Kubernetes 本身并没有用户治理能力，无奈像操作 Pod 一样，通过 API 的形式创立 / 删除一个用户的资源对象。
同时 Kubernetes 内置的资源对象中也没有一个是对应用户的。
当然这里就会有人问：” 那 ServiceAccount 是啥呢？它不算是用户么？”。
其实，在我了解里，ServiceAccount 只能算是一种拜访凭证，比方像是 Jwt 的 token，之类的货色，它没有传统意义上的用户相干的数据，如果说邮箱、手机号等等之类的。
咱们如果须要拜访 Kubernetes 集群的话，咱们能够应用 ServiceAccount 拜访，同时也能够应用 Kubernetes 为咱们提供的其中一种认证形式并联合集群外的用户拜访控制系统来进行认证拜访，例如 ldap。
到这里，必定也会有人有纳闷，那就是 kubectl 是通过什么形式进行拜访的呢，其实 kubectl 是通过 Kubernetes 配置文件中的证书来进行认证拜访的，别着急，前面我会一一的介绍到对应的各种认证形式。
认证
不论是应用 kubectl 还是通过 Client-Go 与 Kubernetes APIServer 交互的时候，都是最先进入认证这一环节的。
在认证的这一环节来校验，申请是否为一个无效的用户发送的。
同时，咱们还能够配置多个认证模块，申请会顺次进行认证模块的校验，只有有一个认证模块通过校验，则可进入下一环节。反之，若所有的模块都校验失败，则会给客户端发送 401 的 HTTP 状态码。
认证通过后，会解析认证信息中的用户，这个用户会作为后续步骤的决策依据。
须要留神的是，尽管 Kubernetes 通过用户来进行对 Kubernetes APIServer 申请的认证及审计，然而，正如下面说的，Kubernetes 自身是没有用户这个资源对象的，因而也无奈通过 API 进行治理和查问。
当然咱们也能够应用自定义 CRD 的形式，来欠缺一下咱们缺失的这个用户相干的资源对象。
鉴权
在申请通过认证后，则会进入到鉴权这一环节，鉴权这一环节能够决定是承受还是拒绝请求。
Kubernetes 中反对多种鉴权模块，比方 Node、ABAC、RBAC、WebHook。通过配置这些鉴权模块，咱们就能够进行申请的鉴权校验。
- Node：节点鉴权是一种非凡用处的鉴权模式，专门对 kubelet 收回的 API 申请进行受权。
- ABAC：基于属性的访问控制。
- RBAC：基于角色的访问控制。
- Webhook：基于 Webhook 的一种 HTTP 回调机制，通过给 URL 发送 POST 申请，进行近程鉴权治理。
鉴权同样也反对开启多个鉴权模块，如果开启多个鉴权模块，则依照程序顺次执行鉴权模块的校验，排在后面的鉴权模块有较高的优先级来容许或者拒绝请求。只有有一个鉴权模块通过，则鉴权胜利。若所有鉴权模块都回绝了申请，则会给客户端返回一个 403 的 HTTP 状态码。
准入管制
在申请通过认证和鉴权后，就进入了准入控制器环节。
准入控制器只针对创立、批改或删除资源对象的申请无效，对于只读的申请是有效的。
准入控制器也是能够配置多个的，会依照程序顺次进行调用。然而与认证和鉴权不同的是，当有任何一个准入控制器回绝了申请，则这个申请同样会被其余准入控制器回绝。
一旦申请通过了所有的准入控制器，则会应用相应的验证逻辑对资源对象进行验证，验证通过后，便会写入到存储中。
准入控制器的作用分为两个阶段，别离是 变更 和验证。
- 变更（MutatingAdmission）：变更用户提交的资源对象信息，例如补充一些字段的默认值。
- 验证（ValidatingAdmission）：校验用户提交的资源对象信息。
准入控制器个别是以插件的模式在 Kubernetes APIServer 中运行的。通常在启动 APIServer 的时候通过参数的模式进行准入控制器的配置。
准入控制器依据下面的两个阶段能够划分为两种类型，一个准入控制器可能属于以上两者中的一种，也可能两者都属于。当申请达到 API Server 的时候首先执行变更准入管制，而后再执行验证准入管制。
须要留神的是，咱们在部署 Kubernetes 集群的时候，通常都会默认开启一系列准入控制器，如果没有设置这些准入控制器的话，那么能够说您的 Kubernetes 集群就是在裸奔，且应该只有集群管理员能够批改集群的准入控制器。