Protecting Azure Resources with Resource Manager Locks

Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion or changing of a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and when applied will place the restriction on the resource for all users. These are very useful when you have an important resource in your subscription which users should not be able to delete or change and can help prevent accidental and malicious changes or deletion.

There are two types of resource locks that can be applied:
1. CanNotDelete – This prevents anyone from deleting a resource whilst the lock is in place, however they may make changes to it.
2. ReadOnly – As the name suggests, it makes the resource read only, so no changes can be made and it cannot be deleted.

Resource locks can be applied to subscriptions, resource groups or individual resources as required. When you lock Subscription, all resources in that subscription (including ones added later) inherit the same lock. Once applied, these locks impact all users regardless of their roles, if it becomes necessary to delete or change a resource with a lock in place then the lock will need to be removed before this can occur.

Permissions

Permission to set and remove locks requires access to one of the following RBAC permissions:

– Microsoft.Authorization/*
– Microsoft.Authorization/locks/*

By default, these actions are only available on the **Owner** and **User Access Administrator** built in RBAC Roles, however you can add them to custom roles as required. As mentioned, users with these roles are still subject to the locks, but obviously they can remove them if required. Creation and deletion of a lock is tracked in the Azure Activity log.

Users who attempt to delete or change a resource with a lock in place will receive this error:

Creating Locks

Locks can be created both at the time of creation of a resource inside an ARM template, or later using the portal or PowerShell.

Creating Locks At Resource Creation

The best way to ensure that locks are in place and protecting your resources is to create them at run time and configure them in your ARM templates. Locks are top level ARM resources, they do not sit underneath the resource being locked. They refer to the resource being locked, so this must exist first. In the example below we are creating a storage account, and then adding a lock to prevent it being deleted. The “type” provided will be specific to the resource type your are attempting to lock.

Summary

By using Resource Logs you can put in place an extra line of defense against accidental or malicious changing and/or deletion of your most important resources. It’s not perfect, as your administrators can still remove these locks, but doing so requires a conscious effort, as the only purpose for removing a lock is to circumvent it. As these locks sit outside of RBAC you can apply them and be sure that they are impacting all your users, regardless of what roles or custom permissions you may have granted them.