使用kops在AWS创建K8s集群后CA证书相关技术问询

一、签发客户端证书该用哪组CA？ #

结论先行：你需要使用S3存储路径里的根CA密钥/证书对（也就是s3://<BUCKET_NAME>/<CLUSTER_NAME>/pki/private/ca/*.key和s3://<BUCKET_NAME>/<CLUSTER_NAME>/pki/issued/ca/*.crt）来签发客户端证书。

为什么kubeconfig里的certificate-authority-data和它不一样？因为这两个CA的用途完全不同：

• kubeconfig里的certificate-authority-data是API Server服务端证书的签发CA（通常是分层架构里的中间CA），作用是让kubectl验证自己连接的API Server是合法的——毕竟你得确保没连到钓鱼服务器对吧？
• 而S3里的根CA是整个集群PKI体系的信任根，API Server的配置里会把它设为客户端证书的信任CA，只有它（或者它签发的中间CA）签发的客户端证书，才会被API Server认可为合法身份。

如果你的集群是新版本kops的默认分层CA架构，用根CA签发的客户端证书会自动被API Server信任（因为中间CA本身就是根CA签发的，信任链是通的）；如果是旧版本的单层CA，根CA直接负责所有证书签发，那就更不用说了。

二、为什么会存在多个CA？ #

这完全是安全设计的考量，核心是把风险隔离在最小范围内：

• 根CA是“终极信任源”：一旦根CA密钥泄露，攻击者可以随便签发任何组件或客户端的证书，直接接管整个集群。所以kops会把根CA加密存在S3里，尽量少用它做日常签发，而是用它来签发各种“各司其职”的中间CA。
• 中间CA拆分权限：不同的中间CA负责不同的集群组件：
  • API Server CA：专门管API Server的服务端证书，以及部分客户端证书的签发
  • Etcd CA：只负责Etcd集群内部的节点和客户端证书
  • Kubelet CA：给kubelet签发身份证书，让API Server能验证kubelet的合法性
• 缩小泄露影响范围：万一某个中间CA的密钥丢了，最多影响它负责的那部分组件，不会波及整个集群的信任体系，根CA依然安全，集群的核心信任链没断。

实操验证小技巧 #

如果你想确认两者的关系，可以动手对比一下：

1. 把S3里的根CA证书下载下来：

   aws s3 cp s3://<BUCKET_NAME>/<CLUSTER_NAME>/pki/issued/ca/ca.crt ./root-ca.crt
   

2. 解码kubeconfig里的CA证书：

   kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ./kubeconfig-ca.crt
   

3. 查看两个证书的详情：

   openssl x509 -in ./root-ca.crt -text -noout
   openssl x509 -in ./kubeconfig-ca.crt -text -noout
   

你会发现，kubeconfig里的CA证书的Issuer字段就是根CA的信息，而Subject是API Server CA——这就实锤了分层CA的架构。

内容的提问来源于stack exchange，提问作者pkaramol