This is part 2 in a short series on Azure Data Lake permissions.

Part 1 - Granting Permissions in Azure Data Lake
Part 2 - Assigning Resource Management Permissions for Azure Data Lake Store {you are here}
Part 3 - Assigning Data Permissions for Azure Data Lake Store

In this section, we're covering the "service permissions" for the purpose of managing Azure Data Lake Store (ADLS). Granting a role on the resource allows someone to view or manage the configuration and settings for that particular Azure service (i.e., although we're talking about ADLS, this post is applicable to Azure services in general). RBAC, or role-based access control, includes the familiar built-in Azure roles such as reader, contributor, or owner (you can create custom roles as well).

Tips for Assigning Roles for the ADLS Service

Setting permissions for the service + the data stored in ADLS is always two separate processes, with one exception: when you define an owner for the ADLS service in Azure, that owner is automatically granted 'superuser' (full) access to manage the ADLS resource in Azure *AND* full access to the data. Any other RBAC role other than owner needs the data access specifically assigned via ACLs. This is a good thing because not all system administrators need to see the data, and not all data access users/groups/service principals need access to the service itself. This type of separation is true for certain other services too, such as Azure SQL Database.

Try to use groups whenever you can to grant access, rather than individual accounts. This is a consistent best practice for managing security across many types of systems.

If you are using resource groups in Azure the way they are intended to be used, you may be able to define service permissions at the resource group level rather than at the individual resource level (although the example shown is here is setting RBAC for ADLS specifically). Managing permissions at the resource group level reduces maintenance, assuming your resource group isn't too broadly defined.

If you need to allow a user or group to be able to peruse data using the Data Explorer, then they'll need reader permissions to the ADLS Azure service. Basically, if any access to ADLS in the Azure portal is needed, or if managing the ADLS service (such as through ARM or PowerShell or the portal) is needed, then the appropriate RBAC entry is necessary.

Typically, automated processes which do need access to the data (discussed in Part 3), don't need any access to the ADLS resource itself. In Part 4 we'll talk a bit about using service principals. I've found that frequently a service principal needs data access (ACLs), but not any RBAC access to the service.

The RBAC functionality is consistent across Azure services. When roles are updated for an Azure resource, it is recorded in the Activity Log:

Defining RBAC Permissions in the Azure Portal

Setting up permissions can be done in the portal in the Access control (IAM) pane. (By the way, the IAM acronym stands for Identity and Access Management.)

Defining RBAC Permissions via PowerShell Script

The technique shown above in the portal is convenient for quick changes, for learning, or for "one-off" scenarios. However, in an enterprise solution, and for production environments, it's a better practice to handle permissions via a script so you can do things such as:

Promote changes through different environments
Pass off scripts to an administrator to run in production
Include permission settings in source control

Setting Permissions for a Group

In the following PowerShell script, we are assigning contributor permissions to an AAD group:

Here's a copy/paste friendly script from the above screenshot - for a group:

#-----------------------------------------

#Input Area
$subscriptionName = 'YourSubscriptionName'
$resourceGroupName = 'YourResourceGroupName'
$resourceName = 'YourResourceName'
$groupName = 'YourAADGroupName'
$userRole = 'Contributor'

#-----------------------------------------

#Manual login into Azure
Login-AzureRmAccount -SubscriptionName $subscriptionName

#-----------------------------------------

$resourceId = Get-AzureRmResource `
    -ResourceGroupName $resourceGroupName `
    -ResourceName $resourceName 
$groupId = Get-AzureRMADGroup `
    -SearchString $groupName

New-AzureRmRoleAssignment `
    -ObjectId $groupId.Id `
    -RoleDefinitionName $userRole `
    -Scope $resourceId.ResourceId

Setting Permissions for a User

This next script is nearly the same, but this time we are assigning read+execute permissions to a user instead of a group (which should be the exception not the rule):

And, here's the copy/paste friendly version of the above screenshot - for a user:

#-----------------------------------------

#Input Area
$subscriptionName = 'YourSubscriptionName'
$resourceGroupName = 'YourResourceGroupName'
$resourceName = 'YourResourceName'
$userName = 'YourUserNameInEmailFormat'
$userRole = 'Contributor'

#-----------------------------------------

#Manual login into Azure
#Login-AzureRmAccount -SubscriptionName $subscriptionName

#-----------------------------------------

$resourceId = Get-AzureRmResource `
    -ResourceGroupName $resourceGroupName `
    -ResourceName $resourceName 
$userId = Get-AzureRmADUser `
    -UPN $userName 

New-AzureRmRoleAssignment `
    -ObjectId $userId.Id `
    -RoleDefinitionName $userRole `
    -Scope $resourceId.ResourceId

The online examples for the New-AzureRmRoleAssignment cmdlet enumerates the IDs or GUIDs, which makes things clear for learning but isn't ideal for operationalized scripts. Therefore, the purpose for $resourceId and $groupId above is to do the work of looking up the GUIDs so you don't have to do that manually.

Personally, I like using PowerShell instead of ARM (Azure Resource Manager) templates for certain things, such as permissions, but you do have additional options beyond what I've discussed here based on what you're most comfortable with.

Finding More Information

Get Started with Role-Based Access Control in Azure