Sunday, November 05, 2017

Notes on Azure + PowerShell + Account SAS

Well, below are my notes on using account Shared access signatures in Azure using Azure PowerShell modules.


Let's get the basics out of the way first.

A shared access signature is a way to delegate access to resources in a storage account, without sharing the storage account keys.

SAS gives us granular control over the delegated access by :
  • 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.

There are two types of SAS.
  1. Service SAS: This type of SAS delegates access to resources in a single storage service. Note - Azure storage is made of Blob, Queue, Table and File services.
  2. Account SAS: This type of SAS delegates access to resources in one or more storage services. In addition, it can also delegate access to the operations that apply to a given service.
So, in a nutshell, SAS is a signed URI that delegates access to one or more storage resources. Note that this URI basically contains all the information in it.

Now the SAS can take two forms.
  1. Ad-hoc SAS: This type of SAS contains/implies all the constraints in the SAS URI e.g. start time, end time, and permissions. Both Service and Account SAS can take this form.
  2. SAS with stored access policy: A stored access policy can be used to define the above constraints e.g. start/end time and permissions on a resource container (blob container, table, queue, or file share). So when a SAS is applied on the resource container it inherits the above constraints from the stored access policy.

    Note - Currently Service SAS can only take this form.
One more thing of importance is that while creating Service SAS tokens, it is a best practice to have stored access policy associated with the resource containers in place because the SAS can simply be revoked (if needed) by deleting the stored access policy.

If you do not follow above then you have to revoke the storage account key which was used to generate the SAS token.

Example: Create and use an account SAS

For this post, I will be showing how to create an account SAS to grant service-level API access to Blob and file storage services and then using a client to update the service properties.

Following the .NET code samples listed here

 +azureprep (resource group)
   \-azprepstore (storage account)
       \-testblobcontainer1 (blob container)
           \- docker.png (blob)

Create an Account SAS token

First, step is to create the Account SAS token using AzureRM and AzureSM PowerShell modules.

Use Account SAS token (created above)

Open another PowerShell console, this will act as a client. The intent here is to show that using SAS token one can access the storage resource independently from another client.

Hope this is useful.


Using Shared access signatures

Create and use an account SAS (.NET)


  1. You don't specify expiry. Any idea how long this SAS token would be valid?

    1. Good point grizzly,
      I could not find what would be the default, hence looked at the source code for the New-AzureStorageAccountSASToken cmdlet and found out below.

      if (startTime != null)
      SharedAccessStartTime = startTime.Value.ToUniversalTime();

      if (expiryTime != null)
      SharedAccessExpiryTime = expiryTime.Value.ToUniversalTime();
      else if (shouldSetExpiryTime)
      double defaultLifeTime = 1.0; //Hours

      if (SharedAccessStartTime != null)
      SharedAccessExpiryTime = SharedAccessStartTime.Value.AddHours(defaultLifeTime).ToUniversalTime();
      SharedAccessExpiryTime = DateTime.UtcNow.AddHours(defaultLifeTime).ToUniversalTime();

      The above C# code shows that when the Expiry time is not supplied it will by default add 1 hour as the expiry time, thank heavens for open source :)

      BTW You can specify the expiry time while generating the SAS token using the cmdlet

      Refer to the -ExpiryTime parameter in the help here.