search

Azure / azure-cli

Azure Command-Line Interface
MIT License
3.98k stars 2.96k forks source link

Wildcards in repository names #11315

Open mkstephenson opened 4 years ago

mkstephenson commented 4 years ago

When defining the repositories in the scope-map, can you use wildcards? So if you have a convention that each repository is named <team_name>/<project_name>, you could use <team_name>/* to provide a team with access to all of their repositories without listing each one individually and also automatically provide access to any future repositories created by this team?

Dokumentdetails

⚠ Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.

ghost commented 4 years ago

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @stevelasker, @sajayanthony

yugangw-msft commented 4 years ago

Thanks for the suggestions. Repository based permission control is still under preview, and we will take this feedback into consideration and update here when we roll out any improvements.

shwetazambre commented 4 years ago

I am also looking for a help on "Wildcards in repository names ", any update on this?

SteveLasker commented 4 years ago

Hi folks. We’re looking into various options. Can you provide more details on what the result is you’re looking to accomplish?

shwetazambre commented 4 years ago

I created a scope map with a wildcard so that many repositories can make use of it. And with this scope map generated a token and logged in to the registry. But I couldn't perform any operation like a pull or push.

e.g repositories:

test/myrepo test/myrepo1 test/myrepo2 test/myrepo3

Scope-map I have created:

az acr scope-map create --name MyScopeMap --registry MyRegistry --repository **test/*** content/read content/write --description "test scope map"

Result: { "actions": [ "repositories/test//content/read", "repositories/test//content/write" ], "creationDate": "2020-04-20T11:27:49.643716+00:00", "description": "test scope map", "id": "/subscriptions/****----****/resourceGroups/mytest-rg/providers/Microsoft.C ontainerRegistry/registries/MyRegistry/scopeMaps/MyScopeMap", "name": "MyScopeMap", "provisioningState": "Succeeded", "resourceGroup": "mytest-rg", "scopeMapType": "UserDefined", "type": "Microsoft.ContainerRegistry/registries/MyScopeMap" }

Scope map has created successfully and even token too. But when I logged in with that token and try to pull/push I ended up with below message:

pull - docker pull myregistry.azurecr.io/test/myrepo:v1

message:

"Error response from daemon: repository myregistry.azurecr.io/test/myrepo not found: does not exist or no pull access"

push - docker push myregistry.azurecr.io/test/myrepo:v2

message:

The push refers to a repository [myregistry.azurecr.io/test/myrepo] a65c16532822: Preparing 75b1b9938a41: Preparing 94a7e5001357: Preparing fea4f503ccf8: Preparing 3172a1c8308a: Preparing 264a7fdea008: Waiting 3b10514a95be: Waiting denied: requested access to the resource is denied

SteveLasker commented 4 years ago

@shwetazambre, thanks for the details. We don’t support wildcards like this. Based on feedback like this, we’re re-evaluating the approach and are seeking feedback. Can you explain what you’re trying to accomplish? Are you looking to have management delegation to team leads for a set of repos? Or, can a single set of people manage permissions for all teams? In other words, do you need permissions isolation between teams? TeamA can manage their set of repos, while teamB manages their repositories? The owners of TeamA can’t manage TeamBs repos

mkstephenson commented 4 years ago

@shwetazambre, thanks for the details. We don’t support wildcards like this. Based on feedback like this, we’re re-evaluating the approach and are seeking feedback. Can you explain what you’re trying to accomplish? Are you looking to have management delegation to team leads for a set of repos? Or, can a single set of people manage permissions for all teams? In other words, do you need permissions isolation between teams? TeamA can manage their set of repos, while teamB manages their repositories? The owners of TeamA can’t manage TeamBs repos

That is the approach we were looking for as well. We need to be able to assign repo based permissions and would prefer not to have to define it for every single repo since we work with prefixes for teams.

SteveLasker commented 4 years ago

We’re considering two approaches. The wildcard approach, which could give different groups different access. The second approach is about delegating management to teams. Imagine an Org like management approach similar to github or docker hub. The later is a lot more complicated to split permissions and logs. But, we’d rather understand that now, before we implement wildcards that won’t scale. Which approach do you need?

shwetazambre commented 4 years ago

As far as I know, we are looking for an approach similar to the first one. Here I consider the group as a project/team. If we assign read-only permission for project1/team1 then all repositories under that project/team will have the same permission. Different projects will have different permissions and all repositories, sub-repositories will work according to that permissions.

