Docker image for microsoft/go

[arinto]

Where we can find the docker image for microsoft/go?

Something similar to FROM us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.17.2b7 in Go+BoringCrypto.

[dagood]

You can find our images/tags on MCR with this API:

• https://mcr.microsoft.com/v2/oss/go/microsoft/golang/tags/list
• Docker tag: mcr.microsoft.com/{name}:{tag}

This project is new, so you might hit some rough edges. The images on MCR are also not really set up for general public use. (Some MCR tags are available to browse on Docker Hub, like .NET's images--our Go tags aren't.) We're planning to open the GitHub repository we use to build these images so it's at least more obvious how we assemble them, though.

You mentioned boring in particular, so FYI: the *-fips-* images use the microsoft/dev.boringcrypto* branches on this repo, which are based on the golang/go boring branches but with patches to use OpenSSL crypto instead of Boring. This helps with FIPS compliance--but it's important to note they aren't FIPS certified.

Could you tell us a little about how you're planning to use these images? We're really curious. 😄

[arinto]

We're evaluating the options to enable FIPS compliance in our Golang app. (which is packaged as a container running on top of Amazon Linux on Fargate).

And I believe this fork is a valid option (assuming the underlying OpenSSL crypto is FIPS validated). 😄

So the end game in my mind is: the Docker image for this project is capable to build a Golang application (i.e binary) that is FIPS compliant. The FIPS compliant is achieved by building the binary against FIPS-validated-OpenSSL-library.

Let me know your thought whether that use case make sense or not. 😄

[arinto]

Ah, found this repo: https://github.com/microsoft/go-crypto-openssl which contains the actual implementation (of replacing built-in crypto package with OpenSSL-based crypto package).

Do you have end-to-end example from build, execute and validate the Golang binary/app for FIPS Compliance? The validation part is on how we can be sure that we're using FIPS-validated-OpenSSL-library.

[dagood]

We're evaluating the options to enable FIPS compliance in our Golang app. (which is packaged as a container running on top of Amazon Linux on Fargate).

And I believe this fork is a valid option (assuming the underlying OpenSSL crypto is FIPS validated). 😄

This makes sense to me. 🙂 I found https://github.com/aws/containers-roadmap/issues/659 that suggests Fargate container hosts may not be FIPS compliant, but I'm far from an authority on AWS. Container scenarios are definitely something we want this fork to support.

So the end game in my mind is: the Docker image for this project is capable to build a Golang application (i.e binary) that is FIPS compliant. The FIPS compliant is achieved by building the binary against FIPS-validated-OpenSSL-library.

Yep. I think the best way to use the image is as a "builder" stage in a multi-stage Dockerfile. That way, you can throw away the Go toolset and have a smaller app image.

One clarification: the builder stage doesn't actually have to compile against FIPS-compliant OpenSSL. The OpenSSL library is loaded in with dlopen, so all you need is a FIPS-compliant OpenSSL present in the final image.

Do you have end-to-end example from build, execute and validate the Golang binary/app for FIPS Compliance?

No, we haven't gone through this entire process through to certification yet. Validation is complicated--there's the basics that automation can catch, and things that it can't. More about that at https://github.com/microsoft/go/issues/428.

---

We have a couple more docs here with more details about how our implementation works, and some notes about FIPS: https://github.com/microsoft/go/tree/microsoft/main/eng/doc/fips https://github.com/microsoft/go/tree/microsoft/main/eng/doc/fips/UserGuide.md