In this tutorial, we will learn and understand about configuring access controls for storage accounts using Azure active directory.
Azure Storage supports using Azure Active Directory (Azure AD) for authorizing requests to Blob and Queue storage. However, with Azure AD, you can use role-based access control (RBAC) for granting permissions to a security principal.
- Firstly, authorizing requests against Azure Storage with Azure AD provides superior security and ease of use over Shared Key authorization. However, Microsoft recommends using Azure AD authorization with your blob and queue applications for minimizing potential security vulnerabilities inherent in Shared Key.
- Secondly, authorization with Azure AD is available for all general-purpose. And, also for Blob storage accounts in all public regions and national clouds. And, only storage accounts developed with the Azure Resource Manager deployment model support Azure AD authorization. Moreover, blob storage additionally supports creating shared access signatures (SAS) that signs with Azure AD credentials.
Azure AD for blobs and queues overview
When a security principal tries to access a blob or queue resource, then the request must be authorized. This is done unless it is a blob available for anonymous access. Using Azure AD, accessing a resource is a two-step process. Firstly, the security principal’s identity is authenticated and an OAuth 2.0 token is returned. Then, the token is passed as part of a request to the Blob or Queue service. And further, used by the service for authorizing access to the specified resource.
However, the authentication step needs that an application requests an OAuth 2.0 access token at runtime. And, if an application is running from within an Azure entity like an Azure VM. Then, a virtual machine scale set, or an Azure Functions app. Then, it can use a managed identity to access blobs or queues.
You should know that the authorization step needs that one or more Azure roles assign to the security principal. Azure Storage offers Azure roles that encompass common sets of permissions for blob and queue data.
Assigning Azure roles for access rights
Azure Active Directory (Azure AD) authorizes access rights for securing resources through Azure’s role-based access control (Azure RBAC). Azure Storage explains Azure built-in roles that encompass common sets of permissions used to access blob and queue data. However, when an Azure role is assigned to an Azure AD security principal. Then, Azure grants access to those resources for that security principal. An Azure AD security principal may be a user, a group, an application service principal. Or it can be a managed identity for Azure resources.
Azure built-in roles for blobs and queues
Azure provides Azure built-in roles for authorizing access to blob and queue data using Azure AD and OAuth that includes:
- Firstly, storage Blob Data Owner that is for setting ownership and managing POSIX access control for Azure Data Lake Storage Gen2.
- Secondly, storage Blob Data Contributor that grants read/write/delete permissions to Blob storage resources.
- Thirdly, the storage Blob Data Reader that grants read-only permissions to Blob storage resources.
- Next, the storage Blob Delegator. This is used for getting a user delegation key for creating a shared access signature that is signed with Azure AD credentials for a container or blob.
- Then, storage Queue Data Message Processor that grants peek, retrieve, and delete permissions to messages in Azure Storage queues.
- Lastly, storage Queue Data Message Sender which is for granting add permissions to messages in Azure Storage queues.
Before assigning an Azure role to a security principal, firstly, determine the scope of access for the security principal. The list below explains the levels at which you can scope access to Azure blob and queue resources.
- Firstly, an individual container. At this scope, a role assignment applies to all of the blobs in the container including the container properties and metadata.
- Secondly, an individual queue. Here, a role assignment applies to messages in the queue including queue properties and metadata.
- Thirdly, the storage account. This refers to a role assignment that applies to all containers and their blobs, or to all queues and their messages.
- After that, the resource group. Here, a role assignment applies to all of the containers or queues in all of the storage accounts in the resource group.
- Then, the subscription. This refers to a role assignment that applies to all of the containers or queues in all of the storage accounts. Further, in all of the resource groups in the subscription.
- Lastly, a management group. This refers to the role assignment that applies to all of the containers or queues in all of the storage accounts. Further, in all of the resource groups in all of the subscriptions in the management group.
Data access from the Azure portal
The Azure portal can use either your Azure AD account or the account access keys for accessing blob and queue data in an Azure storage account. However, when you attempt to access blob or queue data, then the Azure portal first checks if you have been assigned an Azure role with Microsoft.Storage/storageAccounts/listkeys/action. And, if you have been assigned a role with this action, then the Azure portal uses the account key for accessing blob and queue data via Shared Key authorization. Further, if you have not been assigned a role with this action, then the Azure portal attempts to access data using your Azure AD account.
For accessing blob or queue data from the Azure portal using your Azure AD account, firstly, you require permissions for accessing blob and queueing data. Secondly, you also require permission for navigating through the storage account resources in the Azure portal. However, the built-in roles provided by Azure Storage grant access to blob and queue resources, but they don’t grant permissions to storage account resources. For this reason, accessing the portal also needs the assignment of an Azure Resource Manager role such as the Reader role, scoped to the level of the storage account or higher.
Reference: Microsoft Documentation