k8s之认证鉴权准入控制

k8s认证，Authentication，检查用户是否为合法用户。认证方式有很多，常用的是 X509 Client Certs（用于外部用户如kubectl）和Service Accout Tokens（用于pod中进程），kubeconfig使用X509 Client Certs方式。
同时ServiceAccount Resource中主要包含了三个内容：namespace、token和ca.crt，其中namespace表示当前管理的命名空间；ca.crt用于校验服务端的的证书信息，即apiserver是否可信；token用于对pod进行身份认证。

k8s鉴权，Authorization，判断该用户是否具有该操作的权限。支持 Node、RBAC、ABAC等机制，RBAC 为主流方式。
RBAC 其实就是通过创建角色(Role），通过 RoleBinding 将被作用者（subject）和角色（Role）进行绑定
其中，
role：指定namespace上一系列权限的集合，如对某个资源的list、get、watch操作权限。
clusterRole： 集群维度的一系列权限的集合
subjects：可以是开发人员、集群管理员这样的自然人，也可以是系统组件进程、Pod中的业务进程，即user（这个user暂时理解为kubectl）、group或sa（自动生成secret并绑定到sa）；
roleBinding：进行role和Subject的绑定
clusterRoleBinding：进行clusterRole和Subject的绑定
同时系统预置了一些clusterRole，如 cluster-admin（最高权限）、admin、edit、view等，可以通过以下命令快速绑定集群管理员权限
kubectl create clusterrolebinding vela-core-clusterrolebinding --clusterrole=cluster-admin --user=vela-core

k8s准入控制，Admission Control，在对象被持久化到etcd之前，对请求的资源对象进行修改和校验。
Admission webhooks是Admission的扩展，是一种HTTP回调，能够接收Admission请求并对进行修改或验证，主要有MutatingAdmissionWebhook（修改）和ValidatingAdmissionWebhook（验证），如果启用了MutatingAdmissionWebhook，当开始操作一种k8s资源对象的时候，创建请求就会通过apiserver路由到service再到所编写的服务中，然后我们就可以做一系列的操作,包括植入注解等；而ValidatingAdmissionWebhook 是按照你自定义的逻辑是否允许资源的创建。