Comment by merb | Hacker News Reader

Comment by merb | Hacker News Reader

without docker the software is even safer.

Actually for all people below, here are my reasons:

Docker adds another Layer. This also adds another attack target (docker). Saying a software is more secure while adding another layer is just naiv.

Docker is good for some companies and it definitiv is true that you can make it to run a PaaS, it's still not more secure as the world before.

Also some other people also pointed out other things. With docker you add a lot of complexity to your actual software, that is negligible if your big since you have a total different set of problems.

Still when it comes to docker it's mostly buzzword bingo. I mean just looking at the table... oh god it's like half the things there could just be done without docker in a way more secure way, without LXC, Docker or RKT.

Also I always tought that docker should make the deployment easier, which would be a hugh bonus in security since the process of understanding and everything beyond would be more understandable. however the more docker grows the worse the complexity gets. Docker once looked shiny but than the enterprise hit it and it's direction more and more makes it less secure since they try to add more and more stuff and stops focusing on the stuff docker was firstly invented.

How could adding a ton of abstraction (which grows every release) making something more secure? I just keep that as an open question to everybody.

This couldn't be further from the truth.

Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArmor, SELinux), and capability dropping.

These are all common sense security controls that aren't widely available because they're typically hard to use. Docker makes them defaults for everyone. This makes classes of remote attacks against applications far more difficult. Tangible example: read-only filesystems + mount namespacing make vulns that require filesystem modification or directory traversal far more difficult.

At this point arguing against running in Docker is like arguing in favor of IE6's security model instead of Chrome's.

Disclaimer: I manage security at Docker.

You guys are doing a great job! Some security-related sandboxing options to docker run that people may not be aware of, which are hard to assemble individually from Linux pieces:

  * --read-only
  * --security-opt="no-new-privileges"
  * --cap-drop=ALL
  * --net="none"
  * --cpu-period=
  * --cpu-quota=

Is it intended that the last two have nothing after the equal sign? If yes, what does that do?

There is also --pids-limit=<some number> against fork bombs.

EDIT - this git repo has more links to security related articles etc. https://github.com/wsargent/docker-cheat-sheet#security

I argue against using docker but simply due to the fact that docker encompasses too much when everything docker does could be accomplished by simple single use tools like unshared, cgexec, etc. Git does this and it works very well.

