kubernete的证书总结 服务端保留公钥和私钥，客户端使用root CA认证服务端的公钥。

服务端保留公钥和私钥，客户端使用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