Open mthalman opened 1 year ago
FIPS-enabled .NET images
Could you elaborate on the scope of FIPS-enabled images? Is it just about using a set of FIPS-verified Ubuntu packages for these container images? Is there anything being done on the .NET side to verify that FIPS is enabled, FIPS-required restrictions are in effect and .NET continues to work for all the normal use cases (eg, SDK commands work, applications can be built and run)?
Effectively it is just adding the FIPS version of OpenSSL to the image and everything else remains the same. .NET can seamlessly work with that OpenSSL library just as it does with the non-FIPS version. So there's no special logic needed in .NET for this. There will need to be some level of testing to verify scenarios.
Thanks!
This work requires the ACR Caching feature which is currently in preview. The preview release doesn't support using an ACR as the upstream source which is what would be required for this work. So this work is blocked until that's supported.
We have a need to produce FIPS-enabled .NET images for customers based on Ubuntu. This process is described in Create FIPS-enabled Ubuntu container images with 10-year security updates.
Because an Ubuntu Advantage subscription is required for the production and use of these images, they would need to be published to a registry requiring authenticated access and not be publicly available from MAR.
Currently the only FIPS-enabled dependency .NET has is OpenSSL. But to be comprehensive in our implementation, we would install all .NET dependencies with the FIPS feed in scope:
Implementation Notes
Dockerfile
This would be representative of what would be in the runtime-deps Dockerfile. The rest of the Dockerfiles would be effectively the same.
Image Builder
Image Builder needs to be updated to include additional options in order to specify the path to the subscription secret that the Dockerfile would then consume:
Image Caching
Because the published images will not be installed in a public registry, it throws a wrench into the image caching system. Image caching relies on the digest value stored in image info file. This value gets generated assuming the image will end up publicly in MAR. Example: https://github.com/dotnet/versions/blob/090c295f2ba11a24417c1695867ebc08daa24f8d/build-info/docker/image-info.dotnet-dotnet-docker-main.json#L4145. But that wouldn't be the case for these images. It would require a different registry and one which required authenticated access. Work has already been started on addressing this for a similar scenario at https://github.com/dotnet/dotnet-docker/issues/4139.
One option is to not support image caching in our pipeline at all for these images. In that case, there are some potential ways to do that:
imageBuilder.pathArgs
variable to appropriately filter what gets built. Since that variable is inclusive-only, we'd have to be very explicit about what paths get included. If there was a variable that provided a way to exclude paths, that would be better.