一个内核标志缺失，FIPS容器在托管K8s中静默崩溃

Mark Do 3 小时前暂无评论阅读 31 次

问题背景：云环境中的隐形陷阱

一位客户正在推进跨多个平台的 FedRAMP 合规迁移项目，其容器化工作负载依赖 Ubuntu Pro 22.04 FIPS 认证镜像。然而，当这些容器部署到 AWS EKS、Fargate 等托管 Kubernetes 环境时，却出现了静默失败——不是配置错误，而是一种更深层的兼容性断裂。

根因：云端内核中不存在的标志位

深入排查后发现，问题根源在于 libgcrypt20-fips 包对 GRND_RESEED_ONLY 这个 Ubuntu 专属内核标志的硬依赖。该标志是 Canonical 在 FIPS 实现中引入的，而主流云厂商的托管 Kubernetes 服务运行的是标准 mainline Linux 内核，根本不具备这个标志。

当容器内的加密库尝试以 GRND_RESEED_ONLY 参数调用 getrandom() 系统调用时，底层内核直接返回错误，容器随即崩溃。即便宿主机本身是 FIPS 合规的、容器镜像构建正确、且与在 Jammy FIPS 内核上正常运行的镜像完全一致，结果依然是失败——因为包在调用一个内核不支持的系统调用。

客户自行完成了初步诊断，并依据公开缺陷报告（包括 bug 2055825）和内部测试，向 Canonical 提交了包含具体包名、错误现象和参考链接的详细报告。

为何这不只是个案

这一架构模式广泛存在于任何需要在 mainline 内核的托管 Kubernetes 上运行 Ubuntu Pro FIPS 镜像的组织中，尤其是受 FedRAMP、FISMA 或 DoD 合规约束的企业。一个常见的假设是：FIPS 认证镜像的行为应与底层内核无关、始终一致。但在本次修复之前，这个假设并不成立。

升级调查与修复方案

Canonical 支持团队将问题升级至 FIPS 专项小组，由支持工程师 Matthew 主导技术调查。核心挑战在于找到一个能同时满足两个目标的补丁：

让 libgcrypt20-fips、gnutls28 和 ubuntu-fips 在缺乏 GRND_RESEED_ONLY 标志的标准内核上正常工作；
保持 FIPS 合规性，避免触发 NIST CMVP（密码模块验证计划）数月的重新认证流程。

加密包的任何改动都可能使现有认证失效，届时需要走完整的重新验证周期。任何破坏认证的”修复”实际上只是把一个阻碍换成了另一个阻碍。最终，Matthew 的补丁通过修改相关包在 GRND_RESEED_ONLY 不可用时的回退逻辑，在不损害 FIPS 密码学保证的前提下，让容器在标准内核上也能正确运行。