Can OP or an admin de-abbreviate "CS" to "Commercially-Supported"?
Oh so it's not Counter Strike running in Docker. That makes much more sense.
My first guess was closed source :/
Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
31–40 of 80 posts
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#32Earlier quoted context omitted.
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…
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 temporary directory, copies in the necessary identity files from ~, and does a docker run that maps those identify files into the docker image.
After the docker image exits, the bash invocation script cleans up.
It's a hack, but it works surprisingly well. In my tests, it adds about 100ms of invocation latency for a python program. That is, running the docker image containing a python program that copies some files in as described is about 100ms slower than just running the same python program directly.
It would be nice to have a more elegant solution to this, but it's not too bad.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#33Earlier quoted context omitted.
As I read this again I'm quite confused what this announcement means. The mention of snap package makes it seems like "apt-get install docker..." would be a separate binary. A wild guess would be that 99% of Ubuntu users will never buy CS Docker Engine so will that 99% of users be running the debian/ubuntu packaged docker.io binary that exists today?
I think Docker through snap is still free, they'll just sell support.
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.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#34Earlier quoted context omitted.
Center for Internet Security Docker Benchmark, rule 1.5: Keep Docker up to date [1] [1] https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1...
"Keep a tab on these product updates and upgrade as frequently as when new security vulnerabilities are fixed." https://www.docker.com/docker-cve-database
Backports. I saw Docker break more than once after supposedly stable releases with security fixes.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#35Earlier quoted context omitted.
I think Docker through snap is still free, they'll just sell support.
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.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#36Earlier quoted context omitted.
> without the VM overhead or the VM security
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.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#37Earlier quoted context omitted.
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.
I think it's better for someone from the Canonical/Snap team to comment on that. I'll ask them to comment.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#38Don't be confused. CS Docker Engine is not the public available Docker Engine: https://docs.docker.com/cs-engine/install/
Can anyone enumerate the differences between this and the public Docker Engine?
Does it just have a different release process/QA process to allow for more stable use in deploy environments bundled with a support contract?
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#39Earlier quoted context omitted.
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.
LXD supports using different id maps per container, which mitigates some of that.
I get that containers will always have a larger attack surface than Xen/KVM. Just thought it was worth mentioning that some container approaches are thinking about security more than others.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#40Earlier quoted context omitted.
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 same vein, there are plenty of Xen machines that are vulnerable despite the host OS being updated (which, honestly, I don't thing happens as quickly as it should considering it requires a restart for new kernel params). With things like live-patching, updating the kernel once, while running, makes sure all guests are also updated as well.
It's a trade off, but one that seems to trend towards more secure despite potentially a few quirks.