Get Azure Datacenter IP ranges via API V2

Hi,

In my previous post, I showed how to create a light-weight Azure function that allows you to request the Azure Datacenter IP ranges via API. You can rapidly test it by following the instructions on the section 3- Try it before deploying
it here : https://buildwindows.wordpress.com/2017/11/19/get-azure-datacenter-ip-ranges-via-api/

The feedback was positive, but a lot have asked for a way to see if there were updates compared to the last version, and what the updates are if any.

In this post, I will publish the second version of the API (with the how-to), that allows you to :

  • Get the current Azure Datacenter IP ranges
  • Get the current Azure Datacenter IP ranges for a specific region
  • Get region names (since, unfortunately, the region names published by Microsoft are not exactly the same used by the Microsoft Azure services)
  • New : Get the current version ID of the Azure Datacenter IP ranges
  • New : Get the previous version ID of the Azure Datacenter IP ranges
  • New : Get the difference between the current and the previous version for all regions
  • New : Get the difference between the current and the previous version for a specific region

The new features will allow you an easy integration with your environment, and simplify the update of your Firewall rules within your infrastructure.

  • 1- How to request the API ?

The API supports only POST requests. You can make the following API requests using the following body construction.

Here the examples using Powershell, but you can use any tool to request the API using the same body content

#V1

#Get the current Azure IP address ranges of all region

$body = @{“region”=“all”;“request”=“dcip”} | ConvertTo-Json

#Get the current Azure IP address ranges of a specific region, example europewest

$body = @{“region”=“europewest”;“request”=“dcip”} |ConvertTo-Json

#Get the azure regions names, that we can request IPs for

$body= @{“request”=“dcnames”} |ConvertTo-Json

#Post the request

$webrequest=Invoke-WebRequest -Method “POST” -uri ` https://azuredcip.azurewebsites.net/getazuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

#New in V2

#Get the (added and/or removed) IP address ranges updates of a specific region

$body = @{“request”=“getupdates”;“region”=“asiaeast”} | ConvertTo-Json

#Get the (added and/or removed) IP address ranges updates of all regions

$body = @{“request”=“getupdates”;“region”=“all”} | ConvertTo-Json

#Get the current Azure DC IP ranges version ID

$body = @{“request”=“currentversion”} | ConvertTo-Json

#Get the previous Azure DC IP ranges version ID

$body = @{“request”=“previousversion”} | ConvertTo-Json

#Post the request

$webrequest Invoke-WebRequest -Method “POST” -uri ` https://azuredcip.azurewebsites.net/getazuredcipupdates -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

  • 2- How to build the solution ?

2.1- Solutions components

The V2 version is still using only Azure Functions, but unlike V1, it uses multiple functions within the Function App:

  • 1 Function App
    • Function 1
    • Function 2
    • Function 3
    • Proxy1
    • Proxy2
    • Storage Account

The following table details each component configuration. If you want to create the solution within your environment, create the same components using the given configuration:

Function App

Name

Description

App Service Plan

azuredcip This Function App will host the entire solution. It will include 3 functions, 1 Storage Account and two Proxies Shared or greater. Use at least a Basic Tier to benefit from SSL, Custom Names and backup

Function1

Name

Description

Language

Integrate

Manage

azuredcipranges This function will return you the V1 information.
https://buildwindows.wordpress.com/2017/11/19/get-azure-datacenter-ip-ranges-via-api/
HttpTrigger – Powershell
Allowed HTTP Methods : POST
Authorization level : Anonymous
You can add Function Keys if you want to secure the API Access. In my case, my API still Public (anonymous) to continue support my V1

Function2

Name

Description

Language

Integrate

Manage

azuredciprangesupdater This function will do the following :
– Get the current Azure DC IP ranges version and store it to the storage account

– Always keep the previous Azure DC IP ranges version file in the storage account

– Create and store a file containing the current and previous files difference and store it to the storage account

– Return the mentioned information based on the API request body

HttpTrigger – Powershell
  1. Inputs (Type : Azure Blob Storage)
Name Path SA connection
vnowinblob azuredcipfiles/vnow.json AzureWebJobDashboard
vpreviousinblob azuredcipfiles/vprevious.json AzureWebJobDashboard
vcompareinblob azuredcipfiles/vcompare.json AzureWebJobDashboard
  1. Outputs (Type : Azure Blob Storage)
Name Path SA connection
vnowoutblob azuredcipfiles/vnow.json AzureWebJobDashboard
vpreviousoutblob azuredcipfiles/vprevious.json AzureWebJobDashboard
vcompareoutblob azuredcipfiles/vcompare.json AzureWebJobDashboard

