Scott Johnston

Docker 1.3: signed images, process injection, security options, Mac shared directories

Scott Johnston


Today we’re pleased to announce the availability of Docker Engine 1.3.  With over 750 commits from 45 contributors, this release includes new capabilities as well as lots of quality enhancements.  You can get more details in the release notes, but we’ll highlight four of the new features here.

Tech Preview: Digital Signature Verification

First up, in this release, the Docker Engine will now automatically verify the provenance and integrity of all Official Repos using digital signatures. Official Repos are Docker images curated and optimized by the Docker community to be the best building blocks for assembling distributed applications.  A valid signature provides an added level of trust by indicating that the Official Repo image has not been tampered with.

With Official Repos representing one out of every five downloads from the Docker Hub Registry, this cryptographic verification will provide users with an additional assurance of security. Furthermore, it represents the first of several features we’ll be shipping in the coming months for both publishers and consumers of repos, features that will support publisher authentication, image integrity and authorization, PKI management, and more.  Watch this space.

Note that this feature is still work in progress: for now, if an official image is corrupted or tampered with, Docker will issue a warning but will not prevent it from running. And non-official images are not verified either. This will change in future versions as we harden the code and iron out the inevitable usability quirks. Until then, please don’t rely on this feature for serious security, just yet.

Inject new processes with docker exec

Next, when developing an application, you sometimes need to look at it while it’s running.  A number of tools, like nsinit and nsenter, have sprung up to help developers debug their Dockerized apps, but these are additional tools to find, learn, and manage.  Similarly, some users have taken to running an init process to spawn sshd along with their app to allow them access, which creates risk and overhead.

To make debugging easier, we’re introducing docker exec, which allows a user to spawn a process inside their Docker container via the Docker API and CLI.  For example…

$ docker exec -it ubuntu_bash bash

…will create a new Bash session inside the container ubuntu_bash.

To be clear, by providing this we’re not changing our recommended approach of “one app per container.”  Instead, we’re responding to users who’ve told us they sometimes need helper processes around the app. That’s what `docker exec` is about.

Tune container lifecycles with docker create

The docker run <image name> command creates a container and spawns a process to run it.  Many users have asked to break this apart for finer-grained management of their container lifecycles.  The docker create command makes this possible.  So for example…

$ docker create -t -i fedora bash

…creates a writable container layer (and prints the container’s ID to STDOUT), but doesn’t run it.  You could then do the following… 

$ docker start -a -i 6d8af538ec5

…to run the container.  That is, docker create gives the user and/or process supervisors the flexibility to use the docker start and docker stop CLI commands to manage the container’s lifecycle.

Security Options

With this release we’ve added a new flag to the CLI, --security-opt,  that allows users to set custom SELinux and AppArmor labels and profiles.  For example, suppose you had a policy that allowed a container process to listen only on Apache ports.  Assuming you had defined this policy in svirt_apache, you could apply it to the container as follows:

$ docker run --security-opt label:type:svirt_apache -i -t centos \ bash

One of benefits of this feature is that users will be able to run docker-in-docker without having to use docker run --privileged on those kernels supporting SELinux or AppArmor.  Not giving the running container all the host access and rights as --privileged significantly reduces the surface area of potential threats.

boot2docker: Shared directories on Mac OS X

Using Docker on Mac OS X has become much easier since we incorporated boot2docker, but the experience has had some usability quirks. With this release we are addressing the most common issue: sharing directories between your Mac and your containers. Using Docker 1.3 with the corresponding version of boot2docker, host-mounted volumes now work the way you expect them to.

For example, this command:

$ docker run -v /Users/bob/myapp/src:/src [...]

Will mount the directory /Users/bob/myapp/src from your Mac into the container. This makes it much easier to use Docker for a continuous development flow, where you benefit from a predictable containerized development environment, but don’t want to rebuild a new container every time you change a line in your source code. If you are using Fig for your development workflow, for example, the benefits are immediately obvious.

Note that there are still some limitations: for example this feature is limited to boot2docker’s virtualbox configuration, cannot be managed dynamically, and only works for directories in /Users . But we are receiving exciting contributions to improve volume management, so expect this area to improve drastically in the next few releases.

Many thanks to all 45 contributors who participated in this release.  In particular, we’d like to give shout-outs to @burke, @duglin, @hugoduncan, @rhatdan, @tianon, @vbatts, and to release captain, @crosbymichael.  Thanks everyone!

We hope the above gives a glimpse into Docker Engine 1.3.  For more details, please check-out the GitHub 1.3 milestone issues and pull requests. We look forward to your feedback!

Happy hacking,

– The Docker Team

Learn More

“Identity Penguin” cartoon by Laurel.


15 thoughts on “Docker 1.3: signed images, process injection, security options, Mac shared directories

  1. Thumbs up for docker exec!

  2. Riccardo Forina

    Amazing stuff!

    Just a note, running `docker exec centos -it bash` doesn’t work. Tried it both on bash and zsh.

    The -it should come before the image name, like in `docker exec -it centos bash`. Docs get it wrong too (

  3. It’s a good upgrade release!

  4. I just started using boot2docker and noticed no -v option. Excellent!

  5. docker exec doesn’t create a fully functional terminal?

    example, to attach to an nginx container to tail the access log:

    docker exec -it nginx bash
    less /var/log/nginx/access.log
    WARNING: terminal is not fully functional

    This works fine when using nsenter

  6. Really appreciating the Mac shared directories support – makes things much much easier for us! Thank you.

  7. Mac shared directories are indeed a life-saver, they make Docker work perfectly.
    I cannot find a similar thing for boot2docker/Windows – is this available and I just don’t know it?

    How do you share host files on Windows? You still need to do smb shares? I was under the impression that samba is slow, can anyone share their experiences?

  8. In newer versions of Docker (1.8) they introduced DOCKER_CONTENT_TRUST environment variable which enables Docker Content Trust which integrates The Update Framework (TUF) into Docker using Notary, an open source tool that provides trust over any content.
    More info at

Leave a Reply