David Lawrence

Introducing Image Signing Policy in Docker Datacenter

David Lawrence

My colleague Ying Li and I recently blogged about Securing the Software Supply Chain and drew the analogy between traditional physical supply chains and the creation, building, and deployment involved in a software supply chain. We believe that a software pipeline that can be verified at every stage is an important step in raising the security bar for all software, and we didn’t stop at simply presenting the idea.

Software Supply Chain

Integrated Content Trust and Image Signing Policy

In the recent release of Docker Datacenter,  we announced a new feature that starts to brings these security capabilities together along the software supply chain. Built on Notary, a signing infrastructure based on The Update Framework (TUF), along with Docker Content Trust (DCT), an integration of the Notary toolchain into the Docker client, DDC now allows administrators to set up signing policies that prevent untrusted content from being deployed.

In this release of DDC, the Docker Trusted Registry (DTR) now also ships with integrated Notary services. This means you’re ready to start using DCT and the new Signing Policy features out of the box! No separate server and database to install, configure and connect to the registry.

DTR replicas

Bringing it all together

Image signing is important for image creators to provide a proof of origin and verification through a digital signature of that image. Because an image is built in layers and passes through many different stages and is touched by different systems and teams, the ability to tie this together with a central policy ensures a greater level of application security.

In the web UI under settings, the admin can enable Content Trust to enforce that only signed images can be deployed to the DDC managed cluster. As part of that configuration, the admin can also select which signatures are required in order for that image to be deployed.

Docker Datacenter

The configuration screen prompts the admin to select any number of teams from which a signature is required. A team in DDC can be defined as automated systems (Build / CI) or people in your organization.

The diagram below shows a sample workflow where the Content Trust Settings are required to check for CI and QA.

  • Stage 1: Developer checks in code and kicks of an integration test. Code passes CI and automatically triggers a new image build, signature and push to Docker Trusted Registry (DTR).
  • Stage 2: QA team pulls image from DTR, performs additional testing and once completed (and passes), signs and pushes the image to DTR
  • Stage 3: Release engineering goes to deploy the image to the production cluster. Since the Content Trust setting requires a signature from both CI and QA, DDC will check the image for both signatures and since they exist (in our example) will deploy the container.

Docker Content Trust

We are excited to introduce this feature to our enterprise users to increase the security of their software supply chain and add a level of automated enforcement of policies that can be set up centrally.  As applications scale and teams grow, these features help provide assurances with proof of content origin, safe transport and that the approval gates have been met before deploying to production.

Download the free 30 day evaluation of Docker Datacenter to get started today.

Learn More

Continue reading...

Be the first to write a comment.

Leave a Reply