首页 > Web开发 > 详细

kubernete的证书总结

时间:2018-10-15 15:51:52      阅读:151      评论:0      收藏:0      [点我收藏+]

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

kubernete的证书总结

原文:https://www.cnblogs.com/charlieroro/p/9791240.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!