Assigning Resource Management Permissions for Azure Data Lake Store (Part 2)

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
Part 4 – Using a Service Principal for Azure Data Lake Store
Part 5 – Assigning Permissions for Azure Data Lake Analytics

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.

Typically, automated processes which do need access to the data (discussed in Part 3), don’t need any access to the ADLS resource itself. However, if any access to the Azure portal or to manage the ADLS service (such as through ARM or PowerShell) is needed, then the appropriate RBAC entry is necessary. 

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:

ADLS RBAC ActivityLog Assigning Resource Management Permissions for Azure Data Lake Store (Part 2)

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.)

ADLS RBAC Portal Assigning Resource Management Permissions for Azure Data Lake Store (Part 2)

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

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

ADLS RBAC PowerShell Assigning Resource Management Permissions for Azure Data Lake Store (Part 2)

Here’s a copy/paste friendly script from the above screenshot:

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

#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 

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

Want to Know More?

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

Let’s block ads! (Why?)

Blog – SQL Chick