Deny Assignment Not Blocking Access to Storage Account

Question

Deny Assignment Not Blocking Access to Storage Account

Andrew McWilliams 10

I’ve deployed a storage account using a deployment stack that includes a deny assignment intended to block access to all principals. The deny settings appear to be configured correctly (see attached screenshot).

User's image

However, I assigned a test user the 'Storage Blob Data Reader' role at the subscription level, and this user is still able to access blobs in the storage account.

My expectation is that the deny assignment should override the RBAC role and prevent access entirely. Can you help me understand why this deny assignment is not working as expected?

Hari Babu Vattepally 3,350 Reputation points Microsoft External Staff Moderator

2025-06-05T18:04:55.2+00:00
Hi @Andrew McWilliams,

In your scenario, even if you've set up a deny assignment to block access for everyone, the "Storage Blob Data Reader" role might still let the user read the blobs. Make sure your deny assignment is set up to specifically block the actions tied to the "Storage Blob Data Reader" role.

However, If a user is assigned a role that grants them access at a higher scope, such as the subscription level, it can override deny assignments at a lower scope, like the storage account level. In your case, since the test user has the role assigned at the subscription level, this role grants them access to all storage accounts within that subscription, which may explain why the deny assignment is not functioning as expected.

Additionally, deny assignments are managed by Azure and cannot be created directly by users, which means they may not function as expected if there are conflicting permissions or if the deny assignment does not apply to the specific actions allowed by the role.

To troubleshoot further, you should verify the following:

Ensure that the deny assignment is correctly applied to the scope of the storage account.

Check if there are any other roles or permissions that might be allowing access to the storage account despite the deny assignment.

To ensure that the deny assignment effectively blocks access, you may need to adjust the RBAC roles or modify the scope of the deny assignment.

However, we see that there is a known limitations that the deployment stack doesn't manage implicitly created resources. Therefore, you can't use deny-assignments or cleanup for these resources.

For more additional information, please refer the below document:

List Azure deny assignments

Use Azure Policy to enforce authorized access

Hope this helps!

Kindly let us know if the above helps or you need further assistance on this issue.

Please don’t forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Andrew McWilliams 10 Reputation points

2025-06-09T13:19:11.3333333+00:00

I’ve tested assigning the user the Storage Blob Data Reader role at the storage account level (not subscription), and they were still able to read blobs—despite the deny assignment being in place. My understanding is that deny assignments should override allow roles, so this result is unexpected?

Also, you mentioned that deny assignments "cannot be created directly by users"—but I’ve used a deployment stack to configure one. Could you clarify what limitations you're referring to here, and whether they affect deny assignment behavior?

Lastly, can you expand on what you meant by "deployment stacks don’t manage implicitly created resources" and how that would impact a deny assignment applied at the storage account level?
Hari Babu Vattepally 3,350 Reputation points Microsoft External Staff Moderator

2025-06-10T16:14:19.21+00:00

Hi @Andrew McWilliams,

Just checking in to see if the above answer helped. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

2 answers

Your answer

Andrew McWilliams 10 Reputation points

2025-06-09T13:19:11.3333333+00:00

I’ve tested assigning the user the Storage Blob Data Reader role at the storage account level (not subscription), and they were still able to read blobs—despite the deny assignment being in place. My understanding is that deny assignments should override allow roles, so this result is unexpected?

Also, you mentioned that deny assignments "cannot be created directly by users"—but I’ve used a deployment stack to configure one. Could you clarify what limitations you're referring to here, and whether they affect deny assignment behavior?

Lastly, can you expand on what you meant by "deployment stacks don’t manage implicitly created resources" and how that would impact a deny assignment applied at the storage account level?
Hari Babu Vattepally 3,350 Reputation points Microsoft External Staff Moderator

2025-06-10T16:14:19.21+00:00

Hi @Andrew McWilliams,

Just checking in to see if the above answer helped. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 1

I have observed the following:

Azure Deny Assignments Behavior:
1. Deny assignments apply only to the Azure Resource Manager (management plane). They do not affect the data plane.
2. Management plane vs. Data plane:
  - Management plane: Operations like creating, deleting, or configuring resources.
  - Data plane: Operations on the resource’s data, such as reading, writing, or deleting blobs.
3. My observations:
- Contributor role + deny assignment:
  - You can see the storage account because Contributor grants read access to resource metadata.
  - You cannot modify the storage account because deny assignment blocks management plane changes.
  - You cannot access data because Contributor does not grant data plane permissions.
- Storage Blob Data Reader role:
  - You can read blob data because this role grants data plane read permissions.
  - You cannot write or delete because the role is read-only.
- Storage Blob Data Contributor role:
  - You can read, write, and delete blob data because this role grants full data plane permissions.
  - Deny assignment does not block these actions since they are data plane operations.
Summary:
Deny assignments block management plane actions, even if you have RBAC roles like Contributor.
- Deny assignments do not block data plane actions. Data plane access is controlled by Azure RBAC roles for data plane or shared keys/SAS tokens.
- Assigning Storage Blob Data Reader or Contributor works for data access despite deny assignments.

Answer 2

Hi @Andrew McWilliams,

Thanks for the response,

If a user is assigned the Storage Blob Data Reader role, they will have permissions to read blobs. While deny assignments are intended to block actions, if they are not explicitly configured to deny the specific actions permitted by the role, the role may still take precedence. Therefore, it is crucial to ensure that deny assignments are accurately set up to restrict the actions you want to block.

Also, as said that users cannot directly create deny assignments; however, they can configure them through deployment stacks. Therefore, while deployment stacks enable the creation of deny assignments, it is not possible to create them independently outside of this context.

Here the limitation is due to Azure managing these assignments, meaning users are unable to create them directly through the Azure portal or other interfaces.

And, regarding deployment stacks, they manage only explicitly created resources. If a resource is created implicitly, such as those automatically generated as dependencies of other resources, the deny settings applied to the deployment stack will not affect these implicitly created resources. Consequently, if the storage account or its components were created implicitly, the deny assignment may not apply, potentially allowing access that is expected to be restricted.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.