I don't mean to sound adversarial - but what's your counterpoint to that?
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).
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.
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?
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.
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).
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.
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.
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.
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.
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
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.
Has there been significant improvement in this area lately?