前言

本章节正式开始部署 Kubernetes（密钥部分）

TLS 证书生成

均在 jumpbox 上操作：

cat ca.conf

查看 CA 配置文件内容，包括证书的 CN、组织、SAN 等信息，用来生成证书模板。

  openssl genrsa -out ca.key 4096
  openssl req -x509 -new -sha512 -noenc \
    -key ca.key -days 3653 \
    -config ca.conf \
    -out ca.crt

certs=(
  "admin" "node-0" "node-1"
  "kube-proxy" "kube-scheduler"
  "kube-controller-manager"
  "kube-api-server"
  "service-accounts"
)

for i in ${certs[*]}; do
  openssl genrsa -out "${i}.key" 4096

  openssl req -new -key "${i}.key" -sha256 \
    -config "ca.conf" -section ${i} \
    -out "${i}.csr"

  openssl x509 -req -days 3653 -in "${i}.csr" \
    -copy_extensions copyall \
    -sha256 -CA "ca.crt" \
    -CAkey "ca.key" \
    -CAcreateserial \
    -out "${i}.crt"
done

# 查看
ls -1 *.crt *.key *.csr

传输文件到各个节点：

for host in node-0 node-1; do
  ssh root@$host mkdir /var/lib/kubelet/

  scp ca.crt root@$host:/var/lib/kubelet/

  scp $host.crt \
    root@$host:/var/lib/kubelet/kubelet.crt

  scp $host.key \
    root@$host:/var/lib/kubelet/kubelet.key
done

scp \
  ca.key ca.crt \
  kube-api-server.key kube-api-server.crt \
  service-accounts.key service-accounts.crt \
  root@server:~/

但在实际生产环境中，证书属于敏感凭证，必须严格保护。

---

CA 体系文件说明

不感兴趣可直接跳过

本次操作中，有一堆相关文件：

ca.key
ca.conf
ca.crt

xxx.key
xxx.csr
xxx.crt

它们对应一个标准的证书签发体系。

1. ca.key —— CA 的私钥（绝密）

• 用来给其他组件签发证书
• 只存在于 CA 节点
• 泄露即整个集群证书体系作废

类比：

公证处的钢印

2. ca.crt —— CA 的证书（公开）

• 包含 CA 的公钥、身份信息、用途声明
• 作用：验证其他证书是不是 CA 签发的
• 所有组件需要保存一份 ca.crt 来建立信任

类比：

公证处的营业执照（大家看到就信任你）

3. ca.conf —— OpenSSL 配置模板

• 指定证书 CN、组织、SAN、用途等
• 类比：证书申请的表单模板
• 不是密钥，也不是证书

4. xxx.key —— 组件私钥

• 每个组件自己的私钥
• 用来证明“我是证书持有者”，参与 TLS 加密通信

类比：身份证的指纹

5. xxx.csr —— 证书申请表

• 包含身份信息、公钥、用途、SAN
• 交给 CA 签发证书

签完后，这个文件就没用了

6️. xxx.crt —— 正式 TLS 证书

• CA 签发的证书，包含身份信息、公钥、CA 签名
• 作用：向别人证明你是谁，以及你是被 CA 认证过的

生成与验证流程概览

1. 生成私钥：xxx.key
2. 生成证书申请：xxx.csr（包含身份信息 + 公钥）
3. CA 使用 ca.key 对 CSR 内容签名 → 得到正式证书 xxx.crt
4. 验证证书时：使用 ca.crt 中的 CA 公钥验证签名

核心关系：

TLS 证书 = 公钥 + 身份信息 + CA 的签名
ca.crt 用于验证 xxx.crt 是否由可信 CA 签发
xxx.key 用于证明：我真的是 xxx.crt 的持有者（身份真实性）

简要说明：

xxx.crt 说明你是谁
ca.crt 说明你是不是合法的
xxx.key 说明你真的是你

---

TLS 认证原理及过程

Kubernetes 是全员实名制系统 + 双向 TLS。

• 所有组件都保存 ca.crt，用来验证对方证书
• 每个组件用自己的 xxx.key 证明身份
• 每个组件用自己的 xxx.crt 作为身份证

1. 浏览器访问 HTTPS 网站

你在浏览器输入：

https://www.baidu.com

Step 1：TCP 三次握手

1. 浏览器（Client）发 SYN → 服务器（Server）
2. 服务器回复 SYN+ACK
3. 浏览器回 ACK
4. TCP 连接建立

TLS 握手在 TCP 建立之后开始，基于这个连接进行安全通信。

Step 2：服务器发送证书

• 服务器把自己的证书 baidu.crt 发送给浏览器

• 证书里包含：

  • 百度的身份信息（CN、组织等）
  • 公钥
  • CA 签名（比如 DigiCert）

