FIPS-Validated Container Images: When, Where, and Why

Chainguard’s catalog of 1,400+ trusted container images includes 400+ FIPS-validated variants. Our FIPS images cover everything from common runtimes (Python, Go, etc.), the long-tail of third-party applications (Redis, Grafana, etc.), critical AI/ML projects (PyTorch, Spark, etc.), and more. Customers who deploy their products in highly regulated environments (security, financial services, healthcare) and public sector infrastructure (FedRAMP, DoD, etc.) rely on Chainguard to build and maintain these images to simplify their compliance requirements. 

A question we often hear from our customers is, “Do I need FIPS-validated cryptography at the container level or can I rely solely on other encryption technologies?" 

The short answer: Yes! FedRAMP (and NIST 800-53) requirements clearly state that data in transit – whether from a container to container, container to sidecar, or container to another source outside the host – must be encrypted with cryptographic modules that are FIPS-validated. Relying solely on FIPS-enabled container hosts, FIPS-validated service mesh, or VPN tunnels means there are gaps in your encryption program that auditors will flag and poke at. That’s why we’ve built 400+ FIPS-validated container images that make compliance and authorization simple. And importantly, per FedRAMP’s Policy for Encryption, Chainguard’s container images are FIPS-validated (meaning we have a CMVP certificate validating our use for FIPS encryption), as opposed to ambiguous terms like “FIPS-compliant."  

In this blog post, we’ll break down where, why, and when FIPS-validated cryptography at the container image level is critical and how leveraging Chainguard Containers can save you significant overhead in meeting customer requirements while shaving weeks off your compliance timelines. 

What is FIPS – and Why Do Customers and Regulators Care?

A FIPS-validated container image is one whose entire cryptographic boundary maps to a module certificate listed in the NIST CMVP database. Anything outside that boundary is rebuilt from source so the running process cannot fall back to non-validated code paths. FedRAMP and NIST 800-53 are very specific about their definition of encryption and leave little room for interpretation.

NIST CMVP FAQ defines the “why” for encryption: Non-validated cryptography is viewed as providing no protection… in effect the data would be considered unprotected plaintext… In essence, if cryptography is required, then it must be validated.”

FedRAMP Rev 5 Baselines define the “when and where” for FIPS encryption: “FedRAMP considers any data in transit, whether that be from one container to another container, from a container to a sidecar inside the same host virtual machine, or from a container to any other source outside that container, that SC-8 [encryption] controls must be applied…”

Now let’s talk about why alternatives to image-level FIPS don’t quite do the job. 

“Can’t I Just Use a FIPS-Validated Service Mesh?”

Service meshes like Istio and Linkerd are excellent for establishing traffic encryption between nodes. This approach might be good enough for your application to meet FedRAMP’s SC-8 requirements around FIPS encryption for data-in-transit. But if we drill deeper, we see there are some significant gaps:

• Inside the pod, we skip the mesh: Traffic between the main container and your sidecars and/or helper processes still need FIPS encryption and sit outside the boundary of your service mesh.

• Container-to-Container Calls: Again, the service mesh can’t handle the encryption required here and you still require FIPS-validation.

• Workload-level Encryption: Your application may deal with data calls inside the container, which means the workload itself is storing and handling secrets that require image-level FIPS validation. 

So while a FIPS-validated service mesh solves certain parts of your encryption requirements, it isn’t a silver bullet. It cannot solve all your requirements for FIPS-at-rest, FIPS integrity checks, FIPS authentication, or any other FIPS requirements that your customers and auditors may ask of you. 

The good news is that many Chainguard customers pair their service mesh with our FIPS-validated images to build a holistic encryption program. Many of those customers are actively using our FIPS-validated Istio images.

“Okay, but what if I use VPN Tunnels?”

Taking the approach to route all your traffic between network endpoints through a VPN is common among our customers. And it can be a very effective way to simplify data-in-transit FIPS encryption.

But like the service mesh, the VPN tunnel is just a wrapper around host-to-host traffic. And compliance guidelines (like FedRAMP baselines) specifically point to FIPS encryption within the pod, cluster, and container workload itself. With that in mind, here are a few things to remember:

• Layered encryption doesn’t provide blanket coverage unless you’re covering every layer — that means you can pair VPN tunnels with container images but by itself its not sufficient

• Intra-host and intra-pod traffic is relevant and outside the scope of outer layer encryption wrappers like VPNs and service mesh

So yes, your VPN protects packets moving across the wire, but it doesn't cover the cryptographic operations that need to happen inside the pod or container. So to avoid customer scrutiny and auditor red flags, leveraging FIPS-validated container images in tandem with your VPN is the way to go. 

“Wait, wait! What about my FIPS-Enabled Host OS”

This one is a throwback! Relying on a hardened, FIPS-enabled operating system can simplify a lot of compliance requirements and mandates from regulatory-sensitive customers. And it’s certainly true that hardened OS binaries often offer dual configuration: FIPS mode and non-FIPS mode.

With that said, enabling FIPS mode on a host does not force user-space applications to exclusively use those modules. Applications must be explicitly configured to use FIPS-validated cryptographic modules. If they use alternative or custom cryptography implementations, or if they bypass the system libraries, then they are likely not configured in accordance with NIST Guidance. As a result, cloud providers like GCP are explicit that customer applications including their own cryptographic implementations must independently integrate FIPS-validated modules. 

And perhaps even more frustrating is that relying on a FIPS-enabled host means that you have to accept a rigid dependence on a limited set of FIPS-enabled kernels, many of which are 5+ years old. 

That’s part of what makes Chainguard Containers so unique – every FIPS-validated image is kernel-independent, meaning that you can deploy our images on the latest hardware and kernels.

Learn More about FIPS!

Curious to discover more about Chainguard’s FIPS-validated containers? Get in touch with our team to learn more.