k8s的认证：
与API server通信的客户端大致有两类：
1.集群客户端工具（kubectl、kubeadm、kubelet等）
2.集群内pod.
任何客户端访问k8s时的过程：
1.认证：任何客户端访问k8s，首先需要通过k8s的认证；认证通过是说明所用账号只是k8s的合法用户；
2.授权：认证通过后，是否具有对k8s集群中资源的操作，需要k8s对其进行授权检查；
3.准入控制：授权检查通过后，并不能说明你的操作都在我们指定的操作范围内；进一步补充授权。
认证：k8s中常见的认证方式有：token令牌认证和SSL认证。
授权：k8s中常见的授权方式有：Node、ABAC(Attribute Base Access Control基于属性的访问控制)、RBAC(Role Base Access Control基于角色的访问控制)
k8s是高度模块化设计的，认证、授权、准入控制等，都通过插件方式部署，可由用户自定义选择经由什么样的插件来完成何种控制逻辑。
每个名称空间下都会有一个默认的token，该名称空间下的pod使用默认使用这个token来与API Servre通信。
kubeadm初始化后生成的客户端证书和私钥在:.kube/config
k8s的kubectl等客户端工具对集群操作时，命令被转化为一个http协议的请求：
如：若想访问default名称空间下的deployment控制器生成的nignx pod时的URL路径为：
http://node_ip:node_port/apis/apps/v1/namespaces/default/deployments/nginx
service account(sa):
kubernetes集群有两类认证时的账号：
user account（管理者、访问者）、service account（pod）。
创建一个sa：
1 kubectl create serviceaccount SA_NAME
若要对单独或一组pod使用单独token来实现权限的提升或者降级，需要单独创建pod账户（Service account）。
service account简写sa，创建一个sa的同时，系统会自动给这个sa生成一个token，用于使创建的sa连接API Server 。
查看某个pod使用的sa：kubectl describe pods POD_NAME 在输出的结果中寻找volumes段的SecretName。
pod若要使用某个自定义sa时，须在创建Pod时，在pod的资源清单中添加SA_NAME（spec.serviceAccountName:SA_NAME）。
例：k8s创建pod时，需要docker在镜像仓库中拉取镜像，若是私有镜像仓库，则需要提供账户及密钥，此时的解决方法有两种：
1.直接在定义pod时定义imagePullSecret。（较不安全）
2.创建单独的账户（sa），在sa中定义imagePullSecret，然后在创建pod时定义serviceAccountName为此sa名称。