More detail on actual security issues (real CVE's) prevented just by using docker: https://docs.docker.com/engine/security/non-events/

Reply to the edited comment:

The reasoning that "more layers of abstraction necessarily equals less security" does not seem true to me. Granted, it increases the "surface area" that is exposed to attacks, and there's indeed a tradeoff involved, but this tradeoff may swing either way - either it does pay off or not.

Taking this reasoning to the extreme, there are plenty of abstractions that pay off for secutiry. One simple example is that software written in Java (for example) is by default more buffer-overflow-resistant than software written in C, due to managed memory/bounds-checking. In this case, the tradeoff was performance vs security.

> How could adding a ton of abstraction (which grows every release) making something more secure?

One example is the "buffer overflow resistence" in Java vs C mentioned above.

Actually we are a 100% Java Shop but the JVM has a lot of Bugs, Bugs that you won't have in C. Yes you can run into your own code smell, Bugs or whatever, but the same could happen on Java, too. The biggest problem with docker is the tone of stuff they try to put into. While most stuff is just possible without docker and the big abstraction. Hell you can start your programs under Linux with user namespaces just without docker.

Actually trust me it's way easier to control a single stack instead of managing a stack on top of another. Especially networking is no fun. Maybe it's cool and easy / shiny if you can have everything in the cloud, but that just won't apply to everybody.

> the JVM has a lot of Bugs, Bugs that you won't have in C

There will be different classes of bugs, of course, but I find it hard to believe that it will be more bugs, or more serious bugs, or most costly-to-fix bugs. Otherwise, your own company would have decided to use C instead of Java, right?

> Hell you can start your programs under Linux with user namespaces just without docker

Sure you can, but if Docker (or any other solution, for that matter) makes it easier or faster to do that, more people would do that. There's a more or less fixed number of work units to dedicate on a certain project, if you have to use them all to set up security solutions, your lunch will be eaten by other people.

> most stuff is just possible without docker and the big abstraction

Most stuff is "just possible" without any abstraction at all. However, one has to learn to leverage abstracted-away stuff, otherwise one will spend a lot of time and accomplish very little valuable stuff.

> trust me it's way easier to control a single stack instead of managing a stack on top of another

Easier does not equal safer, faster, or more business-valuable.

> it's cool and easy / shiny if you can have everything in the cloud

Not sure where "the cloud" enters the equation? You can use Docker (or whatever else) to manage even your on-premises stack.

---

I don't know the specifics of your situation at all, but if your only argument against a particular piece of tech is "it abstracts away stuff, therefore it is worse", you might want to consider some self-reflection on whether you're not just suffering of NIH Syndrome (https://en.wikipedia.org/wiki/Not_invented_here)

Why, exactly? The article's argument is that containerization limits the vulnerable area - even if an attacker gains root access to a container, they still can't do as much damage as they would had they gotten root access in a host machine.

I don't mean to sound adversarial - but what's your counterpoint to that?

Is that really true? I have always read that cgroups based containerization on Linux is kind of a joke and that root in the container more or less equals root on the host.

Has there been significant improvement in this area lately?

I'm not familiar with that perception, any good reads on that?

tends to be much older articles that had that perception, pre userns, seccomp, extended cgroup support etc.

The fix for that is user namespaces which is (finally) included in Docker. So yes, it has gotten better.

There isn't one. It's just a narrative regurgitated by people with an axe to grind. The anti-Docker crowd. User namespacing arrived in 1.10, which brought a lot of great possibilities for further compartmentalization with it. Alpine is the default base image. Lots of great, positive changes have gone into this blog post.

> Lots of great, positive changes have gone into this blog post.

I'm not sure I agree, I'd offer some improvements:

- Gartner "studies" are usually paid advertisements

- The comparison table is missing columns for DOM0/1 VM's and BSD jails

- Encryption in-transit or at-rest isn't mentioned

- Nothing about key management or key rotation

- Non-mutable / exported log files aren't in the defaults

Great points, we're working on a bunch of this stuff.

Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required.

Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system.

Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications.

In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.

How is the overlay network encrypted? I couldn't find any information. https://github.com/docker/docker/issues/24253 says it's not encrypted by default and must be enabled manually.

You're right -- it needs to be enabled manually using `--opt encrypted`. 1.13 is shooting for this to be the default.

The bundling of all your software's dependencies into your container means that you can't upgrade 1 .so on a machine, and all software be updated. Great example recently was libgcypt's security bugs.

You have to upgrade all containers, which requires figuring out which ones need upgrading.

The concern isn't generally that someone will escalate and then delete some other container's filesystem.. it's that once they get remote execution in a container that has connections to your database, http to your discovery service etc, they can steal your customer information.

I will say however that this post is showing that by using docker or frankly other well manicured execution enviroments, large swaths of attacks will hopefully not work (selinux & seccomp being great examples).

Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much.

The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.

I'm not sure I understand this.

Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?

Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...

Running a traditional relational DB inside a container is pretty stupid. It can take a while for those suckers to stop & start and they often don't work properly if placed behind a load balancer with random distribution of connections. Also, if a connection gets cut off in the middle of a transactions things can go very, very wrong.

On the other hand, if you architect your database usage in such a way as to ensure that cutoff transactions get detected and retried without relying on persistent connections it can be a good idea to use containers for hosting your database(s). Of course, your use case needs to fit this kind of model for it to work. If your use case requires mostly serial transactions and can't work with "eventual consistency" then containers are probably a no-go.

> We should build a new container after each apt-get for security patches, right?

Yes. That's the idea. Here's when and why you re-deploy:

    * A new, updated version of software/a package is out.
    * You've made changes to your app.  Even something as simple as a typo.
    * Your container has been up too long (e.g. 24 hours).

Replacing existing containers multiple times a day in a production environment is the norm. "The only constant is change" and the more often things change the more often you'll be swapping out your containers for new ones.

The whole point of containers is that they can be brought up and down in an instant without impact (if you architect things correctly). So even a VM that runs "apt-get update ; apt-get -y upgrade" every night may not be as up-to-date or secure as the same software running inside a container.

If you're using an image tagged "latest" (e.g. FROM ubuntu:latest), updates are already being pulled into your containers by default. Since containers are ephemeral, fixing security bugs can be as simple as just rebuilding and redeploying your containers.

That's a good point, for sure. But on the other hand, some upgrades may be delayed or left undone because more services depend on the same library, so the risk of breakage is higher. So, there's at least some incentive to using more recent versions, because there's less surface area to test.

Not sure how much this affects what's in the wild, though - I mean, I have no data to show that people really do tend to upgrade more often while containerized than not.

The important metric with patching vulnerabilities is time-to-patch. Docker based environments are able to significantly reduce time-to-patch precisely because the libs are bundled with the application. Most orgs have trouble rolling out patches to system libs because the testing matrix for rolling out patches mandates testing across the board for all application and system-level consumers of the lib. This can often take weeks or months. When the lib travels bundled with the app, just the app in isolation can be patched and rolled out immediately.

It is important to have an inventory so you can do patching across the board and have notifications that it's needed. This is why there are now a number of security scanners for Docker containers, including Docker's own: https://blog.docker.com/2016/05/docker-security-scanning/

Disclaimer: I manage security at Docker.

So it's the static/dynamic linking argument all over again.

Personally, as a sysadmin, I dislike docker. Not that there's anything wrong with its implementation in particular, but because I can no longer confidently say what is actually in our stack (we run 4 different versions of Python, last I checked -- it's absolute madness).

Now, I grant Docker's argument: if you're going to do something like that, Docker is pretty much the best way around to do it. Fair enough: it's the best available tourniquet for the self-inflicted wound of bad stack management. But to me, the ease of redeploying gets outweighed by the increased complexity of the security reasoning you have to do.

Reply on news.ycombinator.com