如题所述
user account是在集群外部访问apiserver时使用的用户，比如kubectl命令就是作为kubernetes-admin用户来执行的，其中~/.kube/config指定了用户的证书，以便和apiserver互相认证。当然对于user account来说，是有多种认证方式的， 参考官网 ，但是默认使能是x509客户端证书方式。
因为x509客户端证书认证采用双向认证，所以开始之前先通过此 网址 简单了解下https双向认证的原理和流程
一、Http
HyperText Transfer Protocol，超文本传输协议，是互联网上使用最广泛的一种协议，所有WWW文件必须遵循的标准。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。
使用TCP端口为：80
二、Https
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。
使用TCP端口默认为443
三、SSL协议加密方式
SSL协议即用到了对称加密也用到了非对称加密(公钥加密)，在建立传输链路时，SSL首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL对传输内容使用对称加密。
对称加密
速度高，可加密内容较大，用来加密会话过程中的消息
公钥加密
加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥
四、双向认证
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
3、客户端使用服务端返回的信息验证服务器的合法性，包括：
（1）证书是否过期。
（2）发型服务器证书的CA是否可靠。
（3）返回的公钥是否能正确解开返回证书中的数字签名。
（4）服务器证书上的域名是否和服务器的实际域名相匹配。
（5）验证通过后，将继续进行通信，否则，终止通信。
4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端。
5、验证客户端的证书，通过验证后，会获得客户端的公钥。
6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
8、将加密方案通过使用之前获取到的公钥进行加密，返回给客户端。
9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端。
10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
下面我们要生成一个新的用户，并通过新用户并访问apiserver。
这里验证使用curl命令携带客户端证书来访问apiserver，--insecure表示curl将跳过对server端证书的验证
使用客户端证书访问apiserver，--cacert指定了server端证书，以便curl可以验证server
上面使用client.crt证书访问apiserver时，首先经过了认证模块的认证，会被分配一个group system:authenticated，此group是系统自动创建的group，并且已经被默认关联到了下面的三个clusterrole，他们是有查看资源的权利，但是很受限，比如上面 访问/api是可以的
下面尝试访问更多的资源，比如pod，就会报错，此请求被Forbidden，因为上面的三个clusterrole都没有访问pod的权利。
下面创建一个clusterrole，指定访问pod的权限后，将用户tester绑定到此clusterrole
将用户tester绑定到刚创建的ClusterRole，再次尝试获取pod可以成功。
平时我们执行kubectl命令时，它会先读取配置文件~/.kube/config(在k8s种，这种文件被称为kubeconfig)，获取客户端证书后，再访问apiserver。
现在我们要把上面生成的client.crt证书配置到~/.kube/config，让kubectl执行命令时，使用我们的客户端证书。
kubeconfig文件格式如下，其中clusters指定了要访问的k8s集群，可以配置多个，users指定了user account，contexts指定了使用哪个user，访问哪个集群，current-context 表示使用哪个context。
我们这里访问的是同一个集群，所以只需要修改user和context即可。使用下面三个命令进行设置，也可以直接修改配置文件。
在curl访问apiserver时已经将用户tester绑定到了ClusterRole test-pod，此ClusterRole只能访问test namespace下的pod，所以此时使用kubectl也只能访问test namespace下的pod。
kubectl可以获取 test namespace下的pod，并且不能获取kube-system下的pod
验证完后，记得将context切换回默认的
在创建客户端证书时，需要在生成csr时会指定 -subj 的CN指定用户，说明证书中会保存用户的信息。在配置文件中~/.kube/config
client-certificate-data和client-key-data分别指定了客户端证书和私钥数据(经过base64加密)，只要将client-certificate-data指向的数据base64解密后，就可以得知用户信息，操作如下:
由上可知，该证书绑定的用户组是system:masters，用户名为kubernetes-admin。而集群中默认有个 ClusterRoleBinding 叫 cluster-admin，它将名为 cluster-admin 的 ClusterRole 和用户组 system:masters 进行了绑定，而名为 cluster-admin 的 ClusterRole 有集群范围的 Superadmin 权限，这也就理解了为什么默认的 Kubeconfig 能拥有极高的权限来操作 k8s 集群了。
https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/
https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
https://blog.csdn.net/qianghaohao/article/details/100012855
