Docker 1.3 is out

https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/

by jpdlla • 12 years ago

176 40 12 years ago

blog.docker.com

_mikz2• 12 years ago

What happened to the "release every first week of a month"?

micah_chatt2• 12 years ago

I'm guessing that would be a second dot release (1.3.1) monthly. If you look at the github milestones, it appears a dot release is scheduled for every 3 months. https://github.com/docker/docker/milestones

_mikz2• 12 years ago

from http://blog.docker.com/2014/02/docker-0-8-quality-new-builde...

"One release per month. Every first week of the month, we release a new version of Docker. For example, in the first week of March we will release 0.9."

looking at https://github.com/docker/docker/blob/master/CHANGELOG.md it does not fit very well

shykes6• 12 years ago

We moved the cadence to every other month, because packagers complained we were shipping too fast :)

hackerboos• 12 years ago

"You need more waterfall in your agile."

ewindisch3• 12 years ago

This includes critical security updates for boot2docker to resolve a RCE vulnerability. Docker itself containers a lower priority security update. Users, especially those of boot2docker, are highly encouraged to upgrade.

https://groups.google.com/forum/#!topic/docker-announce/aQoV...

McKayDavis• 12 years ago

Thank you for pointing this out!

For those wanting to avoid upgrading to a new boot2docker release you can patch the vulnerability with the following command from the boot2docker shell:

  sudo sed -i "s/DOCKER_TLS:=''/DOCKER_TLS:=auto/g" /etc/init.d/docker && sudo /etc/init.d/docker restart

This will enable TLS by default and restart the docker daemon. Note that this will also kill all of your running containers.

perlpimp• 12 years ago

hope 1.3 will be soon in the homebrew, we're migrating tomorrow to docker and all of our office is OSX. that is regarding new standard folder sharing feature.

whiteacid• 12 years ago

Looks like it's almost there https://github.com/Homebrew/homebrew/pull/33225

teacup503• 12 years ago

Your entire office is OS X and you're migrating to a Linux-only non-portable technology stack that requires a VM to run on your desktop?

Is this really cheaper and more effective than cleaning up your code base so that it doesn't require complete ownership of the host environment in order to run?

yazaddaruvala• 12 years ago

...maybe I'm confused... Is your premise that they will only run their application/service internally?

Normally what I've seen is, develop on OSX and then push to Heroku (Linux) / <infrastructure provider of choice, running a Linux VM>. Why then wouldn't the natural progression be, develop in boot2docker and push to <docker PASS of preference>?

vyshane2• 12 years ago

Why assume that they are using Docker because they have a portability problem?

They probably like OS X as a workstation OS, and want to use Docker for the DevOps benefits that they gain from it. boot2docker is just a lightweight solution for running Docker locally.

general_failure2• 12 years ago

What is the status of user namespaces? Is this not one of the core security problems with docker?

ewindisch3• 12 years ago

User namespaces will come. Patches are in progress and you can refer to github for the status of that effort.

I'd hesitate before calling it a "security problem" with Docker. It's a highly-requested security feature. The absence of it makes containers less secure, but does not make them vulnerable. There are use-cases for Docker without user namespaces, but user namespaces will make Docker better and will make containers more secure.

We do distinguish between the security of the Docker engine and the pieces of our ecosystem and the security of containers themselves. We seek to improve both.

Vulnerabilities such as the one fixed today in boot2docker 1.3 whereby either web browsers or containers may control the Docker daemon and perform remote code execution are serious issues in Docker itself and/or its ecosystem of products. Resolving such vulnerabilities is not, for me, less important than adding user namespaces.

general_failure2• 12 years ago

Totally agree. Do you have a link to the patch in progress? I would love to test them out.

wmf• 12 years ago

I dug into all the bug trackers to find the current status and it looks like user namespaces can be enabled once Go 1.4 is released in December.

valarauca1• 12 years ago

Still SSL problems. I remember reporting them last announcement, even emailing back and forth with docker... still not fixed. I sent another email.

ewindisch3• 12 years ago

Thank you. We will be updating the blog to support higher versions of TLS as well as to evaluate its cipher suite. It has taken longer than it should, and for that we apologize. It has not been forgotten or abandoned and will be resolved as promptly as possible.

Our other sites, including the Docker website and the Docker Hub already have relatively aggressive cipher suites and have disabled SSLv3, protecting it from POODLE.

ahmett• 12 years ago

Docker Remote API v1.15 is also out. But without a WHATSNEW section... https://docs.docker.com/reference/api/docker_remote_api/#ful...

calebm3• 12 years ago

Has anyone been able to get Mac host drive sharing working with boot2docker 1.3? I have not yet.

bfirsh• 12 years ago

