Earlier quoted context omitted.
Oh so it's not Counter Strike running in Docker. That makes much more sense.
My first guess was closed source :/
Or Computer Science, Creative Suite... so many things before I would think of 'Commercially-Supported".
Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
51–60 of 80 posts
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#52Earlier quoted context omitted.
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.
Disabling the docker hub certainly is.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#53Earlier quoted context omitted.
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.
Nope. If you get to the kernel it's game over.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#54Earlier quoted context omitted.
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 s…
If you manage so many hosts you had better use Ansible, or Satellite or whatever so that updating 1 or 50 or 500 hosts is the same effort.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#55thought Canonical is doing its own "docker", e.g. SNAP, lxd etc that are not totally identical but very similar to docker, what's going on here.
There's more than one type of container. Docker, and docker flavors (runc, rkt, etc). LXD is a machine container, it's the same technology that Docker was first built off of, but it's a hypervisor for really dense machines that are as light as process containers. Snaps is a package format that gives you a cross (linux) platform distribution, atomic updates, security, and isolation. It's not really like docker as it's…
Calling rkt and runc docker flavors is a bit misleading. Runc is an OCI standard container runtime which docker itself also uses. Although rkt can consume docker images it is an entirely different container runtime with several distinct execution stages. For instance, you can run rkt containers with an LKVM stage1 instead of systemd-nspawn.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#56Can OP or an admin de-abbreviate "CS" to "Commercially-Supported"?
Sure thing, we've updated the title.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#57Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#58Earlier quoted context omitted.
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…
I think this is the common solution. It definitely feels like a hack, though.
I thought of the ssh-agent trick, but never thought of how to actually do it and moved on to other problems.
I would love to hear thoughts on better ways to fix this. Apologies for not responding earlier, as I really want this conversation to end somewhere. I just feel ashamed that I don't know how to continue it.
I do want to throw out there that this should not keep folks from trying docker. Please try it. Even better, suggest ways to advance this use case.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#59Earlier quoted context omitted.
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.
Apologies for the slow response on this post. I would love to think of ways to fix this. I think most uses of docker today involve deploying applications that you do want completely sandboxed. And for those, this works rather well. Hopefully this doesn't keep you from trying it. (Indeed, you may have a nice solution to this that escaped me.)
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#60This 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).
Do not use Docker distributed by Red Hat, full stop. It has been irresponsibly patched to be insecure. They disable important seccomp filters.
Instead, install using instructions here: https://docs.docker.com/engine/installation/linux/centos/#/i...