› › ›

定义角色

一个角色由以下 JSON 结构定义

{
  "run_as": [ ... ], 
  "cluster": [ ... ], 
  "global": { ... }, 
  "indices": [ ... ], 
  "applications": [ ... ], 
  "remote_indices": [ ... ], 
  "remote_cluster": [ ... ], 
  "metadata": { ... }, 
  "description": "..." 
}

	此角色的所有者可以模拟的用户名的列表。
	集群权限的列表。这些权限定义了拥有此角色的用户可以执行的集群级操作。此字段是可选的（缺少 `cluster` 权限实际上意味着没有集群级权限）。
	定义全局权限的对象。全局权限是一种请求敏感的集群权限形式。标准的集群权限仅基于正在执行的操作进行授权决策。全局权限还会考虑请求中包含的参数。目前，对全局权限的支持仅限于管理应用程序权限。此字段是可选的。
	索引权限条目的列表。此字段是可选的（缺少 `indices` 权限实际上意味着没有索引级权限）。
	应用程序权限条目的列表。此字段是可选的。
	用于使用基于 API 密钥的模型配置的远程集群的索引权限条目的列表。此字段是可选的（缺少 `remote_indices` 权限实际上意味着对任何基于 API 密钥的远程集群都没有索引级权限）。
	用于使用基于 API 密钥的模型配置的远程集群的集群权限条目的列表。此字段是可选的（缺少 `remote_cluster` 权限实际上意味着对任何基于 API 密钥的远程集群都没有额外的集群权限）。
	与角色关联的元数据字段，例如 `metadata.app_tag`。元数据在内部被索引为扁平字段类型。这意味着在查询和排序时，所有子字段都像 `keyword` 字段一样工作。元数据值可以是简单值，也可以是列表和映射。此字段是可选的。
	带有角色描述文本的字符串值。它的最大长度为 `1000` 个字符。该字段在内部被索引为文本字段类型（具有所有参数的默认值）。此字段是可选的。

角色名称必须至少为 1 个字符，且不超过 507 个字符。它们可以包含字母数字字符（a-z、A-Z、0-9）、空格、标点符号以及基本拉丁语（ASCII）块中的可打印符号。不允许前导或尾随空格。

索引权限

编辑

以下描述索引权限条目的结构

{
  "names": [ ... ], 
  "privileges": [ ... ], 
  "field_security" : { ... }, 
  "query": "...", 
  "allow_restricted_indices": false 
}

	此条目中的权限适用的数据流、索引和别名的列表。支持通配符（`*`）。
	角色所有者在 `names` 参数中指定的关联数据流和索引上拥有的索引级权限。
	角色所有者拥有读取访问权限的文档字段的规范。有关详细信息，请参阅设置字段和文档级安全性。
	定义角色所有者具有读取访问权限的文档的搜索查询。关联数据流和索引中的文档必须与此查询匹配，才能被角色所有者访问。
	受限索引是一类特殊的索引，它们在内部用于存储配置数据，不应直接访问。通常，只有内部系统角色才应授予对受限索引的权限。强烈不建议切换此标志，因为它可能会有效地授予对关键数据的无限制操作，从而使整个系统不稳定或泄漏敏感信息。但是，如果出于管理目的，您需要创建一个具有涵盖受限索引的权限的角色，则必须将此字段设置为 `true` （默认为 `false`），然后 `names` 字段也将涵盖受限索引。

names 参数接受通配符和正则表达式，它们可以引用多个数据流、索引和别名。

通配符（默认）- 简单的通配符匹配，其中 * 是零个或多个字符的占位符，? 是单个字符的占位符，\ 可用作转义字符。
正则表达式 - 一种更强大的语法，用于匹配更复杂的模式。此正则表达式基于 Lucene 的 regexp 自动机语法。要启用此语法，必须将其包裹在一对正斜杠 (/) 中。任何以 / 开头且不以 / 结尾的模式都被认为是格式错误的。

正则表达式示例。

