The container registry is the most trusted component in a container platform, every node pulls from it, every deployment references it, and it is usually configured once in a hurry and never revisited. Azure Container Registry deserves the revisit: it has grown from an image store into a build service, a cache, and a supply chain control point.

Premium, Replicated, Private

Premium SKU for production: private endpoints, geo replication, zone redundancy, and the throughput a busy AKS fleet actually generates during a rolling deploy. Geo replication turns one registry into a multi region push once, pull locally system: a single login server URL, with the platform routing pulls to the nearest replica, which cuts cross region egress, speeds node startup, and keeps deployments working during a regional registry outage. Networking follows series law, public access disabled, private endpoints per consuming region, and the AKS clusters pulling through their managed identity with AcrPull, never admin credentials, which stay disabled entirely.

resource "azurerm_container_registry" "this" {
  name                          = "acrcontosoprod"
  resource_group_name           = azurerm_resource_group.platform.name
  location                      = "westeurope"
  sku                           = "Premium"
  admin_enabled                 = false
  public_network_access_enabled = false
  zone_redundancy_enabled       = true

  georeplications {
    location                = "eastus"
    zone_redundancy_enabled = true
  }

  retention_policy_in_days = 30
}

resource "azurerm_role_assignment" "aks_pull" {
  scope                = azurerm_container_registry.this.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_kubernetes_cluster.this.kubelet_identity[0].object_id
}

The retention policy reaps untagged manifests; pair it with lifecycle discipline on tags (the acr purge task on a schedule) or a busy CI system will grow the registry into a storage bill with a git history.

ACR Tasks: The Registry That Builds

ACR Tasks run container builds in the registry’s compute: az acr build for remote builds from a context (no Docker daemon on your CI agent), triggered tasks on source commits, and, the underused gem, base image update triggers. When the base image your Dockerfile FROMs gets patched, the task rebuilds your image automatically, which is the only scalable answer to the recurring question of how yesterday’s OpenSSL fix reaches your two hundred services. Multi step task YAML chains build, test, and push with when conditions, effectively a small pipeline living next to the images. For estates standardizing pipelines elsewhere, use Tasks at minimum for the base image automation; it closes a gap that pipeline schedulers handle badly.

Cache, Tokens, and the Supply Chain

Cache rules proxy and cache upstream registries, Docker Hub, MCR, Quay, through your ACR: pulls of library/nginx resolve from your registry, immune to Docker Hub rate limits and outages, and subject to your scanning. Combined with a policy blocking direct external registry references in the cluster (from the AKS hardening post), the registry becomes a true chokepoint in the good sense: everything that runs came through it. Scoped tokens and repository permissions handle the partner and multi tenant edges, a token that can pull exactly one repository, expiring on a date, for the vendor integration that must not see everything else. And on integrity: enable vulnerability scanning through Defender (findings gate promotion, not just report), sign images in CI with notation and cosign style tooling, and verify signatures at admission in the cluster, so the chain from build to runtime is attested rather than assumed. The registry is where supply chain security is either enforced or merely discussed.

Cheers
Osama