Container Registry
Azure Container Registry is a private registry for container images and OCI artifacts — the source of truth for what AKS, Container Apps, and App Service actually run. You push built images here, and your compute pulls from here, with access governed by Entra ID rather than registry credentials.
A registry is a supply-chain control point, not just storage. The images it holds become the workloads in production, so scanning them for vulnerabilities, restricting who can push, and authenticating pulls with managed identities are security decisions, not conveniences. An unscanned, openly writable registry is a direct path into production.
Registries and Tiers
Three service tiers differ in throughput, storage, and features. Basic suits development; Standard fits most production; Premium adds geo-replication, private endpoints, content trust, and higher throughput. The tier is chosen for scale and the security features (private networking, replication) a production registry needs, not just storage size.
Geo-Replication
Premium registries replicate to multiple regions under a single registry name, so clusters in each region pull from a local replica with low latency and no cross-region egress. For a multi-region deployment this both speeds pulls and removes a single-region dependency for the images everything runs.
Security
Authenticate pulls and pushes with Entra ID and managed identities — an AKS cluster pulls with its identity, with no registry password stored. Restrict network access with private endpoints. Vulnerability scanning (through Microsoft Defender for Containers) inspects pushed images for known CVEs, and content trust signs images so only trusted ones deploy. These together make the registry a defended supply-chain link.
Tasks
ACR Tasks builds images in the cloud — on push, on a base-image update, or on a schedule — without a separate build agent. Crucially, base-image-update triggers rebuild and re-patch your images automatically when the base they derive from gets a security fix, so a patched base does not require a manual rebuild of everything downstream.
- Authenticating pulls with a stored registry password instead of a managed identity, leaving a credential to leak.
- Never scanning images, so known-vulnerable images flow straight into production workloads.
- Leaving the registry openly writable, turning it into an unguarded path into production.
- Running a Basic or Standard registry for a multi-region deployment that needs Premium geo-replication and private endpoints.
- Pulling cross-region from a single registry, adding latency and egress instead of replicating.
- Ignoring base-image-update tasks, so a patched base never propagates to derived images.
- Authenticate pulls and pushes with Entra ID and managed identities; store no registry passwords.
- Scan images for vulnerabilities (Defender for Containers) and block or remediate known CVEs before deploy.
- Restrict push access and reach the registry over a private endpoint.
- Use the Premium tier with geo-replication for multi-region deployments.
- Use ACR Tasks with base-image-update triggers so security patches propagate to derived images automatically.
- Sign images with content trust so only trusted images deploy.
Knowledge Check
Why is a container registry a security control point, not just storage?
- Its images become production workloads, so scanning, push restrictions, and authenticated pulls are supply-chain controls
- Registries are billed per vulnerability scan run against each stored image
- Images cannot run on AKS or App Service unless the registry is made fully public and anonymous pulls are enabled, so locking it down breaks every deployment
- It is the only Azure service where application secrets can be stored
What does an ACR Tasks base-image-update trigger do?
- Rebuilds derived images automatically when their base image is patched, propagating the fix
- Deletes any image older than a configured age to reclaim storage
- Replicates the registry to another region for low-latency pulls
- Signs each pushed image with content trust automatically so unsigned images are rejected before any consumer can pull them
How should an AKS cluster authenticate to pull from ACR?
- With its managed identity, so no registry password is stored
- With a shared admin username and password in the pod spec
- By making the registry public so the cluster can pull without credentials
- With a SAS token granting the cluster time-limited pull access
You got correct