News for hackers. Stuff that matters.
Re:Dockerfile Best Practices by KronisLV on Sunday January 03, 2021 @06:01AM (#25621056)
But that's the thing - if so many projects are using these bad practices, then doesn't that mean that there's something fishy going on i.e. it's difficult to do things the "proper" way and therefore most people simply don't? Why must we follow these best practices at all - why aren't they simply the default way of doing things, e.g. having to specify a user for the process in the container to run, instead of defaulting to root?

For example, look at SSL/TLS certificates - before Let's Encrypt ( https://letsencrypt.org/ ) and tools like either Certbot ( https://certbot.eff.org/ ) or even web servers like Caddy ( https://caddyserver.com/ ) which automate both provisioning and renewing certificates, people used to simply run HTTP. But now, it's easier than ever to use them for transport level security, and the stats seem to vaguely back this up, for example: https://www.welivesecurity.com/2018/09/03/majority-worlds-to...

Why should users inside of containers be any different? What are the factors that prevent safe defaults from being implemented? That's what i don't understand.

Disclaimer: i'm not advocating for running things as root, but rather my claim is that if things are hard to do, they simply won't be done unless absolutely necessary. Any tech vendor should acknowledge this and make sure that doing things the "right way" is as easy as possible.

Re:Dockerfile Best Practices by kortex on Sunday January 03, 2021 @12:36PM (#25623284)
I think the fishiness is exactly what your intuition is pointing to: root is easy, "proper" is not. There are very few applications where you need true root at runtime, and most can get by with correctly configured user space.

The issue is complexity and lack of appropriate abstractions.

The "Let's Encrypt" of dockerfile safety would be something that makes it trivial to 1) create a user 2) chmod/chown an appropriate spot on the fs, 3) ideally let the author defer these actions to always finalize the image in user mode. That way, you declare at the top that you will do these user actions, but RUN stays as root. Or just provide an SRUN, SCOPY,SADD directive which acts like running with sudo. Then, you can easily extend a layer or base image without being concerned with the details of how user space is implemented.

Also there is no standard or idiomatic protocol for setting up user space in a dockerfile.