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 restrictions on the resource for all users. these are very useful when you have an important resource in your subscription that 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 a 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, but 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:

failed to delete storage account 'criticalstorageaccount1'. error: the scope '/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/lambdatoys/providers/microsoft.storage/storageaccounts/criticalstorageaccount1' cannot perform delete operation because following scope(s) are locked: '/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/lambdatoys/providers/microsoft.storage/storageaccounts/criticalstorageaccount1'. please remove the lock and try again. 

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 you are attempting to lock.

    "resources": [

        {
            "type": "microsoft.storage/storageaccounts",
            "name": "criticalstorageaccount1",
            "apiversion": "2015-06-15",
            "location": "[resourcegroup().location]",
            "tags": {
                "displayname": "criticalstorageaccount1"
            },
            "properties": {
                "accounttype": "standard_lrs"
            }
        },
        {
            "name": "[concat('criticalstorageaccount1', '/microsoft.authorization/criticalstoragelock')]",
            "type": "microsoft.storage/storageaccounts/providers/locks",
            "apiversion": "2015-01-01",
            "properties": {
                "level": "cannotdelete"
            }
        }       
    ]

the "level" setting can be changed to "readonly" as required.

adding locks

locks can be added to existing resources either through the portal or using powershell.

portal

1. locate the resource you wish to lock and select it. in the main blade, click the "locks" icon



2. click add
3. give the lock a name and description, then select the type, deletion or read only.



4. click ok to save the lock: the resource is now protected.
5. to remove the lock, simply come back to the same interface, select the lock, and then go to delete

powershell

the following can be used to add a lock to an existing resource. again, the resourcetype will vary depending on the resource you are trying to lock.

new-azurermresourcelock -locklevel cannotdelete -lockname criticalstoragelock -resourcename criticalstorageaccount1 -resourcetype microsoft.storage/storageaccounts -resourcegroupname criticalstoragerg

to remove a lock, use remove-azurermresourcelock.

remove-azurermresourcelock -lockname criticalstoragelock -resourcename criticalstorageaccount1  -resourcegroupname criticalstoragerg -resourcetype microsoft.storage/storageaccounts 

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.