k8s的认证和service account简述

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名称。