Configuring Access Control for Storage accounts using Azure AD
In this tutorial, we will learn and understand about configuring access controls for storage accounts using the Azure active directory.
Azure Storage supports using Azure Active Directory (Azure AD) for authorizing requests to Blob and Queue storage. However, you may assign rights to a security principal using Azure AD’s role-based access control (RBAC).
- 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. Also, if an Azure object, such as an Azure VM, is used to run the application. After that, you can either use a virtual machine scale set or an Azure Functions app. It can then access blobs or queues using a controlled identity.
You should know that the authorization step needs that one or more Azure roles assign to the security principal. Azure Storage provides Azure roles for blob and queue data that provide a standard set of permissions.
Assigning Azure roles for access rights
Through Azure’s role-based access control, Azure Active Directory (Azure AD) authorizes access permissions for safeguarding resources (Azure RBAC). Azure Storage delves into Azure built-in roles, which cover the most typical permissions for accessing blob and queue data. When an Azure role is given to an Azure AD security principal, however, things get complicated. Azure then allows that security principal access to those resources. A person, a group, or an application service principal can all be Azure AD security principals. It may also be used to manage 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.
Resource scope
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
For accessing blob and queue data in an Azure storage account, the Azure portal can utilize either your Azure AD account or the account access credentials. When you try to access blob or queue data, however, the Azure site checks to see if you’ve been allocated an Azure role by Microsoft. Storage/storageAccounts/listkeys/action. If you’ve been given a role that includes this action, the Azure portal will utilize your account key to access blob and queue data via Shared Key authorization. In addition, if you haven’t been given a role for this operation, the Azure portal will try 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. The built-in roles supplied by Azure Storage, on the other hand, provide access to blob and queue resources but not to storage account resources. As a result, gaining access to the portal necessitates the assignment of an Azure Resource Manager role, such as the Reader role, scoped to the storage account level or above.
Reference: Microsoft Documentation