eMudhra CA 失陷事件：为什么只给 Kubernetes 节点打补丁还不够

2026 年 10 月，一位研究人员发现，证书颁发机构 eMudhra 生成的八个证书签名私钥并不是随机的 384 位数值，而是单字节数字（4、56、66、115、155、156、230 和 237），因此任何人都能在一秒之内从公开的 CA 证书中恢复出这些私钥。恢复出受影响 TLS 签名密钥的人，可以为自己并不控制的域名签发证书。如果攻击者还能拦截或重定向流量，就可以向仍然信任这些已失陷颁发者的客户端冒充合法服务。即使你自己的证书并非由 eMudhra 签发，你的连接同样可能面临风险。一旦客户端接受了伪造的证书，攻击者就能获取通过该连接发送的凭据和请求数据，并返回被篡改的响应。

主流浏览器已收到屏蔽受影响证书的更新，但这些保护不会自动延伸到 Kubernetes。节点、容器镜像、应用运行时和集群配置，各自都可能提供受信任的证书，或应用自己的校验规则。该修复哪里，取决于正在运行的组件实际使用的是哪一个。

Kubernetes 把信任放在哪里

Kubernetes 集群并不使用单一的共享信任库。容器运行时通常依赖节点上的证书，应用可能在镜像里自带证书包，语言运行时还可能再提供一套。额外的 CA 证书包也可以存放在 Kubernetes 配置中，并挂载到工作负载里。

这些副本是各自独立更新的。正在运行的进程还可能保留更新之前加载的证书，所以修正了文件，并不一定就修正了应用的信任决策。下面几节会说明每一层需要更新什么，以及什么时候需要重启或重新加载。

受影响的是信任这些公共颁发者的连接。仅信任私有集群 CA 或网格 CA 的连接，不会因为这次事件而自动暴露在风险之下。

下图对比了一次典型的镜像拉取和一次应用程序连接。根据 TLS 配置的不同，应用可能使用图中所示来源中的一个或多个。

节点的信任和工作负载的信任沿着不同的路径更新。每个正在运行的客户端都必须重新加载发生变更的证书。

1. 节点：容器运行时与控制平面

Kubernetes 下载镜像时，kubelet 会请求 containerd 或 CRI-O 这样的容器运行时去拉取。运行时连接镜像仓库，并使用节点信任的 CA 校验其 HTTPS 证书。为 containerd 或 CRI-O 配置的仓库专用 CA 是追加到这个证书池中，而不是取代它，所以节点的证书包对这些仓库依然生效。

如果这份信任配置仍然接受已失陷的颁发者，位于网络路径上的攻击者就可以冒充镜像仓库。这发生在工作负载启动之前，所以更新工作负载镜像内的证书并不能保护这次下载。

安装发行版的 CA 更新，或者用已修复的节点镜像替换节点。然后重启那些缓存了旧证书的相关进程，其中包括容器运行时，以及相关的节点组件和控制平面组件。新启动的诊断工具可能已经在用更新后的证书包，而长时间运行的服务却仍在使用旧的。

控制平面同样需要关注。在 kubeadm 集群中，API server 和 controller manager 会挂载节点上的证书目录。这些证书库可能被用于对外的 HTTPS 连接。例如，当准入 webhook 的配置省略了显式的 caBundle 时，API server 会使用系统根证书；如果提供了证书包，则必须单独审查该证书包。

对于 kubeadm 的控制平面组件，请使用受支持的静态 Pod 重启流程。通过 API 删除它们的镜像 Pod（mirror Pod）对象，并不会重启底层的容器。对于多副本的控制平面，请逐个节点滚动进行，并在继续之前确认其已就绪。

此外，还要部署包含证书校验修复的、适用的 Kubernetes 和运行时版本。对于托管 Kubernetes，请遵循提供商关于控制平面和节点镜像发布的指引。提供商的更新不会自动替换你的应用镜像或自定义 CA 证书包。

2. 镜像：容器自带的信任库

更新节点的 CA 证书包，并不会更新其上容器镜像内的证书。许多镜像自带 /etc/ssl/certs，里面是镜像构建时安装的证书。

披露网站提供了一些测试端点，它们会出示受影响颁发者签发的证书。下面的命令使用某个特定的 curl 镜像检查 emSign 端点：

kubectl run curl --image=curlimages/curl:8.22.0 --restart=Never --rm -i -- \
  -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-emudhra.we-have-a-problem.com/

