Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support storage-account-level Azure RBAC authentication in attach (WAT) flow

Open
  • Is something wrong?
#9,168 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
azure
Domain
authentication, cloud

Research direction

Start by locating the existing data-plane attach machinery used for single containers, then trace how the attach flow handles the blob/dfs endpoint and List Containers operation. Done means an account-scoped Blob or ADLS endpoint can attach and browse with an Azure AD token without subscription Reader, while ARM-only account management actions remain unavailable.

Written by the indexing model from the issue text.

Description

:gear: attach :gear: rbac :grey_question: investigate

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.

Dominant language
No language data
Stars
455
Forks
92
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/AzureStorageExplorer

All issues in microsoft/AzureStorageExplorer

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.