Admission controllers主要分为两个phase，一个是mutating，一个是validating。这两个阶段都是在authn&authz之后的，mutating做的变更准入，就是会对request的resource，进行转换，比如填充默认的requestLimit？而validating admission的意思就是验证准入，比如校验Pod副本数必须大于2。
API Server请求链路：
ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks, both of which are in beta status as of Kubernetes 1.13.
k8s支持30多种admission control 插件 ，而其中有两个具有强大的灵活性，即ValidatingAdmissionWebhooks和MutatingAdmissionWebhooks，这两种控制变换和准入以Webhook的方式提供给用户使用，大大提高了灵活性，用户可以在集群创建自定义的AdmissionWebhookServer进行调整准入策略。
TKE中1.10及以上版本也默认开启了ValidatingAdmissionWebhooks、MutatingAdmissionWebhooks
了解更多Admission Controller参考这里
kubernetes权限对接子账户TKE权限实现对接子账户主要的方案是：x509客户端认证+Kubernetes RBAC授权。
认证每个子账户都拥有单独的属于自己的客户端证书，用于访问KubernetesAPIServer。
用户在使用TKE的新授权模式时，不同子账户在获取集群访问凭证时，即前台访问集群详情页或调用DescribeClusterKubeconfig时，会展示子账户自己的x509客户端证书，此证书是每个集群的自签名CA签发的。
该用户在控制台访问Kubernetes资源时，后台默认使用此子账户的客户端证书去访问用户Kubernetes APIServer。
支持子账户更新自己的证书。
支持主账户或集群tke:admin权限的账户进行查看、更新其他子账户证书。
TKE控制台通过Kubernetes原生的RBAC授权策略，对子账户提供细粒度的Kubernetes资源粒度权限控制。
提供授权管理页，让主账号和集群创建者默认拥有管理员权限，可以对其他拥有此集群DescribeCluster Action权限的子账户进行权限管理。
并提供预设的ClusterRole。
所有命名空间维度：
管理员（tke:admin）：对所有命名空间下资源的读写权限， 对集群节点，存储卷，命名空间，配额的读写权限， 可子账号和权限的读写权限
运维人员（tke:ops）：对所有命名空间下控制台可见资源的读写权限， 对集群节点，存储卷，命名空间，配额的读写权限
开发人员（tke:dev）：对所有命名空间下控制台可见资源的读写权限
受限人员（tke:ro）：对所有命名空间下控制台可见资源的只读权限
用户自定义ClusterRole
指定命名空间维度：
开发人员（tke:ns:dev）： 对所选命名空间下控制台可见资源的读写权限， 需要选择指定命名空间。
只读用户（tke:ns:ro）：对所选命名空间下控制台可见资源的只读权限， 需要选择指定命名空间。
所有预设的ClusterRole都将带有固定label：cloud.tencent.com/tke-rbac-generated: "true"
所有预设的ClusterRoleBinding都带有固定的annotations：cloud.tencent.com/tke-account-nickname: yournickname，及label：cloud.tencent.com/tke-account: "yourUIN"