Azure Data Lake Storage Gen2 中的访问控制Access control in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 实现了一个访问控制模型,该模型支持 Azure 基于角色的访问控制 (Azure RBAC) 和类似 POSIX 的访问控制列表 (ACL)。Azure Data Lake Storage Gen2 implements an access control model that supports both Azure role-based access control (Azure RBAC) and POSIX-like access control lists (ACLs). 本文汇总了 Data Lake Storage Gen2 访问控制模型的基本知识。This article summarizes the basics of the access control model for Data Lake Storage Gen2.

基于角色的访问控制Role-based access control

RBAC 使用角色分配对服务主体有效地应用权限集。RBAC uses role assignments to effectively apply sets of permissions to security principals. 安全主体是一个对象,表示 Azure Active Directory (AD) 中定义的用于请求访问 Azure 资源的用户、组、服务主体或托管标识。A security principal is an object that represents a user, group, service principal, or managed identity that is defined in Azure Active Directory (AD) that is requesting access to Azure resources.

一般情况下,这些 Azure 资源限制为顶级资源(例如:Azure 存储帐户)。Typically, those Azure resources are constrained to top-level resources (For example: Azure Storage accounts). 就 Azure 存储以及随后的 Azure Data Lake Storage Gen2 而言,此机制已扩展到容器(文件系统)资源。In the case of Azure Storage, and consequently Azure Data Lake Storage Gen2, this mechanism has been extended to the container (file system) resource.

若要了解如何为存储帐户范围内的安全主体分配角色,请参阅在 Azure 门户中使用 RBAC 授予对 Azure blob 和队列数据的访问权限To learn how to assign roles to security principals in the scope of your storage account, see Grant access to Azure blob and queue data with RBAC in the Azure portal.

备注

来宾用户无法创建角色分配。A guest user can't create a role assignment.

角色分配对文件和目录级访问控制列表的影响The impact of role assignments on file and directory level access control lists

虽然使用 Azure 角色分配是一种强大的访问权限控制机制,但相对于 ACL,这种机制并不精细。While using Azure role assignments is a powerful mechanism to control access permissions, it is a very coarsely grained mechanism relative to ACLs. RBAC 的最小粒度在容器级别,其评估优先级高于 ACL。The smallest granularity for RBAC is at the container level and this will be evaluated at a higher priority than ACLs. 因此,如果将角色分配给容器范围内的某个安全主体,则无论 ACL 分配如何,该安全主体对于该容器中的所有目录和文件都具有与该角色关联的授权级别。Therefore, if you assign a role to a security principal in the scope of a container, that security principal has the authorization level associated with that role for ALL directories and files in that container, regardless of ACL assignments.

通过某个内置角色或某个自定义角色授予安全主体 RBAC 数据权限后,在授权请求时首先评估这些权限。When a security principal is granted RBAC data permissions through a built-in role, or through a custom role, these permissions are evaluated first upon authorization of a request. 如果请求的操作通过安全主体的 Azure 角色分配授权,则立即解析授权,不执行额外的 ACL 检查。If the requested operation is authorized by the security principal's Azure role assignments then authorization is immediately resolved and no additional ACL checks are performed. 或者,如果安全主体没有 Azure 角色分配或请求的操作与分配的权限不匹配,则通过执行 ACL 检查来确定安全主体是否有权执行请求的操作。Alternatively, if the security principal does not have an Azure role assignment, or the request's operation does not match the assigned permission, then ACL checks are performed to determine if the security principal is authorized to perform the requested operation.

备注

如果为安全主体分配了“存储 Blob 数据所有者”内置角色,则会将安全主体视为“超级用户”并向其授予对所有转变操作(包括设置目录或文件的所有者,以及设置他们不是所有者的目录或文件的 ACL)的完全访问权限。If the security principal has been assigned the Storage Blob Data Owner built-in role assignment, then the security principal is considered a super-user and is granted full access to all mutating operations, including setting the owner of a directory or file as well as ACLs for directories and files for which they are not the owner. 超级用户访问是唯一获准的更改资源所有者的方式。Super-user access is the only authorized manner to change the owner of a resource.

共享密钥和共享访问签名 (SAS) 身份验证Shared Key and Shared Access Signature (SAS) authentication