"foo-bar":               # match the literal `foo-bar`
"foo-*":                 # match anything beginning with "foo-"
"logstash-201?-*":       # ? matches any one character
"/.*-201[0-9]-.*/":      # use a regex to match anything containing 2010-2019
"/foo":                  # syntax error - missing final /

全局权限

编辑

以下描述全局权限条目的结构

{
  "application": {
    "manage": {    
      "applications": [ ... ] 
    }
  },
  "profile": {
    "write": { 
      "applications": [ ... ] 
    }
  }
}

	管理应用程序权限的能力的权限
	可以管理的应用程序名称列表。此列表支持通配符（例如 `"myapp-"`）和正则表达式（例如 `"/app[0-9]/"`）
	写入任何用户配置文件的 `access` 和 `data` 的权限
	写入权限限制到的名称、通配符和正则表达式的列表

应用程序权限

编辑

以下描述应用程序权限条目的结构

{
  "application": "my_app", 
  "privileges": [ ... ],   
  "resources": [ ... ]     
}

	应用程序的名称。
	要授予此角色的应用程序权限的名称列表。
	这些权限适用的资源。它们以与 `indices` 权限中的索引名称模式相同的方式处理。这些资源对 Elasticsearch 安全功能没有任何特殊含义。

有关这些字段的验证规则的详细信息，请参阅添加应用程序权限 API。

角色可以引用不存在的应用程序权限 - 也就是说，它们尚未通过添加应用程序权限 API 定义（或者它们已定义，但此后已被删除）。在这种情况下，该权限无效，并且不会在拥有权限 API 中授予任何操作。

远程索引权限

编辑

对于使用基于 API 密钥的模型配置的远程集群，远程索引权限可用于指定匹配远程集群的所需索引权限。最终有效的索引权限将是远程索引权限和跨集群 API 密钥的索引权限的交集。

远程索引对使用基于 API 密钥的模型配置的远程集群有效。它们对使用基于证书的模型配置的远程集群无效。

与索引权限条目相比，远程索引权限条目具有一个额外的强制 clusters 字段。否则，两者的结构相同。以下描述远程索引权限条目的结构

{
  "clusters": [ ... ], 
  "names": [ ... ], 
  "privileges": [ ... ], 
  "field_security" : { ... }, 
  "query": "...", 
  "allow_restricted_indices": false 
}

	远程集群别名的列表。它支持文字字符串，以及通配符和正则表达式。此字段是必需的。
	此条目中的权限适用的数据流、索引和别名的列表。支持通配符（`*`）。
	角色所有者在 `names` 参数中指定的关联数据流和索引上拥有的索引级权限。
	角色所有者拥有读取访问权限的文档字段的规范。有关详细信息，请参阅设置字段和文档级安全性。
	定义角色所有者具有读取访问权限的文档的搜索查询。关联数据流和索引中的文档必须与此查询匹配，才能被角色所有者访问。
	受限索引是一类特殊的索引，它们在内部用于存储配置数据，不应直接访问。通常，只有内部系统角色才应授予对受限索引的权限。强烈不建议切换此标志，因为它可能会有效地授予对关键数据的无限制操作，从而使整个系统不稳定或泄漏敏感信息。但是，如果出于管理目的，您需要创建一个具有涵盖受限索引的权限的角色，则必须将此字段设置为 `true` （默认为 `false`），然后 `names` 字段也将涵盖受限索引。

远程集群权限

编辑

对于使用基于 API 密钥的模型配置的远程集群，远程集群权限可用于指定匹配远程集群的其他集群权限。

远程集群权限仅对使用基于 API 密钥的模型配置的远程集群有效。它们对使用基于证书的模型配置的远程集群无效。

以下描述远程集群权限条目的结构

{
  "clusters": [ ... ], 
  "privileges": [ ... ] 
}

	远程集群别名的列表。它支持文字字符串，以及通配符和正则表达式。此字段是必需的。
	远程集群的集群级权限。此处允许的值是集群权限的子集。内置权限 API 可用于确定此处允许哪些权限。此字段是必需的。

示例

编辑

以下代码段显示了 clicks_admin 角色的示例定义

