无论我们用kubectl还是通过sdk编程访问kubernetes，其实都是在于apiserver通讯，而这个通讯过程需要认证+鉴权。

认证+鉴权的过程，涉及到3个方面：

• 客户端确认apiserver是可信的。
• apiserver确认客户端是可信的，并对应到用户名。
• apiserver确认用户名是否有权操作对应资源。

而kubeconfig文件则是客户端使用的，用以与apiserver完成上述过程的唯一依据。

剖析kubeconfig文件

下面是我测试用kubernetes集群的kubeconfig文件：

它的类型是v1/Config，分为3大板块，下面依次说明。

contexts

我们可以在kubeconfig里配置多套kubernetes集群，然后使用kubectl的时候就可以指定使用哪个环境，因此1个context就代表1个kubernetes集群。

current-context指定了默认选择的context，也就是下面这个：

这个context的名字叫做kubernetes-admin@kubernetes，对应集群是kubernetes，用户是kubernetes-admin。

那么这里的集群和用户，其实对应kubeconfig剩下的2大板块配置。

users

用户，这个kubeconfig里只有一条配置：

大家要注意，这个name仅仅是一个标识，并不代表kubernetes集群中的用户。

真正的用户身份是谁呢？其实秘密藏在client-certificate-data和client-key-data中，前者是kubernetes签发的客户端证书（里面记录着真正的用户名），后者是客户端私钥。

客户端调用apiserver时提交自己的证书给apiserver，那么apiserver将用自己的CA验证客户端证书是否有效，一旦确认有效则完成”认证”，apiserver也就知道了客户端的username。

实际上，kubernetes集群搭建的时候，会生成一个CA，给所有其他组件签发证书，这样客户端的身份安全性就可以得到检验。

具体怎么用openssl生成RSA公私钥，并使用kubernetes的CA签发证书，大家参考这个链接即可：https://zhuanlan.zhihu.com/p/43237959。

至于username到底能不能操作对应资源，那是serviceaccount以及role/rolebinding做的事情了，大家只需要在kubernetes中做好配置即可。

clusters

users中的配置是为了认证客户端身份，而clusters板块的配置则为了验证服务端身份。

这里只配置了1个cluster：

name仅仅是kubeconfig文件内的集群标识，用在context配置里面。

server指定了apiserver的访问地址，它通常是一个负载均衡地址，因为kubenetes master是分布式部署的。

certificate-authority-data是kubernetes的CA证书自身（注意：CA密钥不会公开），这样TLS握手的时候客户端可以判断出服务端是否合法（服务端CA密钥加密，客户端CA证书解密）。

其实user部分除了CA客户端证书认证的方式之外还支持bearer token或者basic auth的认证方式，但是据我了解python sdk仅支持user采用CA客户端证书进行身份验证，所以大家需要注意kubeconfig里面到底采用了什么认证方式。