Azure Data Lake Storage Gen2 支持使用共享密钥和 SAS 方法进行身份验证。Azure Data Lake Storage Gen2 supports Shared Key and SAS methods for authentication. 这两种身份验证方法的特点是没有与调用方关联的标识,因此不能执行基于安全主体权限的身份验证。A characteristic of these authentication methods is that no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

就共享密钥这一种方法而言,调用方有效地获得了“超级用户”访问权限,这意味着对所有资源上所有操作(包括设置所有者和更高 ACL)的完全访问权限。In the case of Shared Key, the caller effectively gains 'super-user' access, meaning full access to all operations on all resources, including setting owner and changing ACLs.

SAS 令牌本身就包含允许的权限。SAS tokens include allowed permissions as part of the token. 它包含的权限有效地应用到所有授权决策,但不执行额外的 ACL 检查。The permissions included in the SAS token are effectively applied to all authorization decisions, but no additional ACL checks are performed.

文件和目录上的访问控制列表Access control lists on files and directories

可将安全主体关联到文件和目录的访问级别。You can associate a security principal with an access level for files and directories. 这些关联在访问控制列表 (ACL) 中捕获。These associations are captured in an access control list (ACL). 存储帐户中的每个文件和目录都有一个访问控制列表。Each file and directory in your storage account has an access control list.

备注

ACL 仅适用于同一租户中的安全主体。ACLs apply only to security principals in the same tenant.

如果在存储帐户级别将角色分配到某个安全主体,则可以使用访问控制列表授予该安全主体对特定文件和目录的提升访问权限。If you assigned a role to a security principal at the storage account-level, you can use access control lists to grant that security principal elevated access to specific files and directories.

无法使用访问控制列表来提供比角色分配授予的级别更低的访问级别。You can't use access control lists to provide a level of access that is lower than a level granted by a role assignment. 例如,如果将存储 Blob 数据参与者角色分配到了某个安全主体,则无法使用访问控制列表来防止该安全主体写入目录。For example, if you assign the Storage Blob Data Contributor role to a security principal, then you can't use access control lists to prevent that security principal from writing to a directory.

使用访问控制列表设置文件和目录级权限Set file and directory level permissions by using access control lists

若要设置文件和目录级权限,请参阅以下任一文章:To set file and directory level permissions, see any of the following articles:

环境Environment 项目Article
Azure 存储资源管理器Azure Storage Explorer 使用 Azure 存储资源管理器管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Azure Storage Explorer to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
.NET.NET 使用 .NET 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse .NET to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
JavaJava 使用 Java 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Java to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PythonPython 使用 Python 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Python to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PowerShellPowerShell 使用 PowerShell 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse PowerShell to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
Azure CLIAzure CLI 使用 Azure CLI 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Azure CLI to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
REST APIREST API 路径 - 更新Path - Update

重要

如果安全主体是服务主体,则必须使用该服务主体的对象 ID,而不能使用相关应用注册的对象 ID。If the security principal is a service principal, it's important to use the object ID of the service principal and not the object ID of the related app registration. 若要获取服务主体的对象 ID,请打开 Azure CLI,然后使用此命令:az ad sp show --id <Your App ID> --query objectIdTo get the object ID of the service principal open the Azure CLI, and then use this command: az ad sp show --id <Your App ID> --query objectId. 请务必将 <Your App ID> 占位符替换为应用注册的应用 ID。make sure to replace the <Your App ID> placeholder with the App ID of your app registration.

访问控制列表的类型Types of access control lists

访问控制列表有两种类型:访问 ACL 和默认 ACL。 There are two kinds of access control lists: access ACLs and default ACLs.

访问 ACL 控制对某个对象的访问权限。Access ACLs control access to an object. 文件和目录都具有访问 ACL。Files and directories both have access ACLs.

默认 ACL 是与目录关联的 ACL 模板,用于确定在该目录下创建的任何子项的访问 ACL。Default ACLs are templates of ACLs associated with a directory that determine the access ACLs for any child items that are created under that directory. 文件没有默认 ACL。Files do not have default ACLs.

访问 ACL 和默认 ACL 具有相同的结构。Both access ACLs and default ACLs have the same structure.

备注

更改父级的默认 ACL 不影响现有子项的访问 ACL 或默认 ACL。Changing the default ACL on a parent does not affect the access ACL or default ACL of child items that already exist.

权限级别Levels of permission

