Hacker News new | ask | show | jobs
by sgnnseven 2073 days ago
Solid post though there are a couple of things I would disagree with:

> Do not upgrade your system packages

Most distros will have smooth upgrades and provide you with patched libs that your app may need and the latest image may not provide. It's slightly more prone to breaks but it creates a less vulnerable runtime app env.

> Do not use ‘latest’ tag for base image

Depends on the org but sometimes pinning means that you will likely end up using and end-of-life image because it requires proactive work to maintain. If you leave it as 'latest' this won't happen but you will get out-of-band breaks to keep that working. Choose wisely.

A few things I would add too:

- Don't mount Docker socket into any container unless absolutely necessary

- Your biggest security threat will be from your app's dependencies, not the container's setup

- Do not run a full init system unless absolutely necessary as this is just a security disaster waiting to happen. There are valid use cases for it but they're rare.

1 comments

Can you explain your last point further please?
“Full” init systems tend to need to do things that are hard to secure in a container.

Many must run as root, and the reasons not to do that are discussed in the article this HN thread is discussing.

Systemd is particularly tricky because it needs to be able to control the cgroups of its child processes, which means the container needs to be granted that capability. See https://developers.redhat.com/blog/2019/04/24/how-to-run-sys... about how to run systemd in a container via Podman, and is a follow up to https://developers.redhat.com/blog/2016/09/13/running-system... which discusses why the Docker case is even more difficult.

That said, if you just want a process supervisor for a multi process container, there are several more minimal init systems that will work well, for example, supervisord.

Thanks for the response