Azure Container Registry: Identity, OCI Artifacts, Geo-Replication, and Governance

Azure Container Registry is a private registry for OCI container images and related artifacts. The registry is a security boundary; repositories organize content within it. Microsoft Entra identities, managed identities, service principals, and repository-scoped tokens cover different automation and delegation needs. Prefer short-lived or managed identity over the registry admin account.

Artifact identity and promotion

Tags are convenient release names but can be reassigned. Digests identify content. A sound promotion pipeline builds once, records the digest and SBOM, evaluates policy, then promotes that same artifact rather than rebuilding source independently for each environment. Tag locking and repository permissions reduce accidental movement.

Networking and authorization

Azure RBAC and the registry’s supported repository permission model should separate readers, writers, and administrators. Private Link and firewall rules can constrain network paths, but agents and clusters still need working DNS and token endpoints. AKS can pull through a managed identity integration; verify the exact role assignment rather than distributing Docker credentials.

Replication, retention, and security

Premium geo-replication presents a global registry endpoint and synchronizes content to writable replicas with eventual consistency. It improves locality but adds replicated storage and transfer costs, and a newly pushed artifact may not be present everywhere immediately. Retention and purge automation must protect deployed digests. Defender and other scanners provide findings; signing/provenance policy must evolve with Microsoft’s current Notary guidance rather than relying on a deprecated trust mechanism indefinitely.

Operational checks

Measure pull latency, throttling, failed authorization, replication lag, storage growth, and vulnerable artifacts. Test restore and region-outage behavior. A registry is part of the production supply chain: losing a manifest, key, or permission can block deployment just as effectively as losing source code.

Choose an authentication mechanism deliberately

Human users can authenticate through Microsoft Entra ID and az acr login; unattended systems should use a managed identity or service principal appropriate to their host platform. The registry admin account is a high-privilege shared credential and should remain disabled unless a documented compatibility exception requires it. Repository-scoped tokens use scope maps for delegated access in supported scenarios, but they are credentials that require storage, rotation, and revocation.

Authentication only establishes identity. Azure RBAC or repository-scoped permissions determine allowed data-plane operations, while control-plane roles govern registry configuration. Separate image pull, image push, artifact deletion, policy administration, networking, and role assignment. For AKS, validate the kubelet or workload identity and the effective AcrPull-equivalent permission; do not distribute a registry password through every namespace.

Immutability and promotion records

ACR supports locking images and repositories to reduce accidental delete or write operations. A production pipeline should push a unique release tag, resolve the manifest digest returned by the registry, run policy against that digest, and deploy the digest. Import or retagging workflows must preserve the link to source evidence. If an environment rebuilds the same Git revision independently, it has created a different artifact that needs its own verification.

Keep the SBOM, vulnerability result, provenance, and signing evidence associated with the digest in a system whose retention matches the image. Scanner findings change as advisories change, so define when deployed artifacts are reevaluated and rebuilt. A signature proves only the verified identity and statement; admission policy still needs trusted issuers, repositories, and build claims.

Private access and geo-replication

Private Link gives registry endpoints private addresses reachable through configured virtual networks and connected on-premises networks. Clients still need correct private DNS for the login server and regional data endpoints. When geo-replication and private endpoints coexist, Microsoft documents additional regional endpoints and subnet-address requirements. Test image pull from each consumer network after adding a replica rather than assuming the global hostname is sufficient.

Geo-replication is eventually consistent and replicas are writable. Define where publishers may write, how conflicting operational actions are controlled, and what happens before a new digest reaches every deployment region. Registry configuration, role assignments, private DNS, and consumer permissions need their own recovery path; replicating blobs alone does not reproduce the entire security boundary.

Retention and incident recovery

Cleanup automation should protect digests referenced by production, staged rollouts, rollback windows, investigations, and legal holds. Preview purge filters and run them first against a nonproduction repository. Avoid rules based only on untagged state: deleting a tag can make a still-deployed digest appear disposable to a poorly designed process.

During an incident, preserve the manifest, config, layers, signatures, attestations, role changes, and relevant activity logs. Verify a clean pull by digest from an isolated runner and record the image’s platform variants. Monitor authorization failures, delete operations, network-rule changes, replication health, storage, and scan regressions. These controls make the registry a recoverable release system rather than a mutable cache.

Manage the registry itself as infrastructure code where supported: SKU, location, replicas, network access, private endpoints, diagnostic settings, encryption choices, policies, and role assignments should be reviewable. Keep secret material and generated credentials outside state files. After an emergency portal change, reconcile it back to the approved definition rather than allowing a permanent undocumented exception.

An acceptance test should push under the publisher identity, deny an unrelated identity, pull under each runtime identity, resolve the digest, verify policy evidence, and repeat from every recovery region. Test an intentionally expired or revoked credential as well. Successful negative tests are important: they show the registry rejects paths the architecture says should be impossible.

Review current ACR quotas and SKU-specific features before depending on throughput, retention, replication, private networking, or repository permissions. Record the approved SKU and reasons in architecture decisions. A downgrade or regional recreation must not silently remove a control the release process assumes exists.

Related:

Sources: