azure-cli: Azure DevOps Build Agent not able to access Azure Storage Account during deployment

@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

- Services deployed in the same region as the storage account use private Azure IP addresses for communication.
- IP network rules have no effect on requests originating from the same Azure region as the storage account

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.

The IP address is the public IP given to the build agent machine and I obtain it from an api call to this so it is right and satisfy the rules. The weird part is before the problem started to happen, the original approach of adding IP rule to firewall was working fine. I managed to get it to work by using default action allow then deny again after uploading the static content of the website. To find the ip in ADO is like that:

# obtain build agent IP to be used later
Build_Agent_IP=$(curl -k https://ipinfo.io/ip)
echo 'Build Agent IP is: ' $Build_Agent_IP

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):

export CURRENT_IP=$(curl -s http://ipinfo.io/json | jq -r '.ip')
echo "Whitelisting $CURRENT_IP"
az storage account network-rule add \
  --resource-group [resource-group-name] \
  --account-name [storage-account-name] \
  --ip-address $CURRENT_IP

az storage account show -n [storage-account-name] --query networkRuleSet --resource-group [resource-group-name] > network_rules.json 
IP_MATCH=$(cat network_rules.json | jq --arg CURRENT_IP "$CURRENT_IP" '.ipRules[] | select(.ipAddressOrRange | contains($CURRENT_IP))')
if [ -z "$IP_MATCH" ]
  then 
echo "IP $CURRENT_IP was not whitelisted. Try again."
  exit 2
else
  # Upload file or something