BenjaminHerbert commented 4 years ago

We like the concept of namespaces, as that is described in a section in the "best practices". I'd like to enable teams full access to one or several "namespaces". I guess that could work with tokens & wildcard scope maps, but I can imagine this not scaling well. So we'd prefer a "full fledged" solution to be able to control access to namespaces for groups - ideally without tokens - distributing these will definitely not scale.

ajhall commented 4 years ago

We're looking for this feature too and would upgrade to the Premium SKU if it was available. Our needs are fairly simple right now, so the first approach would be sufficient for us, but I could see some benefit to the second approach as well.

shaunco commented 4 years ago

+1 on this request. Given that a docker push can dynamically create new repositories, creating a read or write token that has access to company/* would be super helpful.

I should add that the only reason I need to define custom scope-maps is because the built in scope maps don't include metadata read/write. That is:

Which breaks docker buildx as used in Docker's official docker/build-push-action@v2 github action.

It would also seem there are a few more votes for this at https://feedback.azure.com/forums/903958-azure-container-registry/suggestions/40878493-give-the-repositories-pull-repositories-push-m

soring-isb commented 3 years ago

+1 on this request. Not being able to use wildcards or use directories to scope permissions makes this nigh unusable.

AntonioNaranjo1 commented 3 years ago

+1

steffen201706 commented 3 years ago

+1 something like reponame/* or "shortcut" reponame/

galigula2 commented 3 years ago

+1 This would be very useful when planning deployment scenarios where product names are namespaces and access needs to given in multiple setups.

illrill commented 3 years ago

@SteveLasker any further news in this area? I want everyone in my company share a single ACR, but only allow individual teams push permissions to their own "namespace".

companyacr.azurecr.io/customerteam/ companyacr.azurecr.io/productteam/

SteveLasker commented 3 years ago

This is the plan, to align AAD objects, Tokens and namespace hierarchy of access. We have been discussing the root namespace for a team can have slashes to account for these types of paths

companyacr.azurecr.io/baseartifacts/ companyacr.azurecr.io/org1/teama/ companyacr.azurecr.io/org2/teama/ companyacr.azurecr.io/prod/ companyacr.azurecr.io/archive

It won’t actually be star wildcards, rather repo path based.

Will that work? @mangalorereshmi for details.

galigula2 commented 3 years ago

@SteveLasker not sure what you mean by "teams" in this context? We have multiple teams working with group of products (sometimes same people work also on different products) so our scheme would be

companyacr.azurecr.io/product-a/service-a companyacr.azurecr.io/product-a/service-b companyacr.azurecr.io/product-b/service-c companyacr.azurecr.io/product-b/service-d

We'd like to create push Scope maps to match e.g. companyacr.azurecr.io/product-a/ to be able to push to all repositories under a single product and pull Scope maps with read access to product-a/ and product-b/* so we can combine containers from multiple products.

Not sure how this team model would work in this case?

Perhaps the * wildcard could work in tandem with the team feature? We're basically just looking to avoid typing and managing all of the repositories manually.

SteveLasker commented 3 years ago

@galigula2, Reshmi is off this week, so let me try and explain a bit.

Reshmi has designed a repo-group option, which is essentially a github or docker hub org. The big difference is we can provide /'s within the org name, or the repo name so you get more flexibility.

Using your example above, you could create companyacr.azurecr.io/product-a/ and all repos below it would be managed by the admin of product-a.

What this can also look like is:

The root of the repo-group may also have /'s in the names, so you can structure your repo-groups alongside your company lines.

galigula2 commented 3 years ago

So this would require us to re-push all of the images to a separate prod-repository for the image if we want to have a single place to read from? And then we would still need to list all of the prod-repositories separately in all scope maps we want to read them from? In this case I would still prefer writing prod/*. Or did I misunderstand something in the way read scope-maps would work in this case?

What about a use case where we want to import public images to ACR to safeguard against build problems later. It would be really convenient to have them all under e.g. externals/ namespace in the registry and just allow externals/* so we don't need to specifically list all repositories in all of the scope maps that need them. There are public images and not under any team in our organization.

Ayatallah commented 3 years ago

I created a scope map with a wildcard so that many repositories can make use of it. And with this scope map generated a token and logged in to the registry. But I couldn't perform any operation like a pull or push.

e.g repositories:

test/myrepo test/myrepo1 test/myrepo2 test/myrepo3

Scope-map I have created:

az acr scope-map create --name MyScopeMap --registry MyRegistry --repository **test/*** content/read content/write --description "test scope map"

Result: { "actions": [ "repositories/test//content/read", "repositories/test//content/write" ], "creationDate": "2020-04-20T11:27:49.643716+00:00", "description": "test scope map", "id": "/subscriptions/****----****/resourceGroups/mytest-rg/providers/Microsoft.C ontainerRegistry/registries/MyRegistry/scopeMaps/MyScopeMap", "name": "MyScopeMap", "provisioningState": "Succeeded", "resourceGroup": "mytest-rg", "scopeMapType": "UserDefined", "type": "Microsoft.ContainerRegistry/registries/MyScopeMap" }