Keep the default http output

Allowed HTTP Methods : POST

Authorization level : Function

You can use the default function key or generate an new key. This API will not be directly exposed, so you can protect it with a key

Function3

Name

Description

Language

triggerazdciprangesupdate This function will trigger the azuredciprangesupdater weekly to update the current and previous version TimerTrigger – Powershell
Schedule : 0 0 0 * * 3

(Each Wednesday, but you can choose any day of the week, as Microsoft will not apply the updates before one week of their publication)

Proxy 1

Name

Description

Root template

Allowed HTTP methods

Backend URL

getazuredcipranges This proxy will relay requests to azuredcipranges /getazuredcipranges POST https://azuredcip.azurewebsites.net/api/azuredcipranges
(add the key if you have secured it)

Proxy 2

Name

Description

Root template

Allowed HTTP methods

Backend URL

getazuredcipupdates This proxy will relay requests to azuredcipranges /getazuredcipupdates POST https://azuredcip.azurewebsites.net/api/azuredciprangesupdater?code=typethekeyhere

Storage Account

Name

Description

container

Files

azuredcipsa

This is the storage account automatically created with the Function app (it can have any other name) azuredcipfiles Upload the following files:
– vnow.json

– vprevious.json

NB : These files are fake files. During the first API update request, the vnow content will be copied to the vprevious file. The vnow content will be then replaced by the real current version. At this moment, you can only request the current version. After one week, a new version of the file will be published by MS, so another cycle will set the vnow and the vprevious to real 2 consecutive versions, so you can benefit from the update and comparison feature.

2.2- Download the files

You can download the needed files here, you will find the powershell code for each function (function1, function2, function3) and the two json files (vnow.json and vprevious.json).

NB : As mentioned before, after the first request to the API (getupdates), you will have a valid vnow version, but the previous version will be the version uploaded now. You need to wait at least 1 week to have the valid version.

Enjoy!!

Advertisements

Create an Azure AD service principal (Based on Azure AD App) secured by a Certificate

When working with Azure, you may need to create an Azure AD Application, to act a Service Principal and use it to run operation on Azure resources. This post will show you how to register an Azure AD application secured by a Self-Signed Certificate, all via Powershell. You can modify the third script if you want to create the application using an existing certificate. The used scripts can be downloaded from here

1- Create a pfx certificate

In order to the Azure AD App to be secured, a certificate needs to be created. You can prepare the following information to create your certificate :

  • common name (cn)
  • A password to protect the private key

The files Create-SSCv1.ps1 (for Windows 2008 R2/7) and Create-SSCv2.ps1 (for Windows 2016 /10) are powershell scripts that allow you to create a self-signed certificate.

Example using Create-SSCv1.ps1 (the DNS name replaces the common name)

.\Create-SSCv1.ps1 -DNSName zookeeperazure -Password P@ssw0rdzook -PFXPath c:\-PFXName 
zookeeper

Example using Create-SSCv2.ps1 (More control over some options)

.\Create-SSCv2.ps1 -SubjectName zookeeper -Password P@ssw0rd -PFXPath C:\temp -PFXName 
zookeeper -MonthsValidity 24 -FriendlyName zookeepernva

2- Import the Certifictate the windows Certificates Store

The file Import-CertToStore.ps1 will import the certificate to the personal Store, in order to be used to create the Azure AD App later. Provide the password used on the previous step

.\Import-CertToStore.ps1 -Path C:\temp\zookeeper.pfx -Password P@ssw0rd

3- Create an Azure AD application to act as a Service Principal Name

Use the script file Create-azureadapp.ps1 to create the Azure AD application. The Azure Ad Application should have the same name than the certificate CN, so that the script can work. You will be prompted to login to Azure

.\Create-azureadapp.ps1 -ApplicationName zookeeper

You can see now that an new Application has been added to your Azure AD registered application. Azure Portal à Azure Active Directory à App registration


4- Add the application to an Azure Role

Now that your application has been created, you can assign it to any Azure RBAC role. For example, I assigned the created application (zookeeper) the Reader role on the resource group RG-Azure

Get Azure Datacenter IP address ranges via API

Hi folks,

One of the struggles that we may face when dealing with Azure services, is the network filtering. Today, we consume a lot of services provided by Azure, and some Azure services can consume services from our infrastructure. Microsoft is publishing an ‘xml’ file that contains the exhaustive list of the Azure Datacenter IP ranges for all its public regions (No gov). This ‘xml’ file is regularly updated by Microsoft to reflect the list updates as they can add or remove ranges.

