Granting Permissions in Azure Data Lake

This purpose for this set of posts is to share some tips & scripts for setting permissions for Azure Data Lake. This content is split up into a short series:

Part 1 - Granting Permissions in Azure Data Lake {you are here}
Part 2 - Assigning Resource Management Permissions for Azure Data Lake Store
Part 3 - Assigning Data Permissions for Azure Data Lake Store
Part 4 - Using a Service Principal for Azure Data Lake Store <Coming Soon>
Part 5 - Assigning Permissions for Azure Data Lake Analytics <Coming Soon>

Overview of Permissions in ADLS

There are two parts to how permissions work in Azure Data Lake Store:

ADLS_Permissions.jpg
 

(1) RBAC permissions to the ADLS account itself, for the purpose of managing the resource.
RBAC = Role-based access control. RBAC are the familiar Azure roles such as reader, contributor, or owner. Granting a role on the service allows someone to view or manage the configuration and settings for that particular Azure service (ADLS in this case). See Part 2 for info about setting up RBAC.

(2) ACL permissions to the data stored in ADLS, for the purpose of managing the data.
ACL = access control list. The ACLs grant read/write/execute permissions on the data itself. Granting permissions here allows someone to create, read, and/or modify files and folders (i.e., the actual data) stored in ADLS. If you come from the Unix or Linux world, the POSIX-style ACLs will be a familiar concept. See Part 3 about setting up ACLs.

Finding More Information

There is quite a bit more to know about ADLS security than what is covered in this series, so be sure to also dive into the official documentation links:

Security in Azure Data Lake Store

Access Control in Azure Data Lake Store

Securing Data in Azure Data Lake Store

Best Practices for Using Azure Data Lake Store

Want to Know More?

My next all-day workshop on Architecting a Data Lake is in Raleigh, NC on April 13, 2018