How a missing kernel flag broke FIPS-certified containers in managed Kubernetes

Key points

Canonical describes how Ubuntu Pro 22.04 FIPS container images were failing silently on standard mainline kernels, the kind used by managed Kubernetes services such as AWS EKS and Fargate, and how the problem was fixed without a new FIPS certification cycle. Fixed packages are in the FIPS update repositories for 22.04 and 24.04.

What went wrong

• libgcrypt20-fips had a hard dependency on GRND_RESEED_ONLY, an Ubuntu-specific kernel flag introduced with Canonical's FIPS implementation.
• Mainline kernels do not have that flag. When the library called getrandom() with it, the syscall returned an error and the container failed.
• It was not a misconfiguration: a FIPS-compliant host and a correctly built image, identical to one working on a Jammy FIPS kernel, would still fail.
• The issue is tracked as bug 2055825. The customer, in the middle of a FedRAMP migration, diagnosed it themselves from public bug reports and internal testing.

Who is affected

• Organisations under FedRAMP, FISMA or DoD requirements that run Ubuntu Pro FIPS images on managed Kubernetes with mainline kernels rather than Ubuntu FIPS kernels.

The fix

• Canonical Support escalated the case to the FIPS team.
• The patch changes how libgcrypt20-fips, gnutls28 and ubuntu-fips behave when GRND_RESEED_ONLY is unavailable, so they fall back correctly on standard kernels.
• It was designed to preserve FIPS compliance. Changes to cryptographic packages can otherwise invalidate certification and require months of revalidation through NIST's CMVP process.
• The customer validated the patched packages from a private PPA against their target environments before the general release.

What to do

• Ubuntu Pro 22.04 FIPS images: make sure they pull from jammy-fips-updates.
• Ubuntu Pro 24.04 FIPS images: make sure they pull from noble-fips-updates.

Takeaway from the post

• The container looked correct and the host was compliant; the failure appeared only between a package assumption and a kernel that did not support it.
• FIPS compliance in cloud-native environments depends on the interaction between certified packages and the underlying kernel, not only on using certified images.

Summary by DistroNews, based on the original post.