Dotnet-docker: Provide distroless base image for dotnet core runtime dependencies.

Created on 11 Jul 2020  路  9Comments  路  Source: dotnet/dotnet-docker

The benefits of distroless base image for dotnet core is mainly for security.

  1. Well known base images introduce lots of unused binaries which may introduce security vulnerabilities.
  2. The distroless base image could only contain the minimum number of native binaries that's not linked or packaged by dotnet publish. And this base image will be very tiny in size.
  3. You can also consider to release another distroless image with dotnet core runtime built in.

Most helpful comment

An important distinction of distroless from Alpine is the availability of glibc (when using distroless/cc) for applications that use native libraries that expect to find debian libs. Alpine uses musl which is only partially compatible with glibc. In my experience this usually leads to recompiling from source which can be tricky if there are complex dependencies.

All 9 comments

@TonyDou - Can you explain the usage scenarios in which a distroless base image would be advantageous over using the Alpine based .NET image? Alpine is our smallest and most secure offering.

@TonyDou - Can you share your usage scenario?

Hi @MichaelSimons It's true that Alpine is already very small but it also contains binaries like sh that's not referenced or used by dotnet runtime. The request is more about security concerns not about image size. If we remove binaries in base image as much as possible, the potential security vulnerabilities will be fewer.

One is already provided by distroless repo
https://console.cloud.google.com/gcr/images/distroless/GLOBAL/dotnet/core/aspnet?gcrImageListsize=30

It would be better if the dotnet team maintains this so that we get the latest dotnet as well as the correct dependences for all features.

We've heard a couple requests for this but not a significant amount. Adding support for distroless images is a significant cost because it requires adopting a new tool chain. It is more work than adding images for an already supported distro.

We would like to hear from others who would find this useful and what their motivations are. We will close this issue in 30 days if we do not hear from a substantial number of users.

+1 for distroless, we run internet-faced pods in AKS. We use AAD Pod Identity(https://github.com/Azure/aad-pod-identity) to authenticate with Azure resources, such as SQL/Storage etc.

Brief introduction about AAD Pod Identity: You can bind Azure Identity to pod, in the pod any process can get the access token of binded Azure Identity by send get request to http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com/.

My concern is if a hacker exploits the web pods, he can gain the access token by shell/curl.

Also I would like to add that since we only have the essential so's, the rate of scanning alerts reduce a lot.
We don't need to use distroless, if you create a dotnet image from docker scratch image, you would get the same benefits.

Closing per the 30 day comment I made earlier. If you would find distroless images useful, please continue to share your scenario/comments.

An important distinction of distroless from Alpine is the availability of glibc (when using distroless/cc) for applications that use native libraries that expect to find debian libs. Alpine uses musl which is only partially compatible with glibc. In my experience this usually leads to recompiling from source which can be tricky if there are complex dependencies.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

galvesribeiro picture galvesribeiro  路  7Comments

deployable picture deployable  路  8Comments

twhittakeriq picture twhittakeriq  路  5Comments

agr picture agr  路  3Comments

MichaelSimons picture MichaelSimons  路  7Comments