{
	"id": "5875a391-592d-4fca-8c40-750a18838d7b",
	"created_at": "2026-04-06T00:15:57.522119Z",
	"updated_at": "2026-04-10T03:20:56.354196Z",
	"deleted_at": null,
	"sha1_hash": "d2720b5c9066708c7130a698bc8b3a86f9a8b333",
	"title": "Manage Signed Images with Docker Content Trust in Azure Container Registry - Azure Container Registry",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 141492,
	"plain_text": "Manage Signed Images with Docker Content Trust in Azure\r\nContainer Registry - Azure Container Registry\r\nBy rayoef\r\nArchived: 2026-04-05 17:02:17 UTC\r\nAzure Container Registry implements the Docker Content Trust (DCT) model to enable pushing and pulling\r\nsigned images. This article gets you started with enabling DCT in your container registries. DCT is a feature of the\r\nPremium service tier of Container Registry.\r\nImportant\r\nStarting May 31, 2026, Docker Content Trust cannot be enabled on new container registries or registries that\r\nhaven't enabled it previously.\r\nDCT will be deprecated and completely removed on March 31, 2028. For details and transition guidance, refer to\r\nTransition from Docker Content Trust to Notary Project.\r\nLimitations\r\nA token that has repository-scoped permissions doesn't currently support Docker push and pull of signed images.\r\nHow DCT works\r\nImportant to any distributed system that's designed with security in mind is verifying both the source and the\r\nintegrity of data entering the system. Consumers of the data need to be able to verify the publisher (source) of the\r\ndata and ensure that the data wasn't modified after it was published (integrity).\r\nAs an image publisher, you can use DCT to sign the images that you push to your registry. Consumers of your\r\nimages (people or systems pulling images from your registry) can configure their clients to pull only signed\r\nimages. When an image consumer pulls a signed image, their Docker client verifies the integrity of the image. In\r\nthis model, consumers are assured that you published the signed images in your registry, and that the images\r\nweren't modified after publication.\r\nNote\r\nContainer Registry does not support acr import to import images signed with DCT. By design, the signatures\r\naren't visible after the import. Notary v2 stores these signatures as artifacts.\r\nTrusted images\r\nDCT works with the tags in a repository. Image repositories can contain images that have both signed and\r\nunsigned tags. For example, you might sign only the myimage:stable and myimage:latest images, but not\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 1 of 7\n\nmyimage:dev .\r\nSigning keys\r\nYou manage DCT by using a set of cryptographic signing keys. These keys are associated with a specific\r\nrepository in a registry.\r\nThere are several types of signing keys that Docker clients and your registry use in managing trust for the tags in a\r\nrepository. When you enable DCT and integrate it into your pipeline for container publishing and consumption,\r\nyou must manage these keys carefully. For more information, see Manage keys later in this article and Manage\r\nkeys for content trust in the Docker documentation.\r\nEnable DCT for the registry\r\nYour first step is to enable DCT at the registry level. After you enable DCT, clients (users or services) can push\r\nsigned images to your registry.\r\nEnabling DCT for your registry doesn't restrict registry usage to only consumers who have DCT enabled.\r\nConsumers who don't have DCT enabled can continue to use your registry as normal. Consumers who enabled\r\nDCT in their clients, however, can see only signed images in your registry.\r\nTo enable DCT for your registry by using the Azure portal, go to the registry. Under Policies, select Content\r\ntrust. Select Enabled, then select Save. You can also use the az acr config content-trust update command in the\r\nAzure CLI.\r\nEnable DCT for the client\r\nTo work with trusted images, both image publishers and consumers need to enable DCT for their Docker clients.\r\nAs a publisher, you can sign the images that you push to a DCT-enabled registry. As a consumer, enabling DCT\r\nlimits your view of a registry to signed images only. DCT is disabled by default in Docker clients, but you can\r\nenable it per shell session or per command.\r\nTo enable DCT for a shell session, set the DOCKER_CONTENT_TRUST environment variable to 1 . For example, in\r\nthe Bash shell, use this code:\r\n# Enable DCT for a shell session\r\nexport DOCKER_CONTENT_TRUST=1\r\nIf you want to enable or disable DCT for a single command, several Docker commands support the --disable-content-trust argument.\r\nTo enable DCT for a single command, use this code:\r\n# Enable DCT for a single command\r\ndocker build --disable-content-trust=false -t myacr.azurecr.io/myimage:v1 .\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 2 of 7\n\nIf you enabled DCT for your shell session and want to disable it for a single command, use this code:\r\n# Disable DCT for a single command\r\ndocker build --disable-content-trust -t myacr.azurecr.io/myimage:v1 .\r\nGrant image signing permissions\r\nOnly the users or systems to which you grant permission can push trusted images to your registry. To grant this\r\npush permission to a user (or a system by using a service principal), assign the AcrImageSigner role to the user's\r\nMicrosoft Entra identity. This permission is in addition to the AcrPush (or equivalent) role that's required for\r\npushing images to the registry. For more information, see Azure Container Registry permissions and role\r\nassignments overview.\r\nThe AcrImageSigner role includes both the Microsoft.ContainerRegistry/registries/sign/write action and\r\nthe Microsoft.ContainerRegistry/registries/trustedCollections/write data action.\r\nAzure portal\r\nTo grant the AcrImageSigner role by using the Azure portal:\r\n1. Select Access control (IAM).\r\n2. Select Add \u003e Add role assignment to open the Add role assignment pane.\r\n3. Assign the following role. In this example, the role is assigned to an individual user. For detailed steps, see\r\nAssign Azure roles by using the Azure portal.\r\nSetting Value\r\nRole AcrImageSigner\r\nAssign access to User\r\nMembers Alain\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 3 of 7\n\nAzure CLI\r\nTo grant signing permissions to a user by using the Azure CLI, assign the AcrImageSigner role to the user,\r\nscoped to your registry. The format of the command is:\r\naz role assignment create --scope \u003cregistry ID\u003e --role AcrImageSigner --assignee \u003cuser name\u003e\r\nFor example, to assign the role to a non-administrative user, you can run the following commands in an\r\nauthenticated Azure CLI session. Modify the REGISTRY value to reflect the name of your Azure container\r\nregistry.\r\n# Grant signing permissions to an authenticated Azure CLI user\r\nREGISTRY=myregistry\r\nREGISTRY_ID=$(az acr show --name $REGISTRY --query id --output tsv)\r\naz role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee azureuser@contoso.com\r\nYou can also grant a service principal the rights to push trusted images to your registry. Using a service principal\r\nis useful for build systems and other unattended systems that need to push trusted images to your registry. The\r\nformat is similar to granting a user permission, but you specify a service principal ID for the --assignee value:\r\naz role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee \u003cservice principal ID\u003e\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 4 of 7\n\nThe \u003cservice principal ID\u003e value can be the service principal's appId value, its objectId value, or one of\r\nits servicePrincipalNames values. For more information about working with service principals and Azure\r\nContainer Registry, see Azure Container Registry authentication with service principals.\r\nPush a trusted image\r\nTo push a trusted image tag to your container registry, enable DCT and use docker push . After pushing with a\r\nsigned tag finishes the first time, you're asked to create a passphrase for both a root signing key and a repository\r\nsigning key. Both the root and repository keys are generated and stored locally on your machine.\r\n$ docker push myregistry.azurecr.io/myimage:v1\r\n[...]\r\nThe push refers to repository [myregistry.azurecr.io/myimage]\r\nee83fc5847cb: Pushed\r\nv1: digest: sha256:aca41a608e5eb015f1ec6755f490f3be26b48010b178e78c00eac21ffbe246f1 size: 524\r\nSigning and pushing trust metadata\r\nYou are about to create a new root signing key passphrase. This passphrase\r\nwill be used to protect the most sensitive key in your signing system. Please\r\nchoose a long, complex passphrase and be careful to keep the password and the\r\nkey file itself secure and backed up. It is highly recommended that you use a\r\npassword manager to generate the passphrase and keep it safe. There will be no\r\nway to recover this key. You can find the key in your config directory.\r\nEnter passphrase for new root key with ID 4c6c56a:\r\nRepeat passphrase for new root key with ID 4c6c56a:\r\nEnter passphrase for new repository key with ID bcd6d98:\r\nRepeat passphrase for new repository key with ID bcd6d98:\r\nFinished initializing \"myregistry.azurecr.io/myimage\"\r\nSuccessfully signed myregistry.azurecr.io/myimage:v1\r\nAfter your first docker push action with DCT enabled, the Docker client uses the same root key for subsequent\r\npushes. On each subsequent push to the same repository, you're asked only for the repository key. Each time you\r\npush a trusted image to a new repository, you're asked to supply a passphrase for a new repository key.\r\nPull a trusted image\r\nTo pull a trusted image, enable DCT and run the docker pull command as normal. To pull trusted images, the\r\nAcrPull role is enough for normal users. No additional roles (like an AcrImageSigner role) are required.\r\nConsumers who have DCT enabled can pull only images that have signed tags. Here's an example of pulling a\r\nsigned tag:\r\n$ docker pull myregistry.azurecr.io/myimage:signed\r\nPull (1 of 1): myregistry.azurecr.io/myimage:signed@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed\r\nsha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b: Pulling from myimage\r\n8e3ba11ec2a2: Pull complete\r\nDigest: sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 5 of 7\n\nStatus: Downloaded newer image for myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb5\r\nTagging myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b as\r\nIf a client that has DCT enabled tries to pull an unsigned tag, the operation fails with an error similar to the\r\nfollowing example:\r\n$ docker pull myregistry.azurecr.io/myimage:unsigned\r\nError: remote trust data does not exist\r\nBehind the scenes\r\nWhen you run docker pull , the Docker client uses the same library as in the Notary CLI to request the tag-to-SHA-256 digest mapping for the tag that you're pulling. After the client validates the signatures on the trust data, it\r\ninstructs Docker Engine to do a \"pull by digest.\" During the pull, the engine uses the SHA-256 checksum as a\r\ncontent address to request and validate the image manifest from the Azure container registry.\r\nNote\r\nAzure Container Registry doesn't officially support the Notary CLI but is compatible with the Notary Server API.\r\nThe Notary Server API is included with Docker Desktop. Currently, we recommend Notary version 0.6.0.\r\nManage keys\r\nAs stated in the docker push output when you push your first trusted image, the root key is the most sensitive.\r\nBy default, the Docker client stores signing keys in the following directory:\r\n~/.docker/trust/private\r\nBack up your root and repository keys by compressing them in an archive and storing the archive in a secure\r\nlocation. For example, use this command in Bash:\r\numask 077; tar -zcvf docker_private_keys_backup.tar.gz ~/.docker/trust/private; umask 022\r\nAlong with the locally generated root and repository keys, Container Registry generates and stores several other\r\nkeys when you push a trusted image. For a detailed discussion of the various keys in the DCT implementation,\r\nincluding management guidance, see Manage keys for content trust in the Docker documentation.\r\nLost root key\r\nIf you lose access to your root key, you lose access to the signed tags in any repository whose tags that key signed.\r\nContainer Registry can't restore access to image tags signed with a lost root key. To remove all trust data\r\n(signatures) for your registry, disable and then re-enable DCT for the registry.\r\nWarning\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 6 of 7\n\nDisabling and re-enabling DCT in your registry deletes all trust data for all signed tags in every repository in your\r\nregistry. This action is irreversible. Container Registry can't recover deleted trust data. Disabling DCT does not\r\ndelete the images themselves.\r\nTo disable DCT for your registry, go to the registry in the Azure portal. Under Policies, select Content Trust.\r\nSelect Disabled, then select Save. You're warned of the loss of all signatures in the registry. Select OK to\r\npermanently delete all signatures in your registry.\r\nRelated content\r\nFor more information about DCT, including docker trust commands and trust delegations, see Content\r\ntrust in Docker.\r\nFor an example of using DCT when you build and push a Docker image, see the Azure Pipelines\r\ndocumentation.\r\nSource: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust"
	],
	"report_names": [
		"container-registry-content-trust"
	],
	"threat_actors": [],
	"ts_created_at": 1775434557,
	"ts_updated_at": 1775791256,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d2720b5c9066708c7130a698bc8b3a86f9a8b333.pdf",
		"text": "https://archive.orkl.eu/d2720b5c9066708c7130a698bc8b3a86f9a8b333.txt",
		"img": "https://archive.orkl.eu/d2720b5c9066708c7130a698bc8b3a86f9a8b333.jpg"
	}
}