Merge pull request #229281 from jimmart-dev/jammart-storage-abac-perms-eval

storage abac and acl permissions evaluation

Author: PMEds28

articles/storage/blobs/data-lake-storage-access-control-model.md

@@ -7,7 +7,7 @@ author: jimmart-dev
 ms.subservice: data-lake-storage-gen2
 ms.service: storage
 ms.topic: conceptual
-ms.date: 02/17/2021
+ms.date: 03/07/2023
 ms.author: jammart
 ---
 
@@ -18,13 +18,14 @@ Data Lake Storage Gen2 supports the following authorization mechanisms:
 - Shared Key authorization
 - Shared access signature (SAS) authorization
 - Role-based access control (Azure RBAC)
+- Attribute-based access control (Azure ABAC)
 - Access control lists (ACL)
 
-[Shared Key and SAS authorization](#shared-key-and-shared-access-signature-sas-authorization) grants access to a user (or application) without requiring them to have an identity in Azure Active Directory (Azure AD). With these two forms of authentication, Azure RBAC and ACLs have no effect.
+[Shared Key and SAS authorization](#shared-key-and-shared-access-signature-sas-authorization) grants access to a user (or application) without requiring them to have an identity in Azure Active Directory (Azure AD). With these two forms of authentication, Azure RBAC, Azure ABAC, and ACLs have no effect.
 
-Azure RBAC and ACL both require the user (or application) to have an identity in Azure AD. Azure RBAC lets you grant "coarse-grain" access to storage account data, such as read or write access to **all** of the data in a storage account, while ACLs let you grant "fine-grained" access, such as write access to a specific directory or file.
+Azure RBAC and ACL both require the user (or application) to have an identity in Azure AD. Azure RBAC lets you grant "coarse-grain" access to storage account data, such as read or write access to **all** of the data in a storage account. Azure ABAC allows you to refine RBAC role assignments by adding conditions. For example, you can grant read or write access to all data objects in a storage account that have a specific tag. ACLs let you grant "fine-grained" access, such as write access to a specific directory or file.
 
-This article focuses on Azure RBAC and ACLs, and how the system evaluates them together to make authorization decisions for storage account resources.
+This article focuses on Azure RBAC, ABAC, and ACLs, and how the system evaluates them together to make authorization decisions for storage account resources.
 
 <a id="role-based-access-control"></a>
 
@@ -42,24 +43,38 @@ The following roles permit a security principal to access data in a storage acco
 
 Roles such as [Owner](../../role-based-access-control/built-in-roles.md#owner), [Contributor](../../role-based-access-control/built-in-roles.md#contributor), [Reader](../../role-based-access-control/built-in-roles.md#reader), and [Storage Account Contributor](../../role-based-access-control/built-in-roles.md#storage-account-contributor) permit a security principal to manage a storage account, but do not provide access to the data within that account. However, these roles (excluding **Reader**) can obtain access to the storage keys, which can be used in various client tools to access the data.
 
-## Access control lists (ACLs)
+## Attribute-based access control (Azure ABAC)
 
-ACLs give you the ability to apply "finer grain" level of access to directories and files. An *ACL* is a permission construct that contains a series of *ACL entries*. Each ACL entry associates security principal with an access level. To learn more, see [Access control lists (ACLs) in Azure Data Lake Storage Gen2](data-lake-storage-access-control.md).
+Azure ABAC builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more refined access control. You cannot explicitly deny access to specific resources using conditions.
 
-## How permissions are evaluated
+For more information on using Azure ABAC to control access to Azure Storage, see [Authorize access to Azure Blob Storage using Azure role assignment conditions](storage-auth-abac.md).
+
+For the status of attributes applicable to Data Lake Storage Gen2, see [Status of condition features in Azure Storage](../common/authorize-data-access.md#status-of-condition-features-in-azure-storage).
 
-During security principal-based authorization, permissions are evaluated in the following order.
+## Access control lists (ACLs)
 
-:one:&nbsp;&nbsp; Azure role assignments are evaluated first and take priority over any ACL assignments.
+ACLs give you the ability to apply "finer grain" level of access to directories and files. An *ACL* is a permission construct that contains a series of *ACL entries*. Each ACL entry associates security principal with an access level. To learn more, see [Access control lists (ACLs) in Azure Data Lake Storage Gen2](data-lake-storage-access-control.md).
 
-:two:&nbsp;&nbsp; If the operation is fully authorized based on Azure role assignment, then ACLs are not evaluated at all.
+## How permissions are evaluated
 
-:three:&nbsp;&nbsp; If the operation is not fully authorized, then ACLs are evaluated.
+During security principal-based authorization, permissions are evaluated as shown in the following diagram.
 
 > [!div class="mx-imgBorder"]
 > ![data lake storage permission flow](./media/control-access-permissions-data-lake-storage/data-lake-storage-permissions-flow.png)
 
-Because of the way that access permissions are evaluated by the system, you **cannot** use an ACL to **restrict** access that has already been granted by a role assignment. That's because the system evaluates Azure role assignments first, and if the assignment grants sufficient access permission, ACLs are ignored.
+1. Azure determines whether a role assignment exists for the principal.
+    - If a role assignment exists, the role assignment conditions (2) are evaluated next.
+    - If not, the ACLs (3) are evaluated next.
+1. Azure determines whether all of the ABAC role assignment conditions, if any exist, match the attributes of the request.
+    - If no conditions exist, access is granted.
+    - If conditions exist and all of them match the attributes of the request, access is granted.
+    - If conditions exist and at least one of them does not match the attributes of the request, the ACLs (3) are evaluated next.
+1. If access has not been explicitly granted after evaluating the role assignments and conditions, the ACLs are evaluated.
+    - If the ACLs permit the requested level of access, access is granted.
+    - If not, access is denied.
+
+> [!IMPORTANT]
+> Because of the way that access permissions are evaluated by the system, you **cannot** use an ACL to **restrict** access that has already been granted by a role assignment and its conditions. That's because the system evaluates Azure role assignments and conditions first, and if the assignment grants sufficient access permission, ACLs are ignored.
 
 The following diagram shows the permission flow for three common operations: listing directory contents, reading a file, and writing a file.
 
@@ -68,10 +83,10 @@ The following diagram shows the permission flow for three common operations: lis
 
 ## Permissions table: Combining Azure RBAC and ACL
 
-The following table shows you how to combine Azure roles and ACL entries so that a security principal can perform the operations listed in the **Operation** column. This table shows a column that represents each level of a fictitious directory hierarchy. There's a column for the root directory of the container (`/`), a subdirectory named **Oregon**, a subdirectory of the Oregon directory named **Portland**, and a text file in the Portland directory named **Data.txt**. Appearing in those columns are [short form](data-lake-storage-access-control.md#short-forms-for-permissions) representations of the ACL entry required to grant permissions. **N/A** (_Not applicable_) appears in the column if an ACL entry is not required to perform the operation.
+The following table shows you how to combine Azure roles, conditions, and ACL entries so that a security principal can perform the operations listed in the **Operation** column. This table shows a column that represents each level of a fictitious directory hierarchy. There's a column for the root directory of the container (`/`), a subdirectory named **Oregon**, a subdirectory of the Oregon directory named **Portland**, and a text file in the Portland directory named **Data.txt**. Appearing in those columns are [short form](data-lake-storage-access-control.md#short-forms-for-permissions) representations of the ACL entry required to grant permissions. **N/A** (_Not applicable_) appears in the column if an ACL entry is not required to perform the operation.
 
-|    Operation             | Assigned Azure role               |    /        | Oregon/     | Portland/ | Data.txt |
-|--------------------------|----------------------------------|-------------|-------------|-----------|----------|
+| Operation                | Assigned Azure role (with or without conditions) | /        | Oregon/  | Portland/ | Data.txt |
+|--------------------------|----------------------------------|----------|----------|-----------|----------|
 | Read Data.txt            |   Storage Blob Data Owner        | N/A      | N/A      | N/A       | N/A    |
 |                          |   Storage Blob Data Contributor  | N/A      | N/A      | N/A       | N/A    |
 |                          |   Storage Blob Data Reader       | N/A      | N/A      | N/A       | N/A    |