Authorize access to Azure blobs and queues using Azure Active Directory
Azure Storage supports using Azure Active Directory (AD) to authorize requests to Blob and Queue storage. With Azure AD, you can use role-based access control (RBAC) to grant permissions to a security principal, which may be a user, group, or application service principal. The security principal is authenticated by Azure AD to return an OAuth 2.0 token. The token can be used to authorize a request to access a resource in Blob or Queue storage.
Authorizing users or applications using an OAuth 2.0 token returned by Azure AD provides superior security and ease of use over Shared Key authorization and shared access signatures (SAS). With Azure AD, there is no need to store the account access key with your code and risk potential security vulnerabilities. While you can continue to use Shared Key authorization with your applications, using Azure AD circumvents the need to store your account access key with your code. You can also continue to use shared access signatures (SAS) to grant fine-grained access to resources in your storage account, but Azure AD offers similar capabilities without the need to manage SAS tokens or worry about revoking a compromised SAS. Microsoft recommends using Azure AD authorization with your Azure Storage applications when possible.
Authorization with Azure AD is available for all general-purpose and Blob storage accounts in all public regions and national clouds. Only storage accounts created with the Azure Resource Manager deployment model support Azure AD authorization. Authorization with Azure AD is not supported for Azure Table storage.
Overview of Azure AD for blobs and queues
When a security principal (a user, group, or application) attempts to access a blob or queue resource, the request must be authorized, unless it is a blob available for anonymous access. With Azure AD, access to a resource is a two-step process. First, the security principal's identity is authenticated and an OAuth 2.0 token is returned. Next, the token is passed as part of a request to the Blob or Queue service and used by the service to authorize access to the specified resource.
The authentication step requires that an application request an OAuth 2.0 access token at runtime. If an application is running from within an Azure entity such as an Azure VM, a virtual machine scale set, or an Azure Functions app, it can use a managed identity to access blobs or queues. To learn how to authorize requests made by a managed identity to the Azure Blob or Queue service, see Authorize access to blobs and queues with Azure Active Directory and managed identities for Azure Resources.
The authorization step requires that one or more RBAC roles be assigned to the security principal. Azure Storage provides RBAC roles that encompass common sets of permissions for blob and queue data. The roles that are assigned to a security principal determine the permissions that the principal will have. To learn more about assigning RBAC roles for Azure Storage, see Manage access rights to storage data with RBAC.
Native applications and web applications that make requests to the Azure Blob or Queue service can also authorize access with Azure AD. To learn how to request an access token and use it to authorize requests for blob or queue data, see Authorize access to Azure Storage with Azure AD from an Azure Storage application.
Assigning RBAC roles for access rights
Azure Active Directory (Azure AD) authorizes access rights to secured resources through role-based access control (RBAC). Azure Storage defines a set of built-in RBAC roles that encompass common sets of permissions used to access blob and queue data. You can also define custom roles for access to blob and queue data.
When an RBAC role is assigned to an Azure AD security principal, Azure grants access to those resources for that security principal. Access can be scoped to the level of the subscription, the resource group, the storage account, or an individual container or queue. An Azure AD security principal may be a user, a group, an application service principal, or a managed identity for Azure resources.
Built-in RBAC roles for blobs and queues
Azure provides the following built-in RBAC roles for authorizing access to blob and queue data using Azure AD and OAuth:
- Storage Blob Data Owner: Use to set ownership and manage POSIX access control for Azure Data Lake Storage Gen2. For more information, see Access control in Azure Data Lake Storage Gen2.
- Storage Blob Data Contributor: Use to grant read/write/delete permissions to Blob storage resources.
- Storage Blob Data Reader: Use to grant read-only permissions to Blob storage resources.
- Storage Queue Data Contributor: Use to grant read/write/delete permissions to Azure queues.
- Storage Queue Data Reader: Use to grant read-only permissions to Azure queues.
- Storage Queue Data Message Processor: Use to grant peek, retrieve, and delete permissions to messages in Azure Storage queues.
- Storage Queue Data Message Sender: Use to grant add permissions to messages in Azure Storage queues.
RBAC role assignments may take up to five minutes to propagate.
Only roles explicitly defined for data access permit a security principal to access blob or queue data. Roles such as Owner, Contributor, and Storage Account Contributor permit a security principal to manage a storage account, but do not provide access to the blob or queue data within that account.
To learn how to assign a built-in RBAC role to a security principal, see one of the following articles:
- Grant access to Azure blob and queue data with RBAC in the Azure portal
- Grant access to Azure blob and queue data with RBAC using Azure CLI
- Grant access to Azure blob and queue data with RBAC using PowerShell
For more information about how built-in roles are defined for Azure Storage, see Understand role definitions. For information about creating custom RBAC roles, see Create custom roles for Azure Role-Based Access Control.
Access permissions for data operations
For details on the permissions required to call specific Blob or Queue service operations, see Permissions for calling blob and queue data operations.
Before you assign an RBAC role to a security principal, determine the scope of access that the security principal should have. Best practices dictate that it's always best to grant only the narrowest possible scope.
The following list describes the levels at which you can scope access to Azure blob and queue resources, starting with the narrowest scope:
- An individual container. At this scope, a role assignment applies to all of the blobs in the container, as well as container properties and metadata.
- An individual queue. At this scope, a role assignment applies to messages in the queue, as well as queue properties and metadata.
- The storage account. At this scope, a role assignment applies to all containers and their blobs, or to all queues and their messages.
- The resource group. At this scope, a role assignment applies to all of the containers or queues in all of the storage accounts in the resource group.
- The subscription. At this scope, a role assignment applies to all of the containers or queues in all of the storage accounts in all of the resource groups in the subscription.
If your subscription includes an Azure DataBricks namespace, roles assigned at the subscription scope will be blocked from granting access to blob and queue data.
Access data with an Azure AD account
Access to blob or queue data via the Azure portal, PowerShell, or Azure CLI can be authorized either by using the user's Azure AD account or by using the account access keys (Shared Key authorization).
Data access from the Azure portal
The Azure portal can use either your Azure AD account or the account access keys to access blob and queue data in an Azure storage account. Which authorization scheme the Azure portal uses depends on the RBAC roles that are assigned to you.
When you attempt to access blob or queue data, the Azure portal first checks whether you have been assigned an RBAC role with Microsoft.Storage/storageAccounts/listkeys/action. 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. If you have not been assigned a role with this action, then the Azure portal attempts to access data using your Azure AD account.
To access blob or queue data from the Azure portal using your Azure AD account, you need permissions to access blob and queue data, and you also need permissions to navigate through the storage account resources in the Azure portal. 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, access to the portal also requires the assignment of an Azure Resource Manager role such as the Reader role, scoped to the level of the storage account or higher. The Reader role grants the most restricted permissions, but another Azure Resource Manager role that grants access to storage account management resources is also acceptable. To learn more about how to assign permissions to users for data access in the Azure portal with an Azure AD account, see Grant access to Azure blob and queue data with RBAC in the Azure portal.
The Azure portal indicates which authorization scheme is in use when you navigate to a container or queue. For more information about data access in the portal, see Use the Azure portal to access blob or queue data.
Data access from PowerShell or Azure CLI
Azure CLI and PowerShell support signing in with Azure AD credentials. After you sign in, your session runs under those credentials. To learn more, see Run Azure CLI or PowerShell commands with Azure AD credentials to access blob or queue data.
Azure AD authorization over SMB for Azure Files
Azure Files supports authorization with Azure AD over SMB for domain-joined VMs only (preview). To learn about using Azure AD over SMB for Azure Files,see Overview of Azure Active Directory authorization over SMB for Azure Files (preview).