{
	"id": "655a9853-d4d1-4b8e-81b2-ae3eaa672349",
	"created_at": "2026-04-06T00:18:18.162053Z",
	"updated_at": "2026-04-10T13:13:03.512582Z",
	"deleted_at": null,
	"sha1_hash": "e697301cde0a99dce578a8580945bab66e27dd48",
	"title": "Content trust in Docker",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 233841,
	"plain_text": "Content trust in Docker\r\nBy Docker Inc\r\nPublished: 2025-11-03 · Archived: 2026-04-05 17:28:12 UTC\r\nWhen transferring data among networked systems, trust is a central concern. In particular, when communicating\r\nover an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data\r\na system operates on. You use Docker Engine to push and pull images (data) to a public or private registry.\r\nContent trust gives you the ability to verify both the integrity and the publisher of all the data received from a\r\nregistry over any channel.\r\nAbout Docker Content Trust (DCT)\r\nDocker Content Trust (DCT) provides the ability to use digital signatures for data sent to and received from\r\nremote Docker registries. These signatures allow client-side or runtime verification of the integrity and publisher\r\nof specific image tags.\r\nThrough DCT, image publishers can sign their images and image consumers can ensure that the images they pull\r\nare signed. Publishers could be individuals or organizations manually signing their content or automated software\r\nsupply chains signing content as part of their release process.\r\nDocker is retiring DCT for Docker Official Images (DOI). You should start planning to transition to a\r\ndifferent image signing and verification solution (like Sigstore or Notation). Timelines for the complete\r\ndeprecation of DCT are being finalized and will be published soon.\r\nFor more information, see Retiring Docker Content Trust.\r\nImage tags and DCT\r\nAn individual image record has the following identifier:\r\nA particular image REPOSITORY can have multiple tags. For example, latest and 3.1.2 are both tags on the\r\nmongo image. An image publisher can build an image and tag combination many times changing the image with\r\neach build.\r\nDCT is associated with the TAG portion of an image. Each image repository has a set of keys that image\r\npublishers use to sign an image tag. Image publishers have discretion on which tags they sign.\r\nAn image repository can contain an image with one tag that is signed and another tag that is not. For example,\r\nconsider the Mongo image repository. The latest tag could be unsigned while the 3.1.6 tag could be signed.\r\nIt is the responsibility of the image publisher to decide if an image tag is signed or not. In this representation,\r\nsome image tags are signed, others are not:\r\nhttps://docs.docker.com/engine/security/trust/content_trust/\r\nPage 1 of 5\n\nPublishers can choose to sign a specific tag or not. As a result, the content of an unsigned tag and that of a signed\r\ntag with the same name may not match. For example, a publisher can push a tagged image someimage:latest\r\nand sign it. Later, the same publisher can push an unsigned someimage:latest image. This second push replaces\r\nthe last unsigned tag latest but does not affect the signed latest version. The ability to choose which tags\r\nthey can sign, allows publishers to iterate over the unsigned version of an image before officially signing it.\r\nImage consumers can enable DCT to ensure that images they use were signed. If a consumer enables DCT, they\r\ncan only pull, run, or build with trusted images. Enabling DCT is a bit like applying a \"filter\" to your registry.\r\nConsumers \"see\" only signed image tags and the less desirable, unsigned image tags are \"invisible\" to them.\r\nhttps://docs.docker.com/engine/security/trust/content_trust/\r\nPage 2 of 5\n\nTo the consumer who has not enabled DCT, nothing about how they work with Docker images changes. Every\r\nimage is visible regardless of whether it is signed or not.\r\nDocker Content Trust Keys\r\nTrust for an image tag is managed through the use of signing keys. A key set is created when an operation using\r\nDCT is first invoked. A key set consists of the following classes of keys:\r\nAn offline key that is the root of DCT for an image tag\r\nRepository or tagging keys that sign tags\r\nServer-managed keys such as the timestamp key, which provides freshness security guarantees for your\r\nrepository\r\nThe following image depicts the various signing keys and their relationships:\r\nThe root key once lost is not recoverable. If you lose any other key, send an email to Docker Hub\r\nSupport. This loss also requires manual intervention from every consumer that used a signed tag from\r\nthis repository prior to the loss.\r\nYou should back up the root key somewhere safe. Given that it is only required to create new repositories, it is a\r\ngood idea to store it offline in hardware. For details on securing, and backing up your keys, make sure you read\r\nhow to manage keys for DCT.\r\nhttps://docs.docker.com/engine/security/trust/content_trust/\r\nPage 3 of 5\n\nSigning images with Docker Content Trust\r\nWithin the Docker CLI we can sign and push a container image with the $ docker trust command syntax. This\r\nis built on top of the Notary feature set. For more information, see the Notary GitHub repository.\r\nA prerequisite for signing an image is a Docker Registry with a Notary server (such as Docker Hub) attached.\r\nRefer to Deploying Notary for instructions.\r\nDocker is retiring DCT for Docker Official Images (DOI). You should start planning to transition to a\r\ndifferent image signing and verification solution (like Sigstore or Notation). Timelines for the complete\r\ndeprecation of DCT are being finalized and will be published soon.\r\nFor more information, see Retiring Docker Content Trust.\r\nTo sign a Docker Image you will need a delegation key pair. These keys can be generated locally using $ docker\r\ntrust key generate or generated by a certificate authority.\r\nFirst we will add the delegation private key to the local Docker trust repository. (By default this is stored in\r\n~/.docker/trust/ ). If you are generating delegation keys with $ docker trust key generate , the private key\r\nis automatically added to the local trust store. If you are importing a separate key, you will need to use the $\r\ndocker trust key load command.\r\nOr if you have an existing key:\r\nNext we will need to add the delegation public key to the Notary server; this is specific to a particular image\r\nrepository in Notary known as a Global Unique Name (GUN). If this is the first time you are adding a delegation\r\nto that repository, this command will also initiate the repository, using a local Notary canonical root key. To\r\nunderstand more about initiating a repository, and the role of delegations, head to delegations for content trust.\r\nFinally, we will use the delegation private key to sign a particular tag and push it up to the registry.\r\nAlternatively, once the keys have been imported an image can be pushed with the $ docker push command, by\r\nexporting the DCT environmental variable.\r\nRemote trust data for a tag or a repository can be viewed by the $ docker trust inspect command:\r\nRemote Trust data for a tag can be removed by the $ docker trust revoke command:\r\nClient enforcement with Docker Content Trust\r\nContent trust is disabled by default in the Docker Client. To enable it, set the DOCKER_CONTENT_TRUST\r\nenvironment variable to 1 . This prevents users from working with tagged images unless they contain a signature.\r\nWhen DCT is enabled in the Docker client, docker CLI commands that operate on tagged images must either\r\nhave content signatures or explicit content hashes. The commands that operate with DCT are:\r\npush\r\nhttps://docs.docker.com/engine/security/trust/content_trust/\r\nPage 4 of 5\n\nbuild\r\ncreate\r\npull\r\nrun\r\nFor example, with DCT enabled a docker pull someimage:latest only succeeds if someimage:latest is\r\nsigned. However, an operation with an explicit content hash always succeeds as long as the hash exists:\r\nDelegations for content trust\r\nAutomation with content trust\r\nManage keys for content trust\r\nPlay in a content trust sandbox\r\nSource: https://docs.docker.com/engine/security/trust/content_trust/\r\nhttps://docs.docker.com/engine/security/trust/content_trust/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.docker.com/engine/security/trust/content_trust/"
	],
	"report_names": [
		"content_trust"
	],
	"threat_actors": [],
	"ts_created_at": 1775434698,
	"ts_updated_at": 1775826783,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e697301cde0a99dce578a8580945bab66e27dd48.pdf",
		"text": "https://archive.orkl.eu/e697301cde0a99dce578a8580945bab66e27dd48.txt",
		"img": "https://archive.orkl.eu/e697301cde0a99dce578a8580945bab66e27dd48.jpg"
	}
}