Container Access Policies
Azure Blob Storage allows you to control access to your containers and the blobs within them. Container access policies define how clients can access blobs without requiring Azure credentials. This is particularly useful for scenarios like sharing files publicly or providing temporary access.
There are two primary ways to manage container access:
- Public Access Level: Setting a container to be public allows anonymous read access to blobs.
- Shared Access Signatures (SAS): SAS tokens provide granular, time-limited, and permission-specific access to resources.
1. Public Access Level
You can configure the public access level for a container at three granularities:
- No public access: The default setting. Only authenticated principals can access container and blob data.
- Blob public access: Allows anonymous read access for blobs within the container. The container ACL is set to
blob. Anonymous clients can list blobs within the container. - Container public access: Allows anonymous read access for blobs and anonymous container data, including listing blobs. The container ACL is set to
container.
Configuring Public Access
You can configure the public access level through the Azure portal, Azure CLI, PowerShell, or REST API.
Using Azure CLI:
az storage container set-permission \
--account-name \
--name \
--public-access blob
Replace and with your actual values.
2. Shared Access Signatures (SAS)
SAS tokens are a powerful mechanism for delegating access to Blob Storage resources. A SAS token is a string that contains a security token and is appended to the URI of a Blob Storage resource.
Types of SAS:
- Service SAS: Signed with the storage account key. It provides delegated access to a resource in one of the storage services (blobs, queues, tables, files).
- Account SAS: Signed with the storage account key. It provides delegated access to resources across one or more storage services.
- User delegation SAS: Signed with Azure AD credentials. It provides delegated access to a resource in Blob Storage using Azure AD.
SAS Permissions:
When creating a SAS, you can specify the following permissions:
- Read (r): Allows clients to read the resource.
- Write (w): Allows clients to write to the resource.
- Delete (d): Allows clients to delete the resource.
- List (l): Allows clients to list blobs within a container.
- Add (a): Allows clients to add new blobs to a container.
- Create (c): Allows clients to create new blobs or overwrite existing ones.
- Process (p): Allows clients to process blob data.
- Tag (t): Allows clients to read and write tags on a blob.
- Delete_tag (x): Allows clients to delete tags on a blob.
SAS Expiry and Start Time:
You must specify an expiry time for a SAS token. You can also specify a start time to indicate when the token becomes valid.
Generating a SAS Token (Azure CLI Example):
This example generates a service SAS for a blob with read, write, and delete permissions, valid for one hour.
az storage blob generate-sas \
--account-name \
--container-name \
--name \
--permissions rwd \
--expiry $(date -u -d "1 hour" '+%Y-%m-%dT%H:%MZ') \
--output tsv
The output will be the SAS token itself. You append this token to the blob's URI.
Example URI with SAS: https://
Key Considerations:
- Granularity: SAS tokens can be generated for an account, a container, or a specific blob.
- Permissions: Grant only the necessary permissions to minimize security risks.
- Expiry: Always set an expiration time and keep it as short as is practical.
- IP Restrictions: For added security, you can restrict SAS access to specific IP addresses or ranges.
Understanding and implementing container access policies and SAS tokens are crucial for secure and efficient management of your Azure Blob Storage data.