I'm worried about Docker living up to its valuation, and I haven't seen the business model that will meet the expectation of their valuation long-term yet.
They have built a great open source product, but now that there has been a collective shift to understanding the benefits of containers, the docker runtime + container format will/should be commoditized by infrastructure companies (Google, RedHat, MS etc).
So where is the value-add of Docker the company going to come from?
An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You…
This is well stated. I have been making end-user apps for myself and for folks at work that require such identity, in one case, ~/.ssh, and in another, ~/.gnupg. My solution isn't particularly novel or clever, but it works well. The docker image of the command-line app is the same for all users, and so lacks their identity built in. The hack is to drive invocation of the docker image with a shell script that makes a…
disclaimer: I am not a security expert. Reader beware!
If you're using ssh-agent, maybe you could bind-mount your host's $(dirname $SSH_AUTH_SOCK) into the container, and then set the SSH_AUTH_SOCK environment variable to point at it when you run the Docker container. That way you're not even sharing the private key with the container.
I imagine you could do the same with gpg-agent, too.
Correct. At a not so distant future point, Docker will be delivered as a snap package. Users installing docker via `apt-get` will ultimately be installing the snap. We are working through the final technical details of this portion now. We'll make sure to keep everyone updated as this transition happens, but current best practices should continue to Just Work.
i had a quick question - do you see a convergence of Flatpak and snap at some point ? because it seems that RedHat and Fedora are beginning another divergence on static packaging.
Actually, there's quite a bit of cross-distro compatibility around Snaps. Beyond Ubuntu, Snaps are known to work in Arch Linux, Debian, Gentoo, Fedora, openSUSE, Yocto, and OpenWRT. Snaps simply require a modern systemd and snapd daemons. With the appropriate SELinux profiles and an updated snapd, it's entirely feasible for the same docker.snap to run on both Ubuntu and Fedora (as well as others). You can learn more about Snaps and Linux distributions at snapcraft.io.
I'm worried about Docker living up to its valuation, and I haven't seen the business model that will meet the expectation of their valuation long-term yet. They have built a great open source product, but now that there has been a collective shift to understanding the benefits of containers, the docker runtime + container format will/should be commoditized by infrastructure companies (Google, RedHat, MS etc). So wher…
Depending on your use case, that may not be such a great idea. Unless Red Hat have back-ported it, 1.10 misses several important security advances that have come into Docker in recent versions...
Redhat also has a lot of security features not in upstream docker due to docker, inc not accepting them: Source: https://github.com/projectatomic/docker/tree/410e23a7eeb52d4...
That seccomp patch reduces rather than increases security. None of the others, other than back ports, are security features.
LXD does at least (unlike docker) default to unprivileged containers
Any local kernel vulnerability will let you attack other containers on the same machine. This is a much bigger attack surface than Xen or KVM. It's nice in that it gives the same experience as "traditional" hypervisors (at least the basic features), but it's only applicable if you trust that the application inside the container will not be compromised.
On the flip side, when there is a kernel vulnerability, there's only 1 kernel to update! If you're running the Canonical Livepatch Service, for instance, critical security vulnerabilities are patch in real time, without reboot, and all containers running immediately benefit from the patch. Conversely, if you're running 50 Linux Xen or KVM machines, you have 51 kernels to update. So yeah, do think about what "attack surface" actually means, when comparing LXD and Full Virtualization.
This is well stated. I have been making end-user apps for myself and for folks at work that require such identity, in one case, ~/.ssh, and in another, ~/.gnupg. My solution isn't particularly novel or clever, but it works well. The docker image of the command-line app is the same for all users, and so lacks their identity built in. The hack is to drive invocation of the docker image with a shell script that makes a…
disclaimer: I am not a security expert. Reader beware! If you're using ssh-agent, maybe you could bind-mount your host's $(dirname $SSH_AUTH_SOCK) into the container, and then set the SSH_AUTH_SOCK environment variable to point at it when you run the Docker container. That way you're not even sharing the private key with the container. I imagine you could do the same with gpg-agent, too.
I didn't think about that, thanks!
I didn't mention it, but for one of the apps, I also needed ~/.gitconfig, which I don't think has an agent. :(
i had a quick question - do you see a convergence of Flatpak and snap at some point ? because it seems that RedHat and Fedora are beginning another divergence on static packaging.
Actually, there's quite a bit of cross-distro compatibility around Snaps. Beyond Ubuntu, Snaps are known to work in Arch Linux, Debian, Gentoo, Fedora, openSUSE, Yocto, and OpenWRT. Snaps simply require a modern systemd and snapd daemons. With the appropriate SELinux profiles and an updated snapd, it's entirely feasible for the same docker.snap to run on both Ubuntu and Fedora (as well as others). You can learn more…
It would be great if there was a cohesive roadmap showing how Snaps fit in with Canonical's overall strategy wrt System and Application containers across Cloud and Embedded systems.
Lots of little "islets", not so much an "archipelago".
What do you mean by sanely sharing users in the container?
An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You…
I see.
This is an interesting problem, and I would think one that a lot of people are experiencing.
Seems like an area of opportunity to make docker images a lot more flexible.
This makes me feel good about going with CentOS for Docker. Red Hat has a custom, stable Docker version which is rock-solid (albeit somewhat old, 1.10).
Red Hat has a vested interest in the failure of Docker. So... It's up to you if you want to continue using (or trusting!) any "Docker" software released by Red Hat.