Simplifying managing Azure Front Door IP whitelisting

In the serie 'Advanced Azure Front Door configuration strategies for Sitecore Managed Cloud on Containers', this is part 1: Simplifying managing Azure Front Door IP whitelisting for the Sitecore CD and CM roles.

Sitecore Managed Cloud comes in two flavours, webapps and containers. In my role as Senior Solution Architect at uxbee, I setup and configured the container variant for a customer. In this blog series I will share my configuration experiences, with Azure Front Door in combination with Sitecore Managed Cloud. I named this series ‘Advanced Azure Front Door configuration strategies for Sitecore Managed Cloud on containers’.

In the Managed Cloud environment of Sitecore there are four roles that can be accessed publicly. These roles are:

• Content Delivery (CD)
• Content Management (CM)
• Sitecore Identity Server (SIS)
• Grafana

Every role is behind Azure Front Door to protect the application against attacks from the Internet. In the case of our customer, test, acceptation, and production environments are available. I wanted to use IP whitelisting to hide the test and acceptation environment from getting accessed publicly. In addition, I wanted to prevent public access to the Sitecore client for the production environment as well. In this blog I will be focusing on the IP whitelisting of the CM and CD roles of one of these environments.

In the documentation of Sitecore it is described how to enable IP whitelisting. In most of the cases you want to setup IP whitelisting for a limited number of IP addresses. Like the business network of the customer and the IP address of a VPN connection. In some cases, a VPN is not available and working from home becomes an issue. In this special case, home IP addresses of employees can be whitelisted. Although you can configure IP whitelisting, it is hard to keep track of the owners of the IP addresses. In this blogpost I will explain what I did keep track of specific IP addresses and the owner of these addresses.

NOTE: Many providers supply an IP v6 address. This address is normally dynamic and cannot be used for whitelisting purposes. To prevent this, you can disable the Internet Protocol Version 6 (TCP/IPv6) in your network adapter.

Front Door WAF policies

Out of the box Sitecore Managed Cloud has two Front Door WAF Policies. It is easy to identify the policies by role based on the naming convention.

• xxxxxxxxxxxxxxxxxxxxfdp (CD)
• xxxxxxxxxxxxxxxxxxxxcmfdp (CM)

You could ask yourself why a custom rule for IP whitelisting for the Content Delivery Role exists. It is good practice to have a CD role in a Test or Acceptance environment behind IP whitelisting to prevent public access and indexation of your test and acceptance sites.

Front Door WAF policy for the CD

The policy for the CD role contains lot of ‘managed rules’ for blocking all kinds of malicious attacks.

Under custom rules, there is a rule for IP whitelisting with the name ‘customRuleForWhiteListIP’.

Front Door WAF policy for the CM

The CM policy is missing the managed rules for blocking the malicious attacks, it is important to have an accurate IP whitelisting in place on the CM server. This to prevent direct access from the internet. Authentication is still managed by the Sitecore Identity Server. When opening the custom rule for whitelisting IP Addresses, you will see the whitelisted IP addresses in the right bottom of Azure portal interface.

Infrastructure As Code

The Sitecore managed cloud infrastructure is based on IAC (Infrastructure As Code). It is IMPORTANT to understand that you are not allowed to change anything through the Azure interface! When making changes directly in the Azure interface, you could be in for a lot of trouble (errors). Changes must be made in the correct Terraform file provided by the managed cloud, these changes are deployed with the ‘Front door’ pipeline.

The Sitecore managed cloud DevOps environment consists of two repositories:

• Application
• Infrastructure

IP whitelisting is configured from the infrastructure repository and has the following folder and file structure. In the folder ‘frontdoor’ all the file(s) for managing the Azure Front Door are stored. In the frontdoor folder there is a terraform file called main.tf. In this file you can add the IP addresses for IP whitelisting.

When you open main.tf and scroll to the end of the file, you find two resources of type ‘azurerm_frontdoor_firewall_policy’. One with the name ‘this’ and one with the name ‘cm’. The ‘this’ resource is for the content delivery role and the ‘cm’ resource is for the Content Management role. 

Now let's take a closer look at the ‘this’ (for managing the CD) resource. When you expand the resource node you will see that there are two sections:

• managed_rule
  In this section you can set the rule set type. Out of the box it is set to the DefaultRuleSet version 1.0.
• custom_rule
  In this section you can set custom rules, multiple custom rules can be defined. They will differ by name.

The custom rule shown in the image is for whitelisting IP addresses. You can identify this rule by the name ‘customRuleForWhiteListIP’. ‘Match_values’ is the place where you can add an array of IP addresses that will be whitelisted, as the 'negation_condition' is set to true for the operator IPMatch.

Simplifying IP whitelisting Management

As you can see only IP addresses/ranges can be filled in at ‘match_values’. I did not like this approach at all, as this will not be manageable at all for the long term.

After a while you c remember which IP address belongs to whom. Instead, I wanted to use a Json file, where I enter all the IP addresses connected to a name. So that it is possible to keep track of the owner or purpose of the IP address. The structure of this Json will look like this.

There are two sections where we can manage IP addresses, one for cd and one for cm. In these sections we can manage the IP addresses in a much better way. If after a few months there is a request to remove the IP address of ‘Name 2’ it’s easy to locate the right IP entry. The only question is if this can be implemented in terraform? Delightfully, the answer is YES!

Convert JSON to an object in Terraform

In PowerShell I often read Json file and convert it to an object in the PowerShell context. What if I could do the exact same thing in Terraform. I found two functions that can do the exact same thing. The links below contain the documentation on those functions:

• https://www.terraform.io/language/functions/file
• https://www.terraform.io/language/functions/jsondecode

Whitin the locals section of the main.tf file you can add the loading and decoding of the Json file. It creates a local variable ‘whitelist’ that will hold an object version of the Json file.

The next challenge is how to fill in the property ‘match_values’ on the ‘match_conditon’. As you have seen before this property must be of type Array. (See pic below). So, I wondered if it is possible to do a select statement on the created whitelist object and output an array of IP addresses in Terraform.

Within Terraform there is a powerful ‘for’ expression, that will do the trick. In the local section you add two more variables. You can fill the variable with the ‘for’ expression. You will loop trough the cm or cd children and only output the cidir into an array.

The final step to make this all work, is to put an array list to the ‘match_value’ property.
NOTE: The example only shows the cm, you must also apply this for the cd policy.

Deploying your changes

To deploy your changes, you can create a feature branch and commit the changes. Via a pull request your changes can be merged into the main branch. When your pull request is merged, run the ‘frontdoor’ pipeline. The pipeline should run without any errors and the IP addresses are whitelisted.