azure-cli: Azure DevOps Build Agent not able to access Azure Storage Account during deployment
az feedback
auto-generates most of the information requested below, as of CLI version 2.0.62
Describe the bug I have a static website that I wish to have CD pipeline for it, the pipeline has one task which is Azure CLI to copy files to storage account, I’m using a service connection that has a service principal that has access to the resource. I keep getting the following error You do not have the required permissions needed to perform this operation. Depending on your operation, you may need to be assigned one of the following roles: “Storage Blob Data Contributor” “Storage Blob Data Reader” “Storage Queue Data Contributor” “Storage Queue Data Reader” In the script I’m adding the IP of the build agent to the list of allowed IP on the firewall for the storage account so it would have access then I can issue azure cli commands to list or upload content. This behavior used to work up to yesterday and out of sudden it stopped working, I tried to reproduce on Azure Shell itself and it is working fine and also I tried locally on my work machine and the same steps work fine. To Reproduce Steps to reproduce the behavior.
Expected behavior A successful upload to Azure Storage account container.
Environment summary Azure CLI Version: 2.0.74 Azure CLI Task version: 1.0
Additional context Add any other context about the problem here.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 18 (4 by maintainers)
@micheleissa Thanks for you information. At least we know it is caused by network rules, not CLI issue. In ADO, typically build agent is assigned randomly. But I think what you need to do is to find the correct IP address for you build agent and add it to allow for you storage account. You can find ADO guys for help. I will close it now because it is not a CLI issue and if you still have problems when using CLI, feel free to create a new one.😊
I am doing something similar and it’s still quite problematic, especially with Terraform, that works a bit differently than the CLI. There are API delays and e.g. the firewall rules can take up to 2 minutes to even appear in the target resource…
Set to public - no problems, set with firewall exceptions? Some magical stuff happens from time to time. It’s unreliable. The same routine can work 4 times in a row, to throw API error on the next attempt.
Also, “According to your error code, it should be caused by Firewall. You can check it by setting default action of your storage account to Allow, and it should works well. But why not set default action to Allow? Do you have any concern?”
Why would they even try allowing an IP if they wished for their default rule to be on “allow”?
Is this really not possible to include DevOps agents as Microsoft Service bypass in the Resource settings? It’s only quite rational to categorize Microsoft Agents as Microsoft Services, is it not? The workaround is not very complicated, but I can see some use-cases, where this potentially becomes an obstacle.
PS: Your documentation on assigning the agent’s IP states that the public IPs belong under the (the ServiceTags file), AzureCloud, which can contain even 300 different IPs. Assigning those IPs manually is not a solution at all.
I can’t see why exactly it’s not supported to even retrieve the IP of the agent through some kind of a pre-defined variable? There seems to be no other way than to write custom scripts for this purpose, and they are a workaround using the API, which brings additional delay to the pipeline and even makes them waste time needlessly.
PS2: In case anybody is wondering why exactly a Storage Account with explicitly allowed public IP might WORK FINE 4 times in a row, then throw an API error, here is a random answer from a random place
I would be happy to find this in the documentation instead of wasting 4-5 hours manually testing why exactly it’s broken. Please, tell me, what is the point of putting that information in: https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal
When at the same time it isn’t present in: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml
So basically there is a guide on how to find the IPs of managed agents (which is by the way, pretty much of no use, given the restrictions of the firewall settings), but it doesn’t mention that in fact - even if bypassed, it will not work. Great.
I am doing similar commands in my Azure Pipeline, however there seem to be a delay from whitelisting the IP of the Microsoft hosted agent to it being allowed to write/read from the Storage account. I have, for a temporary solution, added a sleep command in there for 4-5 minutes but is seems to be random if the network rules has been applied. Does anyone know if it is possible to return an exit code 2 instead of the standard ‘the request may be blocked by network rules of storage account’, which is only a warning meaning it will not fail in the Azure Pipeline.
For now I have tried the following (assumes logged into subscription):