Append Blob Seal

The purpose of the Append Blob Seal operation is to allow users and applications to seal append blobs, marking them as read-only. This document outlines the proposed REST API specs for this feature.

Request

You can construct the Append Blob Seal request as follows. HTTPS is recommended. Replace myaccount with the name of your storage account.

PUT method request URI	HTTP version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal	HTTP/1.1

Headers

Append Blob Seal returns common API headers, ETag/LMT (last-modified-time), x-ms-request-id, x-ms-version, content-length, and Date. Append Blob Seal doesn't change the ETag/LMT.

Response header	Value	Description
x-ms-blob-sealed	true/false	Optional. False by default. If the blob is sealed, this header is included in the response when you seal and get properties of a blob. This header should appear in GetBlob, GetBlobProperties, AppendBlobSeal, and ListBlobs for append blobs.

Query parameters

No additional URI parameters.

Request body

None.

Response

The response includes an HTTP status code and a list of response headers.

Status code

You might receive any of the following status codes:

• 200 (Success): The blob is sealed. The call is idempotent and will succeed if the blob is already sealed.

• 409 (InvalidBlobType): The service returns this status code if the call is on an existing page blob or block blob.

• 404 (BlobNotFound): The service returns this status code if the call is on a non-existent blob.

Authorization

Authorization is required when calling any data access operation in Azure Storage. You can authorize the Append Blob Seal 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.

Microsoft Entra ID (recommended)

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 Append Blob Seal operation, and the least privileged built-in Azure RBAC role that includes this action:

• Azure RBAC action: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
• Least privileged built-in role: Storage Blob Data Contributor

To learn more about assigning roles using Azure RBAC, see Assign an Azure role for access to blob data.

Shared access signatures (SAS)

A shared access signature (SAS) provides secure delegated access to resources in a storage account. With a SAS, you have granular control over how a client can access data. You can specify what resource the client may access, what permissions they have to those resources, and how long the SAS is valid.

The Append Blob Seal operation supports three types of shared access signatures: user delegation SAS, service SAS, and account SAS.

As a security best practice, we recommend that you use Microsoft Entra credentials rather than the storage account key, which can be more easily compromised. If your application design requires shared access signatures, use Microsoft Entra credentials to create a user delegation SAS, when possible.

When Shared Key access is disallowed for the storage account, a service SAS token or an account SAS token will not be permitted on a request to Blob Storage. To learn more, see Understand how disallowing Shared Key affects SAS tokens.

User delegation SAS

A user delegation SAS is secured with Microsoft Entra credentials and also by the permissions specified for the SAS.

Calling the Append Blob Seal operation using a SAS token delegated to a container or blob resource requires the Write (w) permission as part of the user delegation SAS token.

To learn more about the user delegation SAS, see Create a user delegation SAS.

Service SAS

A service SAS is secured with the storage account key. A service SAS delegates access to a resource in a single Azure Storage service, such as blob storage.

Calling the Append Blob Seal operation using a SAS token delegated to a container or blob resource requires the Write (w) permission as part of the service SAS token.

To learn more about the service SAS, see Create a service SAS.

Account SAS

An account SAS is secured with the storage account key. An account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service or user delegation SAS are also available via an account SAS.

The following table indicates the signed resource type and signed permissions to specify when delegating access:

Operation	Signed service	Signed resource type	Signed permission
Append Blob Seal	Blob (b)	Object (o)	Write (w)

To learn more about the account SAS, see Create an account SAS.

Shared key

The Append Blob Seal operation supports Shared Key authorization. Authorizing with account keys is not recommended for most scenarios, as it's less secure.

Microsoft recommends disallowing Shared Key authorization for the storage account when possible. For more information, see Prevent authorization with Shared Key.

Remarks

If an append blob has a lease, you need a lease ID to seal the blob.

After you seal a blob, you can still update properties, blob index tags, and metadata. Soft-deleting a sealed blob preserves the sealed state. You can overwrite sealed blobs.  

If you take a snapshot of a sealed blob, the snapshot includes the sealed flag. For existing snapshots in the new version, Microsoft returns the property.

When you copy a sealed blob, the sealed flag is propagated by default. A header is exposed that allows the flag to be overwritten.

A new XML element will be added to the ListBlob response, named Sealed. The value can be either true or false.

If you call AppendBlock on a blob that is already sealed, the service returns the error message shown in the following table. This applies to older versions of the API.

Error code	HTTP status code	User message
BlobIsSealed	Conflict (409)	The specified blob is sealed, and its contents can't be modified unless the blob is re-created after a delete.

If you call Append Blob Seal on an append blob that has already been sealed, you simply see a status code of 200 (Success).

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 Append Blob Seal requests based on the storage account type:

Operation	Storage account type	Billing category
Append Blob Seal	Premium block blob Standard general-purpose v2 Standard general-purpose v1	Write operations

To learn about pricing for the specified billing category, see Azure Blob Storage Pricing.

See also

Azure Blob Storage error codes