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