Authorization Using “Azure Role-Based Access Control” (Azure RBAC) in Azure Data Lake Storage Gen2
Introduction to Access Control Model in Azure Data Lake Storage Gen2
Data Lake Storage Gen2 supports the following “Authorization” mechanisms -
A) Role-Based Access Control (Azure RBAC) - Azure RBAC grants “coarse-grain” access to Storage Account data, like - Read or Write access to All of the data in a Storage Account.
B) Access Control Lists (ACL) - ACLs grant “fine-grained” access, such as - Write access to a specific Directory or File.
Both the “Authorization” mechanisms, i.e., Azure RBAC and ACL, require the user, or, the application to have an Identity in Azure AD.
Shared Access Key grants access to a user, or, an application without requiring to have an Identity in Azure Active Directory (Azure AD). With these two forms of “Authentication”, the “Azure RBAC” and “ACLs” have no effect.
What is Role-Based Access Control (Azure RBAC)
Access Management for Cloud Resources is a critical function for any organization that is using the Cloud. Azure Role-Based Access Control (Azure RBAC) helps to manage -
- Which “User” has “Access” to Azure Resources
- What the “User” can “Do” with those Azure Resources
- What “Areas” the “User” has “Access” to
Following are examples of some of the Scenarios that can be done using Role-Based Access Control (Azure RBAC) with -
- Allow one User to Manage the Virtual Machines in a Subscription and another User to Manage the Virtual Networks.
- Allow a DBA Group to Manage the SQL Databases in a Subscription.
- Allow a User to Manage All the Resources in a Resource Group, such as Virtual Machines, Websites, and, Subnets.
Allow an Application to Access All the Resources in a Resource Group.
How Azure Role-Based Access Control (Azure RBAC) Works
The way to control Access to Azure Resources using the Azure Role-Based Access Control (Azure RBAC) is to Assign the Azure Roles. This is how “Permissions” are Enforced. A “Role Assignment” consists of the following three elements -
A) Security Principal - A “Security Principal” is an Object that represents a “User”, “Group”, “Service Principal”, or, “Managed Identity” that is “Requesting” the “Access” to an Azure Resource.
A “Role” can be Assigned to any of these “Security Principals”.
B) Role Definition - A “Role Definition” is a “Collection of Permissions”. It is typically just called a “Role”. A “Role Definition” lists the Actions that can be Performed, such as - “Read”, “Write” and “Delete”. “Roles” can be High-Level, like - “Owner”, or, can be Specific, like - “Virtual Machine Reader”.
Built-In Role - Azure has several “Built-In Roles” that can be used. Example - the “Virtual Machine Contributor” Role allows a User to “Create” and “Manage” the Virtual Machines.
If the “Built-In Roles” don’t meet the specific needs of the organizations, then the Azure Admin of the respective organizations can create “Azure Custom Roles”.
Azure has “Data Actions” that enables to grant “Access” to Data within an “Object”. Example - if a User has “Read” Data Access to a Storage Account, then that User can “Read” the “Blobs”, or, “Messages” within that Storage Account.
C) Scope - “Scope” is the “Set of Resources” that the “Access” applies to. When a “Role” is “Assigned”, the “Actions” allowed by that “Role” can be further “Limited” by defining a “Scope”. It is important to understand the “Scope” so that the Azure Admin can grant a “Security Principal” just the “Access” that it really needs. By “Limiting the Scope”, the Azure Admin can “Limit” what “Resources” are at Risk, if the “Security Principal” is ever “Compromised”.
Scope Levels - In Azure, it is possible to specify a “Scope” at four levels -
1. Management Group
2. Subscription
3. Resource Group
4. Resource“Scopes” are structured in a “Parent-Child” Relationship. Each Level of Hierarchy makes the “Scope” more specific. It is possible to “Assign” the “Roles” at any of these “Levels” of “Scope”. The selected “Level” determines how widely the “Role” is applied. “Lower Levels” inherit the “Role Permissions” from the “Higher Levels”.
Azure Role Assignment Using Role-Based Access Control (Azure RBAC)
A “Role Assignment” is the Process of attaching a “Role Definition” to a “User”, “Group”, “Service Principal”, or, “Managed Identity” at a particular “Scope” for the purpose of granting “Access”.
- “Access” is “Granted” by “Creating” a “Role Assignment”.
- “Access” is “Revoked” by “Removing” a “Role Assignment”.
Following diagram shows an example of a “Role Assignment”. In the example, the “Marketing” Group has been Assigned the “Contributor” Role for the “Pharma-Sales” Resource Group. This means that “Users” in the “Marketing” Group can “Create” or “Manage” any Azure Resource in the “Pharma-Sales” Resource Group. “Marketing” Users do not have “Access” to “Resources” outside the “Pharma-Sales” Resource Group, unless the Users are Part of another “Role Assignment”.
It is possible to “Assign” the “Roles” using the “Azure Portal”, “Azure CLI”, “Azure PowerShell”, “Azure SDKs”, or, “REST APIs”.
Transitive Role Assignment in Group - “Role Assignments” are “Transitive” for the “Groups” which means that if a “User” is a “Member” of a “Group” and that “Group” is a “Member” of another “Group” that has a “Role Assignment”, then that “User” will have the “Permissions” in the “Role Assignment”.
Multiple Role Assignments - Azure RBAC is an “Additive Model”. So, if a “User” has multiple “Overlapping Role Assignments”, the “Effective Permissions” for that “User” are the “Sum” of the “Role Assignments”.
Following diagram shows an example of a “Multiple Role Assignment”. In the example, a “User” is “Granted” the “Contributor” Role at the “Subscription” Scope, and, the “Reader” Role at the “Resource Group” Scope. The “Sum” of the “Contributor” Permission and the “Reader” Permission is “Effectively” the “Contributor” Role for the “Subscription” Scope. Therefore, in this case, the “Reader” Role Assignment has no impact.
Azure Deny Assignment Using Role-Based Access Control (Azure RBAC)
Previously “Azure RBAC” was an “Allow-Only Model” with “No Deny”, but, now “Azure RBAC” supports the “Deny Assignments” in a “Limited” way.
A “Deny Assignment” defines a “Set of Actions” that are “Not Allowed” and attaches that “Set of Deny Actions” to a “User”, or, a “Group”, or, a “Service Principal”, or, a “Managed Identity” at a particular “Scope” for the purpose of “Denying Access”. In other words, “Deny Assignments” block the “Users” from performing specified “Actions”, even if a “Role Assignment” grants the “Users” some other “Accesses”, because, “Deny Assignments” take “Precedence” over the “Role Assignments”.
How Azure Role-Based Access Control (Azure RBAC) Determines If a User Has Access to an Azure Resource
The following are the High-Level steps that “Azure RBAC” uses to determine if a “User” has “Access” to an “Azure Resource”. These steps apply to “Azure Resource Manager” or “Data Plane Services”, integrated with “Azure RBAC”.
Step 1 - A “User”, or, a “Service Principal” acquires a “Token” for the “Azure Resource Manager”.
The “Token” includes the “User’s Group Memberships” (including “Transitive Group Memberships”).
Step 2 - The “User” makes a “REST API” call to the “Azure Resource Manager” with the “Token” attached.
Step 3 - “Azure Resource Manager” retrieves all the “Role Assignments” and the “Deny Assignments” that are applied to the concerned “Azure Resource”, upon which the “Action” is being taken.
Step 4 - If a “Deny Assignment” is applied on the concerned “Azure Resource”, the “Access” is “Blocked”. Otherwise, the “Evaluation” continues.
Step 5 - “Azure Resource Manager” narrows down the “Role Assignments” that are applied to the “User”, or, their “Group”, and, determines what “Roles” the “User” has for the concerned “Azure Resource”.
Step 6 - The “Azure Resource Manager” determines if the “Action” in the “API” call is “Included” in the “Roles” the “User” has for the concerned “Azure Resource”.
If the “Roles” include “Actions” that have a “Wildcard” (“*”), the “Effective Permissions” are computed by “Subtracting” the “NotActions” from the allowed “Actions”. Similarly, the same “Subtraction” is done for any “DataActions”.
- Effective Management Permissions = Actions — NotActions
- Effective Data Permissions = DataActions — NotDataActions
Step 7 - If the “User” doesn’t have a “Role” with the “Action” at the requested “Scope”, “Access” in “Not Allowed”. Otherwise, any “Conditions” are “Evaluated”.
Step 8 - If the “Role Assignments” include “Conditions”, those are “Evaluated”. Otherwise, “Access” is “Allowed”.
Step 9 - If the “Conditions” are met, “Access” is “Allowed”. Otherwise, “Access” in “Not Allowed”.
The following diagram is “Summary” of the “Evaluation Logic” -
Add, and, View the Role Permissions in an Azure Data Lake Storage Gen2 Instance
In every Azure resource, e.g., Azure Data Lake Storage Gen2, there is a feature called “Access control (IAM)”. “IAM” stands for “Identity and Access Management”. Using this feature the “Role Permissions” applied to the concerned “Azure Resource” can be added, as well as, viewed.
To assign a “Role” of “Contributor” on the Azure Data Lake Storage Gen2 instance “adlsoindrila2022march” for the Azure Data Factory Instance “ADF-Oindrila-2022-March” using the “Managed Identity” Security Principal, perform the following steps -
Step 1 - Open Azure Data Lake Storage Gen2 instance “adlsoindrila2022march”. Click on the “Access Control (IAM)” link.
Step 2 - Click on “+ Add” button, followed by, click on “Add role assignment” link, or, click on the “Add role assignment” button from the “Grant access to this resource” tile.
Step 3 - In the “Add role assignment” page, under “Role” tab for the Azure Data Lake Storage Gen2 instance “adlsoindrila2022march”, it can be seen that, there are more than 60 built-in Roles in Microsoft Azure.
The “Roles” will vary depending on the specific “Resource” on which the “Role Assignment” is being set upon, e.g., the “Roles” available for Storage Account are different than the “Roles” available for Virtual Machines.
Step 4 - Select the “Contributor” Role from the options, and, click on the “Next” button.
Step 5 - In the “Members” tab, select the Radiobutton “Managed identity” for the property “Assign access to”. Then, click on the link “+ Select members” for the property “Members”.
Step 6 - In the opened blade “Select managed identities”, select the proper “Subscription” to use from the Dropdown “Subscription”, and, select “Data factory (V2) (1)” from the Dropdown “Managed identity”.
Upon selecting the proper “Managed Identity”, the “Managed Identity” information for the Azure Data Factory Instance “ADF-Oindrila-2022-March” is displayed under the Dropdown “Select”.
Upon selecting the displayed “Managed Identity” information for the Azure Data Factory Instance “ADF-Oindrila-2022-March”, the same information gets displayed under the “Selected members” section. Click on the “Select” button.
Now, the “Managed Identity” of the Azure Data Factory Instance “ADF-Oindrila-2022-March” is selected as the “Member” in the “Members” tab of the “Add role assignment” page. Then, click on the “Review + assign” button.
Next, review if the following information regarding the “Role Assignment” is correct, or, not in the “Review + assign” tab -
- “Role” to be “Assigned”.
- The “Scope” where the “Role” is being “Assigned”.
- “Managed Identity” information of the Azure Data Factory Instance “ADF-Oindrila-2022-March”.
Finally, click on the “Review + assign” button.
To verify if the “Role” of “Contributor” is properly assigned on the Azure Data Lake Storage Gen2 instance “adlsoindrila2022march” for the Azure Data Factory Instance “ADF-Oindrila-2022-March” using the “Managed Identity” Security Principal, perform the following steps -
Step 1 - Open Azure Data Lake Storage Gen2 instance “adlsoindrila2022march”. Click on the “Access Control (IAM)” link.
Step 2 - Click on “Role assignments” tab. All the “Role Assignments” on the Azure Data Lake Storage Gen2 instance “adlsoindrila2022march” are displayed -