容器对象权限为“读取”、“写入”和“执行”,可对文件和目录使用这些权限,如下表所示: The permissions on a container object are Read, Write, and Execute, and they can be used on files and directories as shown in the following table:

文件File DirectoryDirectory
读取 (R)Read (R) 可以读取文件内容Can read the contents of a file 需有“读取”和“执行”权限才能列出目录内容 Requires Read and Execute to list the contents of the directory
写入 (W)Write (W) 可以在文件中写入或追加内容Can write or append to a file 需有“写入”和“执行”权限才能在目录中创建子项 Requires Write and Execute to create child items in a directory
执行 (X)Execute (X) 不表示 Data Lake Storage Gen2 上下文中的任何内容Does not mean anything in the context of Data Lake Storage Gen2 需要遍历目录的子项Required to traverse the child items of a directory

备注

如果仅使用 ACL(无 RBAC)授予权限,则要授予安全主体对文件的读取或写入访问权限,需要授予安全主体对容器以及通向该文件的文件夹层次结构中每个文件夹的“执行”权限。If you are granting permissions by using only ACLs (no RBAC), then to grant a security principal read or write access to a file, you'll need to give the security principal Execute permissions to the container, and to each folder in the hierarchy of folders that lead to the file.

权限的简短形式Short forms for permissions

RWX 用于表示“读取 + 写入 + 执行”。RWX is used to indicate Read + Write + Execute. 还有更精简的数字形式,“读取=4”,“写入=2”,“执行=1”,其总和表示各种不同的权限。 A more condensed numeric form exists in which Read=4, Write=2, and Execute=1, the sum of which represents the permissions. 下面是一些示例。Following are some examples.

数字形式Numeric form 简短形式Short form 含义What it means
77 RWX 读取 + 写入 + 执行Read + Write + Execute
55 R-X 读取 + 执行Read + Execute
44 R-- 读取Read
00 --- 无权限No permissions

权限继承Permissions inheritance

在 Data Lake Storage Gen2 使用的 POSIX 样式的模型中,项的权限存储在项本身中。In the POSIX-style model that's used by Data Lake Storage Gen2, permissions for an item are stored on the item itself. 换而言之,如果是在已创建子项后设置的权限,则不能从父项继承项的权限。In other words, permissions for an item cannot be inherited from the parent items if the permissions are set after the child item has already been created. 只有于创建子项前在父项上设置了默认权限时,才能继承权限。Permissions are only inherited if default permissions have been set on the parent items before the child items have been created.

下表列出了一些常见方案,可帮助你了解对存储帐户执行特定操作所需的权限。The following table lists some common scenarios to help you understand which permissions are needed to perform certain operations on a storage account.

操作Operation / Oregon/Oregon/ Portland/Portland/ Data.txtData.txt
Read Data.txtRead Data.txt --X --X --X R--
Append to Data.txtAppend to Data.txt --X --X --X RW-
Delete Data.txtDelete Data.txt --X --X -WX ---
Create Data.txtCreate Data.txt --X --X -WX ---
List /List / R-X --- --- ---
List /Oregon/List /Oregon/ --X R-X --- ---
List /Oregon/Portland/List /Oregon/Portland/ --X --X R-X ---

备注

只要以上两个条件成立,删除文件时就不需要文件的写入权限。Write permissions on the file are not required to delete it, so long as the previous two conditions are true.

用户和标识Users and identities

每个文件和目录都有这些标识的不同权限:Every file and directory has distinct permissions for these identities:

  • 拥有用户The owning user
  • 拥有组The owning group
  • 命名用户Named users
  • 命名组Named groups
  • 命名服务主体Named service principals
  • 命名托管标识Named managed identities
  • 所有其他用户All other users

用户和组的标识是 Azure Active Directory (Azure AD) 标识。The identities of users and groups are Azure Active Directory (Azure AD) identities. 因此,除非另有规定,否则“用户”在 Data Lake Storage Gen2 的上下文中可以表示 Azure AD 用户、服务主体、托管标识或安全组。So unless otherwise noted, a user, in the context of Data Lake Storage Gen2, can refer to an Azure AD user, service principal, managed identity, or security group.

拥有用户The owning user

