{"id":43157,"date":"2020-10-14T00:00:00","date_gmt":"2020-10-14T00:00:00","guid":{"rendered":"https:\/\/www.trendmicro.com\/en_us\/devops\/20\/j\/what-is-docker-content-trust.html"},"modified":"2020-10-14T00:00:00","modified_gmt":"2020-10-14T00:00:00","slug":"what-is-docker-content-trust-and-how-do-you-secure-it","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/what-is-docker-content-trust-and-how-do-you-secure-it\/","title":{"rendered":"What is Docker Content Trust and How do You Secure It?"},"content":{"rendered":"

<\/p>\n

By Brandon Niemczyk (Security Researcher)<\/strong><\/p>\n

\u201cCan they be trusted?\u201d One of the primary security problems one must solve in a container-based system is validating that your images are correct and came from the correct source (or maliciously manipulated). One of our security predictions<\/a> for 2020 discussed how malicious container images \u2014 if trusted \u2014 could have a detrimental effect on the enterprise pipeline. We have reported on attacks that involved the abuse of container images to carry out malicious activities such as scanning for vulnerable servers<\/a> and cryptocurrency mining<\/a>.<\/p>\n

To help solve this, Docker provides a feature called \u201cContent Trust.\u201d It allows users to deploy images to a cluster or swarm confidently and verify that they are the images you expect them to be. What the Docker Content Trust (DCT) does not do is monitor your images across the swarm for changes or anything of that nature. It is strictly a one-time check done by the Docker client, not the server<\/strong>.<\/p>\n

This has implications for the usefulness of DCT as a full-on integrity monitoring system. In a previous post by my colleague Magno on cloud-native systems<\/a>, he mentioned using image-signing tools such as Notary<\/a> to solve the question, \u201ccan they be trusted?\u201d DCT is an attempt at providing built-in tools for Docker clients to do just that.<\/p>\n

This article will cover four areas:<\/p>\n

    \n
  1. How DCT works<\/li>\n
  2. How to enable DCT<\/li>\n
  3. What steps can be taken to automate trust validation in the continuous integration and continuous deployment (CI\/CD) pipeline<\/li>\n
  4. What are the limitations of the system<\/li>\n<\/ol>\n

    An additional goal of this article is to provide a singular in-place tutorial on getting up and running with experimenting on DCT, especially since the existing documents appear to be spread out and not centralized.<\/p>\n

    How does Docker Content Trust (DCT) work?<\/strong><\/h3>\n

    At its core, Docker Content Trust is very simple. It is logic inside the Docker client that can verify images you pull or deploy from a registry server, signed on a Docker Notary server of your choosing.<\/p>\n

    The Docker Notary tool allows publishers to digitally sign their collections while users get to verify the integrity of the content they pull. Through The Update Framework (TUF)<\/a>, Notary users can provide trust over arbitrary collections of data and manage the operations necessary to ensure freshness of content. If you have not used a Notary server before, check out Docker’s introductory guide<\/a>.<\/p>\n

    The graphic in Figure 1 shows how deploying a Docker swarm or Docker build \u2013pull allows the client to talk to the registry server to get the required images and the Notary server to see how they were signed. If you have the correct environment variables setup, it will fail to deploy unsigned images. The signing can be done on a different machine so that private keys do not need to be stored on the Docker management node used in deployment.<\/p>\n

    Figure 1. The Docker client can communicate with the registry server and Notary server<\/p>\n

    Enabling DCT<\/strong><\/h3>\n

    By default, DCT is disabled. We need to do a few things to set it up so that we can sign the images we want to deploy:<\/p>\n

      \n
    1. Set up our registry<\/li>\n
    2. Set up a Notary server<\/li>\n
    3. Push an image to our registry server<\/li>\n
    4. Sign the pushed image<\/li>\n
    5. Enable DCT – Set the correct environment variables on our management host so image signatures get verified by Docker commands<\/li>\n<\/ol>\n

      <\/p>\n

      Step 1: Setting up our registry server<\/strong><\/h4>\n

      The easiest way to set up your registry server is to run the base registry image off Docker Hub. We can do this with a single command (see below). Make sure you expose port 5000 because this is what the registry server listens on.<\/p>\n

      ubuntu@ip-{BLOCKED}-20-187<\/b><\/span>:~$ docker run -d -p 5000:5000 --restart always --name registry registry:2<\/b><\/span>\nUnable to find image 'registry:2' locally
      2: Pulling from library\/registry\nDigest: sha256:8be26f81ffea54106bae012c6f349df70f4d5e7e2ec01b143c46e2c03b9e551d\nStatus: Downloaded newer image for registry:2\n5df581b6eb4186edeebb40da766e7907427005d387facdb81365df35647d952d<\/pre>\n
      To validate that it is running:<\/p>\n
      ubuntu@ip-{BLOCKED}-20-187<\/b><\/span>:~$ docker ps\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\n5df581b6eb41 registry:2 \"\/entrypoint.sh \/etc\u2026\" 4 seconds ago Up 3 seconds 0.0.0.0:5000->5000\/tcp registry<\/pre>\n
      Step 2: Setting up a Notary server<\/strong><\/h4>\n
      In addition to a registry server for storing our images, we need a Notary server to store our image signatures. Simply running a registry image from Docker Hub requires a lot of setting up, so let\u2019s go with the simplest way to do it: by cloning the repository from the update framework<\/a>. <\/strong> We can then use a simple docker-compose up<\/em> to deploy with their Dockerfile.<\/p>\n
      ubuntu@ip-{BLOCKED}-20-187<\/b><\/span>:~$ git clone https:\/\/github.com\/theupdateframework\/notary[.]git\nCloning into 'notary'...\nremote: Enumerating objects: 3, done.\nremote: Counting objects: 100% (3\/3), done.\nremote: Compressing objects: 100% (3\/3), done.\nremote: Total 26412 (delta 0), reused 1 (delta 0), pack-reused 26409\nReceiving objects: 100% (26412\/26412), 35.08 MiB | 5.32 MiB\/s, done.\nResolving deltas: 100% (16038\/16038), done.\nubuntu@ip-{BLOCKED}-20-187<\/b><\/span>:~$ cd notary\/
      ubuntu@ip-{BLOCKED}-20-187<\/b><\/span>:~\/notary<\/b><\/span>$ docker-compose up -d\nWARNING:<\/span> The Docker Engine you're using is running in swarm mode. Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node. To deploy your application across the swarm, use `docker stack deploy`.\n\u2026.. Too much output \u2026 cut out \u2026.>\nCreating notary_mysql_1 ... Creating notary_mysql_1 ... done<\/span>\nCreating notary_signer_1 ... Creating notary_signer_1 ... done<\/span>\nCreating notary_server_1 ... Creating notary_server_1 ... done<\/span><\/pre>\n
      I left the warning message about not running in swarm mode on purpose. The docker-compose.yml<\/em> file provided by the update framework<\/a> is not swarm-compatible for a couple of reasons:<\/span><\/p>\n