Allow assigning ABAC conditions to "Container Registry Data Importer and Data Reader" role to restrict imports to specific repos in target ACR

[jabbera]

What is the problem you're trying to solve

We publish transient images to a location like <registry>.azurecr.io/appname/temp/runtime:latest
When they get promoted to production we retag the image to <registry>.azurecr.io/appname/runtime:latest using az acr import since the images are large (15GB or so). With ABAC we can lock down docker push/pull/etc to the /appname/* repo, but we can't do that with import. The docker pull cycle is very long due to image size so we would prefer to use az acr import

Describe the solution you'd like
az acr import should be abac aware.

[johnsonshi]

What are you observing? That role can be used to import images from an ABAC-aware upstream ACR to an ABAC-aware downstream ACR.

[jabbera]

@johnsonshi I can't assign any conditions to the Role so I can't limit the target. For example:

az acr import -n myregistry --source docker.io/library/hello-world:latest -t app/targetrepository:targettag

In this case I have to grant Container Registry Data Importer and Data Reader with no conditions at the root of myregistry allowing the user to import anywhere into myregistry. I want to be able to restrict them to only import into app/* just like I can with docker push.

[johnsonshi]

Thanks for the feedback — that's a fair point. Unfortunately, this isn't something we are planning to support at the moment due to technical limitations (documented) and also priorities. Here's why:

• Importing an image to a target ACR registry requires the control plane Entra permission Microsoft.ContainerRegistry/registries/importImage/action, which is bundled in the Container Registry Data Importer and Data Reader role. The challenge is that this control plane permission isn't currently ABAC-aware, which means there's no way to scope it down granularly.
• As a result, there's currently no solution for proactively promoting or propagating (through az acr import) an image from an upstream registry to a specific downstream registry without granting the identity running the workflow broad access to the downstream registry's data plane.

ACR's artifact cache feature is the closest thing we have to this today — but it falls short because it's reactive rather than proactive. Images only get pulled from the upstream to the downstream registry when a pull event is triggered on the downstream side, rather than being pushed on a schedule or as part of a pipeline.

That said, we do have something in the works: a Workflows feature that would let customers build custom registry workflows tailored to their needs. It's still in internal development, but we're working toward a private preview. Would you be interested in being an early participant?

[jabbera]

@johnsonshi if you think it would solve my problem. I have a bunch of really complicated azure devops pipelines right now that I'm copy pastaing all over the place to do the promotion workflow.