Open romanzdk opened 2 years ago
route to CXP team
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @toddysm, @luisdlp, @northtyphoon.
Author: | romanzdk |
---|---|
Assignees: | - |
Labels: | `Service Attention`, `Container Registry`, `customer-reported`, `Auto-Assign` |
Milestone: | - |
Hello I'm experiencing the same issue. We have ACR with allowed IP ranges and enabled checkbox under "Allow Microsoft trusted services...". But every time, when I run manual task with az cli - i'm retrieving the same error, which mentioned above. I have tried to add range 20.44.23.0/25, and worked well until today's run, because range changed again. How we can handle this issue? We want to add scheduled tasks for ACR, and I'm not sure if it works well with current firewall configuration.
Could you please share correct public IP ranges, which used by Agents for ACR tasks? I guess it's more simpler way to handle this issue.
same here:
2023/02/17 14:51:51 Logging in to registry: [nnnn.azurecr.io](http://nnnn.azurecr.io/)
failed to login, ran out of retries: failed to set docker credentials: Error response from daemon: Get "https://nnnn.azurecr.io/v2/": denied: client with IP '52.178.20.9' is not allowed access. Refer https://aka.ms/acr/firewall to grant access.
: exit status 1
2023/02/17 16:14:52 Logging in to registry: [nnnn.azurecr.io](http://nnnn.azurecr.io/)
failed to login, ran out of retries: failed to set docker credentials: Error response from daemon: Get "https://nnnn.azurecr.io/v2/": denied: client with IP '13.69.110.78' is not allowed access. Refer https://aka.ms/acr/firewall to grant access.
: exit status 1
Can you please update the "trusted Microsoft services" list. We get the above error message despite we selected the option "Allow trusted Microsoft services to access this container registry".
Any update on this issue?
Hello we are experiencing the same issue, we are unable to close Container Registry network because of this issue and it represents a security concern for us. Is there any updates on the topic?
@toddysm, @luisdlp, @northtyphoon Can you please give us some update on this issue?
Same here, I see that the problem has been known for a long time and is not fixed. Is there any workaround ? if not we will need to use other solution than Azure Container Regisstry...
One can always create an own dedicated agent pool, according to the documentation as it is written here:
Run an ACR task on a dedicated agent pool - Create pool in a virtual network
I understand if the above solution does not seem to be appealing. I would like to avoid implementing this solution for our use case as well.
We are also having this issue - update?
One can always create an own dedicated agent pool, according to the documentation as it is written here:
Run an ACR task on a dedicated agent pool - Create pool in a virtual network
I understand if the above solution does not seem to be appealing. I would like to avoid implementing this solution for our use case as well.
I can verify that this works fine. Actually it is very straight forward, once you create the agent pool for the specific ACR you can run any acr task against that agent pool. In the portal you can view both the task and the agent pool created inside the Tasks menu of the corresponding ACR.
Just for your information, the following file contains the IP address ranges for Public Azure as a whole. This file is updated weekly. New ranges appearing in the file will not be used in Azure for at least one week. Please download the new json file every week and perform the necessary changes at your site to correctly identify services running in Azure.
For more information on Service Tags please visit http://aka.ms/servicetags.
Just for your information, the following file contains the IP address ranges for Public Azure as a whole. This file is updated weekly. New ranges appearing in the file will not be used in Azure for at least one week. Please download the new json file every week and perform the necessary changes at your site to correctly identify services running in Azure.
For more information on Service Tags please visit http://aka.ms/servicetags.
Looks like it can be helpful. Will check it a bit later, and let you know.
I am facing a similar issue. I am trying to publish a Machine Learning Pipeline in Azure ML Studio according to this guide: https://github.com/Azure/MachineLearningNotebooks and getting the error message in the log:
2023/11/13 12:45:23 Setting up Docker configuration... 2023/11/13 12:45:23 Successfully set up Docker configuration 2023/11/13 12:45:23 Logging in to registry: {Container registry}.azurecr.io failed to login, ran out of retries: failed to set docker credentials: Error response from daemon: Get "https://{Container registry}.azurecr.io/v2/": denied: client with IP 'XXX' is not allowed access. Refer https://aka.ms/acr/firewall to grant access. : exit status 1 Run ID: cb8 failed after 7s. Error: failed during run, err: exit status 1
One can always create an own dedicated agent pool, according to the documentation as it is written here:
Run an ACR task on a dedicated agent pool - Create pool in a virtual network
I understand if the above solution does not seem to be appealing. I would like to avoid implementing this solution for our use case as well.
I would love to do the above, but my region is not supported. Do we know when this is getting out of preview as its been in preview for over a year.
Until now we were building and pushing Docker image into ACR (that had public access enabled) using Microsoft-hosted DevOps agent and everything was perfect.
However, we need to make ACR accessible only from selected networks, so I thought I gather IP address of the current agent and add a firewall rule to the ACR. This approach works well for other Azure resources (e.g. KeyVault), however, for some reason when using with ACR I am getting an error when calling
az acr build
command.The tasks:
The error:
failed to login, ran out of retries: failed to set docker credentials: Error response from daemon: Get "https://***/v2/": denied: client with IP 'xx.xx.xx.xx' is not allowed access. Refer https://aka.ms/acr/firewall to grant access.
The strange thing is, that ip address retrieved from that curl command is completely different from the one in the error and I have no idea how is it possible? How to overcome this, please?