Prevention is better than Cure – There were quite a few instances when I thought I should have applied this logic. This has even more significance if you are playing around public cloud more so while dealing with mission critical resources there. There must have been numerous occasions when you would have to protect you resources from some unwarranted human actions, to put it bluntly we are seeking a solution prevent other users in organization from accidentally deleting or modifying critical resources.
Azure has given us couple of ways to apply that level of control, firstly with role-based access control (RBAC), With the Reader and various Contributor roles RBAC is a great way to help protect resources in Azure. You can effectively limit the actions that a user can take against a resource. However, even with one of the Contributor roles, it is still possible to delete specific resources. This makes it very easy to accidently delete an item.
Azure Lock provides you the options using which you can effetely control any such adventure. Unlike RBACK, you use management locks to apply a restriction across all users and roles. To learn about setting permissions for users and roles, see Azure Role-based Access Control. Using Resource lock you can lock a particular subscription, a particular resource group or even a specific resource. With this in place authorize users can still be able to read or modify the resources but they CAN NOT breach that lock and delete the same.
To make this happen you have to apply the Resource Lock Level to aforementioned scopes. You can set the lock level to CanNotDelete or ReadOnly(As of now these two are the only options supported). CanNotDelete means authorized users can still read and modify a resource, but they can't delete it. ReadOnly means authorized users can only read from a resource, but they can't modify or delete it.
When you apply a lock at a parent scope, all child resources inherit the same lock.
One point worth mentioning here is that you will also need to be in either an Owner or User Access Administrator role for the desired scope, because to play with Resource Lock it’s prerequisite to have access to Microsoft.Authorization/* or Microsoft.Authorization/locks/* actions(only these two have appropriate permissions).
Create Resource Lock Using ARM Template
With Azure Resource Manager template we can lock the resources at the time of its creation. An ARM template is a JSON-formatted template file which provide a declarative way to define the deployment of Azure resources.
Here is the example of how to create a lock on particular Storage Account-
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"lockedResource": {
"type": "string"
}
},
"resources": [
{
"name": "[concat(parameters('lockedResource'),
'/Microsoft.Authorization/utLock')]",
"type": "Microsoft.Storage/storageAccounts/providers/locks",
"apiVersion": "2015-01-01",
"properties": {
"level": "CannotDelete"
}
}
]
}
If you see the example clearly the name of storage account coming via parameter while the most important section to be noticed is how the lock (utLock) has been created by concatenating the resource name with /Microsoft.Authorization/ and the name of the lock.
Placing a resource lock on an entire group could be helpful in situations where you want to ensure no resources in that group are deleted. With below example I have tried to create a resource lock on a particular resource Group” UT-RG”
New-AzureResourceLock -LockLevel CanNotDelete `
-LockNotes 'No deleting!' `
-LockName 'utLock' `
-ResourceGroup 'UT-RG' -Verbose
To remove the resource Lock make use of Remove-AzureResourceLock cmdlet, make sure you are providing proper ResourceId.
> Remove-AzureResourceLock -ResourceId '/subscriptions/xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/UT-RG/providers/Microsoft.Storage/storageAccounts/utsrt/providers/Microsoft.Authorization/locks/utLock'
#Deleting Resource Group
Remove-AzureresourceGroup -Name 'UT-RG' -Force -Verbose
Off late Azure has brought this support to ARM Portal as well, to achieve the similar things via portal click the Settings blade for the resource, resource group, or subscription that you wish to lock, select Locks.Once prompted Give the lock a name and lock level and you are immune to those talked about unwanted situations.It gives you options to lock an entire subscription to ReadOnly if malicious activity was detected.
