浅谈 Kubernetes apiserver 使用客户端证书认证的流程

Kubernetes apiserver 使用客户端证书认证的完整流程是一套基于 双向 TLS（mTLS） 的认证过程：

1. 准备阶段

• CA（证书颁发机构）
  集群管理员生成一套 CA，用来给“客户端证书”签名。
  apiserver 启动时通过参数：

  --client-ca-file=/etc/kubernetes/pki/ca.crt
  

  指定这份 CA 证书，表示“凡是这个 CA 签发的客户端证书，我都信任”。

• 客户端证书
  用户或组件（kubectl、kubelet、controller-manager …）持有一对 证书+私钥：

  • .crt（客户端证书，里面带公钥和身份信息）
  • .key（私钥，证明你拥有这份证书）
    证书的签发者必须是 --client-ca-file 里列出的 CA。

2. 握手建立连接（TLS 层面）

1. 客户端发起 HTTPS 请求到 apiserver。

2. apiserver 发送自己的服务器证书（由 apiserver 的 server-ca 签发）。

   • 客户端（kubectl）会用 certificate-authority-data 校验它的合法性。

3. apiserver 要求客户端出示证书（因为启用了 --client-ca-file）。

4. 客户端返回证书（就是 .crt），并用自己的私钥完成握手的签名验证。

5. apiserver 用 --client-ca-file 提供的 CA 公钥校验证书：

   • 确认证书确实由这套 CA 签发；
   • 证书在有效期内；
   • 没有吊销。

如果证书校验失败，TLS 握手中止，连接被拒。

3. 用户身份提取（认证层面）

• 证书验证通过后，apiserver 会把证书中的字段映射为“用户身份”：

  • CN（Common Name） → 用户名（User）
  • O（Organization） → 组（Group）

• 举例：证书主题是

  Subject: CN=alice, O=dev-team
  

  那么 apiserver 会认为这次请求的用户是：

  username: "alice"
  groups: ["dev-team"]
  

4. 授权（RBAC 层面）

• apiserver 拿到用户/组身份后，进入 Authorization 阶段：
  根据 RBAC（Role、ClusterRole、RoleBinding、ClusterRoleBinding）检查该用户/组是否有权限执行请求的操作。
• 如果没有匹配的允许规则 → 返回 403 Forbidden。
• 如果有 → 请求继续执行。

5. 审计 & 日志

• 请求和身份信息会记录到 apiserver 的审计日志里，用于安全追溯。

---

注：--client-ca-file 就是 apiserver 信任的“客户端身份签发者”。客户端证书必须由它签发，apiserver 验证通过后才能把证书里的 CN/O 作为身份交给 RBAC 继续做授权。