kubernetes生成kubeconfig原理

无论我们用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里面到底采用了什么认证方式。

如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~