In the last post, we discussed the concepts behind the valet key pattern. In this post, I will walk through how to perform this operation on Azure.
In Azure, we can accomplish the creation of temporary access by use of shared access signature (SAS) tokens. You can read more about these tokens here (https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1)
Please NOTE: In a previous post, I mentioned that SAS tokens were container level elements. In fact, I was wrong about this. At time of writing, SAS Tokens can be implemented at the container level, the account level, or the blob level.
Therefore, if you grant read access to a token, that token allows for reading of all objects inside the target container. SAS tokens have the following useful parameters:
Start Time - The time at which the token will become effective
End Time - The time at which the token will expire
Permissions - The grants to be allocated with the token
IP - The IP (or range) from which the token will be accepted
Protocol - The types of protocols allowed for use by the token (in this case, HTTP or HTTPS)
SAS tokens are effectively a set of key-value pairs that are passed on the query string (general) and are accompanied by a signature. This means that SAS tokens can be guaranteed to provide integrity of the message (IE: properties cannot be changed by the users) but do not provide confidentiality (the user can read and interpret the access granted).
It is important to note that SAS tokens do not need to specify all the parameters above. In some cases, you can link a SAS Token with a SAS policy. The SAS policy is simply the representation of the parameters, and the SAS Token simply has a reference to the policy it was created with. In general, the recommendation is to use policies (which help to act as a revocation list in the case of long running SAS tokens).
So let’s generate a SAS token for access to a private blob. Here is my current storage account setup.
I want to access the blah blah.docx file in a private container. Here are the steps (using powershell):
Obtain the context for a storage account
$account = Get-AzStorageAccount -Name shamblah2 -ResourceGroupName shamblah2
$context = $account.Context
Obtain a SAS token for a given blob
$token = New-AzureStorageBlobSASToken -Container blah -Blob "blah blah.docx" -StartTime (Get-Date).AddHours(-1) -ExpiryTime (Get-Date).AddHours(4) -Permission r -Protocol HttpsOnly -context $context
Provide token to downstream user/process
The token that was provided looks like this:
?sv=2018-03-28&sr=b&sig=%2BaRbu1W93annjtlAoxZVB3V246HSfgbrSY2kwqlOSEk%3D&spr=https&st=2019-01-20T18%3A59%3A23Z&se=2019-01-20T23%3A59%3A23Z&sp=r
You can then just add it to your url that you would like to access. Like so:
Hitting that will allow you to access the file for 4 hours after the token was created.
If you try and access the blob afterwards, or use the key for some other blob/account, you get the following:
In the next post, we will cover how to do this with AWS.
 
Shamir Charania, a seasoned cloud expert, possesses in-depth expertise in Amazon Web Services (AWS) and Microsoft Azure, complemented by his six-year tenure as a Microsoft MVP in Azure. At Keep Secure, Shamir provides strategic cloud guidance, with senior architecture-level decision-making to having the technical chops to back it all up. With a strong emphasis on cybersecurity, he develops robust global cloud strategies prioritizing data protection and resilience. Leveraging complexity theory, Shamir delivers innovative and elegant solutions to address complex requirements while driving business growth, positioning himself as a driving force in cloud transformation for organizations in the digital age.