Why non-root containers

[Andrew Latham]

I really need to understand the use case for non-root containers.

I am assuming that either

1. The software is checking for user

2. The software needs to be a specific user

3. Mapping volume to a user inside the container instead of with the container tooling.

Please school me on what the use-case is because I am interested.

[Brian de Alwis]

This article summarizes some of the reasons:

https://cloud.google.com/solutions/best-practices-for-operating-containers#avoid_running_as_root

Seems to be a logical extension of the trends in *nix systems of containing apps and daemons as separate users rather than running as root.

Brian.

--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/3498dd66-24d2-4b1d-8528-e91501e80bc6%40googlegroups.com.

[Evan Jones]

I am not a security expert. I've seen this advice in a couple different places, and it does make some sense: you might as well have multiple layers of security in place. If your program doesn't need root privileges even inside the container, don't give it to them. Given that part of the reason to use Distroless is to have less "attack surface", if this recommendation is valid, it seems to me that "secure by default" would be a good policy? In my limited experience: most containerized applications do not need root credentials.

I did a quick survey of Kubernetes Dockerfile images using github search: https://github.com/search?q=org%3Akubernetes+distroless+language%3ADockerfile&type=Code

Here are some that explicitly switch to USER nobody or nonroot:

kube-state-metrics: https://github.com/kubernetes/kube-state-metrics/blob/111c95ac200404aee140af9ff97c7f833e5dd087/Dockerfile

kubeadm: https://github.com/kubernetes/kubeadm/blob/004aff411a9fe0ba1fce9c8990680ef6f5251325/operator/Dockerfile

Here are some that do not. Unclear to me if this is because they need to, or because someone didn't think of it:

cluster-autoscaler: https://github.com/kubernetes/autoscaler/blob/14126d736dbbbadba4605228e3d840d3fa884210/cluster-autoscaler/Dockerfile

admission-controller: https://github.com/kubernetes/autoscaler/blob/ec67e905845f44cd45af8d2d92a3ac89daee402b/vertical-pod-autoscaler/pkg/admission-controller/Dockerfile

On Tuesday, October 29, 2019 at 7:14:14 AM UTC-4, Brian de Alwis wrote:

This article summarizes some of the reasons:

https://cloud.google.com/solutions/best-practices-for-operating-containers#avoid_running_as_root

Seems to be a logical extension of the trends in *nix systems of containing apps and daemons as separate users rather than running as root.

Brian.

On Oct 27, 2019, at 12:01 PM, Andrew Latham <lat...@gmail.com> wrote:

I really need to understand the use case for non-root containers.

I am assuming that either

1. The software is checking for user

2. The software needs to be a specific user

3. Mapping volume to a user inside the container instead of with the container tooling.

Please school me on what the use-case is because I am interested.

--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to distrole...@googlegroups.com.

[Evan Jones]

To revisit this thread, a recent example from this week shows the value of running as non-root by default [1] "if your container is run with a non-root user, you are protected. Even if an attacker compromised your container, he cannot overwrite the container’s libnss libraries as they are owned by root, and therefore cannot exploit the vulnerability". 

[1] https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/