Ensuring adequate access control is of utmost importance for effectively safeguarding your Azure Storage assets. The Access Control Lists (ACLs) of your Azure Storage Account assume a pivotal role in establishing permissions for both containers and blobs situated within the storage account. The inheritance of ACLs is already in place for newly generated child items beneath a parent directory. However, it's noteworthy that now you also have the capability to set, update, or remove ACLs recursively for the pre-existing child items of a parent directory, thereby eliminating the need to undertake these operations for each individual child item.
In this article, I will walk you through the process of setting Azure Storage Account ACLs recursively using three different methods: PowerShell, AZ CLI and Postman.
1. PowerShell
This example sets the ACL of a directory named mydirectory001 through the "Set-AzDataLakeGen2AclRecursive" command. These entries give the owning user read, write, and execute permissions, gives the owning group only read and execute permissions, and gives all others no access. The last ACL entry in this example gives a specific user (an application registration that I created) with the object ID "c0fb41ac-cd34-4380-a482-470251b089c3" read and execute permissions:
$ctx = New-AzStorageContext -StorageAccountName myazurestorageaccount020 -StorageAccountKey {mykey}
$acl = Set-AzDataLakeGen2ItemAclObject -AccessControlType user -Permission rwx
$acl = Set-AzDataLakeGen2ItemAclObject -AccessControlType group -Permission r-x -InputObject $acl
$acl = Set-AzDataLakeGen2ItemAclObject -AccessControlType other -Permission "---" -InputObject $acl
$acl = Set-AzDataLakeGen2ItemAclObject -AccessControlType user -EntityId c0fb41ac-cd34-4380-a482-470251b089c3 -Permission r-x -InputObject $acl
Set-AzDataLakeGen2AclRecursive -Context $ctx -FileSystem myfilesystem001 -Path mydirectory001 -Acl $acl
Once the command is completely executed, you should see an output similar to the following showing the successful operations on directories, files, the failure count, and a continuation token if applicable:
2. AZ CLI
This example sets the ACL of a directory named mydirectory001 through the "az storage fs access set-recursive" AZ CLI command:
az storage fs access set-recursive --acl "user::rwx,group::r-x,other::---,user:c0fb41ac-cd34-4380-a482-470251b089c3:rwx" -p mydirectory001/ -f myfilesystem001 --account-name myazurestorageaccount020 --auth-mode key --account-key {mykey}
3. Postman
This example sets the ACL of a directory named mydirectory001 through the proper PATCH API call in Postman:
PATCH /myfilesystem001/mydirectory001?action=setAccessControlRecursive&mode=set HTTP/1.1
Authorization: Bearer (Redacted)
x-ms-version: 2023-01-03
x-ms-acl: user::rwx,group::r-x,other::---,user:c0fb41ac-cd34-4380-a482-470251b089c3:r-x
User-Agent: PostmanRuntime/7.32.3
Accept: */*
Postman-Token: 7ef695a6-c446-4b35-a0ce-b54ba08db51a
Host: myazurestorageaccount020.dfs.core.windows.net
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 0
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: Windows-Azure-HDFS/1.0 Microsoft-HTTPAPI/2.0
x-ms-namespace-enabled: true
x-ms-request-id: fa55f148-001f-00db-76ff-ca21fc000000
x-ms-version: 2023-01-03
Date: Wed, 09 Aug 2023 20:26:05 GMT
{"directoriesSuccessful":2,"failedEntries":[],"failureCount":0,"filesSuccessful":5}
Recovering from failures
You may come across runtime or permission-related issues while attempting to modify ACLs recursively. In the event of a permission failure, you can obtain a continuation token by configuring the --continue-on-failure parameter to false. Once you rectify the errors, you can resume the process from the point of failure by re-running the command and setting the --continuation parameter to the previously received continuation token.
In the case of runtime errors (outages or connectivity issues), it's advisable to restart the process from the beginning, this is so because in such scenarios there won't be a continuation token available. It's important to note that reapplying ACLs to items won't result in any negative consequences. Even so, we suggest executing the recursive ACL process within an Azure Virtual Machine situated in the same region as your storage account, this approach will help minimizing latency and to optimize the process in general.
Bonus tip!
You can find this very same option through the Azure Storage Explorer tool, it's the one that says "Propagate Access Control Lists...". This feature gets the current ACLs assigned to the selected path and then executes a recursive REST API operation to assign the same permissions to the child objects:
I hope that helps on identifying different options to set ACLs recursively and to save some time and effort by not having to execute a different operation per child object.
References
=======
Use Azure CLI to manage ACLs in Azure Data Lake Storage Gen2
https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-acl-cli
Use PowerShell to manage ACLs in Azure Data Lake Storage Gen2
https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-acl-powershell
Use Azure Storage Explorer to manage ACLs in Azure Data Lake Storage Gen2
https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-explorer-acl