Have you tried running "boot2docker upgrade" to get the latest image? If you're still having trouble email me at benf@docker.com

calebm3• 12 years ago

Actually, maybe I'm not on 1.3... I did do a "boot2docker upgrade", but when I do "boot2docker version", I'm still getting 1.2.0:

(py)cmbpr:~ caleb$ boot2docker upgrade Downloading boot2docker ISO image... Latest release is v1.3.0 Success: downloaded https://github.com/boot2docker/boot2docker/releases/download... to /Users/caleb/.boot2docker/boot2docker.iso Waiting for VM and Docker daemon to start... .............................. Started. Writing /Users/caleb/.docker/boot2docker-vm/ca.pem: Writing /Users/caleb/.docker/boot2docker-vm/cert.pem: Writing /Users/caleb/.docker/boot2docker-vm/key.pem:

To connect the Docker client to the Docker daemon, please set: export DOCKER_HOST=tcp://192.168.59.103:2376 export DOCKER_CERT_PATH=/Users/caleb/.docker/boot2docker-vm

(py)cmbpr:~ caleb$ boot2docker version Client version: v1.2.0 Git commit: a551732 (py)cmbpr:~ caleb$

smegel2• 12 years ago

our recommended approach of “one app per container.” Instead, we’re responding to users who’ve told us they sometimes need helper processes

Isn't it quite normal for an "app" to consist of multiple processes? Maybe a web server, app server, database system, message queue, object store, cron jobs and the like.

shykes6• 12 years ago

Yes, but often you are better off isolating these processes from each other, and only allow communication over the network.

Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.

pbiggar• 12 years ago

It seems like phrasing it as "one service per container" (with service being in the SOA sense), might be better.

Certainly, I think of an SOA app being composed of multiple services, and I'm pretty sure the thing you're suggesting that the thing you want one of in the container is what I'm calling a service.

smegel2• 12 years ago

Sure, if I was designing a production grade system I probably would isolate a lot of the services.

But I thought the whole idea of Docker was I could download something like a "Wordpress image" from the Docker marketplace, and it would just work in a self-contained way. Unless there is some higher level tool to download multiple Docker images for different apps and configure them together to provide a service of some kind.

cpuguy83• 12 years ago

It's not that a container can't run multiple processes, but Docker will itself only start one process. If you use, for instance, Apache with the forking MPM, this will work as expected (it'll work).

If you want to start multiple separate processes, then you'll need to use some sort of init system. This is not really any different than Linux itself.

shykes6• 12 years ago

Noteworthy features:

* Feature preview of digitally signed images

* Process injection with `docker exec`

* More flexible container lifecycle with `docker create`

* Shared directories on Mac OS X thanks to boot2docker

* Fine-grained security options

polvi• 12 years ago

As far as I can tell, the current implementation of signed images hardcodes the Docker, Inc cert-- effectively locking in users to only Docker, Inc's trusted images.

https://github.com/docker/docker/blob/master/trust/trusts.go...

Ideally docker users could sign their own images and provide their own keys to do signature validations. What is the timeline on this work? With out this, "digitally signed images" means "locked into Docker, Inc- otherwise no security", and is very misleading.

A very basic implementation would be to read certs out of a directory on the filesystem and is how all other package managers handle this.

Edit: I missed the part in the post that even if the signature fails, the container still runs. The signatures do nothing. Got it. Preview.

shykes6• 12 years ago

Absolutely, the full implementation will allow each user to sign with their own keys, and provide user-configurable trust rules ("allow images only signed by this key"). The Docker CA will be used as a default convenience to provide a common namespace if you want it, but users who want to use their own custom PKI will have all the flags to do that, and there will be an "escape hatch" to opt out of the entire trust infrastructure altogether.

The only reason we're starting with verification-only, and only for images produced by the official library maintainers, is because the other side of the tools (signing) are not yet ready to be merged in Docker. By releasing a subset now, we can start getting some feedback and ironing out the quirks, while the contributors finish their work on the signing tools, using the library maintainers as guinea pigs. Hope this helps.

PS. to state the obvious, all of this is taking place in the open on #docker-dev in Freenode. It is being designed by key contributors from multiple companies, and you are welcome to join the fun.

vyshane2• 12 years ago

Congratulations on the new release!

I can already see that `docker exec` and `docker create` will allow me to get rid of a number of admin and configurator containers.

When I started playing around with boot2docker, I was gagging for the ability to share directories with OS X. However, it turns out that I didn't really need that once I realised that caching means that building images is very fast.

shykes6• 12 years ago

Yeah, build caching makes it much more practical to rebuild in many cases. But there are still some workflows where even waiting a few seconds is too long - most commonly when you're writing frontend code and want to just refresh the browser every time you edit a line of css.

Docker 1.3 is out

Related Stories