Recently, I encountered a situation with Azure Storage. We were playing with immutability policy in a storage account in a test environment. We've set a policy for tests, we did what we wanted to do, when the time came to delete the environment, I hit a roadblock.

Locked by an immutability policy

The immutability policy on the storage account was preventing deletion. And thinking it back, it is what it is supposed to do.

Azure's immutability policies are a powerful feature for compliance scenarios, where preventing data from being altered or deleted is crucial. These policies, when locked, enforce retention periods and legal holds which can't be bypassed easily.

Understanding immutability policies

Immutability policies in Azure Blob storage allow users to store business-critical data objects in a WORM (Write Once, Read Many) state. This means that once written, the data cannot be modified or deleted for a specified retention period. These policies are crucial for scenarios where data needs to be preserved in an unaltered state for compliance with industry regulations or company policies.

The Mitigation: Removing immutability policies

! This works only if your policy is in an Unlocked state. If Locked, you'll need to wait until the period you set expires. There is nothing to do in a Locked state other than wait.

Luckily for us, we expected that for tests and left the policy Unlocked. But still, I couldn't just delete the storage account, nor the container in a one-shot operation.

The solution involved programmatically removing the immutability policy from each blob within the storage account's container. By leveraging Azure CLI, specifically the az storage blob immutability-policy delete command, I was able to loop over all the blobs and remove their respective immutability policies.

Here is an example of the Azure CLI command I used to remove the immutability policy from a blob:

az storage blob immutability-policy delete --account-name <StorageAccountName> --container-name <ContainerName> --name <BlobName>

This command requires the storage account name, container name, and blob name to identify the blob for which the policy should be removed.

Scripting time

To expedite the process, I wrote a script that iterated through all blobs under the target container and executed the command to remove the immutability policy for each one. Once the policies were cleared, I was able to delete the container, then the storage account without any further issues.

Here's a simplified example of how such a script might look:

# Set variables
$accountName="<myStorageAccount>"
$containerName="<ContainerName>"

# List all blobs in the container
$blobList = az storage blob list --container-name $containerName --account-name $accountName --query "[].name" --output tsv

# Loop through each blob and remove the access policy
foreach ($blob in $blobList) {
    az storage blob immutability-policy delete --container-name $containerName --name $blob --account-name $accountName
}

Remember to replace <myStorageAccount>, <ContainerName> with your actual resource names.

Conclusion

It is important to understand Azure's data protection features such as immutability policies, and how they can impact resource management. While these features are excellent for ensuring data integrity and compliance in production, they require additional steps if you play with it in an ephemeral fashion or test environment.

References

Happy cloud computing!