Azure locks
Locks are mechanisms for stopping certain activities on resources. RBAC provides rights to users, groups, and applications within a certain scope. There are out-of-the-box RBAC roles, such as owner, contributor, and reader. With the contributor role, it is possible to delete or modify a resource. How can such activities be prevented despite the user having a contributor role? Enter Azure locks.
Azure locks can help in two ways:
They can lock resources such that they cannot be deleted, even if you have owner access.
They can lock resources in such a way that they can neither be deleted nor have their configuration modified.
Locks are typically very helpful for resources in production environments that should not be modified or deleted accidentally.
Locks can be applied at the levels of subscription, resource group, management group, and individual resource. Locks can be inherited between subscriptions, resource groups, and resources. Applying a lock at the parent level will ensure that those resources at the child level will also inherit it. Resources that are added later in the sub-scope also inherit the lock configuration by default. Applying a lock at the resource level will also prevent the deletion of the resource group containing the resource.
Locks are applied only to operations that help in managing a resource, rather than operations that are within a resource. Users need either Microsoft.Authorization/* or Microsoft.Authorization/locks/* RBAC permissions to create and modify locks.
Locks can be created and applied through the Azure portal, Azure PowerShell, the Azure CLI, Azure Resource Manager templates, and REST APIs.
Creating a lock using an Azure Resource Manager template is done as follows:
{
"$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/myLock')]",
"type": "Microsoft.Storage/storageAccounts/providers/locks",
"apiVersion": "2019-06-01",
"properties": {
"level": "CannotDelete"
}
}
]
}
The resources section of the Azure Resource Manager template code consists of a list of all the resources to be provisioned or updated within Azure. There is a storage account resource, and the storage account has a lock resource. A name for the lock is provided using dynamic string concatenation, and the lock that's applied is of the CannotDelete type, which means that the storage account is locked for deletion. The storage account can only be deleted after the removal of the lock.
Creating and applying a lock to a resource using PowerShell is done as follows:
New-AzResourceLock -LockLevel CanNotDelete -LockName LockSite '
-ResourceName examplesite -ResourceType Microsoft.Web/sites '
-ResourceGroupName exampleresourcegroup
Creating and applying a lock to a resource group using PowerShell is done as follows:
New-AzResourceLock -LockName LockGroup -LockLevel CanNotDelete '
-ResourceGroupName exampleresourcegroup
Creating and applying a lock to a resource using the Azure CLI is done as follows:
az lock create --name LockSite --lock-type CanNotDelete \
--resource-group exampleresourcegroup --resource-name examplesite \
--resource-type Microsoft.Web/sites
Creating and applying a lock to a resource group using the Azure CLI is done as follows:
az lock create --name LockGroup --lock-type CanNotDelete \ --resource-group exampleresourcegroup
To create or delete resource locks, the user should have access to the Microsoft.Authorization/* or Microsoft.Authorization/locks/* actions. You can further give granular permissions as well. Owners and user access administrators will have access to creating or deleting locks by default.
If you are wondering what the Microsoft.Authorization/* and Microsoft.Authorization/locks/* keywords are, you will get to know more about them in the next section.
Let's now look at Azure RBAC.