Almost every corporate client asks us this question at some point: Which domains and IP addresses are used by Azure DevOps (formerly Visual Studio Team Services). And given that it's a cloud service, it's not an easy question to answer.

The nature of the cloud, it's ability to scale, fail over and the regular update cadence cause these services to change on a regular basis. Much more often than many corporate client fire walls are able to handle (or at least their change process can deal with).

Of course there is the master list of "IP addresses owned by Azure", but let's face it, it's way too easy to put anything in Azure.  It's may give you a fake feeling of security, but doesn't offer a real form of protection..

Then there is the ability to use the reverse DNS to white-list domains on a proxy server. This is already a better alternative, but getting to the complete list of domains to white-list is still not going to be easy. Many IT departments use tools like Fiddler or log blocked traffic at the proxy level to figure out what domains to allow and which ones to block. It's easy to miss specific domains which may only be used to register agents or to receive service hooks etc.

Today I learned there is actually a service which returns a pretty long list of domains associated to your account.  Just request the following URL and you'll be rewarded with a json response containing all the services associated with your account:

https://dev.azure.com/{account}/_apis/resourceareas/

The response looks like this:

{
    "count": 181,
    "value": [
        {
            "id": "fb13a388-40dd-4a04-b530-013a739c72ef",
            "name": "policy",
            "locationUrl": "https://jessehouwing.visualstudio.com/"
        },
        {
            "id": "c73a23a1-59bb-458c-8ce3-02c83215e015",
            "name": "Licensing",
            "locationUrl": "https://jessehouwing.vssps.visualstudio.com/"
        },
        {
            "id": "01e4817c-857e-485c-9401-0334a33200da",
            "name": "dedup",
            "locationUrl": "https://jessehouwing.vsblob.visualstudio.com/"
        },
        {
            "id": "79134c72-4a58-4b42-976c-04e7115f32bf",
            "name": "core",
            "locationUrl": "https://jessehouwing.visualstudio.com/"
        },
        {
            "id": "67349c8b-6425-42f2-97b6-0843cb037473",
            "name": "Favorite",
            "locationUrl": "https://jessehouwing.visualstudio.com/"
        },
        {
            "id": "5264459e-e5e0-4bd8-b118-0985e68a4ec5",
            "name": "wit",
            "locationUrl": "https://jessehouwing.visualstudio.com/"
        },
        ...
    ]
}

The list isn't complete, but it's much more extensive than any other stack overflow post or MSDN forums posts I've seen out there.

Add to that the whitelisted domains from the Azure DevOps content security policy and you're golden:

default-src ;
font-src *.visualstudio.com *.dev.azure.com dev.azure.com *.vsassets.io vsassetscdn.azure.cn ms.gallerycdn.vsassets.io ms.gallerycdn.azure.cn *.microsoft.com *.sharepointonline.com ;
style-src 'unsafe-inline' *.visualstudio.com *.dev.azure.com dev.azure.com cdn.vsassets.io vsassetscdn.azure.cn ms.gallerycdn.vsassets.io ms.gallerycdn.azure.cn ;
connect-src *.visualstudio.com wss://*.visualstudio.com *.dev.azure.com dev.azure.com wss://*.dev.azure.com wss://dev.azure.com *.vsassets.io vsassetscdn.azure.cn ms.gallerycdn.vsassets.io ms.gallerycdn.azure.cn *.blob.core.windows.net ;
img-src http: https: blob: data: ;
script-src 'unsafe-inline' *.visualstudio.com *.dev.azure.com dev.azure.com https://cdn.vsassets.io https://vsassetscdn.azure.cn https://ms.gallerycdn.vsassets.io https://ms.gallerycdn.azure.cn *.ensighten.com *.microsoft.com *.google-analytics.com 'nonce-rl90+lCEC+5X3/aWhviaLg==' ;
child-src blob: tfs: * ;
media-src http: https:

And the beauty of combining these two methods? They're updated automagically by Microsoft every time something changes,  so you can simply monitor them and apply the diffs after a quick review.