Namespace permissions: AAD Support

[mangalorereshmi]

https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/31655977-configure-permissions-at-a-repository-level

[SteveLasker]

Repository scoped permissions are now in public preview. However, they are limited to Tokens.

Our plan has been to add repository scoped permissions for IoT scenarios (devices in the wild) and AAD based objects (services and people).

Our first priority was to enable IoT as enabling millions of devices, connecting from remote, or isolated networks was a blocker. Tokens enable near-infinite scale while limiting access to just the registry. We grouped the token feature with repo-scoped permissions.

Additional Investigations

While adding AAD based support, we received feedback that repo scoped permissions are great, but they need to be managed by individual teams. RBAC on folders/subfolders #338

We're currently investigating the following design, validating with customer calls:

TeamA and TeamB both share the contoso.azurecr.io registry. TeamA owns all the repos below:

• contoso.azurecr.io/teama/
  • contoso.azurecr.io/team-a/project-1/web
  • contoso.azurecr.io/team-a/project-1/api
  • contoso.azurecr.io/team-a/project-2/web
  • contoso.azurecr.io/team-a/project-2/queue-processor TeamB owns all the repos below:
• contoso.azurecr.io/team-b/
  • contoso.azurecr.io/team-b/project-3/web
  • contoso.azurecr.io/team-b/project-3/router
  • contoso.azurecr.io/team-b/project-4/web
  • contoso.azurecr.io/team-b/project-4/mail-processor

Today, the owner or contributor of the registry must assign permissions. This means the managers of TeamA and TeamB either need to be contributors of the entire registry, or they must each ask the contributors of the entire registry to configure permissions.

We acknowledge and recognize this gap and have been doing customer calls/research to understand exactly how teams would like their shared repositories managed.

• Is it just permissions that are delegated?
• Should we isolate audit-logs
• Should Webhook creation be limited to repos owned by the team?
• Should we use AAD groups to manage the teams?

While we appreciate teams are looking for repo-scoped permissions today, the impact to change is significant. Rather than release another preview, where the role names or group management would likely change, we felt it better to gather more info before making incremental improvements that we believe would change.

Next Steps

With many other commitments on our plate for the spring of 2021, we will spend the late spring researching and validating the new design and queue up development for the fall of 2021.

[SteveLasker]

For those tracking updates, I've made a few edits to identify that we've had to move this work out another 6 months.

[kn6405]

Any updates on this feature? I saw above it said development in fall of 2021 and we just reached fall. Hoping someone is working on this or will be picking it up soon. An application I'm working on now could really use this level of RBAC permissions in ACR right now. I'm really hoping for early 2022.

[PeterBennink]

Any update on this?

[mangalorereshmi]

Hi @PeterBennik,

This feature is on our roadmap. With many other commitments on our plate, we have not had a chance to prioritize this ask. Our plan here is to introduce a new resource type called Namespaces for ACR. A Namespace provides a way to group repositories within your registry. All repositories within a given namespace will share the same permissions. Example: In azurecr.io/foo/hello-world:v1 Namespace name = foo repo name = hello-world tag = v1 When available Namespaces will allow you to grant permissions to all repos within a Namespace to be accessed either by a SP, AAD user or an AAD group. Thanks, Reshmi

[davidkarlsen]

Hi @PeterBennik,

This feature is on our roadmap. With many other commitments on our plate, we have not had a chance to prioritize this ask. Our plan here is to introduce a new resource type called Namespaces for ACR. A Namespace provides a way to group repositories within your registry. All repositories within a given namespace will share the same permissions. Example: In azurecr.io/foo/hello-world:v1 Namespace name = foo repo name = hello-world tag = v1 When available Namespaces will allow you to grant permissions to all repos within a Namespace to be accessed either by a SP, AAD user or an AAD group. Thanks, Reshmi

That sound exactly what we're after. But still there is just talk for over two years. This is a feature you'll have in ECR with AWS from day one.

[johnsonshi]

Hi @davidkarlsen,

We're working on GA'ing https://github.com/Azure/acr/issues/412 (Repository-Scoped Permissions using Tokens and Scope Maps). That feature needs to be GA'd first before the other feature first because of internal engineering dependencies.

We're aiming for a preview sometime around 1st or second half of 2023 for this feature (Namespace-level permissions including support for AAD). It's coming and we're devoting resources to this.

[mosabami]

@johnsonshi first or second half of 2023 sounds like a whole year range. can we get something more specific? :)

[johnsonshi]

Hi @mosabami, I'd say around the middle of next year would be more accurate :)

[matthew-fawcett]

Given we're at (roughly) mid 2023 is there any update as to when this may be available?

[johnsonshi]

@matthew-fawcett - We have an internal prototype integration with ABAC and are undergoing testing. At this point, it is likelier that this feature will be available for private preview on the latter half of 2023 or the first few months of 2024.

Please understand that this is a complicated Authz feature, and the Azure team needs to extensively test this so that customer's cloud native workloads are secure with this new option of authorization through ABAC permissions.

[dev-bio]

@matthew-fawcett - We have an internal prototype integration with ABAC and are undergoing testing. At this point, it is likelier that this feature will be available for private preview on the latter half of 2023 or the first few months of 2024.

Please understand that this is a complicated Authz feature, and the Azure team needs to extensively test this so that customer's cloud native workloads are secure with this new option of authorization through ABAC permissions.

@johnsonshi Anywhere we can follow the progress on this?

[leomoreira]

@matthew-fawcett - We have an internal prototype integration with ABAC and are undergoing testing. At this point, it is likelier that this feature will be available for private preview on the latter half of 2023 or the first few months of 2024.

Please understand that this is a complicated Authz feature, and the Azure team needs to extensively test this so that customer's cloud native workloads are secure with this new option of authorization through ABAC permissions.

Any progress with that?

[mike-miller-ct]

@matthew-fawcett - We have an internal prototype integration with ABAC and are undergoing testing. At this point, it is likelier that this feature will be available for private preview on the latter half of 2023 or the first few months of 2024. Please understand that this is a complicated Authz feature, and the Azure team needs to extensively test this so that customer's cloud native workloads are secure with this new option of authorization through ABAC permissions.

@johnsonshi Anywhere we can follow the progress on this?

I jsut wanted to ask whether there is an update on this one? We desperately need this feature. Thank you

[johnsonshi]

Due to an unforeseen dependency, the delivery of this highly awaited feature (repository permissions through Entra ID attribute-based access control) has been delayed to the latter half of 2024.