Limiting storage account access in the portal

Question

I want to provide users with web access to download and upload blobs in a storage account. I was hoping to use the Azure Portal for this but my attempts are giving the user more access than I'd like.

Ideal outcome:

Portal access to only view blob containers in a storage account. Everything else (Networking, IAM, data management etc.) associated with the storage account is hidden or inaccessible

I have created a custom IAM role that does some of this:

                "actions": [
                    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
                    "Microsoft.Storage/storageAccounts/read",
                    "Microsoft.Storage/storageAccounts/blobServices/read"
                ],
                "notActions": [
                    "Microsoft.Authorization/*",
                    "Microsoft.Insights/*",
                    "Microsoft.Network/*",
                    "Microsoft.EventGrid/*",
                    "Microsoft.Storage/storageAccounts/fileServices/*",
                    "Microsoft.Storage/storageAccounts/queueServices/*",
                    "Microsoft.Storage/storageAccounts/tableServices/*",
                    "Microsoft.Storage/storageAccounts/localUsers/*"
				]

The biggest problems I've not been able to block are:

• The user can "Check access" to the storage account on the IAM tab which allows them to search for other users in the tenant
• Networking and configuration of the account is visible

Would Azure Policy and/or Conditional Access help here? Is it possible to use the Portal in this way for restricted blob only access?

Answer 1

Hello Luke Rosser

It sounds like you’re trying to give users just enough access in the Azure Portal to list and download/upload blobs—without letting them poke around the networking settings, IAM “Check access” pane, or any other control-plane blades. Unfortunately, the Portal surface itself doesn’t let you hide those blades via Policy or Conditional Access; it simply shows you whatever resource-level read permissions you have on a storage account. Here’s the scoop and a pattern you can use today:

1. Don’t grant any control-plane “read” rights on the storage account • Your custom role currently includes “Microsoft.Storage/storageAccounts/read” That single read right is what enables the Portal to show the Overview, Networking, Configuration, IAM, etc. • Remove that action from your role. If you strip out all storageAccounts/* control-plane actions (and anything under Microsoft.Authorization/*), Azure Portal will no longer render those blades.
2. Use a data-plane only role (built-in or custom) scoped at the storage account (or container) level • The built-in Storage Blob Data Reader role gives users List + Read on containers/blobs. • If they need upload/delete, go with Storage Blob Data Contributor. • Neither of those roles include the control-plane actions, so the Portal only renders the blob browser UI. • You can scope it to the whole account (so they see every container) or even a single container (if that fits your segregation needs).
3. What about “Check access”? That link in the IAM blade calls Microsoft.Authorization/permissions/read and roleAssignments list APIs. By not granting any Microsoft.Authorization or Microsoft.Storage/storageAccounts/read rights, that blade simply won’t appear.
4. Azure Policy and Conditional Access won’t hide Portal blades • Azure Policy is for enforcing resource properties (firewall rules, SKUs, tags, etc.), not UI. • Conditional Access controls/auth methods to sign in—it can’t turn off a Portal menu.

In short, to get the “blob-only” experience in the Portal, give them only data-plane RBAC (Storage Blob Data Reader/Contributor) and remove all control-plane actions from your custom role. That way the Portal won’t show Networking, IAM “Check access,” Configuration, etc., but will let them browse and manage blobs.

Check the reference document:

https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control-model#role-based-access-control-azure-rbac

https://learn.microsoft.com/en-us/azure/storage/blobs/authorize-data-operations-portal

---

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer 2

The Azure portal cannot be turned into a “blob-only” UI. RBAC can restrict what operations succeed, but it cannot fully hide all non‑data blades (like Networking, IAM, Configuration) or prevent “Check access” from being visible.

For blob‑only access via the portal, the supported pattern is:

1. Assign a data‑plane role such as Storage Blob Data Reader or Storage Blob Data Contributor at the storage account, resource group, or subscription scope.
2. Add an Azure ABAC condition to that role assignment so the user can only operate on specific blobs/containers (for example, only blobs with a given tag, or only in certain containers/paths).

From the tutorial and examples:

• A user can be restricted to read only blobs with a specific tag, for example Project=Cascade, by adding a condition to a data role assignment:

    (
        (
            !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
            AND NOT
            SubOperationMatches{'Blob.List'})
        )
        OR
        (
            @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
        )
    )
  

• Conditions can also restrict access by container name and blob path, using the portal’s visual or code editor. For example, to allow read access only in a specific container and path, the visual editor uses:
  • Attribute source: Resource
  • Attribute: Container name
  • Operator: StringEquals
  • Value: {containerName}
  • And
  • Attribute: Blob path
  • Operator: StringLike
  • Value: {pathString}

These ABAC conditions control which blobs the user can read or write, even though the portal still shows other blades. Attempts to use Networking, IAM, or other management features will fail if the user lacks the corresponding management‑plane permissions.

Azure Policy and Conditional Access do not change the portal surface to a “blob‑only” view. They can enforce compliance and access conditions, but they do not remove blades like IAM or Networking from the UI.

So:

• It is possible to use the portal for restricted blob‑only data access by combining Storage Blob Data roles with ABAC conditions.
• It is not possible to fully hide IAM/Networking blades or the “Check access” experience for a user who can open the storage account in the portal; those controls will be visible, but operations will be denied if the user lacks the required permissions.

---

References:

• Tutorial: Add a role assignment condition to restrict access to blobs using the Azure portal
• Example Azure role assignment conditions for Blob Storage