CKA [Installation] – Ubuntu 从0架设，生成Certificate Authority

为什么 Kubernetes 集群需要 CA / PKI（证书体系）

通信安全 + 身份验证需求

Kubernetes 是一种高度分布式系统：控制面组件（如 kube-apiserver、controller-manager、scheduler）、节点上的 kubelet、各类客户端（kubectl、controller、scheduler 等）彼此之间要互相通信。这些通信如果没有加密／认证，很容易被中间人攻击、被伪装、被窃听、被篡改。

因此几乎所有关键路径都用 TLS 加密，并通过证书来做身份验证。常见场景包括：

  • kube-apiserver 作为服务器端，需要向客户端提供 TLS 证书，客户端（如 kubectl、controller）通过这个证书验证 apiserver 身份。
  • 各个组件（controller、scheduler、kubelet 等）作为客户端，用证书作为客户端证书向 apiserver 认证自己身份。
  • etcd 之间、etcd 客户端与 etcd 服务器之间也可能需要相互认证 + 加密。
  • Aggregation API / extension servers / front-proxy 等也涉及证书链、信任边界。

为了让这些组件互相信任，就要有一个“根”信任来源 —— 即 CA。只要组件都信任这个 CA，那它签的证书就被认为是可靠的。

什么是 CA / PKI

CA（证书颁发机构）在 PKI（Public Key Infrastructure，公钥基础设施）体系中，是负责“签发证书”的机构。它拥有一对密钥（私钥 + 公钥/证书）。私钥用来对下级证书签名；公钥（或 CA 证书）被分发给信任它的各方。信任链就是：

组件 A（持有 CA 公钥）相信 “凡是由 CA 用私钥签名的证书” 就具备可信性，组件 A 可验证 B 给出的证书是由 CA 签发的，从而信任 B。

在 Kubernetes 中，这个 CA 通常被称为 root CA（根 CA）或 cluster CA。Kubernetes 的内置许多证书都是由这个 CA 来签发。

如果没有 CA，证书就必须全部自己签名（每个组件都自己签署自己的证书），那样缺乏集中信任点，也难以管理、更新、撤销。

CA 的职责 + 好处
  • 签发证书：为 apiserver、kubelet、组件、客户端等生成证书。
  • 验证 / 信任根：所有组件信任这个 CA，则信任它签发的证书。
  • 证书生命周期管理：包括证书更新、撤销、续期等。
    • 一旦某个证书或密钥被泄露，可以作撤销或更新处理。
  • 分隔信任边界：有时 Kubernetes 会采用多个 CA（例如一个 CA 专门签发 etcd 证书，一个 CA 为 apiserver 和组件签发）以降低风险传播。

举个比喻：如果没有 CA，就像系统中每个人互相签名自己的“身份证明”，你要信任某个人的身份证就得自己判断；而有 CA 的话，大家只要信任那一家“发证机关”，就信那个机关签发的身份证就可以。这提供了统一的、可管理的信任基础。

Layman的解释方式

CA 是整个 Kubernetes 集群的「中央信任机构」，我们用 openssl 创建 CA 的 private key 和 public certificate。
每个组件（如 kubelet、apiserver 等）各自生成自己的 private key，然后生成 CSR，请 CA 用私钥给它签名，得到组件的证书。
各组件之间通信时，会互相查看对方的证书，并用 CA 的 public key 来验证是否是被 CA 签发的。
如果验证成功，就信任对方的身份，允许通信。

💡 打个比方：

  • 每个组件就像是公司员工
  • 它们去「HR 部门」（CA）领工卡
  • 只要工卡上有 HR 的印章（签名），其他人就知道这是自己人

OpenSSL手动创建 Kubernetes 集群 CA（证书颁发机构） 的完整过程

✅ 第 1 步：创建用于存储证书的目录

mkdir /root/certificates
cd /root/certificates
🔍解释：
  • 你需要一个专门的目录来保存你的 CA 私钥（ca.key）、CA 证书（ca.crt），以及后续为其他组件签发的证书。
  • 把所有证书操作放在一个目录里更容易管理，也更安全。

✅ 第 2 步：生成 CA 的私钥

openssl genrsa -out ca.key 2048
🔍解释：
  • genrsa：生成一个 RSA 私钥
  • -out ca.key：输出保存为 ca.key
  • 2048：密钥长度为 2048 位（安全性足够，常见）
🧠目的：

你现在拥有了 CA 的私钥（这是最高权限的密钥！）

谁掌握了这个私钥，就能签发你 Kubernetes 集群中所有的证书。必须严格保密！

✅ 第 3 步：用私钥生成 CSR（证书签名请求）

openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
🔍解释：
  • req -new：创建新的 CSR（证书签名请求）
  • -key ca.key：用前面生成的私钥来签这个 CSR
  • -subj "/CN=KUBERNETES-CA"：这个证书的主题（Subject），CN = Common Name，写成 KUBERNETES-CA
  • -out ca.csr：生成的 CSR 文件
🧠目的：

你告诉 openssl：“我要申请一个 CA 的证书，这是我的身份信息（CN），这是我的私钥。

✅ 第 4 步：用 CA 自己签自己（自签证书）

openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt -days 1000
🔍解释：
  • x509：生成一个证书
  • -req -in ca.csr：以 CSR 为输入（即刚刚生成的证书申请）
  • -signkey ca.key：用刚才生成的私钥来给这个证书签名（即“自签”）
  • -out ca.crt：输出的证书文件
  • -days 1000：证书有效期 1000 天
🧠目的：

你使用自己的私钥（ca.key）签署自己的 CSR（ca.csr），得到一个「自签名 CA 证书」：ca.crt

这是整个 Kubernetes TLS 信任系统的 根证书。

📌 通常只有根 CA 才会自签，其他组件都会找 CA 签名。

✅ 第 5 步：查看 CA 证书内容

openssl x509 -in ca.crt -text -noout
🔍解释：
  • -in ca.crt：查看这个证书文件
  • -text：以可读形式展示证书内容
  • -noout：不输出 base64 编码内容，只输出解析内容
🧠目的：

检查 ca.crt 是否生成成功，以及它的内容（CN 是不是 KUBERNETES-CA，有效期、使用目的等）。

✅ 第 6 步：删除中间文件 CSR

rm -f ca.csr
🔍解释：
  • CSR 在这时已经没有用了（你已经签完了）
  • 删除它是一种安全操作，也减少文件杂乱

Layman解释流程

一开始使用openssl生产了ca.key ( private key) , 然后使用ca.key 生产了ca.csr , 然后根据ca.csr 和 ca.key 自我签名生成了ca.crt 。 最后需要删除掉ca.csr , 就剩下了ca.key 和 ca.crt 。

ca.key 可以为其他的component （apiserver 等等）生成 apiserver.crt

如何验证apiserver.crt 是否是root ca签发的？ 所以就使用来了ca.crt 和 apiserver.crt 做验证。

openssl verify -CAfile ca.crt apiserver.crt

如果验证通过就放行。

Loading

Facebook评论

Related Posts