Elasticsearch Security 中用户、角色和 API Key 怎么设计？

简化版

ES Security 通过用户、角色和权限控制集群与索引访问。生产中应按最小权限设计角色，服务间调用优先使用可控的 API Key，并定期轮换和审计。

详细版

ES 不应裸奔暴露给业务或公网。权限模型通常包括集群权限、索引权限、应用权限以及认证凭据。

Role 定义权限，User 绑定一个或多个 Role。
Index privilege 控制读写哪些索引，Cluster privilege 控制集群级操作。
API Key 适合服务访问，可以限制权限和有效期。
不要让应用使用超级管理员账号。
安全设计还包括 TLS、审计、密钥轮换和网络隔离。

完整版教学

一、为什么 ES 权限不是可有可无

ES 里可能有日志、用户行为、订单搜索、内部监控等敏感数据。一旦没有权限控制，误删索引、越权查询、数据泄露都可能发生。很多事故不是黑客高级攻击，而是应用拿了管理员账号，脚本写错删了全量索引。Security 的核心就是把“谁能做什么”明确下来，让业务访问被限制在必要范围内。

POST /_security/role/order_reader
{
  "indices": [
    { "names": ["orders-*"], "privileges": ["read", "view_index_metadata"] }
  ]
}

记忆钩子：ES 权限设计的第一原则是“应用只拿它刚好够用的钥匙”。

二、Role 是权限集合，User 是身份

Role 定义权限，User 代表访问身份。一个用户可以绑定多个角色，最终权限是角色权限的组合。权限分集群级和索引级：集群级包括管理模板、快照、节点信息等；索引级包括 read、write、create_index、manage 等。面试时要区分“能查询某个索引”和“能管理整个集群”，后者危险得多。

权限层级	示例	风险
Cluster privilege	manage, monitor	影响整个集群
Index privilege	read, write	影响指定索引
Field/Document level	字段或文档过滤	更细粒度控制

三、为什么应用不要用超级管理员

超级管理员账号通常拥有所有权限，一旦应用配置泄露或代码 bug，影响范围就是整个集群。正确做法是给每个应用或服务创建专用角色，例如订单服务只写 orders-*，搜索服务只读 products-*。如果某个服务只需要查询，就不要给写权限；如果只写当天日志，就不要给删除索引权限。最小权限不是形式主义，是事故半径控制。

POST /_security/api_key
{
  "name": "product-search-api-key",
  "expiration": "30d",
  "role_descriptors": {
    "product_reader": {
      "indices": [
        { "names": ["products-*"], "privileges": ["read"] }
      ]
    }
  }
}

四、API Key 适合服务间访问

相比长期用户名密码，API Key 更适合服务间调用，因为它可以设置有效期、绑定有限权限、单独撤销和轮换。比如某个查询服务泄露了 API Key，你可以只撤销这个 key，而不是影响整套用户体系。API Key 也更适合自动化部署和密钥管理系统。生产里应配合密钥托管，不要把 key 硬编码到仓库。

用户密码：适合人或基础身份
API Key：适合服务调用、可细粒度授权、可轮换
Service Account Token：适合某些平台集成场景

五、带数字理解权限事故半径

假设一个日志写入服务每秒写 5000 条日志。如果它持有 manage 权限，代码 bug 可能在 1 秒内删掉或改坏多个索引；如果它只有 create_doc 到 logs-* 的权限，最坏也主要是写入异常数据。权限越小，事故半径越小。安全设计不是让系统永不出错，而是让出错时损害可控。

管理员权限泄露：影响所有索引、模板、快照
单索引读权限泄露：主要影响该索引数据读取
30 天 API Key 泄露：可撤销、可过期、可追踪

六、权限之外还要做网络和传输安全

权限模型只是一层。ES 还应启用 TLS，避免凭据和数据明文传输；通过 VPC、安全组、防火墙限制访问来源；开启审计日志追踪关键操作；定期轮换 API Key 和密码。不要把 ES HTTP 端口直接暴露公网，再指望用户名密码解决所有问题。安全是多层防护，权限只是其中很核心的一层。

安全层次：
网络隔离 -> TLS -> 认证 -> 授权 -> 审计 -> 轮换

七、常见误区与追问

误区：内网 ES 不需要权限。 内网误操作和横向移动同样危险，至少要做最小权限和网络隔离。
误区：应用用管理员账号最省事。 省事会扩大事故半径，泄露或 bug 的后果非常大。
误区：API Key 创建后不用管。 API Key 应设置有效期、定期轮换、按服务隔离。
追问：读写分离权限怎么做？ 建不同角色和 API Key，读服务只给 read，写服务只给必要写权限。
追问：如何排查越权访问？ 开启审计日志，结合 API Key 名称、用户、来源 IP 和请求路径分析。

八、加强记忆

ES Security 可以用“钥匙串”记：Role 是钥匙权限，User/API Key 是拿钥匙的人或服务。生产设计的关键词是最小权限、服务隔离、可撤销、可审计。回答时从角色权限讲到 API Key，再补 TLS、网络隔离和轮换，才是完整安全方案。

简化版

详细版