RBAC on folders/subfolders

[burkhat]

What is the problem you're trying to solve We try to implement RBAC on project level (folder / subfolder). At the moment it is only possible to implement RBAC on a repository, see https://docs.microsoft.com/en-us/azure/container-registry/container-registry-repository-scoped-permissions

Describe the solution you'd like It would be good that it is possible that you can set permissions on folders / subfolders. For example we have following structure:

• Project1
  • image1
  • image2
• Project2
• ...

So we want to only create one access token for the whole folder Project1/* that we don't need to recreate / update the token if a new image will be pushed to the Project1 folder.

Additional context

[sajayantony]

/cc @mangalorereshmi

[yugangw-msft]

We did talk about this before, but it was deemed too complex. Either way, we will reconsider it before GA repository based permission.

[jomeier]

This feature is a "must have" in my opinion. Without it each team must create three ACR instances (for dev/qual/prod stages) because you need the seperation and don't want team members working in the dev environment to accidently overwrite images on prod.

VmWare Harbor does this very well. And in my opinion it's absolutely crucial for the success of the ACR to implement that. This would be a great feature.

[jomeier]

@burkhat: Congrats for your first github issue :-)

[jabbera]

Yeah. I agree this is a must have. We have namespaces dedicated to teams. I don't care what they put in there. With this current configuration if they want to create a new image they have to get an admin to push it first, reconfigure their scope, then they can push it.... It's crazy town.

https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/40006789-allow-token-scope-to-be-at-the-namespace-level

[SteveLasker]

Thanks for the feedback. Namespace permissions adds quite a set of complexity and perf implications. What if: a group of users could be granted repo create rights? They would then own the repo and could create scope maps for others to have access.

[jabbera]

If that right can be scoped to a namespace that would be fine:-) The issue is I'm managing 30 development teams each of whom are responsible for their own containers. I want to use a single registry, not 30 to simplify image scanning etc. If every time a user needs to create a new repo someone from my team or centralized IT needs to get involved we are going to have a bad time.

[SteveLasker]

Thanks @jabbera, this is helpful. The problem we're trying to avoid is managing a large graph of namespace hierarchies. We're already facing this a bit with registry rights. If I'm owner of a registry, what happens when my same AAD id is limited to a single repo within a scopeMap? (Note: AAD objects will be soon supported within ScopeMaps as well.) A single root repo is an option. What do you think about giving a set of users (dev managers for instance) the ability to create repos within a registry. Not at a namespace, rather the root of the registry. They can create as many as they'd like. They own that repo, or any collection of repos they create. They can create scopeMaps for their team members. The rest of the team wouldn't have repo-creation rights, but would have rights given to them by the repo-creator.

[jabbera]

@SteveLasker It's so similar to the workflow I'm suggesting that I don't really see how it makes things better. I'm probably just going to end up automating this whole thing as everyone has AcrPull. The only thing we are trying to prevent is pushes from deployment accounts for containers they don't own.

[jomeier]

@jabbera: That's exactly what we also want to avoid: that devs can overwrite images they don't own.

Currently we are thinking about providing three ACRs to our devs: for dev/qual/prod. Thats overkill.

[sajayantony]

@jomeier - We actually split it similarly. This is primarily for things like network isolation. Prod doesn't share VNETs. So depends on the scenario and degree of isolation you require.

[SteveLasker]

To Sajay's point, you may need multiple ACRs for network isolation or geo-replication reasons, but your point of multiple teams being able to share a common registry in any one of these is still valid. We're meeting about this later today, so here's some questions: Considering the different options:

1. An "admin" can create a set of root repos, allocated to a set of people (team-a, team-b, ...). Team-a lead can then control that root namespace for their team and create other repos under team-a\
2. An "admin" can give the same team-a, team-b leads ability to create repos. They can create repo they like, as long as the path exists. Just because they can create a repo, doesn't mean they have admin privileges.

• Team-a lead would create team-a\repo1, team-a\repo2
  • Team-a lead would create a scopemap for their team, giving any permission they want to this repo. They would not have permissions to edit permissions to repos they don't own.
• Team-b lead would create team-b\repo1, team-b\repo1
  • team-b lead would do the same as above. However, they also don't have any permissions to edit or access repos they don't own.

We'll discuss the technical tradeoff later today, but from an experience perspective, I'm trying to understand the differences. In example 1, the "admin" of the registry would still need to grant ownership of a root namespace. In scenario 2, we have the same model, except we have a set of leads that can create any repo they want, without having to go back to the admin, and without having access to another teams repo.

We have to figure out the role names here - hopefully this is the hardest part.

[jabbera]

@SteveLasker Let me walk through my actual workflow and maybe you can tell me what you think:

1. Everyone has AcrPull across the entire registry via RBAC. No end users have mutation rights at all.
2. We issue tokens to our deployment accounts that are mapped to a given scope map with push.
3. When someone commits a new dockerfile the deployment account will build it and push it. This is how we ensure what's committed to git is actually whats in the registry.

In this case, who get's ownership of the repo since it's just a token? Does it automatically update the scopemap?

[wsmckenz]

Very important for us. We need to be able to use namespace as a scope. This could even be as simple as wildcards or regex in the scope (jFrog does this, and it works brilliantly). Like @jabbera said, The problem is that assigning or editing a scope requires a service now ticket and an admin. It makes it almost impossible for teams manage their own namespaces, which often get created automatically by CI/CD processes.

[SteveLasker]

Thanks William, We’ve taken a pause on the AAD supported scopes token as we complete the research on org management. One of the questions is how do you want to scope logs? Should teama be able to see teamb’s diagnostic logs? Is namespace enough? Or, do you need a team associated with a set of arbitrary repos.

• registry.azurecr.io/dev/teama-web
• registry.azurecr.io/dev/teamb-web
• registry.azurecr.io/prod/teama-web
• registry.azurecr.io/prod/teamb-web

If you’re interested in helping us with a research call, please reach out at steve.lasker at microsoft dot com.

[jabbera]

Anything you can share on this?

[jomeier]

Come on Microsoft: Listen to your customers. We need that feature.

[SteveLasker]

Hi @joneier and @jabbera, We share your concern and don't want you to feel we're ignoring you.

Why are we waiting, if it's so important?

This is a fairly complex and large feature. We initially launched ACR Tokens with scope maps to provide repo level permissions. We were about to add AAD support but got clear feedback we can't force a single owner of the whole registry to manage permissions for multiple teams. We also heard we need to align the definition of a group (access to a collection of repos) and give equal access to AAD objects and Tokens. In other words, we shouldn't have one way to define access for tokens, and another way to define access for AAD objects. The initial feedback for repo groups is positive, and we are doing the design work to hopefully start execution in the fall.

A bit more background, if interested: As the service grows, so does the complexity of adding these types of important features. There are many large rocks we're building this semester, including IoT on-prem support, completing the gaps for Azure Security Center, AML and other trusted services to access ACR when placed under Private Link, Availability Zone support additional regions, AKS Teleport, Notary v2 signing, completing some dependencies for completing CMK, Region Move, Quarantine and the list goes on.

We realize not all of the above capabilities are the top priority for every customer, but these are the ones we've had to prioritize through the summer. To attempt and add Repo Groups would have asked the team to multi-task too many concurrent efforts, and we felt it more important to do fewer things more completely, than more things less completely, creating more frustration for our users with features you would feel aren't ready to ship.

Please keep the voting and feedback. This does help us keep this at the top of the list, comparing with other features at UserVoice

[alexdegroot]

There are multiple items now on the Uservoice:

https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/40006789-allow-token-scope-to-be-at-the-namespace-level https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/41247682-allow-wildcard-in-scopemap-repository-namespace-co

I know the need is there, especially when you look from multi-team development and Zero Trust principles in accessing the ACRs.

[alexdegroot]

@SteveLasker do you expect this will be on the roadmap for 2021H2?

[SteveLasker]

We’re finalizing the plan for the next 6 months. @mangalorereshmi for details.

[MadCat33]

Our organization is also waiting for this feature to be implemented.

[AntonioNaranjo1]

any new? is a necessary feature, we need it in our organization

[shana]

+10 on namespace support, please. If every time someone wants to push a new image all the scopes need to be updated and an admin has to get involved, it's a huge pain. Same for external CI tokens that act on multiple repos: the system-generated AcrPull scope doesn't have metadata/read on it, so if CI needs more than just content/read, it now suddenly needs full admin permissions on the registry.

[michaelgrossopt]

This is also a major pain point for our team. We're building a mult-tenant platform and would like to namespace folders/repositories (and ideally apply permissions using a service principal and AAD) that allow arbitrary image names (bonus points if it can be an arbitrary folder structure as well).

[mot256]

There are multiple items now on the Uservoice:

https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/40006789-allow-token-scope-to-be-at-the-namespace-level https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/41247682-allow-wildcard-in-scopemap-repository-namespace-co

I know the need is there, especially when you look from multi-team development and Zero Trust principles in accessing the ACRs.

Also, looking namespace level scopes I believe user voice links (mentioned above) have changed to https://feedback.azure.com/d365community/idea/07782a68-0d25-ec11-b6e6-000d3a4f0858 and https://feedback.azure.com/d365community/idea/12782a68-0d25-ec11-b6e6-000d3a4f0858

[jabbera]

Here is a similar ask: https://github.com/Azure/azure-cli/issues/11315

[alvispu]

@SteveLasker or anyone else - is there any updates and estimates around this? Previous comments already explains the importance of this feature but a long time has passed in waiting. Need to start looking on alternatives of ACR?

[Spaanseh]

Do I see this correctly when I state that this would be a combination of AAD Workload Identity (receive an AAD Access Token) and ACR token authentication (uses AAD Access Token as input) to then be able to get scope-limitation enabled? If so; Ignite 2022 made clear AAD Workload Identity will become available starting this November, making the path towards scope-limited access viable.

[johnsonshi]

Hi @Spaanseh, @jabbera, @alvispu, @mot256, @michaelgrossopt, @shana, @AntonioNaranjo1, @MadCat33, and @alexdegroot,

The timeline for namespace permissions (ability to scope permissions and tokens at the namespace level) will be Preview around June next year. This feature will also have AAD support, adding support to assign AAD roles at the namespace scope.

To help you understand our timeline, we'll need to first GA #412 (repository-scoped tokens and scope maps), which is currently in Public Preview. That other feature (#412) is heading to GA in 1st half of 2023.

This feature (#338 - Namespace permissions and permissions on folders aka "namespaces") has internal engineering dependencies on the other feature for repository-scoped tokens and scope map permissions (#412). We're currently working on getting #412 out of the door as soon as possible so that we can work deliver a preview for this feature #338.

Again, thank you for understanding our timelines.

(On a related note, #380 is a relevant issue for this feature #338).