Grant `metadata/read` permission to `_repositories_pull` scope map

[dubitor]

What is the problem you're trying to solve I'm using an ACR as a helm registry. When I run helm dependency update I get a 401: could not retrieve list of tags. However, running helm pull to get the chart in question works fine.

I believe this is because tags are metadata, and my AD identity is assigned _repositories_pull permission which only has content/read and not metadata/read.

Describe the solution you'd like I would like the _repositories_pull scope map to have metadata/read permission to make ACR helm registry functionality work smoothly.

Additional context I've tried fixing my problem by making a token with both content/read and metadata/read scope over the ACR. However when I run helm registry login with this token I get the following error: unauthorized: Application not registered with AAD.

I can think of two getting it to work, neither of which are particularly secure. Either I can use the admin user, or a service principal. It seems to me that my proposed solution (above) would be preferable. I can't think of a good reason for not granting read permission for metadata to those with read permission for content - I believe metadata just means manifests and tags. But I appreciate there may be a good reason, even if I can't think of it! :) Thanks.

[juliusl]

So _repositories_pull scope_map is locked down to content/read because if a token with that permission leaked then the advisory wouldn't be able to enumerate the registry. In most cases container runtimes just need to pull/run the image so that's what that built-in is meant for.

You should be able to create a new scope_map with content/read, metadata/read. Not sure why you're getting that issue with helm though. My guess is that helm client isn't retrying w/ the registry client, because the required scope to enumerate tags is scope:<repository>:metadata_read and it looks like most clients start with pull.

Here is an example script you can use to list tags with the scope_map token,

#!/bin/bash

# $1 is username
# $2 is password
# $3 is registry name
# $4 is repository name

ENCODED_CREDENTIALS=$(echo -n "$1:$2" | base64)

ACCESS_TOKEN=$(curl --location \
     --request GET 'https://$3.azurecr.io/oauth2/token?service=$3.azurecr.io&scope=repository:$4:metadata_read' \
     --header "Authorization: Basic $ENCODED_CREDENTIALS" | jq -r '.access_token')


curl --location \
     --request GET 'https://$3.azurecr.io/v2/$4/tags/list' \
     --header "Authorization: Bearer $ACCESS_TOKEN" -v

You can also use az acr repository show-tags -- See this, https://docs.microsoft.com/en-us/azure/container-registry/container-registry-repository-scoped-permissions#show-repo-tags

Does this answer your question?

[vasdee]

Apologies for the bump on this issue but I'm facing this right now. In my use case, I'm attempting to use the _repositories_pull scope map token within azure iotedge. It seems to require the metadata/read permission in order to serve containers at the edge for itself and any child edge devices.

Pull + metadata read would fit nicely in this scenario from a security point of view. Managing the access on a per repo basis without having the ability to wildcard the repositories would be unmanageable in my situation

[vasdee]

it would be nice if the baked in scope maps somewhat matched what is provided by roles. In my case a _repositories_read scope map would fit perfectly my iot use case

https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[johnsonshi]

We now have a default scope map called _repositories_pull_metadata_read that has both content/read and metadata/read permissions. This should address the ask here.