The problem is that consuming an ‘xml’ file is not very convenient as we need to make many transformations to consume the content. Many of you have requested that Microsoft at least publishes this list via an API so it can be consumed by many sources, using Rest requests. Until Microsoft make it, I will show you today how to create a very lightweight web app on Azure (using Azure Functions) that will ‘magically’ do the job.

NB : The Azure Datacenter IP ranges include all the address space used by the Azure datacenters, including the customers address space

1- Why do we need these address ranges ?

If you want to consume Azure services or some Azure services want to consume your services, and you don’t want to allow all the “Internet” space, you can ‘reduce’ the allowed ranges to only the Azure DC address space. In addition, you can go further and select the address ranges by Azure region in case the Azure services are from a particular region.

Examples :

  • Some applications in your servers need to consume Azure Web Apps hosted on Azure. In a world without the Azure DC address space, you should allow them to access internet, which is a bad idea. You can configure your firewalls to only permit access to the Azure DC IP ranges
  • If you are using Network Virtual Appliances on Azure, and you want to allow the VM’s Azure agent to access the Azure services (storage accounts) in order to function properly, you can allow access only to the Azure DC IPs instead of internet.

2- The Solution

In order to consume the Azure Datacenter IPs via an API, I used the powerful and simple Azure functions to provide a very light weight ‘File’ to ‘JSON’ converter. The Azure function will do the following:

  • Accept only a POST request
  • Download the Azure Datacenter IP ranges xml file
  • Convert it to a JSON format
  • Return an output based on the request:
    • A POST request can accept a Body of the following format : { “region”: “regionname”, “request”: “requesttype” }.
      • The “request” “parameter can have the value of :
        • dcip : This will return the list of the Azure Datacenter IP ranges, depending on the “regionname”  parameter. “regionname” can be :
          • all : This will return a JSON output of all the Azure Datacenter IP ranges of all regions
          • regionname : This will return a JSON output of the regionname’s Azure Datacenter IP ranges
        • dcnames : This will return al list of the Azure Datacenter region’s names. The “regionname” parameter will be ignored in this case
      • In case of a bad region name or request value, an error will be returned

3- Try it before deploying it

If you want to see the result, you can make the following requests using your favorite tool, against an Azure function hosted on my platform. In my case, I’m using powershell and my function Uri is https://azuredcip.azurewebsites.net/api/azuredcipranges

3.1- Get the address ranges of all the Azure DCs regions

#Powershell code

$body = @{“region”=“all”;“request”=“dcip”} | ConvertTo-Json

$webrequestInvoke-WebRequest -Method “POST” -uri ` https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content


 3.2- Get the address ranges of the North Europe region

In this case, note that we must use europnorth
instead of northeurope

#Powershell code

$body = @{“region”=“europenorth”;“request”=“dcip”} | ConvertTo-Json

$webrequest Invoke-WebRequest -Method “POST” -uri `
https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content


3.3- Get the region names

$body = @{“request”=“dcnames”} | ConvertTo-Json

#or #$body = @{“region”=”anything”;”request”=”dcip”} | ConvertTo-Json 

