The most common permission in the Azure environments where there isn’t any dedicated Azure Engineer, is providing the Owner or Contributor permission.
Such environments are waiting for a disaster to happen, mistakes happen, and deleting a resource in cloud environment is as easy as deploying them.
To avoid such blunders to happen you should follow the minimum permissions principal, i.e. provide only the required permission to a user and also lock the resources to avoid the mistakes from happening.
Lock is possible for any resource in Azure and there are two locking strategies:
- CanNotDelete: None can delete the resource even if they are the owner. To delete such resource you are first required to remove the lock and then delete the resource.
- ReadOnly: It means authorized users can read a resource but they can’t delete or update the resource.
It is inherited down the resource hierarchy, for the resources existing and also for any new resource being added in.
As you can see above the locks are inherited down from subscription to resource group to a resource.
Creating the lock using PowerShell is done using the below command:
New-AzResourceLock -LockName DoNotDelete -LockLevel CanNotDelete -ResourceGroupName 4Blog
Doing the same thing using CLI:
az lock create --name DoNotDelete --lock-type CanNotDelete --resource-group 4Blog
There are some operations that are blocked by ReadOnly locks like, listing keys in Storage account, it can prevent users from starting or restarting the virtual machine. So do proper checks when implementing ReadOnly locks.
I hope it helps!