红帽全球峰会3.5. 基于角色的访问控制
基于角色的访问控制的基础知识涵盖了 基于角色的访问控制，以及将 RBAC 添加到 JBoss EAP 安全架构指南中的 管理界面部分。
3.5.1. 启用基于角色的访问控制
默认情况下禁用基于角色的访问控制(RBAC)系统。它通过将 provider 属性从 simple 改为 rbac 来启用。provider 是 management 元素的 access-control 元素的属性。这可通过管理 CLI 或编辑服务器配置 XML 文件（如果服务器离线）完成。当在运行的服务器上禁用或启用 RBAC 时，必须重新加载服务器配置才能生效。
在将供应商更改为 rbac 之前，请确保您的配置具有映射到其中一个 RBAC 角色的用户，最好拥有至少一个 Administrator 或 SuperUser 角色。除关闭并编辑 XML 配置外，否则您的安装将无法管理。如果您使用 JBoss EAP 附带的一个标准 XML 配置启动，$ 用户将映射到 local SuperUser 角色，并且将启用本地身份验证方案。这将允许用户在与 JBoss EAP 进程相同的系统上运行 CLI，具有完整的管理权限。远程 CLI 用户和基于 Web 的管理控制台用户将没有权限。
建议在将提供程序切换到 rbac 之前，至少映射一个用户，而不是 $local。您可以执行与 rbac 提供程序关联的所有配置，即使提供程序设置为 simple。
启用后，只能被具有 Administrator 或 SuperUser 角色的用户禁用。默认情况下，如果管理 CLI 与服务器在同一计算机上运行，则作为 SuperUser 角色运行。
启用 RBAC 的 CLI
要使用管理 CLI 启用 RBAC，请使用访问授权资源的 write-attribute 操作将 provider 属性设置为 rbac。
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
reload在受管域中，访问控制配置是域范围内的配置的一部分，因此资源地址与上述相同，但管理 CLI 连接到主域控制器。
/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
},
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => {
"server-one" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}},
"server-two" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}}
}}}}
}
reload --host=master与单机服务器一样，需要重新加载或重启才能使更改生效。在受管域中，域中的所有主机和服务器都需要重新加载或重启，自主域控制器开始。
管理 CLI 命令以禁用 RBAC
要使用管理 CLI 禁用 RBAC，请使用访问授权资源的 write-attribute 操作将 provider 属性设置为 simple。
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)用于启用或禁用 RBAC 的 XML 配置
如果服务器离线，则编辑 XML 配置以启用或禁用 RBAC。为此，请编辑 management 元素的 access-control 元素的 provider 属性。将值设为 rbac 以启用，而 simple 设置为 disable。
示例：启用或禁用 RBAC 的 XML 配置
<management>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
</include>
</role>
</role-mapping>
</access-control>
</management>3.5.2. 更改权限组合策略
权限组合策略决定如何确定用户是否分配多个角色。这可设置为 permissive 或 reject。默认值为 permissive。
当设置为 permissive 时，如果将任何角色分配给允许某一操作的用户，则允许该操作。
当设置为 拒绝 时，如果为某个用户分配多个角色，则不操作。这意味着，当将策略设置为拒绝每个用户时，应仅分配一个角色。当策略设置为拒绝时，具有多个角色的用户无法使用管理控制台或管理 CLI。
权限组合策略通过将 permission-combination-policy 属性设置为 permissive 或 rejecting 来进行配置。这可通过管理 CLI 或编辑服务器配置 XML 文件（如果服务器离线）完成。permission-combination-policy 属性是 access-control 元素的一部分，而 access-control 元素可在 management 元素中找到。
设置权限组合策略
使用访问授权资源的 write-attribute 操作将 permission-combination-policy 属性设置为所需的策略名称。
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
有效的策略名称是 reject 和 permissive。
示例：拒绝权限组合策略的管理 CLI 命令
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
如果服务器离线，可以编辑 XML 配置以更改权限组合策略值。为此，请编辑 access-control 元素的 permission-combination-policy 属性。
示例：拒绝权限组合策略的 XML 配置
<access-control provider="rbac" permission-combination-policy="rejecting">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
</include>
</role>
</role-mapping>
</access-control>3.5.3. 管理角色
启用基于角色的访问控制(RBAC)时，允许什么管理用户由向用户分配的角色决定。JBoss EAP 7 使用 中的系统 includes 和 excludes，它基于用户和组成员资格来确定用户所属的角色。
如果用户被视为一个角色，则用户被视为被分配给角色：
- 列出为要包含在角色中的用户，或者
- 列在角色中的组的成员。
如果用户不是，则用户也被视为被分配给角色：
- 列为从角色中排除的用户，或者
- 列出角色中排除的组的成员。
排除的优先级高于包含项。
可以使用管理控制台和管理 CLI 配置用户和组的角色包含和排除设置。
只有 SuperUser 或 Administrator 角色的用户才能执行此配置。
3.5.3.1. 使用管理 CLI 配置用户角色分配
将用户和组映射到角色的配置位于： /core-service=management/access=authorization 作为 role-mapping 元素。
只有 SuperUser 或 Administrator 角色的用户才能执行此配置。
查看角色分配配置
使用 :read-children-names 操作获取配置的角色的完整列表：
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
"outcome" => "success",
"result" => [
"Administrator",
"Deployer",
"Maintainer",
"Monitor",
"Operator",
"SuperUser"
]
}
使用指定 role-mapping 的 read-resource 操作获取特定角色的完整详情：
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"include-all" => false,
"exclude" => undefined,
"include" => {
"user-theboss" => {
"name" => "theboss",
"realm" => undefined,
"type" => "USER"
},
"user-harold" => {
"name" => "harold",
"realm" => undefined,
"type" => "USER"
},
"group-SysOps" => {
"name" => "SysOps",
"realm" => undefined,
"type" => "GROUP"
}
}
}
}添加新角色
此流程演示了如何为角色添加 role-mapping 条目。这必须在配置角色前完成。
使用 add 操作来添加新角色配置。
/core-service=management/access=authorization/role-mapping=ROLENAME:add
ROLENAME 是新映射的角色的名称，如 Auditor。
示例：管理CLI命令以进行新角色配置
/core-service=management/access=authorization/role-mapping=Auditor:add添加角色中包括的用户
此流程演示了如何将用户添加到包含角色列表中。
如果没有进行任何角色配置，则必须首先执行角色映射条目。
使用 add 操作向包含角色列表添加用户条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
ALIAS 是该映射的唯一名称。红帽建议将命名规则用于别名，如
user-USERNAME（例如user-max）。 -
USERNAME 是添加到 include 列表中的用户的名称，如
max。
示例：角色中包含的用户管理 CLI 命令
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)将用户添加到角色中已排除用户
此流程演示了如何将用户添加到角色的排除列表中。
如果没有进行任何角色配置，则必须首先执行角色映射条目。
使用 add 操作将用户条目添加到角色的 excludes 列表中。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)-
ROLENAME 是配置的角色的名称，如
Auditor。 -
USERNAME 是添加到 exclude 列表中的用户的名称，如
max。 -
ALIAS 是该映射的唯一名称。红帽建议将命名规则用于别名，如
user-USERNAME（例如user-max）。
示例：在一个角色中没有管理 CLI 命令用户
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)删除用户角色包含配置
此流程演示了如何删除用户包含角色映射的条目。
使用 remove 操作来删除该条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
ALIAS 是该映射的唯一名称。红帽建议将命名规则用于别名，如
user-USERNAME（例如user-max）。
示例：删除用户角色的管理 CLI 命令包含配置
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove从 includes 列表中删除用户不会从系统中删除用户，也不保证该角色不会分配给该用户。该角色可能仍然根据组成员资格来分配。
删除用户角色独到配置
此流程演示了如何从角色映射中删除用户排除条目。
使用 remove 操作来删除该条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
ALIAS 是该映射的唯一名称。红帽建议将命名规则用于别名，如
user-USERNAME（例如user-max）。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove从 excludes 列表中删除用户不会从系统中删除用户，也不保证该角色将被分配给该用户。角色可能仍然会根据组成员资格排除。
3.5.4. 使用 Elytron subsystem 配置用户角色分配
除了直接为用户添加角色映射外，如 管理角色 部分所述，您还可以配置 RBAC 角色，以直接从 elytron 子系统提供的身份获取。
配置 RBAC 系统以使用 elytron 子系统提供的角色：
/core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)必须启用 RBAC 来使用这个功能，并且主体必须具有 RBAC 角色。
3.5.5. 角色和用户组
用户组是一个任意标签，可分配给一个或多个用户。使用管理接口进行身份验证时，会根据管理界面如何保护用户，从 elytron 子系统或核心管理身份验证中分配组。RBAC 系统可以配置为根据他们所属的用户组自动为用户分配角色。它还可根据组成员资格从角色中排除用户。
3.5.6. 使用管理 CLI 配置组角色分配
在管理控制台和管理 CLI 中，可以在角色中包含或排除的组。本主题仅显示使用管理 CLI。
将用户和组映射到角色的配置位于管理 API 中，地址为： /core-service=management/access=authorization 作为 role-mapping 元素。
只有 SuperUser 或 Administrator 角色的用户才能执行此配置。
查看组角色分配配置
使用 read- Child-names 操作获取配置的角色的完整列表：
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
"outcome" => "success",
"result" => [
"Administrator",
"Deployer",
"Maintainer",
"Monitor",
"Operator",
"SuperUser"
]
}
使用指定 role-mapping 的 read-resource 操作获取特定角色的完整详情：
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"include-all" => false,
"exclude" => undefined,
"include" => {
"user-theboss" => {
"name" => "theboss",
"realm" => undefined,
"type" => "USER"
},
"user-harold" => {
"name" => "harold",
"realm" => undefined,
"type" => "USER"
},
"group-SysOps" => {
"name" => "SysOps",
"realm" => undefined,
"type" => "GROUP"
}
}
}
}添加新角色
此流程演示了如何为角色添加 role-mapping 条目。这必须在配置角色前完成。
使用 add 操作来添加新角色配置。
/core-service=management/access=authorization/role-mapping=ROLENAME:add添加角色中包括的组
此流程演示了如何在角色包含列表中添加组。
如果没有进行任何角色配置，则必须首先执行角色映射条目。
使用 add 操作向包含角色列表添加组条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
GROUPNAME 是添加到 include 列表中的组的名称，如
investigators。 -
ALIAS 是该映射的唯一名称。红帽建议为您的别名使用命名规则，如
group-GROUPNAME（例如：group-investigators）。
示例：将组添加到角色中的管理 CLI 命令
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)将组添加到角色中除外
此流程演示了如何在角色排除列表中添加组。
如果没有进行任何角色配置，则必须首先创建角色映射条目。
使用 add 操作将组条目添加到角色的 excludes 列表中。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
GROUPNAME 是添加到 include 列表中的组的名称，如
supervisors。 -
ALIAS 是该映射的唯一名称。红帽建议为您的别名使用命名规则，如
group-GROUPNAME（例如：group-supervisors）。
示例：将组添加到角色中的管理 CLI 命令
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)删除组角色包含配置
此流程演示了如何删除组包括角色映射的条目。
使用 remove 操作来删除该条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
ALIAS 是该映射的唯一名称。红帽建议为您的别名使用命名规则，如
group-GROUPNAME（例如：group-investigators）。
示例：删除组角色的管理 CLI 命令包含配置
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove从 includes 列表中删除组不会从系统中删除组，也不保证该角色不会分配给此组中的用户。该角色可能仍然单独分配给组中的用户。
删除 User Group Exclude Entry
此流程演示了如何从角色映射中删除组排除条目。
使用 remove 操作来删除该条目。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove-
ROLENAME 是所配置的角色的名称，如
Auditor。 -
ALIAS 是该映射的唯一名称。红帽建议为您的别名使用命名规则，如
group-GROUPNAME（例如：group-supervisors）。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove从 excludes 列表中删除组不会从系统中删除组。它也不保证该角色将被分配给组的成员。角色可能仍然会根据组成员资格排除。
3.5.7. 通过 LDAP 使用 RBAC
介绍了将 RBAC 与 LDAP 搭配使用的基础知识，以及如何将 JBoss EAP 与 LDAP 搭配使用 RBAC 阐述在 JBoss EAP 如何配置身份管理指南中的 LDAP 和 RBAC 部分。
3.5.8. 有范围角色
有作用域角色是用户定义的角色，可授予其中一个标准角色的权限，但仅对 JBoss EAP 受管域中的一个或多个指定的服务器组或主机授予。通过有作用域角色，可以允许管理用户将权限授予限制那些仅需要那些服务器组或主机的权限。
可为分配了 Administrator 或 SuperUser 角色的用户创建作用域角色。
它们由五个特征定义：
- 唯一的名称。
- 它要基于的标准角色。
- 如果它适用于服务器组或主机。
- 仅限于的服务器组或主机的列表。
-
如果所有用户被自动包含。默认值为
false。
创建范围的角色后，可以按照与标准角色相同的方式分配给用户和组。
创建全范围角色不允许定义新权限。有作用域角色只能用于在有限范围内应用现有角色的权限。例如，可以基于 restricted 到单个服务器组的 Deployer 角色创建范围的角色。
角色只能限制以下两范围：
- 主机范围内的角色
-
主机作用域的角色将该角色的权限限制为一个或多个主机。这意味着，可以访问相关的
/host=*/资源树，但特定于其他主机的资源会被隐藏。 - server-group-scoped 角色
- 即 server-group 范围的角色将该角色的权限限制为一个或多个服务器组。此外，角色权限也适用于与指定 server-groups 关联的 profile、套接字绑定组、服务器配置和服务器资源。任何与 server-group 相关的子资源都不会对用户可见。
有些资源无法被 server-group 和 host 范围角色提供简化的管理视图，以提高可用性。这与无法被寻址的资源不同，从而保护敏感数据。
对于 主机 范围的角色，这意味着如果它们与角色指定的服务器组无关，则管理模型中的 /host=* 部分中的资源将不可见。
对于 server-group scoped 角色，这意味着 配置文件 中的资源、socket-binding-group、部署、Deployment-overlayserver-group、server-config 和 server 部分（如果与为角色指定的服务器组无关）将无法看到。
3.5.8.1. 通过管理 CLI 配置范围角色
只有 SuperUser 或 Administrator 角色的用户才能执行此配置。
添加新的范围角色
要添加新的范围的角色，必须执行以下操作：
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])将 NEW-SCOPED-ROLE、BASE-ROLE 和 SERVER-GROUP-NAME 替换为正确的信息。
查看并编辑范围角色映射
使用以下命令可以查看有范围的角色详情，包括成员：
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)用正确的信息替换 NEW-SCOPED-ROLE。
要编辑有范围的角色详情，可以使用 write-attribute 命令。例如：
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)用正确的信息替换 NEW-SCOPED-ROLE。
删除范围角色
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove用正确的信息替换 NEW-SCOPED-ROLE。
如果分配了用户或组，则无法删除有范围的角色。首先删除角色分配，然后删除它。
添加和删除用户
向范围角色添加和删除用户与 添加和删除标准角色 的过程相同。
3.5.8.2. 从管理控制台配置范围角色
只有 SuperUser 或 Administrator 角色的用户才能执行此配置。
可以通过下列步骤在管理控制台中找到作用域角色配置：
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 单击 Roles 以查看所有角色，包括范围角色。
以下流程描述了如何为有范围角色执行配置任务。
添加新的范围角色
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 选择 Roles，点 Add (+) 按钮。
- 选择主机范围角色或 服务器组范围角色。
指定以下详情：
- Name ：新 scoped 角色的唯一名称。
- 基本角色 ：此角色将对其权限进行基础的角色。
- Host 或 Server Groups ：根据添加的范围角色类型，角色限制的主机或服务器组列表。可以选择多个条目。
-
Include All: 此角色应该自动包含所有用户。默认值为
OFF。
- 点 Add 以创建新角色。
编辑范围角色
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 点左侧的 Roles 菜单。
- 点所需范围的角色来编辑，然后点 编辑。
- 更新所需详情以更改并单击 保存按钮。
查看范围角色成员
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 点左侧的 Roles 菜单。
- 单击所需范围的角色，以查看包含和排除的成员。
删除范围角色
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 点左侧的 Roles 菜单。
- 点所需范围的角色，从下拉列表中点击 Remove。
- 点 Yes 以删除角色及其所有分配。
添加和删除用户
向范围角色添加和删除用户与添加和删除标准角色的过程相同。更新用户的作用域角色：
- 登录到管理控制台。
- 点 Access Control 选项卡。
- 点左侧的 Roles 菜单，再点所需范围角色。
- 选择 Plus(+)按钮，使其包含成员或要排除成员的减号(-)按钮。
3.5.9. 配置限制
3.5.9.1. 配置敏感限制
每个敏感度约束都定义了一组被视为 敏感的 资源。敏感的 资源通常应该是 secret（如密码）或对服务器有严重影响的资源，如网络、JVM 配置或系统属性。访问控制系统本身也被视为敏感。资源敏感度限制哪些角色能够读取、写入或处理特定资源。
sensitivity 约束配置为 /core-service=management/access=authorization/constraint=sensitivity-classification。
在管理模型中，每个敏感度约束都被识别为分类。然后分类被分成不同的类型。每个分类都有 应用到 元素，它是分类配置适用的路径模式列表。
要配置敏感度约束，请使用 write-attribute 操作设置 configured-requires-read、configure-requires-write 或 configured-requires-addressable 属性。要使该操作类型敏感，请将属性的值设置为 true，否则将其非敏感性设置为 false。默认情况下，这些属性不会被设置，并且使用 default-requires-read、default-requires-write 和 default-requires-addressable 的值。设置配置的属性后，它会使用该值而不是默认值。无法更改默认值。
示例：让读取系统属性成为敏感操作
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)示例：Result
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource{
"outcome" => "success",
"result" => {
"configured-requires-addressable" => undefined,
"configured-requires-read" => true,
"configured-requires-write" => undefined,
"default-requires-addressable" => false,
"default-requires-read" => false,
"default-requires-write" => true,
"applies-to" => {
"/core-service=platform-mbean/type=runtime" => undefined,
"/system-property=*" => undefined,
"/" => undefined
}
}
}角色以及它们能够执行的对应操作取决于属性的配置。下表总结如下：
| 值 | requires-read | requires-write | requires-addressable |
|---|---|---|---|
| true |
读对敏感。只有 |
写入是敏感的。只有 |
寻址是敏感的。只有 |
| false | 读取并不敏感。任何管理用户都可以读取。 |
写不敏感。只有 | 寻址并不敏感。任何管理用户都可以解决。 |
3.5.9.2. 列出敏感限制
您可以使用以下管理 CLI 命令，直接从 JBoss EAP 管理模型中看到可用敏感度限制列表：
/core-service=management/access=authorization/constraint=sensitivity-classification:read-resource(include-runtime=true,recursive=true)3.5.9.3. 配置应用程序资源限制
每个应用资源约束都定义了一组资源、属性和操作，它们通常与应用程序和服务部署相关。当应用程序资源限制被启用 Deployer 角色的管理用户时，会被授予对它应用到的资源的访问权限。
应用程序约束配置位于 /core-service=management/access=authorization/constraint=application-classification/。
每个应用程序资源限制都被标识为分类。然后分类被分成不同的类型。每个分类都有 应用到 元素，它是分类配置适用的路径模式列表。
默认情况下，唯一启用的应用程序资源分类是 core。核心包括部署、部署覆盖和部署操作。
要启用应用程序资源，使用 write-attribute 操作将分类的 configured-application 属性设置为 true。要禁用应用程序资源，请将此属性设置为 false。默认情况下不设置这些属性，并且使用 default-application 属性的值。无法更改默认值。
示例：启用日志记录器的应用程序资源类别
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)示例：Result
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource{
"outcome" => "success",
"result" => {
"configured-application" => true,
"default-application" => false,
"applies-to" => {"/subsystem=logging/logging-profile=*" => undefined}
}
}
应用程序资源限制适用于其配置的所有资源。例如，无法授予 Deployer 用户访问一个数据源资源，但不能访问另一个数据源资源。如果需要这种隔离级别，则建议在不同的服务器组中配置资源，并为每个组创建不同的范围 Deployer 角色。
3.5.9.4. 列出应用程序资源限制
您可以使用以下管理 CLI 命令，直接从 JBoss EAP 管理模型中看到可用应用程序资源限制列表：
/core-service=management/access=authorization/constraint=application-classification:read-resource(include-runtime=true,recursive=true)3.5.9.5. 配置 Vault 表达式约束
默认情况下，读取和写入 vault 表达式是敏感操作。配置 vault 表达式约束可允许将这些操作或两个操作都设置为非敏感。更改此约束可让更多的角色读写 vault 表达式。
vault 表达式约束位于 /core-service=management/access=authorization/constraint=vault-expression。
要配置 vault 表达式约束，请使用 write-attribute 操作设置 configured-requires-write 和 configured-requires-read 设为 true 或 false 的属性。默认情况下，不设置这些设置，并且使用 default-requires-read 和 default-requires-write 的值。无法更改默认值。
示例：使 Vault 表达式成为非敏感操作
/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)示例：Result
/core-service=management/access=authorization/constraint=vault-expression:read-resource{
"outcome" => "success",
"result" => {
"configured-requires-read" => undefined,
"configured-requires-write" => false,
"default-requires-read" => true,
"default-requires-write" => true
}
}角色以及对应的 vault 表达式，它们将能够读取和写入，这取决于属性的配置。下表总结如下：
| 值 | requires-read | requires-write |
|---|---|---|
| true |
读操作是敏感的。只有 |
写入操作是敏感的。只有 |
| false | 读操作不敏感。所有管理用户都可以读取。 |
写入操作不敏感。 |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}