How can I deploy content to a static website in Azure Storage that has IP restrictions enabled?

Question

I'm getting an error in my release pipeline (Azure DevOps) when I deploy content to a static website in Azure Storage with IP restrictions enabled.

Error parsing destination location "https://MYSITE.blob.core.windows.net/$web": Failed to validate destination. The remote server returned an error: (403) Forbidden.

The release was working fine until I added IP Restrictions to the storage account to keep the content private. Today, we use IP restrictions to control access. Soon, we will remove the IP restrictions in favor of vpn and vnets. However, my expectation is that I will have the same problem.

My assumption is that Azure DevOps cannot access the storage account because it is not whitelisted in the IP Address list. My release pipeline uses the AzureBlob File Copy task.

steps:
- task: AzureFileCopy@2
  displayName: 'AzureBlob File Copy'
  inputs:
    SourcePath: '$(System.DefaultWorkingDirectory)/_XXXXX/_site'
    azureSubscription: 'XXXX'
    Destination: AzureBlob
    storage: XXXX
    ContainerName: '$web'

• I have already enabled "trusted Microsoft services" but that doesn't help.
• Whitelisting the IP Addresses for Azure DevOps is not a good option because there are TONS of them and they change regularly.
• I've seen suggestions to remove the IP restrictions and re-enable them after the publish step. This is risky because if something were to fail after the IP restrictions are removed, my site would be publicly accessible.

I'm hoping someone has other ideas! Thanks.

Kassiekassity

Answer 1

You can add a step to whitelist the agent IP address, then remove it from the whitelist at the end of the deployment. You can get the IP address by making a REST call to something like ipify.

I have done that for similar scenarios and it works well.

Arda

Thanks. It is an interesting idea. I could have a pipeline step to get the IP Address of the agent (we are currently using Hosted Agents), then a step to whitelist the IP, then do the other normal pipeline stuff. Then at the end, clear that new whitelist entry. That seems like a lot of work for something that should be built in. But I think it could work thanks. Still looking for more ideas though. – Kassiekassity

@Kassiekassity It's the best approach I've found. The hosted agents are not a trusted service, so there's no built-in option that's going to magically make it work. – Arda

Answer 2

I would recommend a different approach: running an Azure DevOps agent with a static IP and/or inside the private VNet.

Why I consider this a better choice:

1. audit logs will be filled with addition and removal of rules, making harder analysis in case of attack
2. the Azure connection must be more powerful than needed, specifically to change Rules in Security Groups or Firewall or Application Gateway or else, while it only needs deploy permissions
3. it opens traffic from outside, while temporarily, while a private agent needs always initiate from inside

No solution is perfect, so it is important to chose the best for your specific scenario.

Alternation

Needless, to say that with DevOps agents in a private network you only have to manage traffic exceptions from the said VNET - which also ties in very well with your controlled access to storage for static website. – Theron

We are currently using the Hosted Agent and not running private VNETS so this is not possible TODAY. However, we are in the process of setting up the vnets now so we can probably shift to this approach. I'd need to set up an agent too since we are currently using the Hosted Agent. I was hoping to not do that, it is one more thing to manage long term, but in this case it could be very helpful. Thanks for the suggestion! – Kassiekassity