Using Shared Access Signatures in Azure Templates

Did you know you can create and retrieve a Shared Access Signature (SAS) for an Azure Storage account from within an Azure Resource Manager (ARM) template?  Yeah . . . me neither!  It’s been something I’ve wanted to do on several occasions.  I usually resort to creating the storage account and SAS via some other means (Azure Portal, PowerShell, CLI, etc.), and then pass the account name and SAS token to the ARM template as parameters. Doable, but the process felt clunky.

I recently learned of a relatively new template resource function, listAccountSas.  I’m not sure when this function was added, but a quick look at the doc history seems to indicate August 2018. The official documentation does explain the basic functionality of listAccountSas, so please be sure to review that documentation.  However, there are a few topics that deserve additional detail, which is what I will cover in this post.

Input Parameters and Return Values

First, listAccountSas accepts an optional “functionValues” parameter.  For an Azure Storage account SAS, this object parameter defines scope (resource types, expiration, etc.).

{
  "signedServices": "bt",
  "signedPermission": "acluw",
  "signedExpiry": "2018-11-30T00:00:00Z",
  "signedResourceTypes": "co"
}

The documentation page suggests that “functionValues” is optional.  However, I’m not sure how the function would work without it.  I can only assume it is optional to support some future use case.  (Note: Service Bus also uses a Shared Access Signature, but it isn’t really an “account”SAS).

Next, listAccountSas returns an object.  What exactly does that mean?  The documentation page leaves it an exercise to the user to figure out. Well, I’ll show you right now:

{
  "accountSasToken": "sv=2015-04-05&ss=bt&srt=co&sp=acluw&se=2018-11-30T00%3A00%3A00.0000000Z&sig=xxxxxxxxxxxxx"
}

Most places that you want to use a SAS in an ARM template require the SAS token to be in a string format.  Therefore, to use the provided SAS token, you need to use the accountSasToken property from the resulting object.  For example:

listAccountSas(parameters('storageName'), '2018-02-01', parameters('accountSasProperties')).accountSasToken

In my opinion, listAccountSas seems like a pseudo-wrapper around the ListAccount SAS REST API for Azure Storage.  Have a look at the REST API to learn its expected request and response, and you’ll be able to apply that information to using listAccountSas as well.

Using listAccountSas

Again, the official documentation explains the basics of using listAccountSas.  There is even an example template.  What I want to see is how I would really use listAccountSas as part of an ARM template, not just to get the output value of the function itself.

For example, one case where I needed to create and use an Azure Storage account SAS was when setting up the Linux Diagnostic extension on a Virtual Machine Scale Set (VMSS) as part of an Azure Service Fabric cluster.  To configure the diagnostic extension, you will need to provide a storage account name and SAS token.  As previously mentioned,the common way to accomplish this was to create the storage account and SAS first, and then provide those values as input parameters to the ARM template. 

No more, I say!

Using the listAccountSas function, it is possible to create and use the SAS from within the template.  If needed, you can create the necessary storage account from within the same template as well.  In the case of the diagnostic extension, the configuration would be as follows:

"protectedSettings": {
      "storageAccountName": "[variables('applicationDiagnosticsStorageAccountName')]",
      "storageAccountEndPoint": "https://core.windows.net/",
      "storageAccountSasToken": "[listAccountSas(variables('applicationDiagnosticsStorageAccountName'), '2018-02-01', 
parameters('applicationDiagnosticsStorageAccountSasProperties')).accountSasToken]",
      "sinksConfig": {}
}

Summary

I’m very pleased to see listAccountSas added as a resource function for ARM templates.  This makes fully automated deployments for Azure resources much easier to develop and maintain.

Finally, I owe a special “thank you” to Robin for reviewing this post and helping to make it better.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.