创建项的用户自动成为该项的拥有用户。The user who created the item is automatically the owning user of the item. 拥有用户可以:An owning user can:

  • 更改所拥有文件的权限。Change the permissions of a file that is owned.
  • 更改所拥有文件的拥有组,前提是该拥有用户也是目标组的成员。Change the owning group of a file that is owned, as long as the owning user is also a member of the target group.

备注

拥有用户无法更改某个文件或目录的拥有用户。The owning user cannot change the owning user of a file or directory. 只有超级用户可以更改文件或目录的拥有用户。Only super-users can change the owning user of a file or directory.

拥有组The owning group

在 POSIX ACL 中,每个用户都与“主组”关联。In the POSIX ACLs, every user is associated with a primary group. 例如,用户“Alice”可能属于“finance”组。For example, user "Alice" might belong to the "finance" group. Alice 还可能属于多个组,但始终有一个组指定为她的主组。Alice might also belong to multiple groups, but one group is always designated as their primary group. 在 POSIX 中,当 Alice 创建文件时,该文件的拥有组设置为她的主组,在本例中为“finance”。In POSIX, when Alice creates a file, the owning group of that file is set to her primary group, which in this case is "finance." 否则,所有者组的行为类似于为其他用户/组分配的权限。The owning group otherwise behaves similarly to assigned permissions for other users/groups.

为新的文件或目录分配拥有组Assigning the owning group for a new file or directory
  • 情况 1:根目录“/”。Case 1: The root directory "/". 此目录是在创建 Data Lake Storage Gen2 容器时创建的。This directory is created when a Data Lake Storage Gen2 container is created. 在这种情况下,如果容器是使用 OAuth 创建的,则拥有组将设置为创建容器的用户。In this case, the owning group is set to the user who created the container if it was done using OAuth. 如果容器是使用共享密钥、帐户 SAS 或服务 SAS 创建的,则所有者和拥有组将设置为 $superuser。If the container is created using Shared Key, an Account SAS, or a Service SAS, then the owner and owning group are set to $superuser.
  • 情况 2(所有其他情况):创建新项时,从父目录复制拥有组。Case 2 (Every other case): When a new item is created, the owning group is copied from the parent directory.
更改拥有组Changing the owning group

拥有组可由以下用户更改:The owning group can be changed by:

  • 任何超级用户。Any super-users.
  • 拥有用户,前提是该拥有用户也是目标组的成员。The owning user, if the owning user is also a member of the target group.

备注

拥有组无法更改某个文件或目录的 ACL。The owning group cannot change the ACLs of a file or directory. 虽然拥有组设置为在根目录那一种情况(即上面的案例 1)中创建了帐户的用户,但单个用户帐户不能有效地用于通过拥有组提供权限。While the owning group is set to the user who created the account in the case of the root directory, Case 1 above, a single user account isn't valid for providing permissions via the owning group. 可以将此权限分配给有效的用户组(如果适用)。You can assign this permission to a valid user group if applicable.

访问检查算法Access check algorithm

以下伪代码显示了存储帐户的访问检查算法。The following pseudocode represents the access check algorithm for storage accounts.

def access_check( user, desired_perms, path ) : 
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

# Handle the owning user. Note that mask isn't used.
entry = get_acl_entry( path, OWNER )
if (user == entry.identity)
    return ( (desired_perms & entry.permissions) == desired_perms )

# Handle the named users. Note that mask IS used.
entries = get_acl_entries( path, NAMED_USER )
for entry in entries:
    if (user == entry.identity ) :
        mask = get_mask( path )
        return ( (desired_perms & entry.permissions & mask) == desired_perms)

# Handle named groups and owning group
member_count = 0
perms = 0
entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
mask = get_mask( path )
for entry in entries:
if (user_is_member_of_group(user, entry.identity)) :
    if ((desired_perms & entry.permissions & mask) == desired_perms)
        return True 
        
# Handle other
perms = get_perms_for_other(path)
mask = get_mask( path )
return ( (desired_perms & perms & mask ) == desired_perms)

掩码The mask

如访问检查算法中所示,掩码会限制对命名用户、拥有组和命名组的访问权限。As illustrated in the Access Check Algorithm, the mask limits access for named users, the owning group, and named groups.

备注