$webrequest Invoke-WebRequest -Method “POST” -uri `
https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

4- How to deploy it to your system ?

In order to deploy this function within your infrastructure, you will need to create a Azure function (Section : Create a function app) within your infrastructure. You can use an existing Function App or App Service Plan.

NB : The App Service Plan OS must be Windows

After creating the Function App, do the following:

Step Screenshot
Go to your Function App and click the Create new (+)
In Language chose Powersell then select HttpTrigger – Powershell
Give a Name to your function and choose an Authorization level.

In my case, i set the Authorization to anonymous in order to make the steps simpler. We will see later how to secure the access to the function http trigger

Copy paste the following code on the function tab, then click Save

# POST method: $req

$requestBody = Get-Content $req -Raw | ConvertFrom-Json

$region = $requestBody.region

$request = $requestBody.request

#Main

if (-not$region) {$region=‘all’}

$URi = https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653”

$downloadPage = Invoke-WebRequest -Uri $URi -usebasicparsing

$xmlFileUri = ($downloadPage.RawContent.Split(‘”‘) -like https://*PublicIps*”)[0]

$response = Invoke-WebRequest -Uri $xmlFileUri -usebasicparsing

[xml]$xmlResponse = [System.Text.Encoding]::UTF8.GetString($response.Content)

$AzDcIpTab = @{}

if ($request -eq ‘dcip’)

{

foreach ($location
in
$xmlResponse.AzurePublicIpAddresses.Region)

{

if ($region -eq ‘all’) {$AzDcIpTab.Add($location.Name,$location.IpRange.Subnet)}

elseif ($region -eq $location.Name) {$AzDcIpTab.Add($location.Name,$location.IpRange.Subnet)}

}

if ($AzDcIpTab.Count -eq ‘0’) {$AzDcIpTab.Add(“error”,“the requested region does not exist”)}

}

elseif ($request -eq ‘dcnames’)

{

$AzDcIpTab = $xmlResponse.AzurePublicIpAddresses.Region.name

}

else

{$AzDcIpTab.Add(“error”,“the request parameter is not valid”)}

$AzDcIpJson = $AzDcIpTab | ConvertTo-Json

Out-File -Encoding Ascii -FilePath $res -inputObject $AzDcIpJson


Go to the integrate tab, and choose the following:

  • Allowed HTTP methods : Selected methods
  • Selected HTTP methods : Keep only POST

Click Save

It’s done !

To test the function, go back to the main blade and develop the Test tab

On the request body, type :

{

“region” : “europeewest”,

“request”: “dcnames”

}

Then click Run

You should see the results on the output, and the http Status 200 OK

Click Get function URL to get the URL of your function in order to query it via an external tool

 

5- Securing the access to the function URL

There are 3 options that let you secure the access to the Function URL:

5.1- Network IP Restrictions

I personally think that this is best option to secure the access to Function URL. IP Restrictions allows you allow only a set of Public IP addresses to access the Function URL. For example, if you have an automation script that requests the API and update a Firewall object or a database, you can whitelist only the Public IP address used by this automation workflow, which is the outbound IP address. This feature is available for Basic Tier App Service Plans and greater. It’s not supported for free and shared sku. Start using it by following this tutorial : https://docs.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions.

NB : The Networking blade for a Function App can be found by clicking on the Function Name à Platform features à Networking

5.2- Function Key and Host Key

You can restrict the access to the Function URL by leveraging an Authorization feature, by protecting querying the URL  via a ‘Key’. There are two Key types : The Function Key which is defined per Function and a Host key which is defined and the same for all the functions within a Function App. In order to protect a function via a Function key, do the following :

Step Screenshot
Go to the Integrate blade, and change the Authorization level to Function
Go to the Manage blade. You can use the default generated key or Add a new function key. Generating a new key is provided for keys rotation
Now, you can access the ‘protected’ URL by clicking on the Get function URL on the main blade. You can select which key to use.

 

5.3- Authentication and authorization feature in Azure App Service

This feature allows you to secure your Function App by requesting the caller to authenticate to an Identity Provider and provide a token. You can use it against Azure Active Directory or Facebook for example. I will not detail the steps in this post, but here’s some materials :

Overview : https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service/app-service-authentication-overview.md

How to configure your App Service application to use Azure Active Directory login : https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service/app-service-mobile-how-to-configure-active-directory-authentication.md

 

Use the new Azure Services Tags preview

Hi all,

At Ignite 2017, MS announced a very so waited feature, which is Azure Services Endpoints Tags for Network Security Groups. The new additional Service Tags will permit you to allow/Deny access to and from Azure Datacenter IP addresses.

Why is this important ?

A lot of Azure Services, specially Services related to Azure IaaS rely on network access to Azure endpoints located on the Internet address space. For example, you cannot use Azure Backup for IaaS virtual machines if your virtual machines do not have network access to the Azure storage endpoints of the same region. This causes a lot of frustration, since if you are using NSGs, you cannot easily create and maintain rules for only the Azure IP addresses since the list is huge and dynamic (Azure Datacenter IP addresses). This results on all VMs to have access to Internet using HTTPS.

What is new ?

Additional Service tags have been added to some regions to allow filtering access to :

  • Azure Storage endpoints
  • Azure SQL

The feature is now in Preview, and other regions will be added on the future. Make a look to this article to have the last information : Azure Services Tags

How to use the feature ?

You just need to register to the new preview feature. Use the following powershell code against your subscription :

Register-AzureRmProviderFeature -FeatureName AllowAccessRuleExtendedProperties -ProviderNamespace Microsoft.Network
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

Creating an Azure Resource Policy via a template

Hi all,

This post is about Azure Resource Policy, and specifically, about the creation of an ARP via a template.

If you want to understand what is an ARP and why do you need it, you can refer to the official documentation here : Link1

When you start testing the resource policy, things are not complicated, you can use Powershell to create the policy definition, and then the assignment. But when you start creating real usage policies with a lot of variables, you may want a better way of defining the core of the ARP, and hence, you think about the templates.

So the template is just, as usual, a JSON file where you put the policy definition in a structured way, and then use this file to create the policy. This stills easy since, at the end, you will paste the policy definition to a json file, and then use the same command by just putting the file path. This is documented here : Link2

But, what is missing documentation today, is how to create templates of ARPs that relies on parameters.

1- Why do I need parameters on an ARP ?

The answer to this question is very easy. Let’s suppose you want to apply a policy to different subscriptions, or different resource groups. You may found out or notice that the policy is the same but some properties values are just different.

Example : I want that only a set of vm sizes are used within my subscriptions. So the goal is the same ! But I do know that every subscription will have specific sizes.

  • Subscription A : A-Series
  • Subscription B: A-Series, D-Series
  • Subscription C : A-Series, D-Series, F- Series

So In a world without parameters, I will have to create 3 policy definitions. I will assign 1 Policy to each subscription

#Powershell example

#Policy A

PolicyName = “AllowedVMSizesA”

$PolicyFile = “C:\path\AllowedVMSizesA.json”

definition = New-AzureRmPolicyDefinition -Name $PolicyName -Policy $PolicyFile

New-AzureRMPolicyAssignment -Name $PolicyName -Scope “/subscriptions/SubA-ID” -PolicyDefinition $definition

 

#Policy B

PolicyName = “AllowedVMSizesB”

$PolicyFile = “C:\path\AllowedVMSizesB.json”

definition = New-AzureRmPolicyDefinition -Name $PolicyName -Policy $PolicyFile

New-AzureRMPolicyAssignment -Name $PolicyName -Scope “/subscriptions/SubB-ID” -PolicyDefinition $definition

 

#Policy C

PolicyName = “AllowedVMSizesC”

$PolicyFile = “C:\path\AllowedVMSizesC.json”

definition = New-AzureRmPolicyDefinition -Name $PolicyName -Policy $PolicyFile

New-AzureRMPolicyAssignment -Name $PolicyName -Scope “/subscriptions/SubC-ID” -PolicyDefinition $definition

 

 

In a world with parameters, I will have to create 1 policy with a parameter which is the list of allowed sizes. When assigning the policy to Sub X, I will just pass the list of the related sizes

So the application, and the need for parameters is very crucial.

2- What is the solution?

The solution is this case is to define a policy with parameters, and each time you assign the policy to a scope, you supply the parameter(s) value(s).

A parametrized ARP template, is composed of 2 or 3 files:

  • The policy definition file : The file that contains the policy rule, that rely on parameters
  • The policy parameter file : The file that contains the parameters
  • The parameter file

NB: These first 2 files are only used when creating the policy, the third is used to make the assignment

3- What is the syntax of each file ?

The policy definition file is  the copy/paste of the policy definition as described on the MS link : Link1

You have just to copy and paste your definition to a JSON file. Include the parameters into your definition. The parameters have the following format : [parameters(‘paramterName’)]

The policy parameter file have the following syntax (The example file can be used)

#########################

{

“paramterName” : {

“type” : “string”,

“metadata” : {

“description” : “The description”

}

},   “paramterName2” : {

“type” : “string”,

“metadata” : {

“description” : “The description”

}

},

“paramterName3” : {

“type” : “string”,

“metadata” : {

“description” : “The description”

}

}

}

################################

Important : If a parameter is present on the definition file, and not present on the parameter file, an error will be thrown during the Policy creation.

4- How to create and assign the policy ?

Use the following script to create and assign the policy

###################

#Variables

$PolicyName = “PolicyName”

$PolicyFile = “Path of json Policy Definition File”

$PolicyFileparam = ” Path of json Policy parameter File “

$ScopeID = “Type here the scope ID”

#Params

$param1value = “the value of the parameter 1”

$param2value = “the value of the parameter 2”

$paramNvalue = “the value of the parameter N”

#Create the definition

$definition = New-AzureRmPolicyDefinition -Name $PolicyName -Policy $PolicyFile -Parameter $PolicyFileparam

#Assign the policy

New-AzureRMPolicyAssignment -Name $PolicyName -Scope $ScopeID -PolicyDefinition $definition -PolicyParameterObject @{“Param1=$param1value, “Param2″=$param2value,…, “ParamN”=$paramNvalue, }

###################