Introduction
A few days ago the preview for the “User delegation SAS token” has seen the light. In today’s post, we’ll take a first glance on this new capability! Though why should we care about this feature? You can now create SAS tokens based on the scoped permissions of an AAD user, instead of linked towards the storage account key. From a security perspective this is REALLY awesome, cause you can harden the scope of a possible even more.
Bibliography
- https://azure.microsoft.com/en-us/blog/announcing-user-delegation-sas-tokens-preview-for-azure-storage-blobs/
- https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas
- https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-user-delegation-sas-create-cli
- https://docs.microsoft.com/en-us/cli/azure/?view=azure-cli-latest
Azure RBAC
When going through the RBAC roles, you can see a new role in there ;
Though this role is also included in the other roles too ; https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#storage-blob-data-reader
So why does it exist? You need to have the delegator rights on account level. So if you want to be very specific… Granting someone this role on account level, and giving them permissions on container level will be more granular / scoped. Though in this case you need both.
Azure CLI
Check the help pages on “az storage blob generate-sas” ;
For me the most funky parameter was “–expiry”, though the help file provides some good guidance here!
Error : Older Azure CLI Version
If you see the error “az: error: unrecognized arguments: –as-user”, then this is because the version is out of date
Install the new CLI ;
And then it’ll work.
Testing the flow
So we have a little test environment ;
Let’s test it without a SAS token…
Pfew, that doesn’t work (as designed!). Now, we’ll generate the SAS token,
az login
az storage blob generate-sas –help
end=`date -d “30 minutes” ‘+%Y-%m-%dT%H:%MZ’`
az storage container generate-sas \
–account-name kvaestest001 \
–name test \
–permissions acdlrw \
–expiry $end \
–auth-mode login \
–as-user
And add it to our blob URI ;
Boom it works!
What about B2B users?
I’ve added my @kvaes.be (owner) and my @microsoft.com account to this. The @microsoft.com account is a B2B user in this case.
Let’s log in with that account and generate a SAS token
And test it…
B2B users work! 😉
Error Handling : Date in the past
If you see a funky error mentioning some XML stuff… Then it’s probably due to the fact that you didn’t format the datetime of the expiry correctly.
Error Handling : AAD user has no access to data
If you have no access to the data, you will be able to get a token. Though it won’t work once you’re trying to use it!
The easiest way to test this, is to browse to the storage account and change the “Authentication method” to “Azure AD User Account”.
And ensure that this isn’t set to “Access key”.
If it works via the “Azure AD User Account”, then you know this user has the rights to the file.
Revoking Access
What about revoking SAS tokens?
There you go… A bit blunt at the moment, but it does the trick! 😉
Closing Thoughts
The user delegation for SAS tokens is an awesome step in the security of storage accounts. It relieves you from needing a storage key. As you can see in our tests, you can go more granular in terms of permissions and it also works for B2B users. Whilst still in preview, I’m excited to see this one see the light of day!
