Feature request
Support storage-account-level Azure RBAC authentication in the "attach with Azure AD" (WAT / Connect) flow.
Problem
Customers following least-privilege want to grant a user a data-plane role - Storage Blob Data Reader or Storage Blob Data Contributor - scoped directly to a single storage account, without granting Reader at the subscription level (which would let the user discover/enumerate every other storage account in the subscription).
Today:
- Container-level RBAC -> the user can attach and browse that container via Azure AD (data-plane OAuth attach works).
- Storage-account-level Blob Data RBAC -> the user cannot attach the whole storage account via Azure AD. Account discovery is bound to subscription/ARM enumeration, which requires subscription Reader.
As a result, users with account-scoped Blob Data roles are effectively forced to use subscription Reader + sign-in (over-permissioned) or fall back to SAS/account-key authentication - both of which defeat the least-privilege goal.
Requested improvement
Allow a user who holds Storage Blob Data Reader/Contributor scoped to a specific storage account to attach and browse that account's blob/ADLS data plane via Azure AD, by supplying the account's blob/dfs endpoint (e.g. https://<account>.blob.core.windows.net) and an Azure AD token - without requiring subscription-level Reader.
The natural implementation reuses the existing data-plane attach machinery (already used for single containers) and enumerates the account's containers using the data-plane List Containers operation, which is permitted for Storage Blob Data Reader.
Scope / caveats
- This is a data-plane capability (browse containers/blobs/ADLS paths). Account management operations that are ARM-only (viewing keys, account properties/config) would remain unavailable for a data-plane-only attach and should be greyed out or hidden.
- Applies to Blob and ADLS Gen2 endpoints; File/Queue/Table data-plane RBAC could be considered separately.
Why now
Repeatedly requested by customers via CSS. Complements the broader RBAC-experience investigation in #8650, but is a specific, self-contained gap: account-scoped Blob Data RBAC cannot be used to attach an account today.
Feature request
Support storage-account-level Azure RBAC authentication in the "attach with Azure AD" (WAT / Connect) flow.
Problem
Customers following least-privilege want to grant a user a data-plane role - Storage Blob Data Reader or Storage Blob Data Contributor - scoped directly to a single storage account, without granting Reader at the subscription level (which would let the user discover/enumerate every other storage account in the subscription).
Today:
As a result, users with account-scoped Blob Data roles are effectively forced to use subscription Reader + sign-in (over-permissioned) or fall back to SAS/account-key authentication - both of which defeat the least-privilege goal.
Requested improvement
Allow a user who holds Storage Blob Data Reader/Contributor scoped to a specific storage account to attach and browse that account's blob/ADLS data plane via Azure AD, by supplying the account's blob/dfs endpoint (e.g.
https://<account>.blob.core.windows.net) and an Azure AD token - without requiring subscription-level Reader.The natural implementation reuses the existing data-plane attach machinery (already used for single containers) and enumerates the account's containers using the data-plane List Containers operation, which is permitted for
Storage Blob Data Reader.Scope / caveats
Why now
Repeatedly requested by customers via CSS. Complements the broader RBAC-experience investigation in #8650, but is a specific, self-contained gap: account-scoped Blob Data RBAC cannot be used to attach an account today.