You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. 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
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered:
gesarki
changed the title
Request: Please make FIPS 140-2 compliant images available #1191
Request: Please make FIPS 140-2 compliant images available
Apr 6, 2024
I would be interested in what is not fips compliant currently just to get an idea of what the changes would look like, a quick peak I see in argocd they added this. It also seems to me that distroless would have a smaller surface area than the AWS image so I feel that is slightly backwards is distrolless FIPS compliant? Maybe it needs to use this gcr.io/distroless/base-nossl-debian12. I am open to exploring how invasive the changes would end up being though, and possibly include something upstream.
Maybe it needs to use this gcr.io/distroless/base-nossl-debian12
I don't think that's strictly necessary -- the systems just have to use FIPS verified crypto libraries, they can still have other crypto libraries available that aren't used.
I am open to exploring how invasive the changes would end up being though
As far as I can tell, per my Workflows comment, this requires building with GOEXPERIMENT=boringcrypto or similar. It may require that a FIPS verified crypto library like BoringCrypto also exist in the image if it's dynamically linked.
and possibly include something upstream.
And for reference, if it requires a flagged, non-standard build that we can't default to, I recommended an automated, unofficial builds repo. But up to you what you think is best for Rollouts. We could potentially have one unofficial builds repo for all 4 core Argo projects.
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. 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:
Thank you for your time considering this request as well as your efforts supporting this project!
Acquia KaaS Core Services team
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered: