Request: Please make FIPS 140-2 compliant images available

[gesarki]

What would you like to be added: FIPS 140-2 compliant images

Why is this needed: At Acquia we’re currently using this component as part of our globally distributed Kubernetes infrastructure.

Like most providers, we expend a lot of effort ensuring that we remain compliant with varied regulatory regimes across different localities. Currently we're working towards FIPS compliance which is required by federal institutions like healthcare, banking, and defense organizations to set cryptographic standards for highly sensitive data.

The FIPS 140-2 encryption compliance requirement poses a common problem that is likely to be shared by any organizations looking to obtain a FEDRAMP certification and which use a myriad of OSS Kubernetes components under the hood.

FIPS compliance stands as a barrier to entry for smaller organizations. Accepting our contribution would take a small step towards lowering that barrier for the general public and other open source projects.

We, and any other cloud based software providers that are building atop Kubernetes, would benefit from the availability of off-the-shelf FIPS-compliant variants of this project’s images.

While many tools exist to tweak deployment manifests, it can be complex and fragile to rebuild upstream images with constraints placed on encryption libraries. This type of change would be far easier to make inside the originating repo.

Internally, we have explored several paths forward to achieve our compliance objectives. We are hoping to be able to contribute the required changes upstream in a way that benefits the community at large and minimizes toil.

Initially, we are requesting that the current maintainers and community consider supporting FIPS images of metrics-server. We have a notional approach to contribute and would like to collaborate.

Please let us know your thoughts in this Issue or by reaching out directly.

At this time, we have an internal approach that we are using on our internal Go-based controllers and other container images. There are some basic requirements that we’d ask to be built into a -fips variant including assertions that could live in the upstream build steps or in later CI steps.

What we do internally is:

• Image is built with a FIPS library such as boringcrypto for Go
• Image is based on Amazon Linux 2, Canonical Ubuntu 20.04 or later, or UBI8
• Image has appropriate group and user specified and final image executes in that context
• We assert that binaries call out to boringcrypto via dynamic linking (this is recommended during build but is not required, we will verify this ourselves in our CI/CD infra)

Thank you for your time considering this request as well as your efforts supporting this project!

Acquia KaaS Core Services team

/kind feature

[logicalhan]

/assign @dgrisonnet /triage accepted

[dgrisonnet]

From what I've seen in general, upstream is not very interested in FIPS compliance and it is usually expected to be the responsibility of vendors who want to obtain FEDRAMP. So I would take a similar stance and avoid increasing our responsibilities.

Linking to https://github.com/kubernetes/kubernetes/issues/109666#issuecomment-1109715374 so you can see Kubernetes stance.

[imuni4fun]

@dgrisonnet thank you for your response.

I can appreciate the additional burden that adding certification and supporting testing can impose.

In this case, we are hoping to contribute a very small change that would enable this capability, namely using boringcrypto Go experiment when building. It would not add additional testing requirements or attestation as we can do these things in our own downstream deployment repos much more easily.

Not having this feature upstream would require additional maintenance burden as we'd have to maintain a fork, rebase new work, and do additional integration testing beyond our deployment repo's testing. We believe that it makes a lot more sense for us to contribute to upstream for the many OSS components we need to update so that we have less overhead and the various other consumers can benefit as well.

To reiterate, we are asking to contribute and support this change upstream so that more parties can benefit while we also have reduced overhead. We feel this is a win-win and are hoping to find a way to make this contribution. We hope you might reconsider 😄

[dgrisonnet]

It would not add additional testing requirements or attestation as we can do these things in our own downstream deployment repos much more easily.

Anything that we provide to our users in metrics-server needs to be thoroughly tested here, otherwise when we go through a release cycle we can't guarantee that we have not broken a feature that our users rely on.

Not having this feature upstream would require additional maintenance burden as we'd have to maintain a fork, rebase new work, and do additional integration testing beyond our deployment repo's testing.

You have to understand that by adding that feature upstream you are essentially putting that maintenance burden onto us maintainers as we would then be fully responsible for it.

Considering that this is a corporate specific feature, I feel like it should be downstream only. Imagine what it would be like for us if we had to be responsible for the security compliance from all the different countries / certification authorities.

Forking a project and keeping it up-to-date is usually the minimum expectation towards company that want to productize open-source projects. Speaking for myself, even though I am a maintainer here, my company is still maintaining a fork of the project for corporate specific needs.