Set Container ACL
The Set Container ACL operation sets the permissions for the specified container. The permissions indicate whether blobs in a container may be accessed publicly.
As of version 2009-09-19, the container permissions provide the following options for managing container access:
Full public read access: Container and blob data can be read via anonymous request. Clients can enumerate blobs within the container via anonymous request, but can't enumerate containers within the storage account.
Public read access for blobs only: Blob data within this container can be read via anonymous request, but container data isn't available. Clients can't enumerate blobs within the container via anonymous request.
No public read access: Container and blob data can be read by the account owner only.
Set Container ACL also sets a stored access policy for use with shared access signatures. For more information, see Define a stored access policy.
All public access to the container is anonymous, as is access via a shared access signature.
Request
The Set Container ACL request may be constructed as follows. We recommend that you use HTTPS. Replace myaccount with the name of your storage account:
| Method | Request URI | HTTP version |
|---|---|---|
PUT |
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Emulated storage service request
When making a request against the emulated storage service, specify the emulator hostname and Blob service port as 127.0.0.1:10000, followed by the emulated storage account name:
| Method | Request URI | HTTP version |
|---|---|---|
PUT |
http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
For more information, see Use the Azurite emulator for local Azure Storage development.
URI parameters
You can specify the following additional parameters in the request URI:
| Parameter | Description |
|---|---|
timeout |
Optional. The timeout parameter is expressed in seconds. For more information, see Set time-outs for Blob service operations. |
Request headers
The required and optional request headers are described in the following table:
| Request header | Description |
|---|---|
Authorization |
Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage. |
Date or x-ms-date |
Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage. |
x-ms-version |
Optional. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage services. |
x-ms-blob-public-access |
Optional. Specifies whether data in the container may be accessed publicly and the level of access. Possible values include: - container: Specifies full public read access for container and blob data. Clients can enumerate blobs within the container via anonymous request, but can't enumerate containers within the storage account.- blob: Specifies public read access for blobs. Blob data within this container can be read via anonymous request, but container data isn't available. Clients can't enumerate blobs within the container via anonymous request.If this header isn't included in the request, container data is private to the account owner. Note that setting public access for a container in an Azure Premium Storage account isn't permitted. |
x-ms-lease-id: <ID> |
Optional, version 2012-02-12 and later. If it's specified, Set Container ACL succeeds only if the container's lease is active and matches this ID. If there's no active lease or the ID doesn't match, 412 (Precondition Failed) is returned. |
x-ms-client-request-id |
Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives. For more information, see Monitor Azure Blob Storage. |
This operation also supports the use of conditional headers to execute the operation only if a specified condition is met. For more information, see Specify conditional headers for Blob service operations.
Request body
To specify a stored access policy, provide a unique identifier and access policy in the request body for the Set Container ACL operation.
The SignedIdentifier element includes the unique identifier, as specified in the Id element, and the details of the access policy, as specified in the AccessPolicy element. The maximum length of the unique identifier is 64 characters.
The Start and Expiry fields must be expressed as UTC times and must adhere to a valid ISO 8061 format. Supported ISO 8061 formats include the following:
YYYY-MM-DDYYYY-MM-DDThh:mmTZDYYYY-MM-DDThh:mm:ssTZDYYYY-MM-DDThh:mm:ss.fffffffTZD
For the date portion of these formats, YYYY is a four-digit year representation, MM is a two-digit month representation, and DD is a two-digit day representation. For the time portion, hh is the hour representation in 24-hour notation, mm is the two-digit minute representation, ss is the two-digit second representation, and fffffff is the seven-digit millisecond representation. A time designator T separates the date and time portions of the string, and a time zone designator TZD specifies a time zone.
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>unique-64-character-value</Id>
<AccessPolicy>
<Start>start-time</Start>
<Expiry>expiry-time</Expiry>
<Permission>abbreviated-permission-list</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Sample request
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1
Request Headers:
x-ms-version: 2011-08-18
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT
x-ms-blob-public-access: container
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>
<AccessPolicy>
<Start>2009-09-28T08:49:37.0000000Z</Start>
<Expiry>2009-09-29T08:49:37.0000000Z</Expiry>
<Permission>rwd</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Response
The response includes an HTTP status code and a set of response headers.
Status code
A successful operation returns status code 200 (OK).
For more information about status codes, see Status and error codes.
Response headers
The response for this operation includes the following headers. The response may also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.
| Response header | Description |
|---|---|
ETag |
The ETag for the container. If the request version is 2011-08-18 or later, the ETag value is enclosed in quotation marks. |
Last-Modified |
Returns the date and time when the container was last modified. The date format follows RFC 1123. For more information, see Represent date/time values in headers. Any operation that modifies the container or its properties or metadata updates the last-modified time, including setting the container's permissions. Operations on blobs don't affect the last-modified time of the container. |
x-ms-request-id |
Uniquely identifies the request that was made and can be used to troubleshoot the request. For more information, see Troubleshoot API operations |
x-ms-version |
Indicates the Blob service version that was used to execute the request. This header is returned for requests made against version 2009-09-19 and later. |
Date |
A UTC date/time value that's generated by the service, which indicates the time when the response was initiated. |
x-ms-client-request-id |
Can be used to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the x-ms-client-request-id header if it's present in the request and the value contains no more than 1,024 visible ASCII characters. If the x-ms-client-request-id header isn't present in the request, it won't be present in the response. |
Sample response
Response Status:
HTTP/1.1 200 OK
Response Headers:
Transfer-Encoding: chunked
Date: Sun, 25 Sep 2011 22:42:55 GMT
ETag: "0x8CB171613397EAB"
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Authorization
Authorization is required when calling any data access operation in Azure Storage. You can authorize the Set Container ACL operation as described below.
Important
Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests to Azure Storage. Microsoft Entra ID provides superior security and ease of use compared to Shared Key authorization.
Azure Storage supports using Microsoft Entra ID to authorize requests to blob data. With Microsoft Entra ID, you can use Azure role-based access control (Azure RBAC) to grant permissions to a security principal. The security principal may be a user, group, application service principal, or Azure managed identity. The security principal is authenticated by Microsoft Entra ID to return an OAuth 2.0 token. The token can then be used to authorize a request against the Blob service.
To learn more about authorization using Microsoft Entra ID, see Authorize access to blobs using Microsoft Entra ID.
Permissions
Listed below are the RBAC action necessary for a Microsoft Entra user, group, managed identity, or service principal to call the Set Container ACL operation, and the least privileged built-in Azure RBAC role that includes this action:
- Azure RBAC action: Microsoft.Storage/storageAccounts/blobServices/containers/setAcl/action
- Least privileged built-in role: Storage Blob Data Owner
To learn more about assigning roles using Azure RBAC, see Assign an Azure role for access to blob data.
Remarks
When you set permissions for a container, the existing permissions are replaced. To update the container's permissions, call Get Container ACL to fetch all access policies that are associated with the container. Modify the access policy that you want to change, and then call Set Container ACL with the complete set of data to perform the update.
Enable anonymous public access on container data
To enable anonymous public read access on container data, call Set Container ACL with the x-ms-blob-public-access header set to container or blob. To disable anonymous access, call Set Container ACL without specifying the x-ms-blob-public-access header.
If you set x-ms-blob-public-access to blob, clients can call the following operations anonymously:
Get Block List (for the committed block list only)
If you set x-ms-blob-public-access to container, clients can call the following operations anonymously:
The blob access operations that are listed in the preceding section.
Establish container-level access policies
A stored access policy can specify the start time, expiration time, and permissions for the shared access signatures with which it's associated. Depending on how you want to control access to your container or blob resource, you can specify all these parameters within the stored access policy, and omit them from the URL for the shared access signature. By doing so, you can either modify the associated signature's behavior at any time or revoke it. Or you can specify one or more access policy parameters within the stored access policy, and the others on the URL. Finally, you can specify all the parameters on the URL. In this case, you can use the stored access policy to revoke the signature, but not to modify its behavior. For more information, see Define a stored access policy.
Together, the shared access signature and the stored access policy must include all fields that are required to authorize the signature. If any required fields are missing, the request fails. Likewise, if a field is specified in both the shared access signature URL and the stored access policy, the request fails with status code 400 (Bad Request).
At most, five separate access policies can be set for a single container at any time. If more than five access policies are passed in the request body, the service returns status code 400 (Bad Request).
A shared access signature can be issued on a container or a blob regardless of whether container data is available for anonymous read access. A shared access signature provides a greater measure of control over how, when, and to whom a resource is made accessible.
Note
When you establish a stored access policy on a container, the policy might take up to 30 seconds to take effect. During this interval, until the policy becomes active, a shared access signature that's associated with the stored access policy fails with status code 403 (Forbidden).
Billing
Pricing requests can originate from clients that use Blob Storage APIs, either directly through the Blob Storage REST API, or from an Azure Storage client library. These requests accrue charges per transaction. The type of transaction affects how the account is charged. For example, read transactions accrue to a different billing category than write transactions. The following table shows the billing category for Set Container ACL requests based on the storage account type:
| Operation | Storage account type | Billing category |
|---|---|---|
| Set Container ACL | Premium block blob Standard general-purpose v2 |
Other operations |
| Set Container ACL | Standard general-purpose v1 | Write operations |
To learn about pricing for the specified billing category, see Azure Blob Storage Pricing.
See also
Restrict access to containers and blobs
Delegate access with a shared access signature
Create and use a shared access signature
Define a stored access policy
Get Container ACL
Authorize requests to Azure Storage
Status and error codes
Blob service error codes