Delay after whitelisting an IP address

Question

Hi,

I have a github action that builds and deploys a static website into a Azure Storage account. By default the storage account's firewall rules deny incoming connections so I need to whitelist the github runner's current IP for the duration of the deployment.

This is not a problem at all, I can get the current IP with haythem/public-ip@v1.2 then I update the firewall rules with az storage account network-rule add, after this I upload the build artifacts to the storage.

The script looks like this:

az storage account network-rule add -g <RESOURCE GROUP NAME> --account-name <ACCOUNT NAME> --ip-address ${<!-- -->{ steps.ip.outputs.ipv4 }} --action Allow
az storage blob upload-batch --account-name <ACCOUNT NAME> --auth-mode key -d '$web' -s .

The problem is even though network-rule add finished running the actual changes haven't gone through the system(?) and my upload fails with a network error.

If I add a 20 seconds delay between network-rule add and blob upload-batch then it works fine. Is this the expected behavior? Can anyone confirm the shortest amount of time I need to wait here?

Thanks.

Answer 1

Thanks Peter!
I have converted it to bash and simplified for my use case. It seems that just a list of the storage containers is also blocked by the firewall.

FWTestAttempt=1
FWTestMax=10

while true; do
    if az storage container list --account-name ${STORAGE_ACCOUNT_NAME} --account-key ${ACCOUNT_KEY} &> /dev/null; then
        echo "Storage is now accessible."
        break
    else
        if [ $FWTestAttempt -lt $FWTestMax ]; then
            echo "Unable to access storage account $FWTestAttempt/$FWTestMax. Waiting for FW rule to take effect."
            ((FWTestAttempt++))
            sleep 10
        else
            echo "Unable to access storage account $FWTestAttempt/$FWTestMax."
            exit 1
        fi
    fi
done

Answer 2

I have this issue too. It would be much better for ARM not to return until the firewall rules are effective.

In my experience the time it takes is variable, I was seeing failure after 2 mins or more occasionally....

As a workaround I'm using a loop checking if the firewall rule is effective. I appreciate this wont work for everyone though, in my scenario I'm checking if the Devops hosted agent is able to access the storage account.

if ($null -ne $WaitForContainer) {
	Write-Information "Waiting for FW rule to apply." -InformationAction Continue

            $FWTestAttempt = 1
            $FWTestMax = 25

            do {
                try {
                    get-azstorageblob -Container $WaitForContainer -Context $stgContext | Out-Null
                    $FWTest = $true
                    Write-Information "Storage is now accessible." -InformationAction Continue
                }
                catch {
                    if ($FWTestAttempt -lt $FWTestMax) {
                        Write-Warning "Unable to access storage account $FWTestAttempt/$FWTestMax. Waiting for FW rule to take effect." -WarningAction Continue
                        $FWTestAttempt++
                        Start-Sleep -Seconds 10
                    }
                    else {
                        Write-Error "Unable to access storage account $FWTestAttempt/$FWTestMax."
                    }
                }
            } while (-not $FWTest)
        }