In my last post I described how to use Azure Resource Policies to keep your environment clean. However, Azure Resource Policies do not protect you from unwanted modifications or even deletions of critical resources. This is where Azure Resource Locks come into play.

When using Azure in a production environment, you normally have lots of resources that are critical to your applications or your platform. By using Azure Resource Locks you have a simple and powerful approach to easily protect those kind of resources.

Manage Azure Resource Locks

Depending on the exact needs, Azure Resource Locks can be configured at different levels:

• Subscription
• Resource Group
• Resource

Lock configurations are inherited which means that configuration at the subscription level will apply to all resource groups and resources in the subscription. Lock configurations assigned to a resource group will be pushed down to all resources of the group. And lock configurations that are assigned to a single resource will only protect that specific resource.

So let’s say I have a Resource Group that contains critical DNS Zones that I want to protect. When navigating to the Resource Group I can use the “Locks” menu to configure the protection.

Currently there are two different lock types available:

• Read-only
• Delete

“Read-only” obviously protects the Resource Group so that nothing can be changed anymore. In this example that means that I will not be able to provision any new resource (e.g. a new DNS zone) into this Resource Group, not will I be able to change an existing resource (e.g. add a new record to an existing DNS zone). If I try I receive an error message that tells me the resource is locked and that this lock needs to be removed first.

The lock configuration from the Resource Group is pushed down to all the resources in the group. If I go to a resource in the group, in this example a DNS zone, I can see that there is an inherited lock available. However, this configuration cannot be changed here, it needs to be changed on the appropriate parent.

“Delete” means that the resource is protected from deletion, but changes are still allowed.

By using Powershell you can centrally manage Azure Resource Locks:

Get-AzureRMResourceLock

New-AzureRMResourceLock

Remove-AzureRMResourceLock

Set-AzureRMResourceLock

Locks vs. RBAC

You might already know about Azure RBAC, or “role-base access control”. RBAC allows you to assign permissions for a specific resource or object in Azure, even by directly assigning permissions to a user account or to a group. So why not using RBAC to protect critical resources in Azure? The answer is rather simple: this would work, however you would probably end up in a configuration and transparency nightmare. Locks are much simpler to configure than RBAC, and when you want to globally protect a specific resource from deletion or modification this is the way to go. RBAC on the other hand is used when you want to give different and specific permissions to users or groups.

Alternate ways to configure Locks

There are more options available to configure locks, e.g. by using Powershell or ARM. This is very helpful if you want to automate resource deployment and configurations or use a descriptive approach to provision resources in Azure. This Microsoft article explains the needed steps for those approaches in more detail.

That’s more or less it about Locks. Happy locking!

Cheers
Marcel