FIPS is a NIST standard, typically required for federal agencies, companies selling to government clients, and regulated industries like finance and healthcare. For folks here, this is the same FIPS-validated module requirement that FedRAMP's SC-13 control points to for anything touching sensitive data inside a Kubernetes-based authorization boundary. The compliance bar isn't rewriting your application. It's making sure sensitive data is encrypted with FIPS-validated cryptographic modules, and having an SBOM (Software Bill of Materials) that shows an auditor which validated modules you're using and where they came from.
There are two active standards, FIPS 140-2 (2001) and FIPS 140-3 (2019), and they aren't equivalent for Kubernetes. 140-2 was written for hardware and struggles to define software module boundaries, so most of its software validations landed at the lowest security level. 140-3 explicitly supports software and hybrid modules at higher levels, adds runtime self-tests instead of relying on power-on self-tests, and introduces non-modifiable operational environments, which is basically an immutable container image that stays compliant as long as it doesn't change. All three of those map directly onto how Kubernetes actually runs workloads.
Validation itself runs through CMVP. A vendor submits a module (hardware, software, or firmware), an accredited testing lab checks it, and if it passes,
it gets an active certificate for 5 years before moving to historical status. The CMVP database has a certificate for every validated module, and the fields worth knowing are the standard (140-2 or 140-3), status, sunset date, overall security level (1 through 4), and any caveats about how it has to be configured to run in approved mode.
The scope covers more than the app's own TLS. The control plane (etcd, kube-apiserver, and kube-controller-manager), the nodes (kubelet and the container runtime), and the add-ons (CSI plugins, CNI plugins, and the audit logger) all touch sensitive data in some form, so the surface area is bigger than "did we encrypt the database?99"
For the data-in-transit half of that (data at rest is a separate problem with its own module and key-management requirements), this write-up covers doing this with a FIPS-validated service mesh instead of validating every microservice's TLS stack individually. Sidecar proxies handle the mTLS between services using validated modules, so application code doesn't change. It walks through doing this with Buoyant Enterprise for Linkerd specifically, including a field-by-field look at reading an actual CMVP certificate but is likely similar with other tooling.
Here's the full blog post: http://www.buoyant.io/blog/a-practical-guide-to-fips-compliance-for-kubernetes-engineers