ACLs in Azure Data Lake

Access Control Lists(ACLs) in azure are an extremely powerful toolset to provision granular levels of access in Azure Data Lake. Role-Based Access Control (RBAC) is best option to setup broader access levels however with ACLs you can reach the lowest possible grains as low as a file inside a blob container. Think of a scenario where you want to add more than 1 user to a folder inside a blob container and each one of them sees only their data - Possible with ACLs

Prerequisites

• Azure Subscription
• Storage blob with hierarchical namespace enabled
• Reader Access on the storage object via RBAC

How to setup ACLs in Azure Data Lake

Like any other offering, Microsoft has a broad spectrum of tools/ways to setup ACLs, ranging from Azure Portal to writing python code. All the steps involved are available in Microsoft documentation, and in a very descriptive manner, therefore needless to rephrase again in this article. Instead, lets walk through some of the challenges one can come across while setting up ACLs.

• To begin with, RBAC access will always supersede ACLs. We can not restrict an AD Group/User to a folder inside a container who has a contributor-level access on storage account. Their Role-Based Access Control(RBAC) will let them do anything they want inside container.
• Additionally, ACLs provision access from the point in time they are setup. To elaborate more on this, let take an example. If you add SALES to an already existing folder 'SALESFEED', the data already existing in the folder will not be accessible to SALES, they will have have access to future objects they create in SALESFEED.
• To make sure SALES can access objects created by users other than SALES in SALESFEED, they must ensure Default ACL is setup for SALESFEED.
• SALES must have EXECUTE permissions on parent folders/container of SALESFEED, and reader access to subscription.

Principal in ACLs

Principal is an entity that defines an end user or a set of users to be setup in ACLs. Any of the objects in the image below can act as a Principal in ACLs. However, recommendation is to use Azure AD Security Groups as that enables owners to add and replace members with in the ACL without the hassle of reapplying ACL over and over again whenever a change is required. Role assignment happens at Principal level.

Permissions

Read, Write and Execute are the levels that can be granted via ACLs. READ enables a reader access on file, along with read on directory but EXECUTE permission is required on all the parent folders rolling up to root folder to enable 'TRAVERSE'. Likewise, WRITE will enable file creation/modification but this too will require EXECUTE until root folder. I would again like to emphasize that ACL permissions of an object are driven from the object itself and can not be inherited, let me rephrase it- If default permissions are set on the parent directory after child items were created then permissions will not be inherited.

Default ACLs

This option lets you setup visibility rules for future children inside a directory. SALES for instance will not be able to see any files created by a different owning user inside SALESFEED untill and unless Default Permissions are setup for SALESFEED directory. Setup is available under Default Permissions tab in Manage ACL option.

Mask ACLs

Mask overrides default permissions for NAMED USERS and NAMED GROUPS. In the case below, Singh,Harinder will have elevated READ access on the ACL directory though it was not set up in ACCESS ACLs. Similarly, Mask can also restrict access added in ACCESS ACL. In scenarios where a temporary access restriction is required on a directory for ACLs, a single mask can be used instead of removing all the ACLs and adding them back again to cater to a temproray requirement.

ACL Best Practices

Microsoft recommends using Azure AD Security groups in place of adding associates at the User level. Let us go back to the SALES example. Regina Filangie heads Sales at Central Perk and wants all her team to be added to SALESFEED. Regina, however, has skyrocketing attrition in her team and therefore to skip the hassle of adding new joiners and removing ex-employee in ACLs with the help of the Cloud security Team, she plans to setup a security group for SALES with herself as the owner. This enables her to add and remove her team to SALESFEED as and when she wants.
This approach also helps in segregation. Let's say Gunther from SALES OPS too wants access to SALESFEED for some reporting needs. He can work on setting up Azure AD Group-driven ACL for SALES OPS. This way it is easy to identify different categories of users added to storage making it easy to manage access and security on storage account.

Credits: Microsoft documentation