Scope map has created successfully and even token too. But when I logged in with that token and try to pull/push I ended up with below message:

pull - docker pull myregistry.azurecr.io/test/myrepo:v1

message:

"Error response from daemon: repository myregistry.azurecr.io/test/myrepo not found: does not exist or no pull access"

push - docker push myregistry.azurecr.io/test/myrepo:v2

message:

The push refers to a repository [myregistry.azurecr.io/test/myrepo] a65c16532822: Preparing 75b1b9938a41: Preparing 94a7e5001357: Preparing fea4f503ccf8: Preparing 3172a1c8308a: Preparing 264a7fdea008: Waiting 3b10514a95be: Waiting denied: requested access to the resource is denied

+1 same feature needed!

realsenseme commented 3 years ago

I'm so looking for this. Is there any update on this feature? With microservice architecture, it is very likely that an application ends up having tens of repos and scoping with grouping or with wildcards would be necessary to make the use of scope-maps relevant. Otherwise it is not a very useful feature in the process of automation.

AntonioNaranjo1 commented 3 years ago

any new? is a necessary feature

yonzhan commented 3 years ago

container registry service team should take a look

felfa01 commented 2 years ago

@SteveLasker Any updates on this? It is a much sought-after feature for us.

dancave72 commented 2 years ago

Whilst i like the granular nature of being able to control what gets written to a repository at root level - when considering that a user might have 10's or 100's of additional container images they want to push into that repo, currently means having to configure this for each repo as code or manually is a bit of a headache (in the same way Amazon ECR works )

+1 more for this wildcard feature please.. I would like to have several dev teams push existing images into several repos in ACR, using the token and scope map accordingly.

Muchas gracias

@SteveLasker fyi / team

MattiasSjobom commented 2 years ago

Wildcard is a must have for Enterprise companies using a shared ACR, +1 for this feature. An update on the current status and estimated implementation date would be highly appreciated.

Thanks!

rickynguyen4590 commented 2 years ago

We are using single ACR for multiple clients, each client should have dedicated namespace with the following repo /client1/web, client1/api ..So we just provide our client username/password and start to pull their images....

martijndebruijn commented 2 years ago

Any news? This feature request is open since 2019! Please provide wildcard support a.s.a.p.

dinilimento commented 2 years ago

Must have feature for us as well

SteveLasker commented 2 years ago

Hey folks, apologies. We have heard the ask and need. Adding @mangalorereshmi for the latest.

nfsouzaj commented 2 years ago

+1 more for this wildcard feature please... life is very difficult without it.

ghost commented 2 years ago

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @toddysm, @luisdlp, @northtyphoon.

