Intro
Did you know that you can automate the association of Private Endpoints to their respected Private DNS Zone by using Azure Policy?
Azure Policy is a governance platform within Azure that allows for the implementation of guardrails and management over your Azure resources. It ensures that resources are configured with the correct properties and settings before they are deployed into your environment. Additionally, Azure Policy can enforce specific configurations on resources after deployment, ensuring they conform to the requirements set by the platform team.
Basically Azure Policy is a really good way to provide overall governance over your estate…
The Challenge..
If you manage your organisations Azure Platform, and enforce Private Endpoints for PAAS services you will appreciate the important of centralising your Private DNS Zones. Additionally if your Azure estate is aligned to Microsofts Cloud Adoption Framework (CAF), your Private DNS Zones should be situated centrally within your connectivity subscription.
Ok so I have my Private DNS Zones, centrally so what?
Well the challenge is now that as you bring workloads into your Landing Zone, there is now a dependancy to grant permissions those Private DNS Zones, which means the more workload the more permissions, and do you really want to be applying your workload users access your central core services?
In most cases, if deployment is carried out via CI/CD, you only need to grant the app registration or managed identity access to the Private DNS Zones. However, there is still a dependency on ensuring that teams correctly associate Private Endpoints with Private DNS Zones.
This is where Azure Policy (AP) comes into play. With AP, we can use “Deploy if not Exists” policies to continuously scan the Azure environment for Private Endpoints that lack associations with Private DNS Zones. When such an endpoint is found, the policy creates the association, thereby adding the A-Record in the zone to make the Private Endpoint resolvable.
Anyway let’s get into it…..
Creating the Initiative
Now this isn’t happening by magic, there is a user-assigned managed identity behind the scenes that is creating the association. I personally like to bring my own User Assigned Managed Identity, so I create one as part of my landing Zone deployment in the Management Subscription.
Head over to Azure Policy (you can do this by searching “Policy” in the Azure search bar)
Once in the Azure Policy portal, navigate down to “Definitions” and search for “Private DNS”, this will generate a list of BuiltIn policies that are available to assign to for the difference services you may have deployed in your environment.
Ideally you would want to create an initiative that comprises of all of these Policies so you only have one assignment to manage, so that’s what we are going to do.
For the purpose of this blog, we are going to focus on assigning the Blob Private DNS Zone, so let’s start by creating an initiative for our policies. As shown in the image above select “+ Initiative Definition“
Here you need to set the initiate location at the root management group of your Landing Zone, as this will only take affect on resources at or below this scope. We then need to prove a name, (make this relevant :)) We can then chose a category, I created a new one called “DNS” but again you can set this to what makes sense to you and your environment.
Now we need to add a policy to our initiative, as mentioned I’m using the policy related to the blob Private DNS Zone. Navigate to “Add Policy definition” and select the policies you wish to add to the initiative.
Once this is done, we can navigate straight to “Policy Parameters” and you will be presented with something like the below.
Here we can set which policy is associated with which Private DNS Zone, makes sense right? We want to associate the Policy that is used for Blob to the Blob Private DNS Zone. This will be blank initially so you need to select the blue ellipsis and navigate your respected Private DNS Zone, so it will look like the below.
Assigning the Initiative
Now for this initiative to take effect, we need assign it at our desired scope. We can do this by going back to searching for the Polic inittiative and selecting “Assign Policy”.
You will then be presented with this first page, where you can assign the policy at the desired scope and apply any exclusions if needed.
Next we can head over to remediation which is where we will use the Managed Identity that was created previously to apply the association to the Private DNS Zones, it’s important to provide the path to the Managed identity so that the existing identity can be selected.
If you wish, you can create a non-compliance message, but it is not necessary, and you can proceed directly to creating the assignment. It’s also important to note that at the point of assignment, the role assignment of Network Contributor will be created. Therefore, you need to ensure you have the necessary permissions to create role assignments at this scope.
Now that this is done let’s test it out by creating a Private Endpoint for a Blob Storage Account, I won’t cover the ins and outs of creating a Private Endpoint as I cover this off in a video on my blog site.
Once the endpoint is created you will see that the DNS is not currently configured
However after about 5 or so minutes, you will see that the association has been created…. WAHOOO..
It’s important to note that if you apply this policy or initiative after having existing Private Endpoints, the policy will not automatically associate these resources. However, it will flag them in the compliance center, allowing you to create a manual remediation task to enforce the policy on the existing Private Endpoints.
Wrap Up
In summary, I have demonstrated how you can use Azure Policy to automate the association of Private Endpoints with their respective Private DNS Zones. The idea is to continually build out and add to the initiative that was created.
This approach ensures that workloads in the Landing Zone use the correct Private DNS Zones for their Private Endpoints. Additionally, as new workloads are brought into the Landing Zone, you won’t need to manually apply any permissions to the central core services, since Azure Policy will use a User Assigned Managed Identity to create the association.
I hope you found this blog useful. If you have any questions or queries, please do not hesitate to contact me on LinkedIn.
This also ensures workloads in the Landing Zone are using the correct Private DNS Zones for their Private Endpoints. This means also that as new workloads are Brough into the the Landing Zone, you do not have to be concerned with applying any permissions to the central core services as Azure Policy will use a User Assigned Managed Identity to create the association.
I hope you found this blog useful and if you do have any questions or queries, please do not hesitate to contact me on LinkedIn (https://www.linkedin.com/in/jonathan-d-aloia/)