Whitelisting Microsoft Hosted Build Agents within Azure DevOps

With SaaS on the rise, more companies are hosting their applications in “the cloud.” One of the top cloud providers today is Microsoft Azure. According to Microsoft, 95% of Fortune 500 companies trust their business in Azure. As an Engineer, I use Azure daily for a multitude of reasons. While researching an issue related to Azure, I noticed a lot of users were trying to resolve an issue related to restricting Azure’s App Service access with Microsoft’s Hosted Build Agents.

The Problem

Among all the security precautions you can take within Azure, one of them is restricting access to your Azure Web Applications. For some applications, they may be critical internal systems where only members of the company should have access. If this is the case, you want to deny all access to the site except for requests coming from the company’s IP address. This is a great security mechanism to follow. However, what happens when you want to build and release this application through Azure Pipelines? You would think you could just add the hosted agent’s IP address to the allow list…but what is that IP address? You may know it for the first build, but it’s probably going to change each build.

With doing research on this particular issue, you will probably land on official Microsoft documentation. Within this documentation, Microsoft links readers to a json file that has IP ranges for Azure datacenters, broken out by regions. This json file is over 29 thousand lines long and changes weekly. If you are trying to find the IP address range for your build agents, check out these Microsoft instructions for using their file:

Because Azure DevOps uses the Azure global network, IP ranges vary over time. We publish a weekly JSON file listing IP ranges for Azure datacenters, broken out by region. This file is published every Wednesday (US Pacific time) with new planned IP ranges. The new IP ranges become effective the following Monday. We recommend that you check back frequently to ensure you keep an up-to-date list. If agent jobs begin to fail, a key first troubleshooting step is to make sure your configuration matches the latest list of IP addresses.

Your hosted agents run in the same Azure geography as your organization. Each geography contains one or more regions, and while your agent may run in the same region as your organization, it is not guaranteed to do so. To obtain the complete list of possible IP ranges for your agent, you must use the IP ranges from all of the regions that are contained in your geography. For example, if your organization is located in the United States geography, you must use the IP ranges for all of the regions in that geography.

Do these instructions make sense to you? Yeah, they didn’t make sense to me either. If you open the file and do a search for “build agent”, “build”, “agent”, “devops”, “pipeline”, or “hosted”, you will sadly get 0 results.

Small portion of Microsoft's Weekly JSON
{
  "changeNumber": 95,
  "cloud": "Public",
  "values": [
    {
      "name": "ApplicationInsightsAvailability",
      "id": "ApplicationInsightsAvailability",
      "properties": {
        "changeNumber": 1,
        "region": "",
        "platform": "Azure",
        "systemService": "ApplicationInsightsAvailability",
        "addressPrefixes": [
          "13.86.97.224/27",
          "13.86.98.0/27",
          "13.86.98.48/28",
          "13.86.98.64/28",
          "20.37.156.64/27",
          "20.37.192.80/29",
          "20.38.80.80/28",
        ]
      }
    },

So, using the file, how do you know which IP addresses to whitelist? Yeah, I still haven’t figured out how to read the file to answer that question the way Microsoft intended us too. But all hope has not been lost, I have a solution you can use to continue on your journey of protecting your applications while using Azure Pipelines.

The Solution

Adding and Removing an Agent’s IP Address on the Fly

In this solution, we are going to whitelist the hosted agent’s IP address in the pipeline. Make sure you place this build task before any steps that interact with your Azure App Service. Below is the YAML for whitelisting the IP:

- task: AzurePowerShell@4
    displayName: 'Add Hosted Pipeline Access Rule'
    inputs:
    azureSubscription: 'AZURE-SUBSCRIPTION-NAME'
    ScriptType: InlineScript
    Inline: |
        $HostedIPAddress = Invoke-RestMethod http://ipinfo.io/json | Select -exp ip
        Add-AzWebAppAccessRestrictionRule -ResourceGroupName "YOUR-RESOURCE-GROUP-NAME" -WebAppName "YOUR-WEB-APP-NAME" -Name "AzureDevOpAgent$(Agent.MachineName)" -Priority 111 -Action Allow -IpAddress "$HostedIPAddress/32"
    azurePowerShellVersion: LatestVersion

After this task has run, you will see a new item added to your Access Restrictions within Azure Portal. The next thing we want to do is remove the whitelisting after the pipeline has completed any tasks that needed access to the app service. With this being said, place this task towards the end of the pipeline. Below is the YAML for removing the Agent’s IP address from the Access Restriction:

- task: AzurePowerShell@4
    displayName: 'Remove Hosted Pipeline Access Rule'
    inputs:
    azureSubscription: 'AZURE-SUBSCRIPTION-NAME'
    ScriptType: InlineScript
    Inline: |
        Remove-AzWebAppAccessRestrictionRule -ResourceGroupName "YOUR-RESOURCE-GROUP-NAME" -WebAppName "YOUR-WEB-APP-NAME" -Name "AzureDevOpAgent$(Agent.MachineName)"
    azurePowerShellVersion: LatestVersion
    condition: always()

In this task, setting the condition to “always()” tells your pipeline to always run this task even if the build fails in an earlier step.

Note: A simpler solution would be to allow access from everyone, but have a login page to access the site. The negative of this is that if the data has critical information, the site will constantly get pinged by hackers. With this being said, make sure you take appropriate measures to enforce strict login credentials.

I hope I was able to help anyone that may have ran into the same problem I did. Whitelisting an agent’s IP address is very important in some cases.

As always, feel free to leave feedback or comments.

Thanks!