REST 层授权
REST 层授权为插件和扩展 API 请求提供了额外的安全级别,通过在 REST 层提供授权检查机制实现。这种安全级别位于传输层之上,提供了一种补充的授权方法,而不会替换、修改或以任何方式改变传输层上的相同过程。REST 层授权最初是为了解决扩展(不通过传输层通信)的授权检查需求而创建的。然而,该功能也适用于希望在为 OpenSearch 创建未来插件时使用它的开发者。
对于使用 REST 层授权的用户,分配角色、映射用户和角色的方法以及插件和扩展的一般使用方式保持不变——唯一额外的要求是用户需要熟悉新的权限方案。
另一方面,开发者需要理解 NamedRoute
背后的思想以及新的路由方案是如何构建的。有关详细信息,请参阅插件的 REST 层授权。
使用 REST 层进行授权的好处包括能够在 REST 层授权请求并过滤掉未经授权的请求。因此,这减少了传输层的处理负担,同时允许对 API 访问进行细粒度控制。
某些读取操作(例如 scroll)会管理状态。因此,建议使用安全插件的权限来控制读写访问,而不是通过允许/阻止 HTTP 请求动词。
您必须启用安全插件才能使用 REST 层授权。
NamedRoute
REST 层授权使集群管理员能够授予或撤销对集群中特定端点的访问权限。为此,资源路由使用唯一名称。
为了方便 REST 层授权,OpenSearch 项目引入了 NamedRoute
用于路由注册的概念。对于开发者而言,此标准要求一种使用唯一名称注册路由的新方法。虽然传输操作通常由方法名、一部分和相应的传输操作组成,但此新实现要求路由具有方法名、一部分和唯一名称。顾名思义,它必须在所有插件和扩展中保持唯一,换句话说,不能注册到任何其他路由。
例如,考虑以下用于异常检测资源的路由:
_/detectors/<detectorId>/profile
对于扩展,您可以通过引用资源的 settings.yml
文件(本例中为 ad
)中的 routeNamePrefix
值,并将其添加到路由中以完成唯一名称来创建 NamedRoute
。结果如下例所示:
ad:detectors/profile
对于插件,您可以使用插件的名称代替 routeNamePrefix
值。
然后,路由名称可以像传统权限一样映射到角色。这在以下示例中得到了演示:
ad_role:
reserved: true
cluster_permissions:
- 'ad:detectors/profile'
映射用户和角色
使用 NamedRoute
映射用户和角色的方式没有改变。此外,新的权限格式与现有配置兼容。本节提供了一个示例,说明旧配置和 NamedRoute
配置中的用户和角色映射如何显示,以及它们如何授权已注册的操作路由。
当用户发起 REST 请求时,系统会检查用户的角色,并评估与用户关联的每个权限,以确定是否与分配给路由的唯一名称匹配,或者与路由注册期间定义的任何旧操作匹配。用户可以映射到包含为唯一名称或旧操作格式化的权限的角色。考虑以下虚构插件 abc
的角色:
abcplugin_read_access:
reserved: true
cluster_permissions:
- 'cluster:admin/opensearch/abcplugin/route/get'
另请考虑以下角色映射:
abcplugin_read_access:
reserved: true
users:
- "user-A"
如果 user-A
向路由 /_plugins/_abcplugin/route/get
发起 REST API 调用,则该用户被授予该操作的授权。然而,对于不同的路由,例如 /_plugins/_abcplugin/route/delete
,请求将被拒绝。
同样,对于使用唯一路由名称和 NamedRoute
概念的角色和角色映射,也适用相同的逻辑。考虑同一插件 abc
的以下角色:
abcplugin_read_access_nr:
reserved: true
cluster_permissions:
- 'abcplugin:routeGet'
- 'abcplugin:routePut'
- 'abcplugin:routeDelete'
另请考虑以下角色映射:
abcplugin_read_access_nr:
reserved: true
users:
- "user-B"
在第二种情况下,如果 user-B
向任何路由 /_plugins/_abcplugin/route/get
、/_plugins/_abcplugin/route/put
或 /_plugins/_abcplugin/route/delete
发起 REST API 调用,则该用户被授予该操作的授权。