对于新的 Data Lake Storage Gen2 容器,根目录 ("/") 的访问 ACL 的掩码默认为 750(对于目录)和 640(对于文件)。For a new Data Lake Storage Gen2 container, the mask for the access ACL of the root directory ("/") defaults to 750 for directories and 640 for files. 文件不接收 X 位,因为它与只存储系统中的文件无关。Files do not receive the X bit as it is irrelevant to files in a store-only system.

可能会在每次调用时指定掩码。The mask may be specified on a per-call basis. 这就使不同的使用系统(例如群集)能够为文件操作使用不同的有效掩码。This allows different consuming systems, such as clusters, to have different effective masks for their file operations. 如果根据特定请求指定了掩码,则该掩码完全替代默认掩码。If a mask is specified on a given request, it completely overrides the default mask.

粘滞位The sticky bit

粘滞位是 POSIX 容器的更高级功能。The sticky bit is a more advanced feature of a POSIX container. 在 Data Lake Storage Gen2 的上下文中,不太可能需要粘滞位。In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. 总之,如果目录上已启用粘滞位,子项只能由子项的拥有用户删除或重命名。In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user.

粘滞位不会显示在 Azure 门户中。The sticky bit isn't shown in the Azure portal.

新文件和目录的默认权限Default permissions on new files and directories

在现有目录下创建新文件或目录时,父目录的默认 ACL 会确定:When a new file or directory is created under an existing directory, the default ACL on the parent directory determines:

  • 子目录的默认 ACL 和访问 ACL。A child directory's default ACL and access ACL.
  • 子文件的访问 ACL(文件没有默认 ACL)。A child file's access ACL (files do not have a default ACL).

umaskumask

创建文件或目录时,umask 用于修改默认 ACL 在子项上的设置方式。When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. umask 是父目录上一个 9 位的值,它包含“拥有用户”、“拥有组”和“其他”的 RWX 值 。umask is a 9-bit value on parent directories that contains an RWX value for owning user, owning group, and other.

Azure Data Lake Storage Gen2 的 umask 是设置为 007 的常量值。The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. 此值将转换为:This value translates to:

umask 组件umask component 数字形式Numeric form 简短形式Short form 含义Meaning
umask.owning_userumask.owning_user 00 --- 对于拥有用户,将父项的默认 ACL 复制到子项的访问 ACLFor owning user, copy the parent's default ACL to the child's access ACL
umask.owning_groupumask.owning_group 00 --- 对于拥有组,将父项的默认 ACL 复制到子项的访问 ACLFor owning group, copy the parent's default ACL to the child's access ACL
umask.otherumask.other 77 RWX 对于其他,删除子项的访问 ACL 的所有权限For other, remove all permissions on the child's access ACL

Azure Data Lake Storage Gen2 的 umask 值实际上表示无论默认 ACL 作何指示,默认情况下永远不会在新子项上传输“其他”的值。The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for other is never transmitted by default on new children, regardless of what the default ACL indicates.

以下伪代码显示了在为子项创建 ACL 时如何应用 umask。The following pseudocode shows how the umask is applied when creating the ACLs for a child item.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

有关 Data Lake Storage Gen2 中 ACL 的常见问题Common questions about ACLs in Data Lake Storage Gen2

是否必须启用 ACL 的支持?Do I have to enable support for ACLs?

否。No. 只要开启了分层命名空间 (HNS) 功能,存储帐户就能通过 ACL 进行访问控制。Access control via ACLs is enabled for a storage account as long as the Hierarchical Namespace (HNS) feature is turned ON.

即使关闭了 HNS 功能,Azure RBAC 授权规则仍适用。If HNS is turned OFF, the Azure RBAC authorization rules still apply.

应用 ACL 的最佳方式是什么?What is the best way to apply ACLs?

始终将 Azure AD 安全组用作 ACL 中分配的主体。Always use Azure AD security groups as the assigned principal in ACLs. 拒绝直接分配各个用户或服务主体。Resist the opportunity to directly assign individual users or service principals. 使用此结构,你可以添加和删除用户或服务主体,不需要向整个目录结构重新应用 ACL。Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. 而只需要从相应的 Azure AD 安全组添加或删除它们。Instead, you simply need to add or remove them from the appropriate Azure AD security group. 请记住,ACL 不是继承的,重新应用 ACL 需要更新每个文件和子目录上的 ACL。Keep in mind that ACLs are not inherited and so reapplying ACLs requires updating the ACL on every file and subdirectory.

