In one of the previous posts, we discussed how to create and manage Azure Storage accounts using PowerShell. However, we were using storage account key when trying to upload / delete / download files from azure blob storage. In case, you need to delegate access to a third person, this seems like a too much of access since that person will have access to whole storage account. In this post, we will discuss how to use SAS aka Shared Access Signature to delegate access in controlled way.
Concept of Shared Access Signature
A shared access signature is a way to delegate access to resources in a storage account, without sharing the storage account keys.
SAS gives granular control over the delegated access by :
1. Specifying the start and expiry time.
- Specifying the permissions granted e.g read / write / delete
-
Specifying the Source IP address where the requests will originate from.
-
Specifying the protocol to be used e.g HTTP/HTTPS.
Types of shared access signatures
Below are the two types of SAS:
- Service SAS: The service SAS delegates access to a resource in just one of the storage services: the Blob, Queue, Table, or File service.
2. Account SAS: The account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service SAS are also available via an account SAS. Additionally, with the account SAS, you can delegate access to operations that apply to a given service, such as Get/Set Service Properties and Get Service Stats. You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS.
Controlling a SAS with a stored access policy
A shared access signature can take one of two forms:
1. Ad hoc SAS: When you create an ad hoc SAS, the start time, expiry time, and permissions for the SAS are all specified in the SAS URI (or implied, in the case where start time is omitted). This type of SAS can be created as an account SAS or a service SAS.
- SAS with stored access policy: A stored access policy is defined on a resource container–a blob container, table, queue, or file share–and can be used to manage constraints for one or more shared access signatures. When you associate a SAS with a stored access policy, the SAS inherits the constraints–the start time, expiry time, and permissions–defined for the stored access policy.
It is to be noted that an account SAS must be an ad hoc SAS. Stored access policies are not yet supported for account SAS.
Create SAS token (at Azure Storage Account end)
1. Create Storage account and Container
Let’s create a storage container first by mentioning storage account name, location, sku and other basic details using PowerShell:
$location = “eastus2”
$storageAccountName = “mobinotifysa”
$resourceGroupName = “mobinotify-rg”
$storageSku = “standard_lrs”
New-AzureRmStorageAccount -ResourceGroupName $resourcegroupName -Name $storageAccountName -Location $location -SkuName $sku

Once its done, let’s fetch storage account key using below code:
$storageAccountKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName).Value[0]

Now we need to create storage context for storage account by using below code:
$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $storageAccountKey

Once we have it, let’s create a storage container using below code:
$storageContainer = New-AzureStorageContainer -Name rawsamples -Context $storageContext

2. Create Storage Access Policy
Now we need to create a storage access policy first as part of best practices for reasons mentioned above. We can create the same using below code:
$storagePolicyName = “rawsamples-policy”
$expiryTime = (Get-Date).AddYears(1)
New-AzureStorageContainerStoredAccessPolicy -Container rawsamples -Policy $storagePolicyName -Permission rl -ExpiryTime $expiryTime -Context $storageContext
Here, in above code, we mentioned that we need to create a storage policy with an expiry period of 1 year and with permissions read and list.
There are 4 levels of permissions that can be used: read (r), Write (w), list (l) and delete (d).

3. Create Storage Access Signature
Now we have required pre-requisites to create an SAS with storage policy. We can create SAS using below code:
$sasToken = (New-AzureStorageContainerSASToken -Name rawsamples -Policy $storagePolicyName -Context $storageContext).substring(1)
where in Name parameter, we have passed name of the blob container we created above.

We can now share this token with third party / person to delegate access.
Using SAS token (at client end)
For the purpose of this post, we have uploaded few images into above container. Now we’ll open a new PowerShell window to act as client, and then run below code:
$storSas = “sas-token-created-above’
$StorageAccountName = ‘mobinotifysa’
$containerName = “rawsamples”
$clientContext = New-AzureStorageContext -SasToken $storSAS -StorageAccountName $StorageAccountName
Get-AzureStorageBlob -Container $containerName -Context $ClientContext

As we can see, we are able to read and list the contents of the blob container at client end.
Now since we have only provided permission for read and list to the client, it will not be able to delete the files. We can verify the same by trying to delete some files from client side, which will throw errors like this:

So client is not able to do actions which are outside the permission scope granted using token. This way we can delegate access at restricted levels and also keep our storage account content safe.
Use New-AzStorageContext instead of New-AzureStorageContext (2020-May)
LikeLike
https://docs.microsoft.com/en-us/powershell/module/azure.storage/new-azurestoragecontext?view=azurermps-6.13.0
LikeLike