Need to share data hosted in Azure Storage? With two very different options for granting, you may ask “which option is best?”. It pays to know your options, and the capabilities (or limitations) of each. We'll touch on the options for securing access to Azure storage, and start digging into the topic of Azure Key Vault integration in the Infrastructure-as-Code context.
If you're looking back in the "100 Days" series, we touch on various aspects of storage in several installments, including:
- Day 22 - Azure Storage and Secrets in Infrastructure-as-Code (Part 1)
- Day 23 - Storage and Secrets in Infrastructure-as-Code (Part 2)
- Day 24 - Storage and Secrets in Infrastructure-as-Code (Part 3)
- Day 29 - Build Pipelines, using Variables (Windows Edition)
- Day 30 - Build Pipelines, using Variables (Linux Edition)
- Day 42 - Deploy Linked ARM Templates Using Storage Account in YAML Pipeline
- Day 66 - Pipeline-friendly Azure Files Script
In this article:
SPONSOR: Need to stop and start your development VMs on a schedule? The Azure Resource Scheduler let's you schedule up to 10 Azure VMs for FREE! Learn more HERE
Shared Key is exactly what it sounds like: a key (in cryptographic terms, a string of bits used by an algorithm) you share with those to whom you would like to delegate access. This is equivalent to giving root access to a storage account. It grants all privileges to whomever has the key, from anywhere at anytime until the key is revoked or rolled over.
HOW-TO: Authorize with Shared Key
Shared Access Signatures allow you to scope duration, privileges, and even which IP addresses are allowed to connect. By distributing a shared access signature URI to a client, you can grant them access to a resource for a specified period of time, with a specified set of permissions. You can scope access with account-level SAS (one or multiple services in the storage account) or service-Level SAS, which delegates access to resource in just one service (like Queues only, Files only, etc.). There is also user delegation SAS, introduced with version 2018-11-09. A user delegation SAS is secured with Azure AD credentials.
Additionally, a service SAS can reference a stored access policy that provides an additional level of control over a set of signatures, including the ability to modify or revoke access to the resource if necessary. SAS is the route that offers the tightest control over access scope and duration.
HOW-TO: Delegating Access with a Shared Access Signature
There is a relatively new method that allows using Azure AD to grant authorization. Unfortunately it’s only supported for Blob and Queue services, so if you use Table Storage, this wont help. Use Shared Key to authorize requests to Table storage. For the services it supports, it’s no doubt going to become a preferred method of granting access in many scenarios.
Azure Files supports authorization with Azure AD over SMB, but for domain-joined VMs only. For details, check out ["Overview of Azure Active Directory authorization over SMB for Azure Files."](Overview of Azure Active Directory authorization over SMB for Azure Files)
Azure Data Plane security: https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide#data-plane-security Authenticate access to Azure Storage using Azure Active Directory: https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad
The short answer is "it depends". Since not every option supports every service, you'll need to weigh your options for each use case.
If you are working with ARM templates, you can leverage the KeyVaultProperties object to interact with Azure Key Vault in deployment scenarios.
You can also leverage Azure CLI, with the az keyvault and az storage account commands.
We'll dig into some details of Azure Key Vault in the near future.
So, keep an eye out for Key Vault discussions in the next day or two, when we'll dig into Key Vault in the context of Azure storage scenarios.