Skip to content

base: Make -debian10 images default to nonroot user#414

Closed
evanj wants to merge 1 commit intoGoogleContainerTools:masterfrom
evanj:debian10-nonroot-default
Closed

base: Make -debian10 images default to nonroot user#414
evanj wants to merge 1 commit intoGoogleContainerTools:masterfrom
evanj:debian10-nonroot-default

Conversation

@evanj
Copy link
Copy Markdown
Contributor

@evanj evanj commented Oct 12, 2019

Fixes #374.

Running as a non-root user inside a container provides some additional
security. For example, the runc container escape would not work for
non-root users:

https://aws.amazon.com/blogs/compute/anatomy-of-cve-2019-5736-a-runc-container-escape/

The existing Distroless images need to default to a root user for
compatibility. However, the introduction of -debian10 images gives us
an opportunity to break backwards compatibility, since users will need
to opt-in to the update anyway.

Running as a non-root user inside a container provides some additional
security. For example, the runc container escape would not work for
non-root users:

https://aws.amazon.com/blogs/compute/anatomy-of-cve-2019-5736-a-runc-container-escape/

The existing Distroless images need to default to a root user for
compatibility. However, the introduction of -debian10 images gives us
an opportunity to break backwards compatibility, since users will need
to opt-in to the update anyway.
@googlebot googlebot added the cla: yes CLAs look good label Oct 12, 2019
@evanj
Copy link
Copy Markdown
Contributor Author

evanj commented Oct 12, 2019

I recognize that this is a potentially controversial change, so it could make sense to reject it. This fixes #374

@donmccasland
Copy link
Copy Markdown
Member

Any chance we can get on a call tomorrow to talk me through this change?

@evanj
Copy link
Copy Markdown
Contributor Author

evanj commented Oct 14, 2019

Sure; I'm also not attached to this change and am happy to walk away from it. This just came up in discussion on #368; Since the debian10 switch somewhat breaks compatibility anyway, I figured this would be a good chance to introduce this sort of change if we want do. Email me at evan.jones@bluecore.com if you want to arrange a call?

@chanseokoh
Copy link
Copy Markdown
Member

@evanj not making any meaningful point, but I've read the doc you linked for my own curiosity, and my understanding is that the vulnerability can still be exploited when running an image as non-root inside the container, since runc runs and will continue to run as root. The doc mentions some ways to prevent the vulnerability, but I don't see running as non-root is one of them. OTOH, the user namespace mapping is one way to prevent it.

@evanj
Copy link
Copy Markdown
Contributor Author

evanj commented Oct 15, 2019

Upon further review: it appears you may be correct! I am far from an expert in this stuff. I just know that a lot of the "best practices" guides suggest setting a non-root user. If that really is "best practice" then we should make that easy? E.g. https://www.weave.works/blog/kubernetes-best-practices and Google's guide https://cloud.google.com/solutions/best-practices-for-operating-containers#avoid_running_as_root

My understanding is that distroless added the nobody and nonroot users on behalf of people working on Kubernetes. We could check with them before making a decision?

@chanseokoh
Copy link
Copy Markdown
Member

I personally would like to see Distroless switch to use nonroot by default. It is indeed a very good practice, if not best. I remember @mattmoor also said it is unfortunate nonroot wasn't the default at the beginning of this repo.

nobody and nonroot were added by Kubernetes and Knative folks, and now that Kubernetes are now using Distroless in a bunch of places, and I also wonder what they feel about switching to nonroot by default for the next Debian 10 Distroless, breaking compatibility. @thockin @dprotaso @jonjohnsonjr

@yashbhutwala
Copy link
Copy Markdown

+1 to this initiative! Any updates on consensus to this, from k8s community as well as here?

@dprotaso
Copy link
Copy Markdown
Contributor

@chanseokoh Knative is good - we use nonroot images already :)

@bootstraponline
Copy link
Copy Markdown

I think running nonroot by default makes sense.

@sdake
Copy link
Copy Markdown

sdake commented Jun 20, 2020

@evanj I believe for all of Istio's distroless-based images, non-root defaults should be fine. The images in which we run as root, require root, and are not based upon distroless at this time.

Where we face a challenge: Istio's sidecar injection requires root privileges for some parts of the sidecar. We are moving our injection to CNI - such that root on the host is required to run iptables, rather than root within the container.

This model is expensive to implement, but for serious projects, a really sound technical approach.

Please see: istio/istio#24815 (comment) for more details on one of many of the pieces of work that need to complete in Istio to support nonroot defaults. But please, don't let us stop you or slow you down, I, personally, want to see this change happen and think its a great change.

Cheers,
-steve

@dlorenc dlorenc closed this Apr 9, 2021
@dlorenc dlorenc deleted the branch GoogleContainerTools:master April 9, 2021 18:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes CLAs look good

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider having the default distroless tags use non-root user by default

9 participants