MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.2k stars 21.36k forks source link

Documentation content - Combining RBAC + ACLs to Prob file #106692

Closed lencarnacao closed 7 months ago

lencarnacao commented 1 year ago

Hello team, We have been experiencing the situation where a user/service principal with a combined Reader RBAC role and ACL Execute permission at container/folder level is able to prob the exitance of a file using Azure Storage Explorer. Also, no permission is needed at the file level. To archive this, user must set the path to the file including filename. Any action (read/write/delete) will return a Authorization error.

This operation seems not detailed on the existing documentation or any statement describing this behavior of "list file".

I would appreciate some support on finding the correct documentation or should we consider to update and/or include it?


Document Details

Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

SaibabaBalapur-MSFT commented 1 year ago

@lencarnacao Thanks for your feedback! We will investigate and update as appropriate.

SaibabaBalapur-MSFT commented 1 year ago

@lencarnacao the Azure role assignments are evaluated first and take priority over any ACL assignments.If the operation is fully authorized based on Azure role assignment, then ACLs are not evaluated at all.If the operation is not fully authorized, then ACLs are evaluated.

The "Storage Blob Data Reader" role provides read and list access to Blob storage containers and blobs.The "Storage Blob Data Contributor" role provides read, write, and delete access to Blob storage containers and blobs.

It seems that the user/service principal with a combined Reader RBAC role and ACL Execute permission at container/folder level is able to probe the existence of a file using Azure Storage Explorer.However, any action (read/write/delete) will return an Authorization error.

This behavior is not detailed in the existing documentation, but it is possible that the user is able to list the files in the container/folder because of the Execute permission in the ACL. However, the user is not able to perform any actions on the file because the role assignment does not provide sufficient permissions.

below reference document might be helpful https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control-model https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-explorer-acl https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

marcindulak commented 1 year ago

The names of the files may be revealing information on their own. Therefore the possibility of listing the names needs to be documented as a warning.

SaibabaBalapur-MSFT commented 1 year ago

@lencarnacao The names of the files may reveal information on their own, and the possibility of listing the names needs to be documented as a warning. This is an important aspect to consider when working with Blob storage containers and blobs.

Reference document might be helpful. https://learn.microsoft.com/en-us/azure/sentinel/normalization-schema-file-event https://learn.microsoft.com/en-us/azure/sentinel/entities-reference

SaibabaBalapur-MSFT commented 1 year ago

@jimmart-dev Can you please check and add your comments on this doc update request as applicable.

jimmart-dev commented 1 year ago

Looking at this now.

jimmart-dev commented 1 year ago

Hi Saibaba. I have been trying to reproduce this scenario, but cannot. I have tried applying READ at the RG level, and then replacing that with Storage Blog Reader and at the same time applying execute permissions for that user at both the container and directory level. After applying those permissions, I sign in to storage explorer as the user and can browse the tree all of the way from the subscription, to the rg, to the storage account, to blobs, to containers. I can see the list of containers that I granted execute access to, but if I select one of them, it says I do not have permissions for that access and does not list any dirs. Since I can't see or expand the dirs, I cannot see any files. Could you provide me with your steps for reproducing this scenario?

marcindulak commented 1 year ago

The core is the case is that if a file, let's call it "file.txt", with -- ACL is present, a user can list the name of the file (confirm the file exists) by explicitly typing the "file.txt" in the storage explorer (for example by guessing, or enumerating all names). On the contrary, in order to list the presence of a directory the r-x ACL is needed.

It has been pointed out by Azure support that this behavior mimicks the behavior of POSIX filesystem permissions.

jimmart-dev commented 1 year ago

The core is the case is that if a file, let's call it "file.txt", with -- ACL is present, a user can list the name of the file (confirm the file exists) by explicitly typing the "file.txt" in the storage explorer (for example by guessing, or enumerating all names). On the contrary, in order to list the presence of a directory the r-x ACL is needed.

It has been pointed out by Azure support that this behavior mimicks the behavior of POSIX filesystem permissions.

Thanks for the feedback. I spoke with a support engineer who was able to reproduce the issue and I now have a better understanding of the scenario. I am going to complete a small matrix of testing to make sure I fully understand the scope of the issue, then I will engage with the product group to verify the observed behaviors and make doc changes as needed.

akashdubey-ms commented 7 months ago

Thanks for your contribution to our documentation

Unfortunately, we have been unable to review this issue in a timely manner. We sincerely apologize for the delayed response. We are closing this issue. If you feel that the problem persists, please respond to this issue with additional information. ? Please continue to provide feedback about the documentation. We appreciate your contributions to our community.

please-close