浏览器拿到证书的第一步：确认“我拿到的是官方合法网站的证书”。

Step 3：浏览器验证证书合法性

1. 浏览器查找证书签名者（CA）
2. 用本地受信任的 CA 列表里的 ca.crt 公钥验证签名
3. 如果验证通过 → 证书合法
4. 如果是私人网站，需要手动导入 CA 证书并标记信任

这一阶段，浏览器只用 baidu.crt + 本地 ca.crt 就能确认网站合法性，不涉及 baidu.key。

Step 4：服务器证明自己持有私钥（关键）

有两种方法：

现代方式：ECDHE + 证书签名验证（TLS 1.2 / TLS 1.3）

• 服务器使用 baidu.key 对 TLS 握手中的关键数据进行签名
• 浏览器使用 baidu.crt 中的公钥验证该签名
• 验证通过 → 确认服务器确实持有私钥，身份可信
• 随后双方通过 ECDHE 算法协商生成共享的会话密钥

该方式将“身份认证”和“密钥协商”分离：
身份由签名证明，密钥由数学交换生成，具备前向安全性（Forward Secrecy）。

旧方式：RSA 密钥交换（TLS 1.2 及更早）

• 浏览器生成一个随机数（Pre-Master Secret）
• 使用 baidu.crt 中的公钥加密后发送给服务器
• 服务器使用 baidu.key 解密该随机数
• 双方基于该随机数生成会话密钥

在该模式中：
✔ 能成功解密 = 证明服务器持有私钥（身份确认）
✔ 同时完成密钥的安全传递
但不具备前向安全性。

说白了，RSA 是通过解密能力证明，ECDHE 是通过签名能力证明。

主要解决别人拿到 TLS 证书就可以冒充服务器这个问题。

Step 5：双方生成会话密钥

• 使用浏览器随机数 + 服务器随机数 + 协商信息
• 生成对称加密密钥
• 之后的数据通信都用这个密钥加密

Step 6：加密通信开始

• 浏览器 → 服务器 → 双方加密传输
• TLS 握手完成，HTTPS 正式生效

文件	作用
baidu.crt	证明服务器身份
ca.crt	验证证书合法性
baidu.key	证明服务器持有私钥

---

2️. Kubernetes 创建一个 Pod

假设你执行：

kubectl run nginx

Kubernetes 内部 TLS 流程如下：

Step 1：kubectl → apiserver（TLS）

1. apiserver 发送自己的证书 apiserver.crt
2. kubectl 使用本地 ca.crt 验证签名
3. kubectl 确认 apiserver 是可信的

这一步类似浏览器验证 HTTPS 网站。

Step 2：apiserver 证明自己是证书持有者

1. apiserver 使用 apiserver.key 对 TLS 握手中的信息签名
2. kubectl 验证签名
3. 成功 → apiserver 身份确认

Step 3：apiserver 调度 Pod → 与 kubelet 通信（双向 TLS）

1. kubelet 发送自己的证书 kubelet.crt
2. apiserver 用 ca.crt 验证 kubelet.crt 是否由 CA 签发
3. kubelet 用 kubelet.key 对握手数据签名，证明身份
4. apiserver 返回自己的 apiserver.crt
5. kubelet 用 ca.crt 验证 apiserver.crt

这是 双向 TLS (mTLS)，双方都能确认对方身份。
kubelet 就是打工仔（node节点上），apiserver 是上级，互相确认好各自身份后，上级给打工仔安排任务。

Step 4：生成对称密钥 + 加密通信

• kubelet 和 apiserver 协商会话密钥
• 后续所有命令、状态、Pod 配置通过加密通道传输

Step 5：容器创建

• TLS + 身份认证通过 → apiserver 下发 Pod 创建指令
• kubelet 执行 container runtime 拉镜像、启动容器

核心思想总结

条件	文件	作用
合法身份	xxx.crt	谁是谁
能证明我是我	xxx.key	私钥签名/解密，证明身份真实性
统一信任源	ca.crt	验证对方证书是否合法

Kubernetes 全员实名制 + 双向 TLS，确保每个组件身份可验证、通信加密。

TLS 证书修复

证书修复是利用 openssl 等工具快速核对有效期、身份匹配（SAN/CN）和信任链这三大核心要素，而修复流程则统一表现为：基于可信 CA 重新签发（Renew）合法的证书文件，并将其分发至对应路径后重启相关服务以完成新证书的加载与生效。

VMware VSphare TLS 原理也差不多
后面会针 K8S TLS 证书进行试验

结语

这里就过了一下 TSL 证书工作原理以及生成过程，工作上若证书丢失或过期，大致也从工作原理上明白了从哪个点进行修复。