ACR image build does not work when no public access

Question

ACR image build does not work when no public access

Closed this issue a year ago · 6 comments

Background

When I use other services, i.e. storage accounts, I can set Allow Azure services on the trusted services list to access this storage account and the service behaves correctly.

So, I expect that an ACR task is able to integrate to an ACR irrespective of the public network access, when "trusted Microsoft services" are enabled. However, it fails when I build an image.

ACR Network Settings

Build Image

az acr build --image demo:latest --registry 181osz9j9ediz5yv ~/acr/app
Packing source code into tar to upload...
Uploading archived source code from '/var/folders/18/tzm2v2dn5c9fg367ykw1bdqc0000gn/T/build_archive_f877c1f1a36a407bb20f908c5bb8bd5c.tar.gz'...
Sending context (382.000 Bytes) to registry: 181osz9j9ediz5yv...
Queued a build with ID: cs2
Waiting for an agent...
2022/12/19 03:15:33 Downloading source code...
2022/12/19 03:15:34 Finished downloading source code
2022/12/19 03:15:34 Using acb_vol_e4e4768c-6a14-4af2-97c1-ee4312553bac as the home volume
2022/12/19 03:15:34 Setting up Docker configuration...
2022/12/19 03:15:35 Successfully set up Docker configuration
2022/12/19 03:15:35 Logging in to registry: 181osz9j9ediz5yv.azurecr.io
failed to login, ran out of retries: failed to set docker credentials: Error response from daemon: Get https://181osz9j9ediz5yv.azurecr.io/v2/: denied: client with IP '104.46.161.134' is not allowed access. Refer https://aka.ms/acr/firewall to grant access.
: exit status 1
Run ID: cs2 failed after 7s. Error: failed during run, err: exit status 1
Run failed

Note: The ip address 104.46.161.134 is listed under the published on the public azure ip ranges and services tags json file.

Solution

When Allow trusted Microsoft services to access this container registry is on, allow traffic from known ACR build services.

Answer 1 · 2023-02-01T00:30:58.000Z

@josh-barker I shared an example of using Tasks as trusted service to schedule ad-hoc build using your local source code.

https://gist.github.com/northtyphoon/ca48d831fb1859dfef3d75170ad75598

Answer 2 · 2023-02-06T02:50:57.000Z

Hi @northtyphoon , thanks for sharing that.

I'm not sure how your script helps when the error is relates to a firewall issue.
I have set Trusted services, as in the above screenshot.

Answer 3 · 2023-07-27T16:03:38.000Z

Just confirming that the script provided by northtyphoon worked perfectly for me (aside from some minor typos and/or recent updates to the cli).

I believe trusted services works based on the system assigned managed identity so you have to assign one to your ACR task (as in the script) for it to be considered trusted by the network firewall on the container registry.

Answer 4 · 2023-10-08T01:47:40.000Z

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.

Answer 5 · 2023-11-08T01:47:07.000Z

This issue was closed because it has been stalled for 30 days with no activity.

Answer 6 · 2024-04-03T11:22:24.000Z

Just confirming that the script provided by northtyphoon worked perfectly for me (aside from some minor typos and/or recent updates to the cli).

I believe trusted services works based on the system assigned managed identity so you have to assign one to your ACR task (as in the script) for it to be considered trusted by the network firewall on the container registry.

It is not related to the system assigned managed identity. ACR Tasks should "just work" with managed identities when public access is disabled.

Together with the guidance from the gist, and MSFT documentation I was also able to resolve this issue today. Beware my pitfall when tinkering in a dev/sandbox: The System Assigned Managed Identity ID of the created task is different from the System Assigned Managed Identity ID of the Registry. That is also why the code from @northtyphoon gets the system_identity_principal when creating the task.

Link that indicates that ACR Tasks are considered trusted services when accessing a registry
https://learn.microsoft.com/en-us/azure/container-registry/allow-access-trusted-services#about-trusted-services

Link with samples that give more context to why the gist from @northtyphoon does what it does. (The example is about cross registry, but I just used it as guidance for fixing it for my single registry with public access disabled).
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-cross-registry-authentication