Issue Details
When defining the repositories in the scope-map, can you use wildcards? So if you have a convention that each repository is named <team_name>/<project_name>, you could use <team_name>/* to provide a team with access to all of their repositories without listing each one individually and also automatically provide access to any future repositories created by this team? --- #### Dokumentdetails ⚠ *Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.* * ID: ef39d073-f33a-44c5-9cd1-4f30ea881230 * Version Independent ID: a28f7fa6-d25a-c205-14e7-aa8d474a87c9 * Content: [az acr scope-map](https://docs.microsoft.com/de-de/cli/azure/acr/scope-map?view=azure-cli-latest#az-acr-scope-map-create) * Content Source: [src/azure-cli/azure/cli/command_modules/acr/_help.py](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/acr/_help.py) * Service: **container-registry** * GitHub Login: @rloutlaw * Microsoft Alias: **routlaw**
Author: mkstephenson
Assignees: toddysm
Labels: `Service Attention`, `Container Registry`, `customer-reported`, `feature-request`
Milestone: -
navba-MSFT commented 2 years ago

@mkstephenson Apologies for the late reply. We are looking into this issue. We will update this thread once we have more details on this.

@toddysm @luisdlp @northtyphoon @mangalorereshmi Could you please provide an update on this feature request ? Awaiting your reply.

dejeroWilliamScott commented 2 years ago

I'm also interested in this feature. We've manually expanded the scope as a workaround but have discovered a limit of 500 actions/scope group. This would be reduced to 4~10 with the implementation of wildcard rules.

knoxi commented 2 years ago

+1 for this feature, it would be really helpful

any news on this?

doanduyhai commented 2 years ago

+1 on wildcard feature to manage access on namespaces

delian commented 2 years ago

Same here, scope maps should support wildcards, or a top level scope (aka, ending with a /).

steerben commented 2 years ago

+1 as it supports multitenancy. Scope maps are great but whildcard support on the namespaced repos is really mandatory to leverage it to the full extent. Otherwise this is a huge maintenance overhead when it comes to increase and reduce scopes of the scope maps for every repo.

danijam commented 1 year ago

Just want to add our desired use case. This week we started to build out a internal container registry platform for our engineering teams based on ACR. The ACR would have copies of public up stream repositories like node or nginx which all teams require read access. The public images would be under a public namespace: /public/node or /public/nginx. Teams wanting to "cache" a new tag or new repository from an upstream source do that via a Git repo we've built that has a pipeline with write authorization to the ACR resource. So, we've automated the adding of new public upstream images with a bit of engineering platforming.

The teams will also push to their own repositories (Their own services etc). We followed the practise of namespaces like:

My ask would be to assign 2 scope maps to each token: 1) the system defined assignment to the pull scope map

Desired outcome is all teams can pull from our internal container registry platform. But they can only push to their namespace. We've minimized the amount of administration. Teams can self-service create new repositories under their namespace without a handoff.

As of today, because each token can only be assigned to a single scope map and scope maps can't have wild cards for repositories, we need to create a scope map per team that both grants global read and specific writes. Due to no wild cards each repository needs to have a line item per repository. All being read and only their team namespace having write. This scope needs to be updated every time either a public upstream repository is created, or a new team owned repository is created. This is really hard to make self service.

fawadasaurus commented 1 year ago

Please add wildcard support to repository scope maps. This would be great.

mjeco commented 1 year ago

+1 for this feature. Would be really useful!

Danielkem commented 1 year ago

Any updates? @navba-MSFT

navba-MSFT commented 1 year ago

@Danielkem This GitHub issue is assigned to @toddysm .

@toddysm Could you please provide an update on this feature request ?

imadazzam-dejero commented 1 year ago

+1 for this feature. Would be very helpful!

shaneward commented 1 year ago

+1 for this feature. We are trying to build a shared service with separation between teams who are working with multiple images. Maintaining tokens per repo is a large barrier for us to offer an efficient, maintainable solution.

toddysm commented 1 year ago

Sorry folks for not following up here. I am working on a different area but @leodewang can follow up with this ask.

johnsonshi commented 1 year ago

Hi all, Johnson here. I'm responsible for ACR's permissions features. We are designing a feature based on Azure's Attribute-Based Access Control (ABAC).

To give you all an idea of what the experience will be like, let's see the following Storage Accounts example which is in Public Preview today. If you try to assign a Storage Blob Data Reader role, it will show you a Conditions (preview) tab which will allow you to grant read permissions "only if a storage container name matches a prefix". This solves the issue where customers want to grant access to all storage container names without enumerating each one.

image

We are designing an ABAC experience for ACR as well. This would allow you to assign AAD read permissions to users and grant read access "only if a repository name matches a prefix". This allows registry admins to grant read access WITHOUT enumerating each repository. It also allows registry admins to SELECTIVELY GRANT read access to only specific repositories without granting read access to the entire registry.

image

Timeline for this feature to preview is still being determined, but we've already pretty much locked down the design on this. Much progress has been made on this and we'll keep you in the loop on this.

fawadasaurus commented 1 year ago

@johnsonshi @leodewang

This is not what we are asking for.

We are all talking about scope-maps

image

I want to be able to create scope map that allows access to alerta images like this: image

I can not save this because wildcards are not supported. Please make wildcards supported here.

The reason that we are using scope maps is because we are using tokens. This is a much easier way to administer robot accounts than using the ABAC and AAD like you have shown.

It is unfortunate to hear that you say we've already pretty much locked down the design on this. considering it's not what was asked in this ticket.