在 Elasticsearch 中很难找到严格安全所需的权限。 在本博客中，我将通过两个示例概述我用来查找所需权限的过程。

例子一

让我们创建一个只能与 index-* 索引和以 index1 别名交互的用户。 他们将能够：

• 如果不存在则创建索引
• 将文档索引到索引中（创建和更新）
• 从索引中删除文档

我们创建如下的一个文档：

PUT index-1/_doc/1
{
  "content": "This is Xiaoguo, Liu from Elastic"
}

上面的文档创建一个叫做 index-1 的索引。我们在 Kibana 中创建一个叫做 index-* 的 index pattern 或者 data view。

 

 

我们可以参考文章 “Elasticsearch：Index alias” 来为这个索引创建一个叫做 index 的别名：

PUT index-1/_alias/index1

我们首先创建一个具有 Kibana 开发工具控制台访问权限的新用户 test：

PUT _security/role/test
{
  "applications" : [
    {
      "application" : "kibana-.kibana",
      "privileges" : [
        "feature_dev_tools.all"
      ],
      "resources" : [
        "space:default"
      ]
    }
  ]
}

PUT _security/user/test
{
  "username": "test",
  "password": "password",
  "roles": [
    "test"
  ],
  "metadata": {},
  "enabled": true
}

在上面，我们创建了一个叫做 test 的用户。它的密码为 password，而它具有一个叫做 test 的角色（role）。你可以使用 Kibana 的界面来创建这些。请详细阅读文章 “Elasticsearch：用户安全设置”。我们可以在 Kibana 的界面中查看：

 

 

 

 然后，我们可以以该用户身份登录并尝试我们的用户将执行的命令，并记下错误。 提示：使用不同的浏览器或同一浏览器的私人窗口。 这将使向我们的角色添加权限的步骤变得更加容易。

我们使用 test:password 来进行登录 Kibana。我们可以在浏览器 Chrome 中登录。例如，让我们获取我们的别名和索引：

 

 

错误消息的有趣部分是：

• action [indices:admin/get]，缺少的确切操作
• 索引权限 [view_index_metadata,manage,all]，包含操作的权限，从最严格到最不严格排序

让我们来看看 view_index_metadata。我们需要在另外的一个浏览器（比如 Safari）中以 elastic 超级用户登录，并执行如下的命令：

PUT _security/role/test
{
  "indices": [
    {
      "names": [
        "index1",
        "index-*"
      ],
      "privileges": [
        "view_index_metadata"
      ]
    }
  ],
  "applications" : [
    {
      "application" : "kibana-.kibana",
      "privileges" : [
        "feature_dev_tools.all"
      ],
      "resources" : [
        "space:default"
      ]
    }
  ]
}

 我们再次在 Chrome 浏览器中，在 test:password 的登录界面中，执行之前的命令：

 

显然通过添加  view_index_metadata 这个 privileges，上面的命令可以得到顺利的执行。

按照同样的步骤，我们在 Chrome 浏览器中，执行如下的命令：

很显然，在右边，我们看到了错误的信息。 从这里我们得到动作的描述：

• action [indices:data/write/index]

我们看到了所需要的权限：[create_doc,create,index,write,all]。如果我们继续迭代，我们将获得以下角色。我们在另外一个以 elastic 登录的浏览器中打入如下的命令：

PUT _security/role/test
{
  "indices": [
    {
      "names": [
        "index1",
        "index-*"
      ],
      "privileges": [
        "indices:admin/get",
        "indices:data/write/index",
        "indices:data/write/bulk",
        "indices:admin/auto_create",
        "indices:admin/mapping/auto_put"
      ]
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_dev_tools.all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ]
}

 经过执行上面的命令后，我们再次回到 Chrome 浏览器中，并执行如下的命令：

显然这次执行的命令是成功的。也就是说，向一个索引 index-1 写入文档，我们需要有上面定义的 test j角色具有如下的 privileges：

        "indices:admin/get",
        "indices:data/write/index",
        "indices:data/write/bulk",
        "indices:admin/auto_create",
        "indices:admin/mapping/auto_put"

对于我们想要发送的每个其他请求，我们也可以继续此操作。 在许多情况下，这有点过头了。 除非你的项目具有极其严格的安全需求，否则通常最好选择更全面的内置安全权限，如下所示：

PUT _security/role/test
{
  "indices": [
    {
      "names": [
        "index1",
        "index-*"
      ],
      "privileges": [
        "all"
      ]
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_dev_tools.all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ]
}

不过要小心上面的这个特权，因为它还允许该用户删除这些索引。

例子二

具有集群级别（cluster-level）权限以查看 Elastic 主页和 ilm 策略的用户。

我们首先创建一个具有 Kibana Dev Tools 访问权限的新用户，如示例 1 所示，然后运行我们的命令：

GET /
GET _ilm/policy

这给了我们：

 

为了解决这些问题，我们可以使用以下角色：

PUT _security/role/test
{
  "cluster": [
    "cluster:admin/ilm/get",
    "cluster:monitor/main"
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_dev_tools.all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ]
}

 

 我们再次运行上面的命令：

到目前为止，你可能已经注意到这些操作具有路径（即 cluster:admin/ilm/get）。 我们可以使用 cluster:admin/ilm 获得所有集群 ilm 权限，或者使用 cluster:admin 获得所有集群管理员权限。 路径越短，权限的限制就越少。 

更多即将到来

这篇文章展示了一种简单的方法来迭代获取用户所需操作所需的权限。 正如你所看到的，有太多的组合无法用内置角色覆盖它们，更不用说在某些文档中覆盖它们了。 我希望你发现这个简单的技巧很有用。