Azure Container Registry Repository Permissions with Attribute-based Access Control (ABAC)

General Availability announcement

Today marks the general availability of Azure Container Registry (ACR) repository permissions with Microsoft Entra attribute-based access control (ABAC).

ABAC augments the familiar Azure RBAC model with namespace and repository-level conditions so platform teams can express least-privilege access at the granularity of specific repositories or entire logical namespaces. This capability is designed for modern multi-tenant platform engineering patterns where a central registry serves many business domains. With ABAC, CI/CD systems and runtime consumers like Azure Kubernetes Service (AKS) clusters have least-privilege access to ACR registries.

Why this matters

Enterprises are converging on a central container registry pattern that hosts artifacts and container images for multiple business units and application domains. In this model: 

• CI/CD pipelines from different parts of the business push container images and artifacts only to approved namespaces and repositories within a central registry.
• AKS clusters, Azure Container Apps (ACA), Azure Container Instances (ACI), and consumers pull only from authorized repositories within a central registry.

An Azure Container Registry containing images from different business domains across repositories and namespaces.

With ABAC, these repository and namespace permission boundaries become explicit and enforceable using standard Microsoft Entra identities and role assignments. This aligns with cloud-native zero trust, supply chain hardening, and least-privilege permissions.

What ABAC in ACR means

ACR registries now support a registry permissions mode called “RBAC Registry + ABAC Repository Permissions.” Configuring a registry to this mode makes it ABAC-enabled.

• When a registry is configured to be ABAC-enabled, registry administrators can optionally add ABAC conditions during standard Azure RBAC role assignments.
• This optional ABAC conditions scope the role assignment’s effect to specific repositories or namespace prefixes.

ABAC can be enabled on all new and existing ACR registries across all SKUs, either during registry creation or configured on existing registries.

Enabling ABAC on a new ACR registry by setting the permissions mode to "RBAC Registry + ABAC Repository Permissions" in the new registry creation flow.

Enabling ABAC on an existing ACR registry by setting the permissions mode to "RBAC Registry + ABAC Repository Permissions" in the Portal Properties blade.

ABAC-enabled built-in roles

Once a registry is ABAC-enabled (configured to “RBAC Registry + ABAC Repository Permissions), registry admins can use these ABAC-enabled built-in roles to grant repository-scoped permissions: 

• Container Registry Repository Reader: grants image pull and metadata read permissions, including tag resolution and referrer discoverability.
• Container Registry Repository Writer: grants Repository Reader permissions, as well as image and tag push permissions.
• Container Registry Repository Contributor: grants Repository Reader and Writer permissions, as well as image and tag delete permissions.

Note that these roles do not grant repository list permissions. 

• The separate Container Registry Repository Catalog Lister must be assigned to grant repository list permissions.
• The Container Registry Repository Catalog Lister role does not support ABAC conditions; assigning it grants permissions to list all repositories in a registry.

Important role behavior changes in ABAC mode

When a registry is ABAC-enabled by configuring its permissions mode to “RBAC Registry + ABAC Repository Permissions”: 

• Legacy data-plane roles such as AcrPull, AcrPush, AcrDelete are not honored in ABAC-enabled registries. For ABAC-enabled registries, use the ABAC-enabled built-in roles listed above.
• Broad roles like Owner, Contributor, and Reader previously granted full control plane and data plane permissions, which is typically an overprivileged role assignment. In ABAC-enabled registries, these broad roles will only grant control plane permissions to the registry. They will no longer grant data plane permissions, such as image push, pull, delete or repository list permissions.
• ACR Tasks, Quick Tasks, Quick Builds, and Quick Runs no longer inherit default data-plane access to source registries; assign the ABAC-enabled roles above to the calling identity as needed.

Identities you can assign

ACR ABAC uses standard Microsoft Entra role assignments. Assign RBAC roles with optional ABAC conditions to users, groups, service principals, and managed identities, including AKS kubelet and workload identities, ACA and ACI identities, and more.

Next steps

Start using ABAC repository permissions in ACR to enforce least-privilege artifact push, pull, and delete boundaries across your CI/CD systems and container image workloads. This model is now the recommended approach for multi-tenant platform engineering patterns and central registry deployments.

To get started, follow the step-by-step guides in the official ACR ABAC documentation: https://aka.ms/acr/auth/abac