In this second article of our series, we will plunge into Azure DevOps to create our release pipeline of the code that we started in the previous article. We will add security controls to protect our implementation of our public DNS using built-in features of Azure DevOps.
Starting with Azure DevOps
The first step is to create a project in Azure DevOps to support our new workload. If that is your first time, you also need to create an organization to support your DevOps adventures.
If you need to create a DevOps organization (you must have one before starting), log in to the Azure Portal, search for Azure DevOps Organizations, on the new page, click on My Azure DevOps Organizations. A list of all existing organizations will be listed. If none, please create one using the Create new organization button.
After having your organization created, create a new project, or use an existing one for this article. If you want to create a new one, on the Organization page (something like dev.azure.com/<OrganizationName>), you will have a + New Project button.
Now that we have an organization and a project, our first step is to create a repository. Logged in to the Azure DevOps, expand Repos (Item 1), click on the current repo arrow (Item 2), and click on New repository (Item 3).
In the new blade, type in the name of the new repo. In this article, we will label it as PublicDNS and then click on Create. The new repo will be opened on the new page.
We will need two files at the beginning — the template file, which we are calling PublicDNS.json and a parameter file that represents the DNZ zone that we are going to maintain, in our case pconsolidated.ca.json file.
Based on our previous article, the template file is not specific and has the capability to create any given zone and A and CNAME records. All the information about the zone and records come from the parameter file. Using this method, we can use the same template to manage multiple zones without developing new code and optimizing the number of files required. It is easier on the eye when managing a large environment.
Both files can be found in my GitHub under TechGenix repo. Here are the links for the template and parameter files. You need to upload them to your new repo and replace the information on the parameter file (you can rename them to meet your requirements).
Creating the release pipeline
Now that we have a shiny new repo with the files that we need to test the solution, our next step is to create a new release pipeline to deploy the ARM template code.
Logged in the Azure DevOps portal, click on Pipelines (Item 1), Releases (Item 2), then click on New (Item 3), and finally on New release pipeline (Item 4) to start the creation process.
In the new blade, click on Empty job. Back to the new pipeline, click on Add an Artifact (Item 1), and on the new blade select the Azure DevOps project that we are working on, the repo (PublicDNS), and the Default Branch, which should be main. Click on Add.
Let’s focus on Stage 1 (you can rename that to a name that describes your environment or application later on) by clicking on the 1 job, 0 task link.
On the new page, click on + (Item 1), select ARM Template Deployment from the list, and click on Add. A new item will be added under the Agent Job list. Click on it (Item 2).
In the new blade, select the Subscription that you want to deploy. You may have to Authorize, which is creating a service principal behind the scenes to allow this pipeline to deploy code into Azure (Item 3). Select the subscription that you are going to perform the deployment (Item 4).
The remaining fields of that same blade will define key areas of this release pipeline. The first is where we will deploy the DNS zones. We decided to use the resource group called RG-PublicDNS. We can define where the resource group will be created (Canada Central in this article).
Note: If the resource group does not exist, it will be created during the first run of the current release pipeline.
The last two pieces of required information are the template (publicDNS.json) and the parameters file (pconsolidated.ca.json or the name that you already renamed to match your zone). When done, click on Save.
Configuring CI/CD
We have the release pipeline configured. We need to make it automatic so that every time someone changes the code and commits to the main branch, we have an update of the infrastructure (aka DNS zone).
The first step is to click on the lightning icon located on the artifacts area and enable the continuous deployment trigger.
The final step is to click on a similar icon but located in the Stage area. We must make sure that After the release is selected.
After making any changes and committing them to the main branch, a release will be triggered automatically (we can always check that on the Releases area of Azure DevOps), and the results in the Azure Portal will be a new resource group with a new DNS zone containing the name that we specified in the parameters file. Of course, all the A and CNAME records will be located within that same zone.
Auditing changes in the Azure DNS
You may be wondering… infrastructure-as-code (IaC) was designed by Asgardians and brought to us by Odin himself, and that is great, but anyone can go there and change something, right?
Using IaC and repos, we have several layers of protection and tracking. The first one that we will check out is the History, and every single commit is being recorded, with the author’s name and date. We can go one step further and click on any given commit, and it will compare the changes added to that specific version compared with the previous one.
It is essential to lock down the access to the Azure Portal and RBAC permissions at the resource group and DNS zones level to ensure that the only possible able to perform changes is using infrastructure-as-code.
Using pre-deployment approvals
Since we are talking about public DNS, we can configure the release pipeline to wait for approvals from key users in the organization who are responsible for allowing changes to the DNS.
When the release is triggered, the portal’s approval can be done, as depicted in the image below.
If the user is not in the Azure DevOps portal, an email is also sent to the approvers’ mailboxes requesting confirmation to complete the release and perform the changes.
Protecting your public Azure DNS zones: A good start
In this second article of our series, we created the Azure DevOps environment to support a CI/CD deployment. We used a couple of the Azure DevOps features to protect the public DNS zones, enhancing the environment with proper approvals and easy track of the changes.
Is that everything? Not at all, there are plenty of features and security controls that can be added to this simple scenario, but this was a good start to get our brains thinking about how IaC can improve our day-to-day activities.
Featured image: Shutterstock
