一、k8s的认证

1、kubernetes客户端证书认证（TLS双向认证）

        外部kubectl访问k8s集群的apiServer，通过apiServer来控制集群里面的资源（etcd、scheduler、controllermanager等），在发送请求的时候，需要认证所访问的apiServer是否是所需要访问的apiServer，反过来apiServer在被kubectl访问的时候，也需要向kubectl进行认证。

        TLS认证需要的CA证书机构，不再是使用的国际默认的CA证书机构，而是由k8s集群自己提供的CA证书，用来判断认证证书的合法性，k8s集群的CA会给所有需要的组件进行颁发证书，包括集群里面的apiServer及外部的kubectl。

2、BearerToken

        k8s集群生成BearerToken，提供给需要访问集群的组件，组件在访问集群的时候，带上Token，集群中的组件在接收到请求的时候，对Token进行验证，验证通过就可以进行通信。

3、ServiceAccount（namespace、token、ca）

        ServiceAccount会挂载到k8s集群中的pod的目录下，每个应用的pod可以用过读取目录下的ServiceAccount来获取集群的认证证书数据，从而可以与集群中的apiServer进行认证通信。

二、k8s授权

1、ABAC

2、WebHook

3、RBAC（Role Based Access Control）角色权限访问控制

角色访问控制主要由三个部分组成

1）User（用户）

        用户分为普通的User用户以及ServiceAccount，普通用户一般为kubectl等等外部访问k8s集群的用户，ServiceAccount主要是k8s内部访问的用户。

2）Role（角色）

        角色包含了name（名称）、resources（资源）、verbs（操作）几个属性。

        k8s集群的资源由namespace来进行划分，所以在设计权限的时候，k8s集群将role角色也划分到了某个namespace里面，用户（User）绑定了该Role，就拥有了访问该namespace的该Role所拥有的资源以及操作。

        k8s中如果要做跨namespace的权限如何来操作呢，虽然有一个方式就是让用户（User）来binding其它的namespace的Role来实现，这种当然也是可行的，但是k8s集群中的某些资源比如node（节点），它也是一种资源，它是不属于任何namespace的，所以k8s为了解决这种问题，提供了一个特殊的角色---ClusterRole（集群角色），它是不属于任何namespace的，它可以定义Role的所有属性之外，还可以定义不属于namespace的资源，它的绑定也有一个专属的ClusterRoleBinding。

3）Authoritiy（权限）

        权限主要分为Resource（资源）以及Verbs（操作），verbs主要是对k8s的资源的一些操作，类似增删改查。

        普通的权限系统都会由关联关系来将用户与角色进行绑定，由于k8s集群是没有表这种存储结构的，于是k8s将用户与角色使用RoleBinding来进行绑定。

三、准入控制（AdmissionControl）

        做完了上面的认证以及授权之后，要执行对应的请求，还需要通过k8s集群中的AdmissionControl。对于熟悉后端开发的人来说，也可以将它理解成为过滤器，所有对k8s集群的操作指令，都是需要通过一层一层的过滤之后，才可以执行。k8s提供了十几个准入控制器，具体如何执行以及执行顺序，是在配置apiServer的时候进行配置的。

下面简单的介绍几个比较常见的准入控制器

AlwaysAdmit（总是允许进入）

AlwaysDeny（总是拒绝进入）

ServiceAccount

这里的ServiceAccount跟用户层面的ServiceAccount并不是同一个概念，它是辅助用户层面的ServiceAccount，将其做了一个自动化，假设某些pod没有ServiceAccount用户，它会给该pod添加一个当前pod命名空间默认的ServiceAccount给pod，确保每个pod都能存在ServiceAccount。