A container is not a VM and should ONLY contain the exact files needed to run your app to run securely. Any additional packages increase the security footprint.

Every container is one RCE vulnerability away from being compromised and escaped. if your images are distribution based, even slim ones, you’re giving the attacker a broad set of tooling out of the box.

Container runtime defaults in Docker and Kubernetes are insecure and grant attackers a lot of privilege — running as UID 0, no user namespace separation, and potentially dangerous kernel capabilities added to the container’s parent process.

The problem is adding ONLY the exact files needed is currently impossible when building docker containers. If you are building go/rust executables this easy, you will get one executable you'll add. But if you need to pull in some dependency by a package manager you are lost, they will pull in so many dependencies you may not need but are not defined optional by the packages. A small container is really impossible.

No it's perfectly possible, but people are just lazy and/or don't understand their platforms.

Docker is for many a "simple" way of getting their app running, and once it's up, they never look back.

There are ways, but they aren't particularly obvious and are more work than they should. With some elbow grease involving multi-step builds, snapshots and diffing the resulting images to copy only the required files into your final image, you can definitely build them, at least.

It isn't made particular easy for you. Honestly it's actually kind of a pain, wherein lies the problem. Doesn't help that some languages' official images are kind of bloated themselves, either.

Is diffing images really necessary? I've done multi step builds in the past for a Java app and I didn't find it especially hard to only include what was required. E.g. the final resultant image would exclude maven, which would be used in the first stage of the build.

If you copy over files directly built by your build steps, sure, you don't really need diffing images, you know where things are. If you're trying to build a minimal image with some specific dependencies copied over that are the result of things you have less control over diffing is pretty much the only way to figure out what you need IME. E.g. you want to copy only the parts of dependencies you actually need.

Ah I see, thank you, that makes sense.

Multi Step Images will not help if you want to build a python container and the package manager will pull in e.b. Bash for the python runtime snd many more depencies. It only saves you from adding build tools to the image.

Just on a slight tangent, what are the security benefits of having a process run as a non-root user within a Docker container? It's obvious what the benefits are when running outside a container. Inside a container, on the other hand, there should only really be one important process running. That process will need to have access to all the interesting parts of the file system anyway, and being root inside a container doesn't let you do crazy superuser stuff like installing a kernel module.

If you don’t at least drop the sys_module cap, you can install a kernel module [0]. Running as root inside the container increases the risk of a breakout. I’ve seen different approaches at different companies. One bank required a hard-to-get security sign off that included MFA to start (so no automation). A different bank bought expensive monitoring tools and then threw a bunch of money at refining the outputs.

[0] https://blog.pentesteracademy.com/abusing-sys-module-capabil...

It does allow you to exit the boundaries of the application though, and e.g. extract the application's database.

That said, is it possible to disable superuser access entirely in a container? Can't login as root if there is no root.

Docker has a user namespacing feature which can be used to harden container images and also a newer way to run rootless altogether - https://docs.docker.com/engine/security/rootless/

If the application user has access to the database, it doesn't matter if you get access to root or not.

If you've got root on a container, depending on how it's configured, you can gain access to the host in some situations (eg. Using volumes)

But non-root users within the container can also access mounted volumes, no? Is there some kind of exploit that only works if running as root?

You can setuid root in a volume mounted in host. If that's executed at all by any user, bam you have root on the host.

If it's never executed, I don't know what vulnerabilities they were talking about.

Right, but it seems that wouldn't require the app within the Docker container to be running as root to work?

What a shitty concept. Typical Linux NIH (learn from zones jails lpar...no we need to reinvent the wheel in square format)

Linux namespaces are quite flexible and aren't used just for docker style containerization. In some use cases having a shared user namespace makes sense.

Docker just doesn't use the provided interface by default. Which is a shame because a lot of users don't bother or don't know they should bother to configure it.

I think that's kind of a 'we don't care about security' move by docker and given its userbase that's a real problem.

Hmm, i come from a Solaris/BSD background, Jailing (or containerize) a application was all about security, second manageability, and third re-usability. Kind of crazy that Docker ignored the most important thing in the Container-Concept (which can be, run un-trusted code on your trusted platform.)

Docker really is a power tool for developers, especially for freelancers needing to hop customer environments on their own notebook, and excels at that. The problem is the leap of pushing this guerilla tactics into running containers in prod. It's a result of the "move fast and break shit", web-scale, startup, and other agile narrative of the 2010s. And the industry has sure catered for these consumerisation of IT, with outlandish complexity in k8s, depressing oligopolization, and younger developers demanding such technologies to pad their resumes.

One of the most outraging thing i seen in the past: Docker-host as a VM (for security) i mean WTF!!

Exactly, many of these reports are of the kind "your java Web app container has a priv esc vuln in sudo" which is irrelevant 95% of the time. Need some smart tooling to help comb through all that noise.

I don't second that. If the java web app also has some privilege escalation, this allows somebody to overtake not only the container as root, but, given how Docker works, also to overtake the docker host as root!

Security matters, even if it is apparently about unused parts in a complex system.

> if the java web app also has some privilege escalation

If.

Of course "if": That's how security works. The most trivial mistakes are still made in 2020, such as SQL injections. Many people write horribly insecure code, because they were never trained on a security-oriented focus.

Story Time: At a customer I've once seen all (web) applications in their docker containerr running with root permissions. I raised an issue but the devops told me this would be fine. They simply did not care about security.

They run all their containers on two rented VPS. They dockerized everything, also their mail infrastructure, etc.. This means: If anybody found the easiest remote code execution bug in their webpages, they immediately could take over the whole fucking company. Because root in docker = root on the whole machine. Think about that twice.

For that I reason, I typically create my Docker images using Nix. This has been discussed here before a couple of times, for instance at https://news.ycombinator.com/item?id=22295102. :-)

if they were not launched why are they in the image to begin with?