码迷,mamicode.com
首页 > Web开发 > 详细

kubernete的证书总结

时间:2018-03-16 18:38:40      阅读:184      评论:0      收藏:0      [点我收藏+]

标签:context   客户   let   charlie   证书认证   comm   ca认证   body   work   

服务端保留公钥和私钥,客户端使用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)使用证书--requestheader-client-ca-file来请求API Server,API Server使用--requestheader-client-ca-file指定的证书来认证代理的证书
当kubernetes对应的客户端证书中的usernames和group与自己需求不符合时(无法认证或权限不足等),可以使用认证代理(代理使用另一套证书请求API server)

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

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的证书总结

标签:context   客户   let   charlie   证书认证   comm   ca认证   body   work   

原文地址:https://www.cnblogs.com/charlieroro/p/8583693.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!