Azure Container Registry Overview: Store and Manage Container Images

Why a private registry matters

Docker Hub is the default public registry, but using it for private application images creates several problems:

• Access control. Docker Hub’s private repository model requires managing Docker Hub credentials separately from Azure RBAC. ACR uses Azure RBAC, so access is controlled through the same role assignments you use for everything else in Azure.
• Network performance. Pulling images from Docker Hub introduces internet latency and potential rate limits. ACR deployed in the same region as your compute resources is much faster and not rate-limited.
• Security scanning. ACR integrates with Microsoft Defender for Containers to scan images for known vulnerabilities on push and periodically thereafter.
• Geo-replication. Premium ACR can replicate images to multiple regions, so AKS clusters in East US and West Europe both pull from a nearby registry replica rather than crossing regions.

Creating a registry

# Create a resource group
az group create --name my-rg --location eastus

# Create a Standard tier ACR
az acr create \
  --resource-group my-rg \
  --name myorgacr \
  --sku Standard \
  --location eastus

The registry name must be globally unique — it becomes part of the FQDN: myorgacr.azurecr.io. Use lowercase letters and numbers only (no hyphens). Standard tier is appropriate for most production workloads.

Building and pushing images

Option 1: Build locally, push to ACR

# Log in to the registry using your Azure CLI session
az acr login --name myorgacr

# Build your image locally
docker build -t myapp:latest .

# Tag the image with the ACR login server
docker tag myapp:latest myorgacr.azurecr.io/myapp:latest

# Push to ACR
docker push myorgacr.azurecr.io/myapp:latest

Option 2: Build in ACR (no local Docker needed)

# ACR Tasks builds the image in Azure — no local Docker required
az acr build \
  --registry myorgacr \
  --image myapp:latest \
  .

az acr build uploads your build context to Azure, builds the Docker image using ACR’s build infrastructure, and pushes the result to the registry. This is useful in CI/CD pipelines or on developer machines where Docker is not installed. Build logs stream to the terminal so you can monitor progress.

Access control: RBAC over admin credentials

ACR supports two access methods:

Admin account (avoid for production)

Every ACR has an optional admin account with a username/password. It is disabled by default. Do not enable it for production — the credentials do not rotate automatically, there is no audit trail of who used them, and sharing them across teams means you cannot revoke individual access.

RBAC with managed identities (recommended)

Assign the appropriate built-in role to the managed identity (or service principal) that needs registry access:

# Grant AKS the AcrPull role (so node pools can pull images without credentials)
ACR_ID=$(az acr show --name myorgacr --resource-group my-rg --query id --output tsv)
AKS_IDENTITY=$(az aks show --name my-aks --resource-group my-rg \
  --query identityProfile.kubeletidentity.objectId --output tsv)

az role assignment create \
  --assignee $AKS_IDENTITY \
  --role AcrPull \
  --scope $ACR_ID

With this setup, AKS node pools pull images from ACR using the kubelet managed identity — no secrets to rotate, no credentials to store in Kubernetes.

Managing images and storage costs

Each push to ACR creates a new image manifest. Images accumulate quickly in active CI/CD pipelines — a team pushing 10 builds per day creates 300 image versions per month. Without a cleanup policy, storage costs grow unchecked.

List images and their sizes:

# List all repositories in the registry
az acr repository list --name myorgacr --output table

# List tags for a specific image
az acr repository show-tags \
  --name myorgacr \
  --repository myapp \
  --orderby time_desc \
  --output table

# Show size of a specific image
az acr repository show \
  --name myorgacr \
  --image myapp:latest

Run a purge to clean up old untagged images (images pushed without a specific tag or whose tag was overwritten):

# Delete untagged manifests older than 7 days (dry run first)
az acr run \
  --registry myorgacr \
  --cmd "acr purge --filter 'myapp:.*' --untagged --ago 7d --dry-run" \
  /dev/null

# Run without --dry-run to delete
az acr run \
  --registry myorgacr \
  --cmd "acr purge --filter 'myapp:.*' --untagged --ago 7d" \
  /dev/null

Vulnerability scanning

Microsoft Defender for Containers scans images in ACR for known CVEs (Common Vulnerabilities and Exposures). Scanning happens automatically on push and on a schedule. Findings appear in Microsoft Defender for Cloud.

Enable Defender for Containers on the subscription to activate scanning:

az security pricing create \
  --name Containers \
  --tier Standard

Defender for Cloud shows each image with a list of CVEs, their severity, and whether a fix is available. For CI/CD pipelines, integrate this feedback loop: fail the pipeline if a newly pushed image contains critical vulnerabilities with available fixes. This catches known vulnerabilities before they reach production.