Ask HN: How secure is it to run open source software in Docker containers? | Hacker News Reader

Ask HN: How secure is it to run open source software in Docker containers?

4 pointsTekMol5 comments

Like me, some of you will have learned their lesson about trusting software via a message on your screen that said

    Something wonderful has happened Your AMIGA is alive !!! and, even better... 

    Some of your disks are infected by a VIRUS !!!

Now 30 years later, our software stack is so much more complex with each piece of open source software being composed of countless other pieces by developers from all around the world and all walks of life.

How does everybody protect their host OS from all that untrusted code when you try a piece of open source software?

Is it reasonably secure to run it in a Docker container?

View on HN

Containerization is only meant for isolation (preventing accidental contamination), not security (thwarting malicious code). If you are looking for security, virtualization is better (although there are virtualization escape exploits in the wild), and isolated bare metal is best.

I hear conflicting voices about this.

On the one hand, the statement "containers are not made for security" is made often.

On the other hand, a lot of work seems to go into the issue of "container escapes": https://www.google.com/search?q=%22container%20escape%22

And going through these results, all of these escapes seem to need privileged containers that are run with the "--privileged" flag.

Isn't that a sign that normal containers are pretty secure? Otherwise, why would all the escapes need special containers started with a flag that actively gives them permissions to access the host?

Of course we all want containers to be more secure because that would give us more bang for the buck on installed iron if we have better security guarantees that shift the risk assessment for deployment.

But I doubt that containers will ever be as secure as virtualization, nor will virtualization be as secure as a separate machine.

In the end it comes down to your risk appetite.

Dunno. IBM has solid isolation at the hardware level on their P-series frames. It can be yours for more money than non-bigCorp entities would even joke about spending on hardware to back their project.

The attempts to emulate their success in consumer systems is laudable but, at the same time, laughable. VTx came on the scene as the Solution, but it's riding on the same silicon as the parts that need to be protected.

Cgroups targeted job isolation to help resolve binpacking vs dependency stacks vs unhelpful (in this context) dynamic linking conundrums. Docker came on the scene with all of its dev-experience cheer leading.

(royal) We know how to solve the problem. We just will never fork over the kind of money that makes having the solution currently requires.

Use the tools that are available to do the job in front of you. There efforts to bubble up redhat's pod an ecosystem (point being they don't require root privs to run) but its interface still feels like configuring middleware.

If you have all the modern (on by default) side-channel mitigations on, it's a pretty safe isolation barrier. Not being able to f with your drives & see your data is a pretty enormous win. Set some cpu & mem limits. Im not sure what the default behaviors are but there s likely still things like a docker0 bridge, & many of your services are probably exposed there. You can change your services, you can change yoyr container networking, or you can live with letting containers see your local services. I think i general how secure you want your network to be is one of the most interesting/harder things to be certain about.

I have a hard time thinking what the remaining risks are. Certainly you could give the container too many permissions or give it access or network you shouldnt. In general, I feel like we've gotten quite good at preventing break-out attacks.

Reply on news.ycombinator.com