Azure Explorer unusable for users with RBAC Reader role (403 on listKeys)

This is duplicating an issue found in Rider's Azure Explorer plugin, the matching issue can be found here.

Below is the duplicated text from that issue posting:

Bug Report / Feature Request

Summary

Users who only have the Azure RBAC Reader role assigned cannot browse Storage Accounts
or Resource Groups in the Azure Explorer. The plugin silently fails or shows errors because
it unconditionally calls operations that require permissions beyond Reader.

---

Environment

• IDE: JetBrains Rider 2026.1.2
• Plugin version: 4.7.4
• Azure subscription: Reader role only (no Contributor/Owner)

---

Steps to Reproduce

1. Sign in to Azure with an account that has Reader role only on the subscription
2. Open the Azure Explorer tool window
3. Expand Storage → click on any Storage Account node

Expected Behavior

Storage accounts are listed. The user can browse container/blob metadata available
via ARM (which Reader CAN access). Write actions (Delete, Create, Copy Key) are
hidden or disabled.

Actual Behavior

The plugin calls Microsoft.Storage/storageAccounts/listKeys/action when expanding
a Storage Account node (to obtain a connection string for data-plane access). Reader
does not have this permission, resulting in:

• A 403 AuthorizationFailed error
• The node fails to expand or shows a generic error

The same 403 also surfaces in BaseStorageAccountResourceDefinition.initEnv() when
connecting storage to a Run Configuration.

---

Root Cause (investigated)

The plugin has two layers of listKeys calls triggered by Reader-only accounts:

1. Node expansion (StorageNodeProvider.java): When a Storage Account node is
   expanded, StorageAccount::getSubModules is invoked, which triggers the underlying
   SDK to call listKeys to authenticate against the data plane (Blob/Queue/Table/File).
   Reader does not have Microsoft.Storage/storageAccounts/listKeys/action.

2. Action contributors (StorageActionsContributor.java): The context menu actions
   Copy Connection String and Copy Primary Key always call getConnectionString()
   / getKey() regardless of permissions. These are visible even when they will always fail.

Additionally, write actions such as Delete and Create (registered in
ResourceCommonActionsContributor.java) are shown to all users regardless of their
RBAC role, leading to confusing "Access Denied" failures when invoked.

---

Suggested Fix

Add a Reader Mode setting (plugin Settings → Azure → "Reader access mode") that:

1. Skips sub-module expansion for Storage Accounts — prevents listKeys from
   being called; shows a note like "Reader mode: key-based browsing unavailable"
2. Hides write context-menu actions — COPY_CONNECTION_STRING, COPY_PRIMARY_KEY,
   DELETE, CREATE — for all resource types when reader mode is active
3. Gracefully handles 403 in BaseStorageAccountResourceDefinition.initEnv()
   rather than surfacing a raw exception

Optionally, a toolbar toggle on the Azure Explorer panel would allow quick switching
without going to Settings.

Auto-detection (inspecting the user's role assignments at login) would be an even
better long-term solution, but a manual toggle is a low-risk first step.

---

Workaround

None currently. Users with Reader-only access cannot use the Azure Explorer for
Storage at all.

---

References

• Azure RBAC built-in roles:https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
• Microsoft.Storage/storageAccounts/listKeys/action is NOT included in the Reader role
• ARM read operations (list resource groups, list storage accounts by name) ARE available toReader

Read StorageNodeProvider.java and the StorageAccount.getSubModules path first, then inspect StorageActionsContributor.java, ResourceCommonActionsContributor.java, and BaseStorageAccountResourceDefinition.initEnv(). Done means Reader-only users can expand Storage Accounts without a listKeys 403, key and write actions are unavailable when appropriate, and initEnv() handles the authorization failure gracefully.