我们的系统安装了 X-Pack 用于控制访问权限，他可以通过设定 Roles，然后建立用户关联这些 Roles 来完成一个用户的指定权限设定。
我们通过一个 AWS Lambda 程序来备份指定日期的 Index 文件到 AWS S3 系统当中，并且处理所有 Index Aliases 内容。这样我们就需要分配一个 Cluster 中的 Manager 权限，并且对指定的 Indices 给出 Manager 权限。
但是通过官方 Security Privileges 说明可以看到，这两个 manager 权限实在都太大了。这个用户分配给 Lambda 程序后，用户名口令相当于是明文存在的。会对系统产生较高的风险。但是整个系统中 Build-In 的权限设定比较少。所以需要对这个账户的 Role 进行更细颗粒度的限定。
X-Pack Security 结构
在这个系统中，权限管理是下面这么个层次结构：
Privileges --> Roles --> User
其中 Privileges 分为针对整个 Cluster 或者针对特定的 Indices 设定。
如果能够知道更详细的 Privileges 列表，那么将其通过 _xpack/security/role API 就可以创建一个自定义的 Roles，如何创建请参考 Defining Roles 的说明。
但是问题是查遍官方文档，没有任何地方对系统中都提供了什么 Privileges 有列表。官方给出的答复是并不公开提供这个列表内容。
Privileges 列表
在老版本的 Elasticsearch 2.2 中找到了 Action Level Privileges 的列表，这个在 2.3、2.4、5.x 的文档中都不在存在了。
我们测试过部分的 Cluster:admin 功能设定，在 5.6.3 的系统中是能够正常工作和限定的。对于 Indices 的部分，因为我们对 Indices 的控制没有需求，就没多看了。应该这个部分都是正常的，就是可能有缺少而已。
列表的规则很简单，第一个标记的是针对哪个进行权限设定，Cluster 或者 Indices，第二列表示了是用于管理还是数据访问，也就是 admin 或者 data，然后后面的内容跟具体操作的 RESTful API 的路径基本一致。
按照我们的需求：执行 snapshot 并且对 alias 进行一些管理，我们设置了两个自定义 Roles：
POST _xpack/security/role/snap-creator
{
"cluster": [
"cluster:admin/snapshot/status",
"cluster:admin/snapshot/create"
]
}
POST _xpack/security/role/alias-manager
{
"indices":[
{
"names": ["metric-*"],
"privileges": [
"indices:admin/aliases",
"indices:admin/get"
]
}
]
}
其中 indices:admin/get 权限若不设定， _aliases 指令无法执行，应该是拿不到 Indices 的列表导致的。但是并不知道这个 indices:admin/get 权限的具体范畴，因为我们对数据读取没有那么大的安全控制需要，就没有多加尝试。
如何知道我的指令需要什么权限？
在测试我们的 Role 处理的过程中，突然注意到：如果没有权限执行一个操作的时候，Elasticsearch 自己就会告诉你他需要哪个 Privileges 的定义。
curl -XGET -u test-rule:123456 https://localhost:9200/metric-\*/_aliases
{
"error": {
"root_cause": [
{
"type": "security_exception",
"reason": "action [indices:admin/get] is unauthorized for user [test-rule]"
}
],
"type": "security_exception",
"reason": "action [indices:admin/get] is unauthorized for user [test-rule]"
},
"status": 403
}
上面 [indices:admin/get] 的提示内容，就是我们应该设定的 Privileges 的内容。我平时都是在 Kibana Console 中用 Supper-User 做操作，从来没有见过这个，真是坑啊。😂
大家如果在权限设定上需要更加细节的权限控制，完全可以 curl 指令去测试一下，看看给出哪些 Privileges 能够让他正常工作。
不过要特别注意，官方特别强调：Although rarely needed ，并且我们咨询过他们的 Support，他们也说如果不是特别必须，建议我们不要这么设定 Privileges 的内容，还是使用他们的 Build-In Privileges。
不过实在想不明白为什么官方要这么做。就看他们一个 Manager 的描述：
All monitor privileges plus index administration (aliases, analyze, cache clear, close, delete, exists, flush, mapping, open, force merge, refresh, settings, search shards, templates, validate).
为了一个 Alias 操作，给这个权限出去，实在是能吓死我。
其他参考
在找 X-Pack Security 资料的过程中找到了 Search Guard 这么一个 Opensource 软件，从媒体报道和他自己的说明上看，完全可以替代 X-Pack 的使用。
他的相关文档在一个独立的 Github Repository 里面。这个可以看看，整个的工作逻辑跟 X-Pack Security 应该是非常类似的。
我们直接在 Elastic Cloud 上启动了 X-Pack 就没有尝试这个东西。
