Avoiding Azure Configuration Drift: How Policies Can Keep Your Cloud Resources on Track

As cloud environments become bigger and more complex, it's becoming increasingly challenging to keep track of all the resources and configurations that make up our cloud infrastructure.

While it is ideal to manage and provision our resources using Infrastructure as Code (IaC) tools, one risk that may be overlooked is the possibility of configuration drift.

Configuration drift is a gradual divergence of a resource’s actual state from its desired state. This can lead to security vulnerabilities, compliance violations, performance issues and more.

In this blog post, we will discuss how Azure policies can help prevent configuration drift and maintain control over your cloud resources.

Sounds familiar?

If you are using Azure DevOps, it's very likely your setup looks like this:

For your Azure DevOps pipelines to access Azure resources, you use a service principal-based linkage between the two. This project-level linkage is in the form of a service connection. Specifically, one that is an Azure Resource Manager type.

Through a service connection, your pipelines interact with Azure. When you reference a service connection in your pipeline, the service principal identity linked to the service connection is used for authentication and the pipeline's jobs/tasks are executed in that context. That is the reason why Microsoft recommends to use "scoped" service connections with limited deployment access to specific Azure resources or resource groups. However, the question remains: is this measure sufficient?

Problem Statement

With this setup, anybody with access to the DevOps project can also access Azure resources. You want to modify a specific resource setting? It's a straightforward process - create a pipeline with the appropriate commands, reference the service connection, and voila! You can modify the desired setting, potentially leading to configuration drift.

I have personally observed a situation where a central team was dedicating significant effort towards developing a standard set of templates and procedures for provisioning Azure resources, but not giving enough attention to these service connections at the same time.

Consider the following scenario: public network access must be disabled on all SQL logical servers and this is reflected in your IaC code. You may have taken several steps to ensure that DevOps teams consistently deploy servers with this configuration. However, with a service connection in your DevOps project, all it takes is a single PowerShell command to enable public network access.

Set-AzSqlServer -ResourceGroupName 'rg-xyz' -ServerName 'xyz-sql-1' -PublicNetworkAccess "enabled" -RestrictOutboundNetworkAccess "disabled"

While you may argue that your DevOps team members are responsible professionals, it is important to bear in mind that insider threats are not uncommon. Additionally, it is possible for mistakes to occur even without any malicious intent, as humans are prone to errors.

What is the answer? Azure policies!

With a policy, the PowerShell command here above would have thrown an error, effectively protecting your server from an undesired (and potentially dangerous) change.

Policies help ensure that your resources are configured consistently and in accordance with your organizational standards, industry regulations, and security best practices.

The good news is that Microsoft has created a huge list of built-in policies (you can also create custom policies). Referring back to our example of SQL logical servers and public network access, there is a built-in policy to control that.
Follow this link for a list of built-in policy definitions for Azure SQL.

Conclusion

Azure policies are a powerful tool for preventing configuration drift and maintaining control over your cloud environment.

Whenever you configure an important setting, make it a reflex to also consider creating an Azure policy that prevents any unintended changes to that setting.

In an upcoming blog post, I will demonstrate a simple and automated approach to assign Azure policies.