kubernete的证书总结

服务端保留公钥和私钥,客户端使用root CA认证服务端的公钥。

kubernetes的证书类型主要分为3类:

  • serving CA: 用于签署serving证书,该证书用于加密https通信。用于签署kubernetes API serving证书的CA也可以用于签署API server插件的serving证书,可能会用到不同的CA
  • client CA: 用于签署客户端证书,同时也被API server插件用来对客户端发来的证书进行认证。用于签署kubernetes API serving证书的client CA也可以用于签署API server插件的serving证书,可能会用到不同的CA
  • RequestHeader client CA: 该CA用于签署API server代理客户端证书,拥有代理证书的客户端可以有效地伪装成任何身份。当运行在aggregator之后时,该CA必须与前述aggregator代理客户端证书的CA一致()

serving 证书:
--tls-cert-file和--tls-private-key-file,API server用这两个选项来认证连接到自己的TLS。这两个证书也是CA(可以是自签CA)签署的。由于客户端节点可能会拒绝自签CA,因此需要将该CA分发给客户端节点,并在客户端指定该CA。如下kubelet的kubeconfig中的certificate-authority就指定了用于认证tls证书的CA。--tls-cert-file中需要有server字段的名称。API server和kubelet(当需要认证到kubelet的请求时)都有这两个选项,工作原理一样。

current-context: my-context
apiVersion: v1
clusters:
- cluster:
certificate-authority: /path/to/my/ca.crt # CERTIFICATE AUTHORITY THAT ISSUED YOUR TLS CERT
server: https://horse.org:4443 # this name needs to be on the certificate in --tls-cert-file
name: my-cluster
kind: Config
users:
- name: green-user
user:
client-certificate: path/to/my/client/cert
client-key: path/to/my/client/key

client 证书:
--client-ca-file:任何带有 client-ca-file 签名的客户端证书的请求,都将通过客户端证书中 Common Name 对应的标识进行身份认证,证书中的 Common Name 会作为用户名,Organization作为组来使用。默认情况下,API Server使用该选项会自动创建一个名为extension-apiserver-authentication,位于kube-system命名空间的ConfigMap ,该ConfigMap 中包含了--client-ca-file指定的CA。
API server的--kubelet-certificate-authority、--kubelet-client-certificate、--kubelet-client-key 和kubelet的--client-ca-file为一组选项,用于对kubelet进行认证(kubelet 组件在工作时,采用主动的查询机制,即定期请求 apiserver 获取自己所应当处理的任务)

RequestHeader client CA:
主要涉及3个选项--requestheader-client-ca-file、--proxy-client-cert-file、--proxy-client-key-file。代理(如aggregator)使用--proxy-client-cert-file、--proxy-client-key-file来请求API Server,API Server使用--requestheader-client-ca-file指定的证书来认证代理的证书。这三个选项都设置在API server的flag中,即aggregator一方面作为API server认证来自client的证书,一方面作为client,使用自身的代理证书向API server请求认证。
当kubernetes对应的客户端证书中的usernames和group与自己需求不符合时(无法认证或权限不足等),可以使用认证代理(代理使用另一套证书请求API server)

可以看到serving证书是通过TLS来进行认证,client证书通过用户名(Common Name)和组(Organization)进行认证;RequestHeader client证书认证方式与client证书认证方式类似

证书的验证:

显示插件API server支持的证书:openssl s_client -connect <service-cluster-ip>:443更多

验证证书是否由CA签署:openssl verify -CAfile ca.crt   the-certificate.crt

更多参见Certificate Issues

 

serviceaccount:参见http://www.cnblogs.com/charlieroro/p/8484711.html中serviceaccount一节

参考

https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
https://kubernetes.io/docs/concepts/cluster-administration/certificates

相关文章

文章浏览阅读942次。kube-controller-manager 和 kubelet 是...
文章浏览阅读3.8k次。上篇文章详细介绍了弹性云混部的落地历...
文章浏览阅读897次。对于cpu来说,这种分配方式并不会有太大...
文章浏览阅读796次,点赞17次,收藏15次。只要在Service定义...
文章浏览阅读763次。但是此时如果配置成 NONE, 租户创建成功...
文章浏览阅读2.7k次,点赞2次,收藏13次。公司使用的是交老的...