search

argoproj / argo-workflows

Workflow Engine for Kubernetes
https://argo-workflows.readthedocs.io/
Apache License 2.0
15k stars 3.2k forks source link

Make FIPS 140-2 compliant images available #12903

Closed gesarki closed 2 months ago

gesarki commented 6 months ago

Summary

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 workflow-controller, argoexec and argocli. 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:

Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.

blkperl commented 6 months ago

Note there is discussion occurring in https://github.com/argoproj/argo-rollouts/issues/3508 as well

agilgur5 commented 6 months ago
  • Image is based on Amazon Linux 2, Canonical Ubuntu 20.04 or later, or UBI8

Did you mean the container image? This would dramatically increase your surface area compared to the distroless builds that Argo uses, as Zach mentioned in https://github.com/argoproj/argo-rollouts/issues/3508#issuecomment-2045413944

If you mean your AMI, that's out-of-scope for Argo.

  • Image has appropriate group and user specified and final image executes in that context

Is there a problem with the current container image?

  • Image is built with a FIPS library such as boringcrypto for Go

Per https://kupczynski.info/posts/fips-golang/, the simplest way to do this appears to be to use the GOEXPERIMENT=boringcrypto flag.

As that's an experimental build, we wouldn't be able to use that by default. As such, I'd probably recommend the same route as I did for RISC-V (https://github.com/argoproj/argo-workflows/pull/12067#issuecomment-1783603520) and ppc64le architectures (https://github.com/argoproj/argo-workflows/issues/12449#issuecomment-1876257479). We can host an automated, unofficial builds repo in argoproj-labs that does all of the above.

github-actions[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity and needs more information. It will be closed if no further activity occurs.

github-actions[bot] commented 2 months ago

This issue has been closed due to inactivity and lack of information. If you still encounter this issue, please add the requested information and re-open.