Friday, June 9, 2023

 

Shared access signatures are popular for storage accounts to give web-based access to blobs, containers and account. It is a secure way to delegate access to resources and provides granular control on how that data is accessed in terms of resources, permissions, and durations.

Among the three types of SAS, user delegation, service, and account, the first one is preferred while the last one can be easily compromised. The first one uses Azure AD credentials to create a user delegation SAS but it must be set up properly. This article explains a few of those settings so that the pesky error messages are resolved.

The SAS Token is a string that is generated on the client side. This is one of common misunderstandings about the SAS URL. It is not generated and not stored or tracked by Azure Storage Service in any way. Once the SAS URL is created, it can be distributed as many times as necessary. When the service receives a SAS URL, it can validate based on all the contents in the SAS token itself.

A SAS token can be signed by using a user delegation key that was created using the Azure Active Directory credentials. A user delegation SAS is signed with the user delegation key. The key can be generated only when the Azure AD security principal requesting it, is assigned a role that has Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey.

Often, it is assumed that the above permission is available to all users of a storage account but this is not necessarily the case. The permission for blob service operations are different between the built-in roles of Storage Blob Data Owner, Storage Blob Data Contributor and Storage Blob Data Reader.

Another permission that is required for both listing the blobs and reading the contents of the blobs is the

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. Together with this permission and the above generateUserDelegationKey permission, it is possible to create a SAS URL.

Another area of attention is that the authorizations. On the Shared Access Signature menu of the Azure Storage Account Navigation sidebar, there are options to permit on the basis of allowed services, allowed resource types, allowed permissions, blob versioning permissions, and allowed blob index permissions with allowed IP addresses, protocols and preferred routing tier. If any of this options are inconsistent with the operations to be permitted, the net result is the typical error message of:

You do not have permissions to use the access key to list the data

Or

You do not have permission to generate user-delegation SAS for this folder.

It is advisable to restrict those options that do not apply such as file, queue, or table for services or services and container for resource types but check the option for blob and object, if that is the granularity desired.

These are some of the caveats with properly setting the Azure storage account for generating the Shared Access Signature URL.

No comments:

Post a Comment