安全 Kibana 系统用户
Kibana 服务器使用 elastic/kibana 服务账户向 Elasticsearch 进行身份验证。该服务账户拥有的权限等同于 kibana_system 保留角色，其描述符在 Elasticsearch 仓库中进行管理（源码链接）。绝大多数功能不需要更改 kibana_system 用户的权限。更改这些权限必须经过审慎考虑，因为我们不希望 kibana_system 账户拥有访问用户数据的权限。
在审查 kibana_system 角色描述符的更改时，请考虑以下准则。
- 系统索引完全由 Stack 管理，最终用户绝不应访问它们。
- 隐藏索引通常由 Stack 管理，但可能会被最终用户访问。
- 数据索引是指最终用户可以自行创建的索引。作为一般规则，只要索引名称不以
.（点）开头，用户就可以创建任何模式的索引。用户也可以创建隐藏索引，因此，必须为任何由 Stack 管理的隐藏索引提供文档，以减少与用户管理的索引发生冲突的可能性。
因此，Kibana 不应有权访问不以 .（点）开头的非系统索引。
Kibana 也不应有权修改其非所有者的系统/隐藏索引。
| 索引类型 | 允许的权限 | 示例 |
|---|---|---|
| 用户定义的数据索引 | none | my-data, kibana-metrics |
| 非 Kibana 拥有的系统索引 | read |
.security |
| Kibana 拥有的系统索引 | all |
.kibana*, .fleet* |
过去曾为了辅助遥测数据收集而对该规则设置过例外。这不是我们希望长期支持的内容，但目前在没有进行重大重新设计的情况下，没有可行的替代方案。
Fleet 维护着某些包的生命周期。这些包需要在 Stack 升级期间进行升级，因此必须以自动化的方式进行。kibana_system 用户被授予了一组数据索引的提升权限，以促进此过程。
如果 Fleet 管理的索引集发生变化，我们应确保更新文档，以说明索引命名冲突的情况。
这包括
- 用户
- 角色
- 角色映射
制定这些准则有两个主要原因。
kibana_system 凭据如果泄露，可能会严重影响安装环境。我们希望确保这种情况不会演变成灾难性的后果。权限越多 == 潜在破坏越大。我们不应不必要地增加权限。一旦不再需要，我们应立即移除权限。
凭据可能通过多种方式泄露
- 不安全的存储（例如
kibana.yml、便签纸等）。 - Kibana 服务器主机被攻破。
- Kibana 服务器运行时被攻破（例如 RCE）。
Kibana 允许工程师使用不同的凭据集调用 ES
kibana_system凭据。- 最终用户凭据。
如果工程师本打算使用最终用户凭据，却意外使用了 kibana_system 凭据，可能会发生授权绕过。请参阅 访问控制失效 (Broken Access Control)。