RBAC vs Storage Access Keys in Azure

Azure gives you two fundamentally different ways to authorize access to blob data: storage account access keys and Azure RBAC. Access keys are simple but powerful — almost too powerful. RBAC is more complex to set up but gives you fine-grained control over exactly who can do what, without handing out root-level credentials.

Storage access keys: what they are and why they’re risky

Every storage account has two 512-bit access keys. They’re essentially master passwords. Anyone holding a key can read, write, delete, and manage every blob, queue, table, and file share in the account — with no restrictions and no audit trail of what they accessed.

You can view your account keys with:

# List storage account keys (requires Storage Account Key Operator role or Owner)
az storage account keys list \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg \
  --output table

Keys should be treated like database root passwords. Never commit them to source control. Never put them in environment variables in a container image. Never email them. If a key leaks, rotate it immediately.

Azure provides two keys so you can rotate without downtime:

# Rotate key 1 (regenerate it — old key1 is immediately invalidated)
az storage account keys renew \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg \
  --key primary

# Rotate key 2
az storage account keys renew \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg \
  --key secondary

The safe rotation procedure: (1) switch your apps from key1 to key2, (2) rotate key1, (3) switch apps back to key1, (4) rotate key2.

Azure RBAC for storage: data plane roles

Azure RBAC (Role-Based Access Control) lets you assign specific roles to specific identities (users, groups, service principals, or managed identities) at specific scopes (storage account, container, or even individual blob).

There’s an important distinction in Azure Storage RBAC:

Management plane roles control account-level settings — creating containers, changing network rules, viewing keys. The Storage Account Contributor role lives here.
Data plane roles control access to the actual data inside the account. These are what you need for applications reading and writing blobs.

Data plane role	Can read blobs	Can write blobs	Can delete blobs	Can set container permissions
Storage Blob Data Reader	Yes	No	No	No
Storage Blob Data Contributor	Yes	Yes	Yes	No
Storage Blob Data Owner	Yes	Yes	Yes	Yes
Storage Blob Delegator	No	No	No	No (can generate user delegation SAS)

Assigning RBAC roles via CLI

# Assign Storage Blob Data Reader to a user at the storage account scope
USER_ID=$(az ad user show --id user@example.com --query "id" --output tsv)
STORAGE_ID=$(az storage account show \
  --name mystorageaccount123 \
  --resource-group my-storage-rg \
  --query "id" --output tsv)

az role assignment create \
  --assignee-object-id $USER_ID \
  --assignee-principal-type User \
  --role "Storage Blob Data Reader" \
  --scope $STORAGE_ID

# Assign Storage Blob Data Contributor to a managed identity at container scope
IDENTITY_ID=$(az identity show \
  --name my-app-identity \
  --resource-group my-storage-rg \
  --query "principalId" --output tsv)

CONTAINER_SCOPE="$STORAGE_ID/blobServices/default/containers/assets"

az role assignment create \
  --assignee-object-id $IDENTITY_ID \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope $CONTAINER_SCOPE

Scoping an assignment to a specific container rather than the whole account follows least privilege: the managed identity can only access the assets container, not any other container in the same account.

Using RBAC authentication in Azure CLI commands

When running az storage commands, you specify how to authenticate with the —auth-mode flag:

# Use Azure AD (RBAC) authentication — recommended
az storage blob list \
  --account-name mystorageaccount123 \
  --container-name assets \
  --auth-mode login

# Use account key authentication — not recommended for production
az storage blob list \
  --account-name mystorageaccount123 \
  --container-name assets \
  --account-key "your-account-key-here"

# Use a connection string (bundles the account key — same security risks as keys)
az storage blob list \
  --connection-string "DefaultEndpointsProtocol=https;AccountName=..."

Always use —auth-mode login in scripts that run under a managed identity or service principal. Reserve key-based authentication for local development and debugging.

Disabling account key access entirely

For maximum security on production accounts, disable key-based access entirely. All clients must authenticate via Azure AD.

# Disable storage account key access
az storage account update \
  --name mystorageaccount123 \
  --resource-group my-storage-rg \
  --allow-shared-key-access false

# Verify the setting
az storage account show \
  --name mystorageaccount123 \
  --resource-group my-storage-rg \
  --query "allowSharedKeyAccess"

Note

Before disabling key access, verify that every application and service accessing the account uses Azure AD authentication, not connection strings or account keys. Disabling key access will immediately break any application that uses a key — including some Azure services that rely on key-based authentication internally. Test in a non-production environment first.

Choosing between RBAC and access keys

Aspect	Storage access keys	Azure RBAC
Setup complexity	Low — copy and paste the key	Medium — requires Azure AD and role assignments
Permission granularity	All-or-nothing	Fine-grained, scope to container or blob
Rotation/revocation	Rotating key invalidates all users	Revoke by removing role assignment
Audit trail	No per-identity audit	Every action tied to a specific identity
Suitable for	Development, quick testing	Production workloads, compliance requirements

The answer for production is almost always RBAC with managed identities. Access keys are fine during development to keep things moving quickly, but should be replaced before anything goes to production.

Common mistakes

Assigning Storage Account Contributor thinking it grants data access. Storage Account Contributor is a management plane role — it lets you modify account settings and view keys, but doesn’t grant data plane permissions to read or write blobs. To read blob data, you need a data plane role like Storage Blob Data Reader.
Using the Owner role for storage access. Owner at the storage account scope includes every permission including data access and account management. Use purpose-specific data plane roles instead. The principle of least privilege matters even when you trust the recipient.
Storing connection strings in app settings as permanent secrets. Connection strings contain account keys. If your application uses Azure App Service or Azure Functions, use managed identity and RBAC instead — the identity is automatically rotated and never exposed as a string.
Not auditing role assignments periodically. Role assignments accumulate over time — temporary contractors, projects that ended, test identities. Review assignments every quarter and remove what’s no longer needed. Azure Policy can help enforce this automatically.

Frequently asked questions

What happens if I rotate a storage account key?

Any application or service using the old key immediately loses access to the storage account. SAS tokens signed with the rotated key are also instantly invalidated. Before rotating, update all applications and services that use the key. Azure gives you two keys so you can rotate without downtime: switch apps to key 2, rotate key 1, switch apps back to key 1, rotate key 2.

Can I disable storage account keys entirely?

Yes. You can set the "Allow storage account key access" property to false on the storage account. This forces all access to go through Azure AD authentication (RBAC or user delegation SAS). This is the most secure configuration and is recommended for accounts holding sensitive data.

What RBAC role do I need to read blobs?

Storage Blob Data Reader grants read access to blob data. Storage Blob Data Contributor grants read and write access. Storage Blob Data Owner grants full control including setting access policies. These are data plane roles — separate from management plane roles like Storage Account Contributor, which controls the account settings but not the data inside.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.