认证 k8s的请求有两种模式： 非安全模式（insecure-port）
该模式下所有请求都不会经过认证，不建议开启。 安全模式（secure-port)
该模式下开启TLS时，所有请求都需要经过认证。k8s 支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。 如果认证成功，则用户的username 会传入授权模块进一步授权验证；对于失败认证将返回401状态码。
对用户身份进行基本的认证，只允许被当前系统许可的人进入集群内部
不同的用户可以获取不同的资源操作权限，比如普通用户、超级用户、等
类似于审计，主要侧重于 操作动作的校验、语法规范的矫正等写操作场景。
3.2、授权方式
主要针对节点的基本通信授权认证，比如kubelet的正常通信(Attribute Based Access Control)：基于属性的访问控制，在apiserver本地的某一个文件里写入策略规则，如果满足其中一条，就算授权通过。现阶段如果想新
增规则，那么必须重启apiserver，在生产环境中使用几率较小，但未来可能会使用API动态管理。
更多的关于动态属性控制可以参考 OPA(open policy agent)相关资料。(Role Based Access Control)：基于角色的访问控制，这是1.6+版本主推的授权策略，可以使用API自定义角色和集群角色，并将角色和特定的用户，用户组，
Service Account关联起来，可以用来实现多租户隔离功能（基于namespace资源）准入控制(Admission Control)，实际上是一个准入控制器(Admission Controller)插件列表，发送
到APIServer的请求都需要经过这个列表中的每个准入控制器插件的检查，如果某一个控制器插件准入失败，
就准入失败。
它主要涉及到pod和容器对特定用户和特定权限之间的关联关系。
对于k8s来说，他支持的准入控制器有数十种，分别应用于不同的场景功能。一般情况下，k8s的不同版本的
默认准入控制器相差不大。但是其他的功能场景的准入控制器相差还是比较大的，尤其是最近两三年版本中所
支持的准入控制器。1.https://blog.csdn.net/qq_42586468/article/details/128983739
2.https://www.cnblogs.com/ygbh/p/17270653.html#_label3_0_1_0