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.
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.
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.
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.
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.
Comments
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
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.
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.
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.
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.