Using Azure Policies to create an extra layer of security and improve operations

We can assign role-based access control (RBAC) in the Azure Resource Manager and it is a great tool to delegate and implement the least privileges principle in Microsoft Azure. However, that is not the only service available to restrict and define boundaries in Microsoft Azure. We can also take advantage of Azure Policy services. Azure Policies are evaluated when creating Azure Resources and they allow the organization to check which resources are compliant or not with the existent policies. We can take advantage of Azure Policies to create an extra layer of security and implement policies to a predefined scope that could be a Subscription, Management Group, or a Resource Group. By combining Azure Policies with RBAC, we will have a more robust security in place.

It also improves operations. We can restrict all VMs to be created in a single region, which avoids any future mistake of creating a VM in a region where we don’t have an infrastructure in place. We can use policies for a variety of scenarios. A few worth mentioning in this introduction: tags to the resources, type of VM, allowed or denied resource types, and audit diagnostic settings.

In this article, we will create an Azure Policy to make sure that only VMs can be created. This is a useful scenario where after creating and establishing all network and additional resources, we may lock down the subscription to allow just the creation of VMs. Even if a user has permission in RBAC to create a load balancer or even storage, it will be denied by the current policy in effect.

Using Azure Policy

The best way to understand how Azure Policies works is using a simple scenario. Let’s create an Azure Policy that allows only a specific number of resources to be provisioned (VMs in this article) and this policy will be assigned at the subscription level.

Logged in the Azure Portal, go to Subscriptions (either by searching for it or by clicking on the left side). A list with all existent subscriptions will be shown. Click on the desired one. In the new blade containing all information about the given subscription, click on Policies, which is located in the Settings section.

In the new blade, we are going to be directed automatically to Compliance, which is going to give an overall view of all Azure Policies and Initiatives being applied to the environment. The cloud administrator has the ability to filter by scope, type, compliance state, and for a particular string.

For now, we are going to create our very first Azure Policy. Click on Assign Policy. In the new page, our first step (item 1, below) is to click on and a list of available definitions will be listed on the right side. We are going to select Allowed resource types. After that, we need to label our current Azure Policy (in our case Policy – Resources Allowed), and we need to define a Scope. In our case, it is going to be at the Subscription level.

Note: We can define an exclusion at the Resource Group level, and any resources being created on that given Resource Group will not receive the current Policy. Also, pay attention to the name of the Definitions. Some of them are an audit and some of them enforce settings. We will check in a little bit how to see the effect of any given policy.

azure policies

 

The final step is to define the Allowed Resource types of the current policy. Click on the drop-down field and for this exercise. We will select a few items to start with:

  • Compute/virtualmachines
  • Compute/virtualmachines/diagnosticSettings
  • Compute/virtualMachines/extensions
  • Compute/virtualMachines/metricDefinitions

After creating the first Azure Policy, we can click on Compliance and it will be listed on the right side. In that new blade on the right side, we will be able to see in a single glance the scope of the current policy, if it is in compliance or not, the type (initiative or policy), and the number of noncompliant policies and resources.

Click on the Azure Policy that we have just created. In the new blade, we have an overview of this specific policy where we can see the current compliance state, the number of noncompliant resources, and so forth.

In the top bar, we can manage the current policy (item 1, below). In the middle of the screen under Details, we can check the Effect of the policy, in this case, Deny, which means that new resources that do not match this policy will not be deployed. We have also two views (item 2) Non-Compliant and Events. In the first tab, we will see a list of all resources that are no following the current policy (it could be resources created prior to the policy, which is the current case).

azure policies

When we click on Events we have a list of all users that were denied by the current policy. We can get more information by hitting and then Show activity logs, which will open the Activity Log blade. This allows us to go deeper and retrieve the last piece of information, such as what object the user was trying to create, what time, and so forth. (For more information about the Activity Log service, please see this earlier article.)

azure policies

Testing the new policy

The first test is to create any new resource that is not a VM. In the example below, we can see that the object that we are creating is a new Availability Set, and we can see the error There were validation errors. Click here View details. When we click on it more detailed information will be displayed.

azure policies

Troubleshooting Azure Policies

The Azure Policy we created in this article allows the provision of just VMs. But a VM is more than just VM — when you provision a VM you are touching network interfaces, DevLabs for automatic shutdown, extensions, Network Security Groups, Public IPs, and much more.

If we just add the resources that seem to be right, we may be missing a couple of required components that must be allowed as part of the VM process. Using the example that we gave at the beginning of this article, here is the result when we tried to provision a new Windows Server 2016.

azure policies

There are several ways to perform troubleshooting of this kind of issue. My preference is going back to the policy and checking the Events tab that we discussed in the previous section and show the Activity logs.

We will be redirected to the Activity Log. First of all, make sure to check the logs related to the deployment that you want to troubleshoot. In our current situation, it is related to deployments/Microsoft.WindowsServer2016… After that, find the Deny activity, which is underneath validation, and click on JSON.

Go through the JSON — I suggest you do it while sipping a coffee and getting into a relaxed state of mind! Give yourself some time to get acquainted with the information and you will find the blockers — in our example, I missed the DevTestLab resource, which by default shut down the VM automatically. With that feature enabled, our provisioning was failing.

azure policies

After checking the logs, we realized that we had to add some entries, as follows:

  • DevTestLab/Labs
  • Network/networkInterfaces
  • Network/networkSecurityGroups
  • Network/publicIPAddress

It is very important to test any new Azure Policy thoroughly because not every operator/administrator will create the VM in the same way. Let’s say if one operator does not use NSG at all, he or she won’t get an error if the resource Microsoft.Network/networkSecurityGroups is not present in the policy.

If you work in a medium to a large enterprise, my recommendation is to deploy using ARM templates to achieve consistency when deploying resources in your environment.

Photo credit: Shutterstock

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top