Hey, I posted this thread in another site a while ago, but didn’t get any reply. I apologize if you saw this before.
Azure resource locks can be used to prevent accidentally deleting or modifying resources. ReadOnly lock means authorized users can read a resource, but they can't delete or update the resource. Resource Manager locks apply only to operations that happen
in the management plane. The locks usually don't restrict how resources perform their own functions in the data plane.
However, applying ReadOnly can lead to unexpected results because some operations that seem like read operations actually require additional actions. For example, placing a ReadOnly lock on a storage account prevents all users from listing the keys. (https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources).
But depending on your working history in the Portal, your experiences might be different. If you just listed the access keys of a storage account before placing a ReadOnly lock on the storage account, you could still be able to see the keys for a while. Is
this because the keys are cached? However, if you start a new Portal session after placing the ReadOnly lock, you would get the message “The resource is locked”. That means you can list the access keys in one Portal session while getting denied from another
Portal session at the same time.
You will also see different behaviors when accessing different storage account services. From the Portal session where you can still list the keys, you can still access Blob, File, Table and Queue services; and you can upload blobs to blob containers. However,
in the new Portal session where the keys are no longer available, you can’t access File, Table and Queue services. Although you can still access Blob service, you can’t access blob containers. Of course, it is impossible to upload or download blobs/files.
It seems that eventually the “cached” keys would time out. (I don’t know how long it would take.) And the access keys become unavailable in both old and new Portal sessions. At that time, it is impossible to upload/download blobs/files to/from the storage
account from the Portal. However, you can still perform data transfer by using Azure Storage Explorer as long as a connection had been established before the ReadOnly lock is placed, or you copied down the access key and set up a new connection.
Placing a ReadOnly lock to a storage account should not prevent data operations with the storage. But it seems in the Portal accessing different storage services needs the access keys. ReadOnly lock prevents getting the keys if it is not “cached” yet. Therefore,
you may or may not be able to perform data transfer operations in the Portal.
I don’t know if my guess is correct or not. Hope someone can provide some real explanations. Is there a way to enforce the lock behavior, at least within the Portal, i.e. once the ReadOnly lock is placed on a storage account, we would get the same behavior,
whether the operation is allowed or denied, in all existing or new Portal sessions?
