This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent networking discussions on controlled folder access. In this article, we review the access control lists for Azure Data Lake Storage Gen 2.

The access control model in Azure Data Lake storage gen 2 supports both Azure role-based access control (Azure RBAC) and POSIX like access control lists (ACL). The shared key and SAS authorization grants access to a user without requiring them to have an identity in Azure Active Directory (Azure AD). When these are used, the Azure RBAC and ACLs have no effect. Only when there is an identity in Azure AD, can the Azure RBAC and ACL be used. The

Azure RBAC and ACL both require the user (or application) to have an identity in Azure AD. Azure RBAC gives broad and sweeping access to storage account data, such as read or write access to all the data in a storage account, while ACLs is for granting privilege at a finer level where the write access must be to a specific directory or file. The evaluation of RBAC and ACL for authorization decisions is not static. The access control lists, and policy resolution artifacts are static but the evaluation of the identity and its permissions for an identity context is dynamic. It can even involve composition and inheritance. It can allow dynamic assignment of users to roles. So, when a person leaves an organization and goes to another, then a scheduled background job can revoke the privileges and perform cleanup.

Users are mapped via policies to roles, and they are granted different level of access to different resources. The permissions can vary with owner_read, owner_write, owner_delete, group_read, group_write, group_delete, other_read, other_write and other_delete which along with the other state for granted or revoked. The purpose of specifying privilege is that we only need to grant on a need basis. Role-based access control (RBAC) facilitates principle of least privilege. A higher privilege role such as the domain administrator need not be used to work with AD connect or for deployment purposes. A deployment operator is sufficient in this regard.

Role based access control also enforce the most restrictive permission set so a general ability to read can be taken away for specific cases.

When it comes to securing KeyVaults and Storage accounts. The access control policies are the resorted technique. On the contrary, the role-based access control is less maintenance. There is no need to keep adding and removing conditional access polices from the KeyVault because they end up being transient even if they are persisted. Instead, the role-based access control for KeyVault requires zero-touch and automatically flows to all items in the vault.

An Access Control List consists of several entries called Access control lists. It can have zero or more ACEs. Each ACE controls or monitors access to an object by a specified trustee. There are six types of ACEs three of which are general purpose and applicable to all while the other three object-specific ACEs. Every ACE has a security identifier part that identifies the trustee, an access mask that specifies the access rights and a flag that indicates the ACE type and a set of bit flags that determine whether the child container or objects can inherit the ACE from the primary object to the which the ACL is attached. The general-purpose ACEs includes an access-denied ACE which is used in discretionary access control list, an access-allowed ACE which is used to allow access rights to a trustee and a system-audit ACE which is used in a System Access Control List. The special purpose ACEs carry an object type GUID that identifies one of the following: a type of child object, a property set or property, an extended right, and a validated write.

The Active Directory contains two policy objects called a centralized authorization policy (cap) and a centralized authorization policy rule (capr). These polices are based on expressions of claims and resource attributes. Capr targets specific resources and articulates the access control to satisfy a condition. Capes apply to an organization where the set of resource to which it applies can be called out. It is a collection of caprs that can be applied together. A user folder will have a specific cap comprising of several caprs and there will be a similar new cap for assignment to the finance folder.

 

This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent networking discussions on controlled folder access. In this article, we review the access control lists for Azure Data Lake Storage Gen 2.

The access control model in Azure Data Lake storage gen 2 supports both Azure role-based access control (Azure RBAC) and POSIX like access control lists (ACL). The shared key and SAS authorization grants access to a user without requiring them to have an identity in Azure Active Directory (Azure AD). When these are used, the Azure RBAC and ACLs have no effect. Only when there is an identity in Azure AD, can the Azure RBAC and ACL be used. The

Azure RBAC and ACL both require the user (or application) to have an identity in Azure AD. Azure RBAC gives broad and sweeping access to storage account data, such as read or write access to all the data in a storage account, while ACLs is for granting privilege at a finer level where the write access must be to a specific directory or file. The evaluation of RBAC and ACL for authorization decisions is not static. The access control lists, and policy resolution artifacts are static but the evaluation of the identity and its permissions for an identity context is dynamic. It can even involve composition and inheritance. It can allow dynamic assignment of users to roles. So, when a person leaves an organization and goes to another, then a scheduled background job can revoke the privileges and perform cleanup.

Users are mapped via policies to roles, and they are granted different level of access to different resources. The permissions can vary with owner_read, owner_write, owner_delete, group_read, group_write, group_delete, other_read, other_write and other_delete which along with the other state for granted or revoked. The purpose of specifying privilege is that we only need to grant on a need basis. Role-based access control (RBAC) facilitates principle of least privilege. A higher privilege role such as the domain administrator need not be used to work with AD connect or for deployment purposes. A deployment operator is sufficient in this regard.

Role based access control also enforce the most restrictive permission set so a general ability to read can be taken away for specific cases.

When it comes to securing KeyVaults and Storage accounts. The access control policies are the resorted technique. On the contrary, the role-based access control is less maintenance. There is no need to keep adding and removing conditional access polices from the KeyVault because they end up being transient even if they are persisted. Instead, the role-based access control for KeyVault requires zero-touch and automatically flows to all items in the vault.

An Access Control List consists of several entries called Access control lists. It can have zero or more ACEs. Each ACE controls or monitors access to an object by a specified trustee. There are six types of ACEs three of which are general purpose and applicable to all while the other three object-specific ACEs. Every ACE has a security identifier part that identifies the trustee, an access mask that specifies the access rights and a flag that indicates the ACE type and a set of bit flags that determine whether the child container or objects can inherit the ACE from the primary object to the which the ACL is attached. The general-purpose ACEs includes an access-denied ACE which is used in discretionary access control list, an access-allowed ACE which is used to allow access rights to a trustee and a system-audit ACE which is used in a System Access Control List. The special purpose ACEs carry an object type GUID that identifies one of the following: a type of child object, a property set or property, an extended right, and a validated write.

The Active Directory contains two policy objects called a centralized authorization policy (cap) and a centralized authorization policy rule (capr). These polices are based on expressions of claims and resource attributes. Capr targets specific resources and articulates the access control to satisfy a condition. Capes apply to an organization where the set of resource to which it applies can be called out. It is a collection of caprs that can be applied together. A user folder will have a specific cap comprising of several caprs and there will be a similar new cap for assignment to the finance folder.