When planning your Azure environment, the use of infrastructure-as-code (IaC) is almost a requirement when planning to use multiple environments or having a consistent and reliable way to deploy your infrastructure without manual intervention. In this article, we will cover how you can start planning your security components to increase the posture of your Azure environment by creating a resource group for your security team with some essential resources, such as Log Analytics and Storage Account. We shed some light on how to create the Azure DevOps pipelines in previous articles here at TechGenix. You can use this article as your guide to cover the necessary steps to make the Azure DevOps environment and your first pipeline.
The initial design
We will create a resource group to start placing our Azure resources that will support our security initiative moving forward. The goal is to have a resource group starting with a Log Analytics and a Storage Account.
The idea is to start collecting all diagnostic settings from our Azure resources, including a subscription to that central location, used by Azure Security Center and Sentinel down the road. The Storage Account will help some resources that may require this type of resource, such as some security features in Azure SQL, and can also be used to store scripts and logs for future Azure Automation integrations.
Creating the ARM templates
The first step, based on our scenario, is to create a Log Analytics and Storage Account, and those two resources will be used to store our diagnostic settings.
We will start with a new project in Azure DevOps (TechGenix in our article), and we will create a repo called Security, as depicted in the image below.
The first portion of our code is to deploy the necessary infrastructure. We will call the template file security.json. The parameters file will follow the same naming convention of the template file but with the addition of the environment, for example, security.prod.json (where prod is the parameter file for the production environment).
We will create a new set of templates and parameters that will be applied at the subscription level. We will use the name subscription.json (template file) and subscription.prod.json (parameter file for the prod environment). Note: The files described below are available on GitHub. If you need to look at the templates in more detail, please use this link.
Now that we envisioned the process, we need to receive one bit of information from the pipeline: the environment. After that, we will use ARM functions to retrieve additional information and create the new resources that we are planning to use those variables. The goal here is to reduce the number of parameters by performing some simple logic. Here is a list of the variables introduced in this article:
- v_regionCode variable: We will use the check the location of the current resource group and create a code for the Geo-Political region (Canada Central or Canada East).
- v_loganalyticsName variable: we are going to assign a name using the following our naming convention, the result will be something similar to LogAnalytics-CaC-Prod.
- v_storageaccountName variable: we are going to set a name using our naming convention standard. The result will be something similar to tg00stgcacprod.
Now that we know the name of the future resources, we will create the Log Analytics workspace using a small piece of ARM template with just the necessary information. The only configuration that we need to define is the number of days the information will be maintained to match your security requirements.
Managing auditing at the subscription level
It is paramount for any security initiative in Azure to store and analyze the logs at the subscription level. If you want to configure manually, log on the Azure Portal, search for Subscriptions, select the desired subscription, click on Activity Logs, and then Diagnostic Settings.
We can create a new diagnostic setting and assign which logs we will be collecting to either a Log Analytics, Storage Account, or Event Hub. It is OK to do it manually, but we want to perform consistently, and we will address that using ARM templates.
We can configure the subscription logs using the type Microsoft.Insights/diagnosticsettings and define the logs (they are the same that we have listed in the previous image. Note: We used different functions to retrieve some information. The reason behind it is that we are using at the subscription level, and some ARM functions are not available.
Configuring Azure DevOps release pipeline with security repo
The next step is to create a new release pipeline in Azure DevOps. We will use the security repo that we created previously in the artifacts area, and on the stages, we will add our environments. We will start with the prod and configure some tasks in the next section.
The first thing is to consume the name of the environment to find the template file automatically using an Azure DevOps variable. The variable is called $(Release.EnvironmentName). Instead of specifying the security.prod.json file, we always use a variable and make it easier to copy and paste the stages without performing manual changes within the tasks later on.
We will create two ARM template deployment: one for Security and the second one for the subscription. They will use the corresponding ARM templates and parameters.
There is a slight difference between the ARM templates deployment tasks. The task ARM: Security will be scoped to resource group and the ARM: Subscription Audit to use subscription, as depicted in the image below.
Azure security: More to come
In this article, we started creating a basic structure to collect logs in your subscription and configure the Azure subscription logs to use the new resource provisioned. Are we done? Not at all, there are lots of rooms for improvements, for example, use Azure Key Vault and Azure Automation as part of this current pipeline to improve the subscription. stay tuned
Featured image: Shutterstock
More Azure DevOps articles
- Azure DevOps service connections: How to set them up and use them
- Azure DevOps tips and tricks: Using built-in features
- Customize Azure DevOps work items to improve your projects (Part 2)
- Customize Azure DevOps work items to improve your projects (Part 1)
- How to change the current process in an Azure DevOps project