ACR Auth - ABAC-Enabled Registries as Default with Breaking Change Migration for Existing Non-ABAC (RBAC-Only) Registries
- Dominant language
- No language data
- Stars
- 177
- Forks
- 137
- PR merge metrics
- No merged PRs in 30d
Description
# Overview
### Description
This roadmap item tracks ACR's plan to make ABAC-enabled registries (RBAC + ABAC role assignment permissions mode) the default for all Azure Container Registries, including migrating existing registries via a breaking change.
### Context
Azure Container Registry supports [Azure attribute-based access control (Azure ABAC)](https://aka.ms/acr/auth/abac) for managing repository permissions. ABAC-enabled registries use a different set of built-in roles and provide more granular, repository-level permissions management compared to legacy RBAC-only registries.
Today, new registries can opt into ABAC-enabled mode, but existing registries default to RBAC-only mode. The long-term plan is for **all ACR registries to operate in ABAC-enabled mode (`rbac-abac`)**.
### Breaking Change
Migrating existing registries from RBAC-only mode to ABAC-enabled mode is a **behavior breaking change** with security implications. Key impacts include:
- **Legacy ACR roles (`AcrPull`, `AcrPush`, `AcrDelete`) are not honored in ABAC-enabled registries.** Customers must migrate to the new ABAC-enabled roles (`Container Registry Repository Reader`, `Container Registry Repository Writer`, `Container Registry Repository Contributor`) before or at the time of migration.
- **Privileged roles (`Owner`, `Contributor`, `Reader`) have different effects in ABAC-enabled registries.** These roles grant only control plane permissions and no longer grant data plane access to repositories and images.
- **ACR Tasks, Quick Tasks, Quick Builds, and Quick Runs** no longer have default data plane access to an ABAC-enabled source registry and its content, and require explicit role assignments.
- **Switching an existing registry to ABAC-enabled mode without first assigning equivalent ABAC-enabled roles risks cutting off access for existing identities.**
For a full description of the effects and the recommended migration guide, see the [ABAC for repository permissions documentation](https://aka.ms/acr/auth/abac).
### Proposal
ACR plans to:
1. Make ABAC-enabled mode (`rbac-abac`) the **default role assignment permissions mode** for all newly created registries.
2. **Migrate all existing registries** from RBAC-only mode to ABAC-enabled mode via a breaking change, with advance notice and migration tooling/guidance.
Customers are encouraged to proactively migrate their registries to ABAC-enabled mode using the [recommended migration guide](https://aka.ms/acr/auth/abac) to prepare for this transition.
### Related Resources
- ABAC for repository permissions documentation: https://aka.ms/acr/auth/abac
---
# Milestones
### ⏳ Planned
- [ ] ABAC-enabled mode is the default for all newly created registries
- [ ] Migration tooling and guidance for existing registries
- [ ] Breaking change rollout to migrate all existing registries to ABAC-enabled mode
---
# Status
**Planned** — no timeline yet. Follow this issue for updates. Customers are encouraged to begin proactive migration using the [ABAC documentation](https://aka.ms/acr/auth/abac).
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.