I still have some questions about CoreOS. (Actual questions, not doubts).
When you say that CoreOS auto-updating would patch things like OpenSSL vulnerabilities without any intervention (as the founder said on The Changelog), that just doesn't add up to me.
Say, I have CoreOS, and an nginx docker image running (based on an Ubuntu 14.04 image).
If I have an OpenSSL vulnerability and CoreOS says they auto-patched my server, great. They patched the host. But that doesn't mean the openssl library in my nginx image is patched, right? So most of the manual patching (rebuilding the docker image, etc) and responding to these kinds of things is still an issue, isn't it? I might be missing something here that involves the union FS, etc.
Correct -- the base OS would auto-update, but with how it works today, you would still need to upgrade your own containers.
I don't believe this problem of updating dependencies in containers will last forever -- its pretty reasonable that you could mark some dependency as "auto-updatable" in your own container -- then when there is an OpenSSL issue, the base container OS is upgraded, and your app restarted.
The owner of the application stack is not always (rarely?) the owner of the host os / vm. While your container may remain vulnerable it's the application owners responsibility (and capability) to update the application stack. In CoreOS security issues at the host level not only don't require manual admin intervention, but don't even require admin knowledge that there is a security issue or how to solve it to begin with. The CoreOS deployments do all that work for you. It's even reasonable for non root application maintainers to have permission to do reboots. Immediately and simply removing a HUGE workload for admins. Plus it alleviates any concern as to how good your admins are at managing security updates.
In past OpenSSL security issues many servers could not be patched because of complicated application interaction. With the CoreOS architecture these issues are mitigated on multiple levels.
The old way:
VM + Package Manager + application executables = single host system with unknown os and application security issues that are interrelated and may break when patched. Security patches must be known and correctly applied by the admin. Security breach at the application level is equal to full system compromise.
The CoreOS way:
CoreOS host/vm + Docker + container = isolated fire breaks and a pristine host. It isn't possible to contaminate the host, all applications and application environments are in containers. The os can safely upgrade on reboot as soon as patches are available without regard for application deployments. Security breach at the application level is isolated to the container, and require additional exploits to escape the container. And of corse kernel level security patches are inherited by all containers.
You could apply the CoreOS philosophy to an Ubuntu host for example, but since you are not prohibited from running apt-get at some point on an Ubuntu host the odds of contaminating the host is very high unless you do all the homework of locking out such mistakes.
Add to this the CoreOS features (integrated etcd, fleet, docker, systemd, small foot print), and you have a server OS that takes full advantage of what docker enables on the host and application sides.
(In my opinion of course. And just to be clear, I am not an employee of CoreOS. I'm genuinely very excited about CoreOS, and use it exclusively as our server OS of choice.)
This post is from last year. I've been using these images on GCE for testing and they work well. Works particularly nicely for getting a Deis PaaS up and running quickly.
When you say that CoreOS auto-updating would patch things like OpenSSL vulnerabilities without any intervention (as the founder said on The Changelog), that just doesn't add up to me.
Say, I have CoreOS, and an nginx docker image running (based on an Ubuntu 14.04 image).
If I have an OpenSSL vulnerability and CoreOS says they auto-patched my server, great. They patched the host. But that doesn't mean the openssl library in my nginx image is patched, right? So most of the manual patching (rebuilding the docker image, etc) and responding to these kinds of things is still an issue, isn't it? I might be missing something here that involves the union FS, etc.
Would appreciate a clarification on that.