A Secure Supply Chain for Kubernetes, Part 2

Mar 15 2018

Two weeks ago we shared how the upcoming release of Docker Enterprise Edition (Docker EE) is able to secure the software supply chain for Kubernetes; just as it does for Docker Swarm through a combination of scanning for vulnerabilities and implementing image promotion policies. In this blog, we’ll take a closer look at another part of this solution – Docker Content Trust and image signing.

When combined with granular Role Based Access Controls [RBAC] and the secure clustering features of Docker EE, organizations get a secure container platform solution that is ready for the enterprise.

Restricting Unverified Kubernetes Content

As discussed in Part 1 of this blog post, organizations typically have a “supply chain” for how applications progress from a developer’s laptop to production, whether that is on-premises or in the cloud. For larger organizations, the team that handles QA and testing is not always the same team that develops the applications. There may also be a separate team that handles staging and pre-production before an application is pushed to production. Since an application can pass through several teams before it gets deployed, it’s important for organizations to be able to validate the source of the application.

Docker Content Trust is a way for individuals and teams to add private cryptographic signatures to an image, adding a digital signature that helps to ensure proof-of-origin, authenticity and provenance for images. With Docker EE, you can ensure that the images being deployed are the ones you trust and haven’t been altered either in the image registry or on their way from the image registry to your environment by choosing to only run signed images:

In the context of Kubernetes, this means that Docker EE will prevent any workloads from being deployed on the cluster if the underlying images used have not been signed by members of specific teams.

This can be used to enforce image signing at certain stages of your supply chain: when the developer checks in the initial image, when the QA team has completed testing, when the security and networking team has reviewed the app, etc. If an image has missed any of the required signatures, Docker EE will prevent it from being deployed. This allows operations teams to prevent unauthorized content from being deployed into Kubernetes.

Integration of Docker Content Trust to Your Automated Workflow

Image signing does not have to come from an individual or team. It can also be extended to authorized 3rd party tools to indicate that the image build came from an approved workflow. Docker EE makes this simple by giving you the ability to create and manage client bundles within the Docker EE UI. Docker EE creates a keypair that can be used by Continuous Integration (CI) tools like Jenkins or GitLab to sign images as they are created and added to the repository. Learn more about using trusted images with Jenkins here.

Docker EE helps you deliver safer applications by securing your software supply chain. No matter what type of applications you are containerizing (legacy, cloud native, or microservices), the stack it is built for (Windows or Linux), or where it will be deployed (on-prem or the cloud), image vulnerability scanning, automated image promotions, and image signing all give you the ability to enforce a common workflow for the governance and automation of your application delivery process.

 Learn more about Docker Enterprise Edition with Kubernetes integration:


2 thoughts on “A Secure Supply Chain for Kubernetes, Part 2

  1. Avatar for Jenny Fong

    Chirag Shroff


    Is this statement a typo ? "Docker Content Trust is a way for individuals and teams to add private cryptographic keys to an image,"

    I surely hope so..Private keys are just that. They need to be kept private on some hardware security module and never be part of an image.

    With that a follow up question: Is there an ability to make sure that signing can happen with private keys in HSM ?

    • Yes – you caught a typo – that should be "signatures" and not "keys". I went ahead and fixed that. As for HSM, no – that's not currently supported, but we do support YubiKey 4 for root keys.

Leave a Reply