Hacker News Reader

Comment by drinchev | Hacker News Reader

Imagine you have 20 services that need to run with your website ( 5 database daemons, 5 nodejs apps, 5 ngnix instances, 2 dns servers, 2 mail smtpd daemons, 1 git repository ).

Your infrastructure consists of 5+ virtual servers that host your services. Each virtual server might be database only or db + dns or web + dns or ... you got the point.

What docker allows you to do is to isolate all those 20 services in separate containers that if any of them is being hacked your attacker will end up compromising only that service without any access to the main server.

What docker allows you to do is to version control the configuration and the container for the different services in a way that if you need to reinstall a service ( redeploy your app ) it is less of a hassle and since it is containeraized you will not be compromising your other services while doing that.

etc.

View on HN

Maybe I misunderstood GP's question, but what you describe has been done with countless other solutions for years, why should I specifically use docker and not stay with kvm, or bsd jails, or...?

At least in the case of KVM, it's a very heavy-weight solution. Hardware virtualisation takes more RAM, and the I/O is substantially lower. I think hardware virtualisation (e.g. KVM) should only be used when the use-case demands it (e.g. Windows, OS development, or legacy applications).

As for why Docker? Dunno. While I think illumos zones are pretty awesome myself, having a standardised format is handy. Docker is also popularising the container mantra with Linux.

> What docker allows you to do is to isolate all those 20 services in separate containers that if any of them is being hacked your attacker will end up compromising only that service without any access to the main server.

Except that: containers share the same kernel. If a contained application is hijacked with a privilege escalation vulnerability, all running containers and the host are compromised. Also, several resources are not namespaced. Nothing with a shared kernel is going to be very secure.

Malicious container can easily compromise a vulnerable host OS, and an already compromised host OS completely owns the container. This is no different from the failed experiments in sandboxing on PCs.

Can your container share a Linux instance with containers from other customers in the cloud? Not with any confidence, no. Containers do not contain: http://opensource.com/business/14/7/docker-security-selinux

Have the Docker developers changed their stance that they don't promise that Docker can safely untrusted programs running as root? (https://news.ycombinator.com/item?id=7910117)

Well most certainly container to host escalation is possible, but if you play your cards well enough it is highly unlikely.

From the security section [1] :

> Your average server (bare metal or virtual machine) needs to run a bunch of processes as root. Those typically include SSH, cron, syslogd; hardware management tools (e.g., load modules), network configuration tools (e.g., to handle DHCP, WPA, or VPNs), and much more. A container is very different, because almost all of those tasks are handled by the infrastructure around the container ...

> This means that in most cases, containers will not need "real" root privileges at all. And therefore, containers can run with a reduced capability set; meaning that "root" within a container has much less privileges than the real "root". For instance, it is possible to ...

> This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host ...

[1] : https://docs.docker.com/articles/security/

Cool thanks. So while you still need to take the same steps to provide security as you would on a physical (or virtual host), Docker gives you the added benefit of a smaller attack surface.

To add to bildung's comment, what many of us are wondering is given all the existing tools and complexity, why add another integration point?

In the scenario you're describing where you're provisioning virtual machines in a cloud, shuffling docker containers around on a fleet of VMs may not be the way to go. Many people would use some combination of disk images and configuration management to achieve the same ends.

So you have 20 containers each running their own version of the OS? Don't you have to spend a lot of time keeping all of those up to date with OS/library/app updates?

It seems like the kind of thing that makes sense if you have a big deployment anyway, so you might as well hive stuff off, but makes much less sense if you're a "small" shop.

No. The containers share the same OS.

Can you make changes in the underlying OS image, and those changes are directly visible in the application images, without restarting said applications?

What happens is you'd rearchitect (if needed) your stack so that it scales across N-nodes (for each tier). Then docker build files & snapshotting features allow you to 'recompose' the image from a base OS, one step of which is to apply all patches.

So when you are performing patching, you'd bring a container into service with the updated patches, send some traffic to it (possibly tightly controlled to minimise disruption), verify and then put into production. Iterate through your N-nodes per tier and you've patched. Every container after the first is rapidly started up (just the cost of a supervisor/init & the application process).

Reply on news.ycombinator.com