下面的对比在同一个已更新 CA 软件包的节点上使用了两个镜像：

较旧的镜像仍然接受受影响的证书，因为它自带的证书包早于这次修复。对于你自己维护的镜像，请更新 CA 软件包、重新构建并重新部署。对于厂商镜像，请使用包含修复的版本，并确认正在运行的 Pod 已经用上它。

这检查的是 curl 的信任配置。同一个容器中的应用可能使用不同的证书包或运行时，拒绝这个端点也并不能证明其他所有证书链都被拦截。

3. 运行时：应用的证书校验

应用并不总是使用镜像的 /etc/ssl/certs。有些运行时自带受信任的证书。还有一些运行时包含拒绝已失陷签名密钥的代码，即使信任库中仍然保留着受影响的根证书。

Go 与 Kubernetes 的关系尤其密切，因为 Kubernetes 的控制平面组件和许多控制器都是用 Go 编写的。Go 1.27.3 和 1.26.10 在 crypto/x509 中加入了一份阻止列表，会拒绝包含已失陷密钥的证书链。

用三个 Go 版本构建的测试客户端可以说明其中的差别。在使用同一份过期 CA 证书包的情况下，结果如下：

更新后的客户端会拒绝受影响的证书，同时仍然接受对照连接。这种保护是编译进应用里的：请部署使用已修复工具链构建的版本，或者自行重新构建并重新部署。go.mod 中声明的版本并不能说明已部署的二进制是由哪个工具链构建的。请同时检查二进制的构建元数据和它的实际行为。

Java、Node.js、Python 和 Rust 应用同样需要针对各自运行时的检查。请查阅运行时的安全指引，以及任何单独打包的 CA 软件包，例如 Python 的 certifi。更新操作系统的证书并不一定会更新这些副本。

4. 集群配置：Kubernetes 对象中的 CA 证书包

Kubernetes 对象中可以保存 CA 证书包，供工作负载和控制器校验连接时使用。更新节点或容器镜像并不会替换这些已保存的副本。

请检查你的应用获取受信任证书的各个位置：

• ConfigMap 和 Secret，包括 Argo CD 的 argocd-tls-certs-cm、包含 ca.crt 的 Secret，以及 Istio 或 Kasten 引用的证书包。
• Kubernetes API 配置，包括准入 webhook、APIService 和 CRD 转换 webhook 中的 CA 证书包。
• 应用配置，包括自定义资源和 Helm values 中的 CA 设置，以及 trust-manager 分发的证书包。

请使用披露网站受影响根证书列表中的 SHA-256 证书指纹来识别这些根证书。同时检查被显式信任的受影响中间 CA 证书。不要仅仅因为无关的私有集群信任锚或网格信任锚存放在同一类 Kubernetes 对象中，就把它们删除。

如果你在使用 trust-manager，请检查它的默认 CA 软件包，以及是否覆盖了仓库或标签。v0.25.0 及之前的 chart 默认安装受影响的软件包；v0.26.0 安装的是已修复的软件包。更新默认软件包并不会移除通过其他 Bundle 来源提供的受影响证书。

可用的修复与升级指引

下面的表格基于 2026 年 11 月 9 日的快照，列出了 Kubernetes 组件、托管集群和云原生工具所需的操作。在规划上线之前，请查阅所链接的项目指引，确认是否有更新的版本。自定义证书包、辅助程序和其他镜像变体仍然需要单独检查。

Kubernetes 与容器运行时

托管 Kubernetes

提供商已发布更新，并不代表更新已经到达你的集群。请检查控制平面、节点镜像和发布状态，然后单独处理由客户自行管理的工作负载。

服务网格、网关与网络

证书、身份与策略

交付与供应链

容器构建、镜像仓库与扫描

可观测性、数据与平台

总结

eMudhra 失陷事件说明了为什么在节点打完补丁之后，Kubernetes 的安全更新仍可能并不完整。容器可能保留着较旧的 CA 证书包，应用可能使用独立的运行时证书库，集群配置提供的证书则可能在这两类更新之后依然存在。正在运行的进程也可能需要重启，修正才会生效。

对于每一个受影响的客户端，请弄清它如何校验证书，应用相应的更新，并确认它会拒绝已失陷的证书链，同时合法连接仍然正常工作。需要验证的结果是正在运行的平台的实际行为，包括它实际使用的镜像、配置和辅助程序。