以递归方式删除目录及其内容需要哪些权限?Which permissions are required to recursively delete a directory and its contents?

  • 调用方需要拥有“超级用户”权限,The caller has 'super-user' permissions,

Or

  • 父目录必须拥有“写入 + 执行”权限。The parent directory must have Write + Execute permissions.
  • 要删除的目录及其中的每个目录都需要“读取 + 写入 + 执行”权限。The directory to be deleted, and every directory within it, requires Read + Write + Execute permissions.

备注

删除目录中的文件不需要具有“写入”权限。You do not need Write permissions to delete files in directories. 另外,永远无法删除根目录“/”。Also, the root directory "/" can never be deleted.

谁是文件或目录的所有者?Who is the owner of a file or directory?

文件或目录的创建者就是所有者。The creator of a file or directory becomes the owner. 就根目录而言,这就是创建容器的用户的标识。In the case of the root directory, this is the identity of the user who created the container.

创建文件或目录时将哪个组设置为其拥有组?Which group is set as the owning group of a file or directory at creation?

拥有组是从创建新文件或目录的父目录的拥有组复制而来的。The owning group is copied from the owning group of the parent directory under which the new file or directory is created.

我是文件的拥有用户,但没有所需的 RWX 权限,I am the owning user of a file but I don't have the RWX permissions I need. 我该怎么办?What do I do?

拥有用户只需更改文件的权限,即可自动获得所需的任何 RWX 权限。The owning user can change the permissions of the file to give themselves any RWX permissions they need.

为什么我时候在 ACL 中看到了 GUID?Why do I sometimes see GUIDs in ACLs?

如果条目表示一个用户且该用户不再位于 Azure AD 中,则显示 GUID。A GUID is shown if the entry represents a user and that user doesn't exist in Azure AD anymore. 当用户离职,或者其帐户已在 Azure AD 中删除时,往往会发生这种情况。Usually this happens when the user has left the company or if their account has been deleted in Azure AD. 此外,服务主体和安全组没有用于标识它们的用户主体名称 (UPN),因此用它们的 OID 属性(即一个 GUID)来表示它们。Additionally, service principals and security groups do not have a User Principal Name (UPN) to identify them and so they are represented by their OID attribute (a guid).

如何为服务主体正确设置 ACL?How do I set ACLs correctly for a service principal?

为服务主体定义 ACL 时,必须使用所创建应用注册的服务主体的对象 ID (OID)。When you define ACLs for service principals, it's important to use the Object ID (OID) of the service principal for the app registration that you created. 请务必注意,注册的应用在特定的 Azure AD 租户中具有独立的服务主体。It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. 注册的应用会在 Azure 门户中显示一个 OID,但服务主体具有另一个(不同的)OID。Registered apps have an OID that's visible in the Azure portal, but the service principal has another (different) OID.

若要获取服务主体的对应于应用注册的 OID,可以使用 az ad sp show 命令。To get the OID for the service principal that corresponds to an app registration, you can use the az ad sp show command. 指定应用程序 ID 作为参数。Specify the Application ID as the parameter. 以下示例获取服务主体的 OID,该 OID 对应于应用 ID 为 18218b12-1895-43e9-ad80-6e8fc1ea88ce 的应用注册。Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. 在 Azure CLI 中运行以下命令:Run the following command in the Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

随即显示 OID。OID will be displayed.

获取服务主体的正确 OID 后,转到存储资源管理器的“管理访问权限”页,以添加该 OID 并为其分配适当的的权限。When you have the correct OID for the service principal, go to the Storage Explorer Manage Access page to add the OID and assign appropriate permissions for the OID. 请务必选择“保存”。Make sure you select Save.

Data Lake Storage Gen2 是否支持 ACL 继承?Does Data Lake Storage Gen2 support inheritance of ACLs?

Azure 角色分配确实可以继承。Azure role assignments do inherit. 分配从订阅、资源组和存储帐户资源向下传递到容器资源。Assignments flow from subscription, resource group, and storage account resources down to the container resource.

ACL 不支持继承。ACLs do not inherit. 但是,可以使用默认 ACL 来设置父目录下创建的子目录和文件的 ACL。However, default ACLs can be used to set ACLs for child subdirectories and files created under the parent directory.

在哪里可以了解 POSIX 访问控制模型的详细信息?Where can I learn more about POSIX access control model?

另请参阅See also