我用 50 行蓝图取代了 500 行 cert-manager 配置

Source: Dev.to

凌晨 3 点证书过期危机

你是否遇到过这种情况？你的手机被 PagerDuty 警报炸得满屏。生产 API 挂了。并不是因为代码有问题，也不是因为 DDoS 攻击，而是因为内部服务的证书已过期。

讽刺的是，即使使用 cert‑manager 进行“自动化”证书管理，配有 90 天轮换、监控和运行手册，这种情况仍然会发生。

这种危机屡见不鲜。

我的经历：6 小时的恢复过程

• 紧急证书续订 – 45 分钟
• 重启 pod 以加载新证书 – 30 分钟
• 根本原因分析 – 2 小时
• 撰写事后报告 – 1 小时
• 更新运行手册，确保此类“永不再发生” – 2 小时

三周后，另一个服务出现同样的问题。不同的证书。

我学到了什么？ 自动化证书签发并不等同于消除证书问题。

真正的问题不是“我们如何更快地轮换证书？”而是 “我们为何要在内部东西向流量中使用证书？”

这里是“自动化”证书管理的真实样子

之前：cert‑manager

150 + 行 Certificate YAML

• Issuer 配置
• CertificateRequest 管理
• Secret 轮换脚本
• 过期监控告警
• 紧急续订 Runbook

≈ 200 行配置
≈ 30 % 平台团队时间用于管理 PKI

之后：Lane7 Blueprint

# This is the entire deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-pod-1
spec:
  # ... standard Kubernetes deployment
  # Workload Security Proxy (WoSP) sidecar handles all networking, identity, and encryption

共 50 行。10 分钟部署完成。凭证在 Service A 与 Service B（任意两服务）之间的每次通信会话中轮换，并进行身份‑信任验证。

没有证书。没有 PKI。没有凌晨 3 点的告警。

自动化 PKI 的虚假安全毯

我曾以为“自动化证书”意味着：

• ✅ 每 90 天自动续订
• ✅ 自动分发到 pod
• ✅ 监控到期
• ✅ 零人工干预

听起来像是零信任，对吧？

错。它只是“零接触”颁发。

自动化无法解决的问题

1. “Secret Zero”问题 – 如何安全地交付获取证书的第一个密钥？你用…另一个密钥来引导信任。这是一层层的乌龟。
2. 证书颁发机构 = 单点故障 – 如果该 CA 被攻破、配置错误或存在漏洞，你的整个安全模型就会崩溃。
3. 每次证书轮换都是全新的身份 – 当轮换发生时，应用会失去已建立的可信交互历史。这就像每 90 天就换一次带有不同照片、地址和签名的驾驶执照。
4. 握手开销 – 每个连接都需要证书验证、链验证、吊销检查（OCSP/CRL）以及密钥交换协商，这会给每次内部服务调用增加延迟和 CPU 负载。
5. 静态身份窗口 – 即使采用 90 天轮换，证书仍会在磁盘上保存 90 天。如果攻击者在第 1 天获取了证书，他们就有 89 天的使用时间。
6. 过期焦虑 – 无论自动化做得多好，总会有担忧：
   • 如果轮换脚本失败怎么办？
   • 如果 webhook 超时怎么办？
   • 如果监控告警被漏掉怎么办？

领悟

我意识到“自动化 PKI”实际上并不是零信任——它只是一种更快的传统安全。PKI 在根域名上效果良好，因为它们经过第三方审查。对提交 CSR 的工作负载并没有进行审查。关注点是用于快速 TLS 连接的 PKI——而不是信任。

信任链在证书颁发机构结束，而不是在工作负载本身结束。

我需要一种方法来验证服务的身份，而不依赖于磁盘上的文件。