For ADLS Gen1, the two levels of security that applied to ADLS Gen2 were also in place. Even though this isn’t new, it’s worth mentioning the two levels of security because it’s a critical component of getting started with the data lake, and it may be perplexing for newcomers.
-
Access Control by Role (RBAC). Built-in Azure roles such as reader, contributor, owner, and custom roles are included in RBAC. RBAC is typically awarded for two reasons. One is to define who will be in charge of the service (i.e., update settings and properties for the storage account). Another purpose is to allow users to use built-in data explorer tools that need reader rights.
-
Lists of Controlled Access (ACLs). Access control lists define which data items a user is allowed to read, write, or execute (execute is required to browse the directory structure). ACLs are POSIX-compliant, so individuals with a Unix or Linux experience will be familiar with them.
Because POSIX does not use a security inheritance model, access ACLs must be defined for each item. Default ACLs are important for new files in a directory to have the right security settings, but they should not be considered of as an inheritance. Because applying ACLs to each object is time-consuming and there is a maximum of 32 ACLs per object, managing data-level security in ADLS Gen1 or Gen2 through Azure Active Directory groups is critical.