Support non-root containers

[dasMulli]

In order to comply with "restricted" pod security standards ("Heavily restricted policy, following current Pod hardening best practices.") or restrictive PodSecurityProfiles (deprecated k8s feature), it should be possible to product containers that:

• Runs as non-root account
• Binds to ports > 1024 - it may work on some container runtimes / kubernetes setups to run non-root containers binding to low ports but for compatibility, higher port numbers should be used

Having strict Pod Admission policies (or PSPs) in place is an ask of the CIS Kubernetes Benchmark as well and is - in my experience - typically a requirement of operating kubernetes environments in governmental organizations or companies with high security requirements.

The .NET SDKs should allow for easy publishing of containers adhering to these configuration pracices and either

• default to non-root containers
• have an option (-p:PublishProfile=UnprivilegedContainer or other MSBuild property) to opt into this type of configuration

[mthalman]

This ties into the proposal of non-root-capable container images at dotnet/designs#271. That proposal is for .NET 8. Were those images to exist, I think it would be appropriate for there to be some means to tell the SDK "build me a container image that sets the default user to the non-root user provided by the .NET base image". In the absence of those images, or for pre-.NET 8, then I think explicitly creating the non-root user makes sense. In either case, it's probably best to coordinate with that design proposal to ensure a consistent experience is provided.

cc @richlander

[IvanJosipovic]

Here is a doc that explains what is required to run rootless, https://techcommunity.microsoft.com/t5/azure-developer-community-blog/hardening-an-asp-net-container-running-on-kubernetes/ba-p/2542224

[ThorstenHans]

IMO, this needs way more attention and better communication into the developer community. Numerous environments will flag those images because they run in root context.

Upfront communication would ensure teams can act before their images get rejected.

Although, the initial announcement here mentions this fact, I would also expect that docs in this repo (ContainerCustomization.md) outline the limitation

[baronfel]

I think the primary thing that is blocking this repo from supporting rootless containers is

• explicit binding of port 80 (which upon further reflection we could remove or make conditional in some way), and
• unclear handling of base-image user and group permissions on the Layers that we generate. Right now we are not setting ownership information on the Tar file and directory entries that we generate in the layers. I am unclear what kind of behavior this creates - if the user (if any) of the base layer inherits these files, or if they are given 0:0 user and group ids. we should check this

In either case, we do want to support this, and it should just be a matter of time. Of course we'd also accept any and all help from the community to get there faster!