Azure Shared Access Signatures with Stored Policies

I’ve been reading more into Azure security lately and explored the topic of Azure Stored Access Policies. These addressed issues inherent in ad hoc Shared Access Signatures and were a tool I wanted in my knowledge base. Available documentation on the Stored Access Policies was good as far as discussing their need and how to create them, but quite lean on actually implementing them. I finally learned that implementing Stored Access Policies requires a method other than Azure Portal but they are quite simple to deploy.

Shared Access Signature Background

Azure Shared Access Signatures (SAS) provides authenticated access to storage accounts and objects for users outside your tenant. Rather than using Azure Active Directory credentials, the SAS provides all authentication through a cryptographic signature utilizing one of the storage account keys. The SAS tokens can be generated with appropriate permissions and access times to afford granular control over stored resources.

The Azure Portal allows creation of ad hoc SAS. This method allows control over the services, resource types, permissions, access times, source IPs, and access method – a decent level of control. The resulting SAS token can be sent to anyone that needs these permissions to access your account. Perhaps they need to retrieve a file or are uploading blobs for storage or future processing. But the token is simply an access token that stands on its own and is not tied to an access identity. Anyone that has the token can use it to gain the permissions that the token grants. With ad hoc SAS tokens there is no method to revoke the token. Once it is created it is valid until expiration or the resource that it grants access to is removed.

Enter Stored Access Policies. This concept allows the creation of a policy on the Azure resource (e.g. blob container) identifying parameters such as permissions and start/expiration times. When a SAS token referencing a stored access policy is created, this stored policy is referenced each time the SAS token is used. The administrator now holds more control over the permissions and validity of the SAS token. If a SAS token referencing the policy is ever compromised or needs to be revoked, the administrator can change the expiration date to immediately expire the policy – or simply remove the policy to invalidate the SAS token.

Implementing Stored Access Policies

Documentation on the purpose of and creating Stored Access Policies is decent, but the resources did not discuss how to actually implement them when creating a SAS token. No matter where I looked in the Portal, there did not appear to be a way to create a SAS token referencing a Stored Access Policy.

Screenshot of Azure Portal SAS creation blade
No Stored Access Policy references here

I’m pretty comfortable with the Az CLI and have used it quite frequently in Linux to query my subscriptions and create minor resources or script bulk creation. I started exploring the az storage branch and quickly found a promising reference.

Az CLI output
Once again Portal fails us…

Example of creating a SAS token with Stored Access Policy using Az CLI:

az storage container generate-sas -n mycontainer --policy-name readonly --account-key <storage_account_key> --account-name mystorageaccount

where:

  • mycontainer is the name of the blob container in the storage account
  • readonly is the name of the Stored Access Policy you wish to reference
  • mystorageaccount is the name of the storage account
  • <storage_account_key> is one of the two keys for the storage account

Note that instead of the storage account name and storage account key, you can reference a storage account connection string (–connection-string) or SAS token (–sas-token).

Comments are closed.

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: