Skip to content

Azure Blob Storage

FlexBlock drives Azure Blob Storage through its native API. The grant names the storage account, container and prefix, so none of them is passed on the command line. The endpoint is derived from the storage account unless the grant names one.

Two styles are available.

A shared key in AZURE_STORAGE_KEY signs every request directly and grants access to the whole storage account. It is the right choice for Azurite and a fallback where Entra ID cannot be used.

Without AZURE_STORAGE_KEY, flexBlock walks the Entra ID chain, in this order:

  1. A service principal from AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET.
  2. Workload identity, when AZURE_FEDERATED_TOKEN_FILE is present.
  3. The managed identity of the VM.
  4. An az login or azd auth login session on a workstation.

No other Entra ID credential is used. In particular, a service principal that authenticates with a client certificate is not supported; give it a client secret or use a managed identity.

The recommended production setup is a system-assigned managed identity on the VM with the Storage Blob Data Contributor role scoped to the container. That role covers reading the container plus reading, writing and deleting its blobs.

Terminal window
az vm identity assign --resource-group acme-rg --name flexblock-host
az role assignment create --role "Storage Blob Data Contributor" \
--assignee-object-id "<principal id from the previous command>" \
--assignee-principal-type ServicePrincipal \
--scope "/subscriptions/<subscription>/resourceGroups/acme-rg/providers/Microsoft.Storage/storageAccounts/acmedata/blobServices/default/containers/acme-data"

Verify the grant and identity together before touching a device:

Terminal window
sudo -E flexblock show --remote

Label the pod with azure.workload.identity/use: "true" and annotate its service account with the managed identity’s client id. The webhook injects AZURE_CLIENT_ID, AZURE_TENANT_ID and AZURE_FEDERATED_TOKEN_FILE, and flexBlock picks them up.

Server-side encryption on Blob Storage is provider managed. FlexBlock has no encryption setting for Blob; the --s3-sse and --s3-no-sse flags apply to S3 only.

Every chunk object is uploaded with an MD5 checksum that Blob Storage verifies, and verified again by flexBlock on download.

Every command first checks that the store is reachable. On Blob this check reads the container itself, so the identity needs read access to the container as well as to its blobs. Storage Blob Data Contributor covers both.

For evaluation, Azurite stands in for Blob Storage. Use its well-known development key in AZURE_STORAGE_KEY and run commands with sudo -E. See Evaluating Without Hardware.