Setting Up Azure Container Registry: ACR with Managed Identity and RBAC

Setting Up Azure Container Registry: ACR with Managed Identity and RBAC

When a development team runs dozens of microservices in AKS, relying on public registries brings problems: dependence on public registries, risks of proprietary code leaks, and slow pull requests. Azure Container Registry (ACR) solves these, but a standard configuration without retention policy and RBAC leads to storage overflow and vulnerabilities. We configure ACR with managed identity, automatic image cleanup, and geo-replication for multi-region deployments. Over 5 years, we have completed more than 30 projects with ACR, including integration with AKS and CI/CD. Storage costs in Standard are around $0.04 per GB per month, and in Premium $0.10, but geo-replication can save over $200 per month on traffic.

Why Choose ACR for Image Storage?

ACR outperforms Docker Hub in performance: pulling images from AKS is on average 40% faster. ACR supports managed identity, RBAC, and integration with Azure DevOps. Following Microsoft documentation, you should use managed identity and disable the admin account.

resource "azurerm_container_registry" "acr" {
  name = "myappacr" # globally unique
  resource_group_name = azurerm_resource_group.main.name
  location = azurerm_resource_group.main.location
  sku = "Standard"
  admin_enabled = false # use managed identity, not admin

  network_rule_set {
    default_action = "Allow"
  }

  retention_policy {
    days = 30
    enabled = true
  }

  trust_policy {
    enabled = false # enable if content trust is needed
  }
}

admin_enabled = false is mandatory. The admin account provides full access to the registry with a single login/password pair. Managed identity with RBAC is significantly more secure.

Key Features and SKUs

ACR offers three SKUs: Basic, Standard, and Premium. For production, you need at least Standard: 100 GB storage, webhooks, content trust. Premium adds geo-replication, private endpoints, and dedicated data endpoints — necessary if ACR is used from multiple regions or network isolation is required.

ACR SKU Comparison

How Does Geo-replication Work in ACR?

Geo-replication is available only in Premium SKU. It replicates images to up to 30 regions. Pull requests are directed to the nearest replica, reducing latency by 30–50% for remote clusters. Replication is asynchronous (eventual consistency). We configure replication for each region where AKS clusters run. This speeds up deployments and improves fault tolerance.

Security and Authentication Setup

Disabling the Admin Account

The admin account creates a single point of compromise. When enabled, the password is static and can be intercepted. Managed identity is tied to a specific Azure entity (e.g., kubelet in AKS) and the certificate rotates automatically. RBAC allows granting minimal permissions — only AcrPull for reading images. With the admin account, such control is impossible.

Authentication Method Comparison

How to Set Up a Private Endpoint for Network Isolation?

To isolate ACR from the public internet, create a private endpoint in your virtual network. After that, the ACR becomes accessible only from within the network. Setup involves creating a Private Link, DNS records, and network rules. This reduces the attack surface and is required in regulated environments.

AKS Authentication via Managed Identity

# Attach ACR to AKS via az aks attach — this creates a role assignment
az aks update \
  --name my-aks-cluster \
  --resource-group my-rg \
  --attach-acr myappacr

# Manual equivalent:
ACR_ID=$(az acr show --name myappacr --query id --output tsv)
KUBELET_ID=$(az aks show --name my-aks-cluster --resource-group my-rg \
  --query identityProfile.kubeletidentity.objectId --output tsv)
az role assignment create \
  --assignee $KUBELET_ID \
  --role AcrPull \
  --scope $ACR_ID

After this, pods in AKS pull images from ACR without imagePullSecrets — the kubelet uses managed identity. This speeds up deployments and improves security.

Image Lifecycle Management

How to Set Up Automatic Image Cleanup?

Without a retention policy, the registry grows indefinitely. We configure automatic cleanup using az acr task:

# Delete untagged manifests older than 7 days
az acr task create \
  --registry myappacr \
  --name cleanup-untagged \
  --cmd "acr purge --filter 'myapp:.*' --untagged --ago 7d" \
  --schedule "0 1 * * *" \
  --context /dev/null

# Delete tagged images (except latest) older than 30 days
az acr task create \
  --registry myappacr \
  --name cleanup-old-tags \
  --cmd "acr purge --filter 'myapp:[0-9a-f]{7}' --ago 30d" \
  --schedule "0 2 * * 0" \
  --context /dev/null

We also set up storage usage alerts via Azure Monitor. An optimal policy is to keep no more than 20 tags per application.

Integration with CI/CD and AKS

Step-by-Step ACR Setup

1. Determine the SKU and location for the registry.
2. Create a resource group and ACR using Terraform or Azure CLI.
3. Configure network rules: allow access only from required IPs or VNet.
4. Enable retention policy and set the retention period (e.g., 30 days).
5. Disable the admin account (admin_enabled = false).
6. Set up managed identity for AKS: az aks update --attach-acr <acr>.
7. (Optional) Configure geo-replication.
8. (Optional) Configure private endpoint.

What's Included in the Work

• Analysis of current infrastructure and image storage requirements
• Deploy ACR with the appropriate SKU, network rules, private endpoints (if needed)
• Configure RBAC: AcrPull, AcrPush, AcrDelete for different services
• Integrate with AKS via managed identity (no imagePullSecrets)
• Set up retention policy with purge auto-task
• Integrate with Azure DevOps CI/CD (example: Docker push task with managed identity)
• Documentation of the process and incident runbook
• Team training on working with ACR

How Long Does Setup Take?

Basic ACR with retention policy — from 4 hours to 1 day. If geo-replication, private endpoints, integration with AKS and CI/CD are needed — up to 2 days. Timelines depend on the number of integrations and policy approvals.

Common Mistakes When Setting Up ACR

• Using the admin account — forgetting to disable it. We always set admin_enabled = false.
• No retention policy — the registry fills up. We schedule periodic cleanup.
• Incorrect RBAC — granting AcrPush instead of AcrPull. Principle of least privilege.
• No network rules — ACR accessible from the internet. If isolation is needed, we configure private endpoints.

Contact us for a consultation — our engineers will deploy ACR turnkey, integrate with CI/CD and AKS, and train your team in working with the registry. Get reliable image storage without headaches. Order ACR setup today.