resp = client.security.put_role(
    name="clicks_admin",
    run_as=[
        "clicks_watcher_1"
    ],
    cluster=[
        "monitor"
    ],
    indices=[
        {
            "names": [
                "events-*"
            ],
            "privileges": [
                "read"
            ],
            "field_security": {
                "grant": [
                    "category",
                    "@timestamp",
                    "message"
                ]
            },
            "query": "{\"match\": {\"category\": \"click\"}}"
        }
    ],
)
print(resp)

const response = await client.security.putRole({
  name: "clicks_admin",
  run_as: ["clicks_watcher_1"],
  cluster: ["monitor"],
  indices: [
    {
      names: ["events-*"],
      privileges: ["read"],
      field_security: {
        grant: ["category", "@timestamp", "message"],
      },
      query: '{"match": {"category": "click"}}',
    },
  ],
});
console.log(response);

POST /_security/role/clicks_admin
{
  "run_as": [ "clicks_watcher_1" ],
  "cluster": [ "monitor" ],
  "indices": [
    {
      "names": [ "events-*" ],
      "privileges": [ "read" ],
      "field_security" : {
        "grant" : [ "category", "@timestamp", "message" ]
      },
      "query": "{\"match\": {\"category\": \"click\"}}"
    }
  ]
}

根据上述定义，拥有 clicks_admin 角色的用户可以

模拟 clicks_watcher_1 用户并代表其执行请求。
监视 Elasticsearch 集群
从所有以 events- 为前缀的索引中读取数据
在这些索引中，仅读取 click 类别的事件
在这些文档中，仅读取 category、@timestamp 和 message 字段。

有关可用集群和索引权限的完整列表

有两种可用的机制来定义角色：使用 角色管理 API 或 Elasticsearch 节点上的本地文件。您还可以实现自定义角色提供程序。如果您需要与另一个系统集成以检索用户角色，则可以构建自定义角色提供程序插件。有关更多信息，请参阅自定义角色和授权。

角色管理 UI

编辑

您可以在 Kibana 中轻松管理用户和角色。要管理角色，请登录 Kibana 并转到管理 / 安全 / 角色。

角色管理 API

编辑

角色管理 API 使您能够动态地添加、更新、删除和检索角色。当您使用 API 管理 native 域中的角色时，这些角色会存储在内部的 Elasticsearch 索引中。有关更多信息和示例，请参阅角色。

基于文件的角色管理

编辑

除了角色管理 API 之外，角色还可以在位于 ES_PATH_CONF 中的本地 roles.yml 文件中定义。这是一个 YAML 文件，其中每个角色定义都以其名称为键。

如果在 roles.yml 文件和通过角色管理 API 中使用了相同的角色名称，则将使用文件中找到的角色。

虽然角色管理 API 是定义角色的首选机制，但如果您想定义任何人都无法更改的固定角色（除了具有对 Elasticsearch 节点物理访问权限的管理员之外），使用 roles.yml 文件会很有用。但请注意， roles.yml 文件仅作为最基本管理功能提供，不旨在涵盖和用于定义所有用例的角色。

您无法通过使用角色管理 UI 或角色管理 API 来查看、编辑或删除在 roles.yml 中定义的任何角色。

roles.yml 文件由节点在本地管理，而不是由集群全局管理。这意味着，在一个典型的多节点集群中，需要在集群中的每个节点上应用完全相同的更改。

更安全的方法是在其中一个节点上应用更改，并将 roles.yml 分发/复制到集群中的所有其他节点（手动或使用诸如 Puppet 或 Chef 等配置管理系统）。

以下代码片段显示了 roles.yml 文件配置的示例

click_admins:
  run_as: [ 'clicks_watcher_1' ]
  cluster: [ 'monitor' ]
  indices:
    - names: [ 'events-*' ]
      privileges: [ 'read' ]
      field_security:
        grant: ['category', '@timestamp', 'message' ]
      query: '{"match": {"category": "click"}}'

Elasticsearch 会持续监控 roles.yml 文件，并自动获取并应用对其所做的任何更改。

« 内置角色角色限制 »