Hacker News Reader

Comment by kbenson | Hacker News Reader

As a sibling noted, people do that. But disk space is cheap, and you aren't really losing much other than disk space for unused portions of the OS that are in a container, but what you gain is a normalized environment that's easy to develop for, test, and add to as needed.

View on HN

I understand this is easy for a developer, but I think it is not responsible security-wise: that container is a whole toolbox at the disposal of whoever may breach in it.

On top of this, as some sibling commenters were saying, it is a waste of bandwidth, time and disk space.

You think manually compiling all your libraries into a singular executable, or custom making your own minimal distro, is safer than using a minimal distro image from an actual OS distribution with security reviews, notifications about package updates, and easy patching, and where you can literally start a shell instance in the container and just check for updates to see if you have security issues? Good luck manually tracking all the security announcements for all the libraries and modules you used. You are doing that, given this is a conversation about security in containers, right?

If you aren't shipping setuid binaries in your container, even if someone gets a full shell in the container they are locked down by the container permissions and cgroup limitations, which is the whole point. That some extra utility or library exists but is not running that has an exploit is really not providing much of an attack vector. If an attacker can arbitrarily run something the fact that some code is on the system is not likely to really change their abilities, unless it's setuid, so get rid of that stuff.

There are many facets to security. I would not like someone to have shell access + bash, curl, awk, jq in a container that has full network access to sensitive systems in my applications both upstream and downstream.

As per the dependencies of important projects: yep, I read their release notes. And since I do no like to do it, I try to keep them to a minimum, unless it is a prototype or a research project.

I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to.

> I would not like someone to have shell access + bash, curl, awk, jq

Having an OS as the container doesn't mean shipping with everything. bash and awk are commnon, and curl might be for some as well since it may be a dependency for something else, buy jq won't be, as well as many other things (and often you have to include the few things I noted anyway, as many applications will call external items and strict exec use isn't always the norm).

> I get everyone has his sensibility, but please next time try to respect those who have a different attitude. Nobody attacked you or wants to.

Please consider that perhaps you're being a bit too sensitive, given this is a text medium and you can't hear my inflection.

I understand I may have sounded a bit facetious, but I was being honest there. It's a lot of work keeping up with dependencies, so good luck with that if you, I wouldn't want to do it myself, and if you are doing that, I'm always interested in hearing about ways in which people manage it[1]. It's directly relevant to my job. If you weren't doing that, then it was meant as a gentle note that hey, you really should be if you're concerned about security, because anyone that's statically compiling external requirements into a single binary and isn't has got much more to worry about then whether there's other utilities shipped in their container.

1: For example, I wrote https://news.ycombinator.com/item?id=36450815 just the other day, which is directly relevant to that idea.

If your container is big it also takes long time to fetch and start it

Alpine docker container starts at 5mb.

OP was arguing that today the big size doesn't matter, because disk space is cheap. I was providing argument that it still does.

Base image layers are deduplicated though. Now if only we could pick a single base image...

Alpine or Debian. Those are the only base images you ever need.

Specifically, Debian-slim. But even then, the versions are varied.

Theoretically that would work, in practice it doesn't.

Making distroless containers is the way to go.

You might be unnecessarily exposing attack surface by including unused binaries in your container.

Laptop SSD space for 100s of 1 GB containers is not cheap.

The ability to easily see and clear the amount of SSD space that images are wasting on my system is probably supposed to attract me to the proprietary Docker desktop application.

1 GB seems like someone is putting way more than a base OS in a container, and many of the cheapest laptops come with at least a 256GB SSD now (Dell will sell you one for $330).

A RHEL 9 universal base image, which you can add just the packages you need to, is 217MB.

And if you have hundreds of images on your system, maybe remove some you aren't using. I doubt you're using them all, and if you are using them all, they likely aren't using all the space you think they are because they're probably sharing layers.

I would suggest Alpine (5mb) or Debian Slim (<80mb) for base images. There's no need to add the overhead of RHEL inside containers, it really doesn't give you anything.

It gives consistency for those that use RHEL and derivatives outside containers, allows easy use of enterprise software aimed at that distro, and it allows tying into registries such as quay.io that will give you notes about when and what aspects of it are out of date (package wise).

I'm not saying to necessarily use it, but I wanted to pick something that was on the heavier end of the spectrum to forestall complaints about how for some people's workloads it's not realistic to run a 5MB alpine image given their work environment and needs.

Reply on news.ycombinator.com