When transferring data among networked systems, trust is a central concern. In particular, when communicating over an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data a system operates on. You use the Docker Engine to push and pull images (data) to a public or private registry. Content trust gives you the ability to verify both the integrity and the publisher of all the data received from a registry over any channel.

Docker Content Trust is a feature in the Docker containerization platform that enables remote registry content to be digitally signed, ensuring that the content is unaltered and is the most current available version when users access it. It works via cryptographic keys. Docker Content Trust was introduced in Docker Engine with version 1.8.

Docker Content Trust adds security controls that verify the integrity of container images — the container files that hold application components and content — stored in a registry, such as Docker Hub. Enterprise developers and other users can push or pull (upload or download) container images to a registry. Docker Content Trust addresses two concerns with registries. Users might upload a container image infiltrated with malware, and the users accessing it from that remote repository cannot determine its integrity. And secondly, users can put outdated containers on a registry, which creates interoperability, compatibility or performance problems for the business. In Docker parlance, a repository is a collection of container images with the same name, distinguished by tags, placed in the registry.

When a publisher pushes a container image to a remote registry, Docker Engine applies a cryptographic signature to the container image, using the publisher’s cryptographic key. The signed image can be pulled from the registry by users, at which point Docker Engine uses the original publisher’s public key to verify it is the same. This key check only verifies that the image is the original file, unaltered. Docker Content Trust does not certify the suitability or performance of a container for any particular task. It is possible to pull a verified container image, only for that container to generate errors or perform poorly because it is not production-ready. A user can still upload a malicious container image, and Docker Content Trust will sign the image. Public registry and repository users still bear the responsibility to test and vet a container image.

DCT Components

Docker Content Trust security advantages

The verification system helps guard against man-in-the-middle attacks, as it prevents an attacker from secretly forging or tampering with content. DCT also prevents replay attacks, wherein valid actions are copied and replayed by attackers to fool a system. For example, DCT timestamps prevent attackers from passing off older (typically compromised) images from being passed off as most recent. The TUF framework and use of multiple keys allow DCT to guard the system against tagging key compromise, and allow publishers to change tagging keys on demand, without disrupting users.

Docker designed the Content Trust feature to be unobtrusive for developers that upload images and the people who use this content. Content publishers do not have to learn new commands, or change workflows, but they do need to create and manage keys. Users are completely insulated from the digital signage system, and can use the same push, pull, build, run and other commands as they would without Docker Content Trust.

Check Signature of Simplifier Image

To verify the Image you can run the below command

docker trust inspect --pretty simplifierag/runtime:6.5

If the Docker Image is one of the original simplifier image, you will get the following output

SIGNER KEYS

simplifier 30aa71c9ab2a

Repository Key: 7a50f4ba027a885a670160d307f02bee85085bffa104c1b200a8d2753d3fd7db

Root Key: 412960d3c77b40d688b37a57acd6a683cf30c5afe0b510f89d10005aafbf20bf