kubernetes组件，片来源kubernetes.io
Kubernetes中使用到的CA和证书
在Kubernetes的组件之间进行通信时，数字证书的验证是在协议层面通过TLS完成的，除了需要在建立通信时提供相关的证书和密钥外，在应用层面并不需要进行特殊处理。采用TLS进行验证有两种方式：
以上这些组件之间的相互调用都是通过网络进行的。在进行网络通信时，通信双方需要验证对方的身份，以避免恶意第三方伪造身份窃取信息或者对系统进行攻击。为了相互验证对方的身份，通信双方中的任何一方都需要做下面两件事情：
kube-apiserver对外提供服务的服务器证书及私钥。kube-apiserver访问etcd所需的客户端证书及私钥。kube-apiserver访问kubelet所需的客户端证书及私钥。验证访问其服务的客户端的CA。验证etcd服务器证书的CA根证书。验证serviceaccounttoken的公钥。
/usr/local/bin/kube-apiserver \
--tls-cert-file=/var/lib/kubernetes/kube-apiserver.pem \ # 用于对外提供服务的服务器证书
--tls-private-key-file=/var/lib/kubernetes/kube-apiserver-key.pem \ # 服务器证书对应的私钥
--etcd-certfile=/var/lib/kubernetes/kube-apiserver-etcd-client.pem \ # 用于访问 etcd 的客户端证书
--etcd-keyfile=/var/lib/kubernetes/kube-apiserver-etcd-client-key.pem \ # 用于访问 etcd 的客户端证书的私钥
--kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver-kubelet-client.pem \ # 用于访问 kubelet 的客户端证书
--kubelet-client-key=/var/lib/kubernetes/kube-apiserver-kubelet-client-key.pem \ # 用于访问 kubelet 的客户端证书的私钥
--client-ca-file=/var/lib/kubernetes/cluster-root-ca.pem \ # 用于验证访问 kube-apiserver 的客户端的证书的 CA 根证书
--etcd-cafile=/var/lib/kubernetes/cluster-root-ca.pem \ # 用于验证 etcd 服务器证书的 CA 根证书
--kubelet-certificate-authority=/var/lib/kubernetes/cluster-root-ca.pem \ # 用于验证 kubelet 服务器证书的 CA 根证书
--service-account-key-file=/var/lib/kubernetes/service-account.pem \ # 用于验证 service account token 的公钥
...
服务器端证书：服务器用于证明自身身份的数字证书，里面主要包含了服务器端的公钥以及服务器的身份信息。服务器端私钥：服务器端证书中包含的公钥所对应的私钥。公钥和私钥是成对使用的，在进行TLS验证时，服务器使用该私钥来向客户端证明自己是服务器端证书的拥有者。客户端证书：客户端用于证明自身身份的数字证书，里面主要包含了客户端的公钥以及客户端的身份信息。客户端私钥：客户端证书中包含的公钥所对应的私钥，同理，客户端使用该私钥来向服务器端证明自己是客户端证书的拥有者。服务器端CA根证书：签发服务器端证书的CA根证书，客户端使用该CA根证书来验证服务器端证书的合法性。客户端端CA根证书：签发客户端证书的CA根证书，服务器端使用该CA根证书来验证客户端证书的合法性。
etcd证书配置
我们打开controller-manager.conf来看一下。
etcd对外提供服务的服务器证书及私钥。etcd节点之间相互进行认证的peer证书、私钥以及验证peer的CA。etcd验证访问其服务的客户端的CA。
/usr/local/bin/etcd \
--cert-file=/etc/etcd/kube-etcd.pem \ # 对外提供服务的服务器证书
--key-file=/etc/etcd/kube-etcd-key.pem \ # 服务器证书对应的私钥
--peer-cert-file=/etc/etcd/kube-etcd-peer.pem \ # peer 证书，用于 etcd 节点之间的相互访问
--peer-key-file=/etc/etcd/kube-etcd-peer-key.pem \ # peer 证书对应的私钥
--trusted-ca-file=/etc/etcd/cluster-root-ca.pem \ # 用于验证访问 etcd 服务器的客户端证书的 CA 根证书
--peer-trusted-ca-file=/etc/etcd/cluster-root-ca.pem\ # 用于验证 peer 证书的 CA 根证书
...
Kubernetes中的各个组件，包括kube-controller-mananger、kube-scheduler、kube-proxy、kubelet等，采用一个kubeconfig文件中配置的信息来访问kube-apiserver。该文件中包含了kube-apiserver的地址，验证kube-apiserver服务器证书的CA证书，自己的客户端证书和私钥等访问信息。
下面这张来自ThemagicofTLS,X509andmutualauthenticationexplained文章中的形象地解释了双向TLS认证的原理。如果你需要了解更多关于TLS认证的原理，可以阅读一下medium上的原文。
从中可以看到，Kubernetes控制平面中包含了etctd，kube-api-server，kube-scheduler，kube-controller-manager等组件，这些组件会相互进行远程调用，例如kube-api-server会调用etcd接口存储数据，kube-controller-manager会调用kube-api-server接口查询集群中的对象状态；kube-api-server也会和在工作节点上的kubelet和kube-proxy进行通信，以在工作节点上部署和管理应用。
kube-apiserver证书配置
服务器单向认证：只需要服务器端提供证书，客户端通过服务器端证书验证服务的身份，但服务器并不验证客户端的身份。这种情况一般适用于对Internet开放的服务，例如搜索引擎网站，任何客户端都可以连接到服务器上进行访问，但客户端需要验证服务器的身份，以避免连接到伪造的恶意服务器。双向TLS认证：除了客户端需要验证服务器的证书，服务器也要通过客户端证书验证客户端的身份。这种情况下服务器提供的是敏感信息，只允许特定身份的客户端访问。
Kubernetes中的证书配置
通过这张，对证书机制比较了解的读者可能已经看出，我们其实可以使用多个不同的CA来颁发这些证书。只要在通信的组件中正确配置用于验证对方证书的CA根证书，就可以使用不同的CA来颁发不同用途的证书。但我们一般建议采用统一的CA来颁发kubernetes集群中的所有证书，这是因为采用一个集群根CA的方式比采用多个CA的方式更容易管理，可以避免多个CA导致的复杂的证书配置、更新等问题，减少由于证书配置错误导致的集群故障。
需要在kube-apiserver中配置以下证书相关参数：
首先让我们来看一下Kubernetes中的组件：在Kubernetes中包含多个以独立进程形式运行的组件，这些组件之间通过HTTP/GRPC相互通信，以协同完成集群中应用的部署和管理工作。
Kubernetes中使用了大量的证书，本文不会试覆盖到所有可能使用到的证书，但会讨论到主要的证书。理解了这些证书的使用方法和原理后，也能很快理解其他可能遇到的证书文件。下标识出了在kubernetes中主要使用到的证书和其使用的位置：
需要在etcd的启动命令行中配置以下证书相关参数：
在Kubernetes中，各个组件提供的接口中包含了集群的内部信息。如果这些接口被非法访问，将影响集群的安全，因此组件之间的通信需要采用双向TLS认证。即客户端和服务器端都需要验证对方的身份信息。在两个组件进行双向认证时，会涉及到下面这些证书相关的文件：
Kubernetes中使用到的主要证书
上中使用序号对证书进行了标注。中的箭头表明了组件的调用方向，箭头所指方向为服务提供方，另一头为服务调用方。为了实现TLS双向认证，服务提供方需要使用一个服务器证书，服务调用方则需要提供一个客户端证书，并且双方都需要使用一个CA证书来验证对方提供的证书。为了简明起见，上中只标注了证书使用方提供的证书，并没有标注证书的验证方验证使用的CA证书。中标注的这些证书的作用分别如下：
向对方提供标明自己身份的一个证书验证对方提供的身份证书是否合法，是否伪造的？
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论