Kubernetes kubeadm 项目中的 JWS 签名验证问题分析

在 Kubernetes 的 kubeadm 项目中，最近发现了一个与 JWS(JSON Web Signature)签名验证相关的关键问题。这个问题影响了 kubeadm 的 dry-run(试运行)功能，导致集群加入操作无法正常完成。

问题背景

kubeadm 是 Kubernetes 官方提供的集群管理工具，其中的 dry-run 功能允许管理员在实际执行操作前进行模拟运行，以检查配置是否正确。在最新版本中，当尝试以 dry-run 模式加入控制平面节点时，系统会报错"failed to verify JWS signature of received cluster info object"，表明无法验证从 API Server 接收到的集群信息对象的 JWS 签名。

技术分析

这个问题源于对集群信息 ConfigMap 的修改。在 Kubernetes 的集群引导过程中，kubeadm 使用 JWS 机制来验证集群信息的真实性。具体来说：

1. 集群信息存储在名为 cluster-info 的 ConfigMap 中
2. 该 ConfigMap 包含一个 kubeconfig 文件和对应的 JWS 签名
3. 当节点加入集群时，会验证 JWS 签名以确保集群信息未被篡改

问题的根本原因是最近的一个代码变更修改了 dry-run 模式下使用的 cluster-info ConfigMap 内容，但没有同步更新对应的 JWS 签名。这导致签名验证失败，因为：

• 新的 ConfigMap 内容与旧的签名不匹配
• k8s.io/cluster-bootstrap/token/jws/jws.go 中的 DetachedTokenIsValid 函数在校验时返回 false
• kubeadm 因此拒绝信任接收到的集群信息

解决方案

修复方案相对直接：需要为新的 ConfigMap 内容重新生成正确的 JWS 签名。具体修改包括：

1. 更新 dryrun.go 文件中的硬编码 JWS 签名值
2. 确保新签名与修改后的 ConfigMap 内容匹配
3. 保持签名算法和密钥 ID 的一致性

这个修复确保了在 dry-run 模式下，kubeadm 能够正确验证集群信息的签名，使试运行功能恢复正常工作。

经验教训

这个案例提醒我们：

1. 当修改涉及加密签名的内容时，必须同步更新相关签名
2. 硬编码的测试数据在变更时需要特别小心
3. 签名验证机制在安全引导过程中的重要性
4. 完善的测试覆盖对于发现这类问题至关重要

对于 Kubernetes 管理员来说，理解这些底层机制有助于更好地诊断和解决集群管理过程中遇到的问题。