Hello howdy readers, welcome to my post! My name is Khushbu Gandhi, I am Cloud Solutions Architect in Bay Area.
Over the course of my learning with Azure thus far, I have realized that it’s easy to deploy resources in the Azure. In fact, it is this ease of use that has largely catapulted the push towards cloud adoption. But the shortcoming here is that it is just as easy to delete resources in the cloud as it is to deploy them. This is a common concern among organizations wanting to move their infrastructure to the cloud but are skeptical about the safety mechanisms in place to prevent wrongful deletion of critical infrastructure components that could bring an organizations’ business to a standstill. Azure Resource locks allow organizations to put safeguards in place that prevent the accidental deletion or modification of resources in Azure. 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.
Resource locks are just locks that we can associate to different scopes in Azure allowing us to override permissions at that resource scope and down. When we talk about the scope of the resource lock, we can lock subscriptions, we can lock resource groups and individual resources, and the lock restrictions that we have based off the type of lock we select will apply to all users and roles that have access to that resource. Also, it’s worth noting that locks are inherited by child resources. So, if we apply a lock on a subscription, it is inherited by all the resource groups that have been created under that subscription along with the resources that will be created under the resource groups.
There are two types of locks:
- Read Only – resource can’t be modified or deleted but can still be read.
- Can Not Delete – resource can be modified and read but not deleted, by anyone.
In theory, these are perfect for preventing accidental (or deliberate) deletion of resources in Azure. They don’t prevent the deletion of data though, only operating at the “control plane” of a resource. That still sounds great though. Turn them on everywhere! That’s another layer of security in your cloud data platform. Right?
Using Azure Read Only Lock
Step 1: Create demo virtual machine
We are quickly going to create an ubuntu virtual machine via the Azure portal keeping all the default settings as they are.
After logging in to the Azure portal, we are going to type virtual machine in the search bar and click on the virtual machine search result to navigate to the virtual machine service. Now click on the create button on the left side under the virtual machines title to being the virtual machine creation process.
Populate the required fields in the virtual machine creation menu with appropriate values. For our example, we are going to create Ubuntu virtual machine named lock-demo in the West US 2 region.
Once you’ve specified the required values for the fields, click on Review + create. On the next page, click on the create button. Once you click on create, the below prompt will appear.
As a security best practice direct root login to Linux virtual machine is strongly discouraged and therefore, we are prompted to download the private key (to be utilized for key based authentication) and create the resource. Once you click on this button the VM deployment process will begin. Once the VM has been deployed successfully you will be shown the message saying your deployment is complete.
Click on the go to resource button to navigate to the virtual machine settings page for the VM we just created.
Step 2: Add a lock to the virtual machine
Under the VM settings page on the left, we are going to scroll down to the locks section. Click on the locks button to view any existing locks.
As you may have observed this resource currently does not have any locks associated with it. To add a lock, click on the add button. We will now be prompted to provide the name for our lock and its type i.e., read-only or delete. We will select the read only lock here and click on ok.
We will now see that a lock entity now appears in the azure resource locks section. The name and type are the same that we selected, and the scope of the lock is the virtual machine lock-demo.
Step 3: Test the effect of the azure resource locks
To validate how the read only lock affects our ability to manage the virtual machine we will try to perform a couple of operations.
First, let’s try to stop/shut down this virtual machine. For this click on the overview button in the virtual machine settings menu on the left. On the overview page, click on the stop button.
We are now greeted with the below error message -
The message clearly states that we cannot perform write operations on this resource because it is locked.
Now, let’s try to delete this virtual machine by clicking on the delete button and click on ok to confirm the deletion.
Once again, the same error message will be displayed.
We are not allowed to delete this virtual machine because of the presence of azure resource locks.
Using Azure Delete Lock
Note that applying resource locks are management level operations. In this example, we will create a storage account and apply a “cannot delete” lock on it. In this case is that we will not be able to delete the storage account itself, but we would be allowed to delete any data that resides within the storage account.
Step 1: Create storage account
In search bar on the Azure home page, type in storage and select storage accounts from the search results.
You will be brought to the Storage Account service page. From here click on create to create a new storage account.
Fill in the appropriate values for the subscription and resource group and provide a valid name for your storage account. Please note that the storage account name can only contain lower case alphabets and numbers. We have named our storage account lock7demo
Once satisfied with your selections, click on review + create. On the next page, click on the create button to create the storage account.
Once the deployment of the storage account has been completed successfully, you should see the “Deployment is complete” confirmation on the page. Here you will also see a “go to resource” button. Click on this button to navigate to the storage account you’ve just created.
Within our storage account, we’ve created a file share and uploaded two files in this file share as shown in the below screen shot.
Please note that we are not going through the details of creating storage accounts and would explore them in depth in a future article.
Step 2: Apply the Cannot Delete Lock
On the left side menu scroll down to the azure resource locks section in the settings and click on it.
As you may observe from looking at the below screen shot, we presently do not have any locks applied on this storage account.
Click on the add button to associate a lock on this storage account. Type in a name for the lock and select delete as the lock type and then click on ok.
Our lock has now been successfully associated with the storage account lokc7demo.
Step 3: Test the Azure Resource Locks
To test the azure resource locks, let’s attempt to delete the storage account. For this, click on the overview tab in the menu options on the left side of the storage account page and then click on the delete button.
Once we click the delete button, the below error message will be displayed.
The above error message confirms the fact that our delete lock is in effect.
But what if we just wanted to delete some data from the storage account and not the account itself.
To delete data that I have in my file share, click on file share from the menu options on the left side of the page. On this page, we’ll select the demo file share that we had created.
We can see that our share along with its content are available. Now we will delete one of the files in the share i.e., Locking and Moving Resource.txt. to do so, click on the three dots towards the end of the line and select delete.
Click on yes to confirm.
The deletion operation would be successful.
But if you try to delete the file share itself then that operation will fail.
With this example, we wanted to illustrate that resource locks get applied on the entity or resource level and not to the data that resides within these resources.
Administering Resource locks by adding a Custom Role
Given the resource lock functionality is outside of standard Role Based Access Control (RBAC), it would be prudent to create a resource lock administrator role to prevent inadvertent unlocking of resources. By adding this role is you can have specific permissions granted for managing just resource locks rather than needing to provide the wide owner or contributor role reducing the risk of the user being able to do unintentional damage.
Adding a custom role
In the Azure portal, open a subscription or resource group where you want the custom role to be assignable.
Select Access control (IAM) -> Click Add -> Select Add custom role
For Custom Role Name field enter ‘Resource Lock Administrator’. In the Description field enter ‘Can Administer Resource Locks’. For Baseline permissions select Start from scratch -> Click next
In the Permissions tab, select Add permissions. In the Search for a permission box, type in Microsoft.Authorization/locks to search for permissions. Now, select the check box next to the permission called Microsoft.Authorization/locks -> click add
Click Review+create -> Click Create. You can now assign the newly created role to the appropriate user.
Considerations
There are a lot of these considerations before applying Resource locks. These are documented in the Azure Resource Locks docs. Here are a few excerpts:
- A cannot-delete lock on a resource group prevents Azure Resource Manager from automatically deleting deployments in the history. If you reach 800 deployments in the history, your deployments will fail.
- A cannot-delete lock on the resource group created by Azure Backup Service causes backups to fail. The service supports a maximum of 18 restore points. When locked, the backup service can’t clean up restore points. For more information, see Frequently asked questions-Back up Azure VMs.
- A cannot-delete lock on a resource group prevents Azure Machine Learning from autoscaling Azure Machine Learning compute clusters to remove unused nodes.
Not all the considerations are documented here. The most significant impact I’ve came across is with Azure Data Factory’s functionality. We will talk about Azure Data Factory’s functionality using Azure Resource locks in a separate blog.
Summary
In this article, we discussed why need the capability to apply Azure resource locks on our resources in the cloud and explained the two types of resource locks available in Azure. We also practically demonstrated how operations on locked resources are affected. We have also discussed considerations before applying resources locks and using a custom role to administer resource locks. To make the protection process more robust, it is recommended to combine resource locks with Azure Blueprints. Azure Blueprints enables you to define the set of standard Azure resources that your organization requires. For example, you can define a blueprint that specifies that a certain resource lock must exist. We’ll talk about Azure Blueprints in a separate blog or review the link provided above.