上一篇解决了性能模型和调优思路——定位瓶颈再针对性调整。这一篇进入 ES 的安全层怎样保护集群。

ES 8.x 默认启用安全功能。在此之前安全是 X-Pack 的商业特性。理解安全层的架构——加密、认证、授权、审计——才能正确配置生产集群的访问控制。

本文只抓一个问题:ES 的安全层从外到内有哪几层,各自保护什么。

四层安全从外到内依次拦截请求,每一层解决一个独立的安全问题:

graph LR
    R[Client Request] --> L1[TLS 加密<br/>防窃听/篡改]
    L1 --> L2[Authentication<br/>你是谁]
    L2 --> L3[Authorization<br/>你能做什么]
    L3 --> L4[Audit Log<br/>你做了什么]
    L4 --> O[Operation]

    style L1 fill:#4a90d9,color:#fff
    style L2 fill:#50b86c,color:#fff
    style L3 fill:#e6a23c,color:#fff
    style L4 fill:#909399,color:#fff

后文逐层展开。

安全特性的历史变化

版本 安全状态
< 6.8 X-Pack 商业功能,需要 Gold/Platinum license
6.8 / 7.1 基础安全免费化(Basic license 即可使用认证、TLS、RBAC)
8.0+ 安全默认启用。首次启动自动生成 CA 证书、TLS 配置、elastic 用户密码

ES 8.x 首次启动时会自动完成:生成自签名 CA 证书和节点证书、启用 transport 和 HTTP 层的 TLS、生成 elastic 超级用户的初始密码、生成 enrollment token 供新节点加入集群。

洋葱模型:四层安全

1
2
3
4
5
6
Request
→ Layer 1: TLS Encryption(传输加密)
→ Layer 2: Authentication(身份验证:你是谁)
→ Layer 3: Authorization(权限控制:你能做什么)
→ Layer 4: Audit Logging(审计日志:你做了什么)
→ Operation

Layer 1:TLS 加密

两个层面的加密:

层面 配置 保护内容
Transport layer(节点间) xpack.security.transport.ssl 节点间数据传输、shard 复制
HTTP layer(客户端到集群) xpack.security.http.ssl REST API 请求和响应

Transport TLS 在安全启用后是强制的(节点间通信必须加密)。HTTP TLS 可选但强烈建议启用。

Layer 2:认证(Authentication)

认证回答"你是谁"。ES 使用 realm chain——按顺序尝试多个认证提供者:

Realm 类型 License 认证方式
native Basic(免费) ES 内部用户数据库
file Basic 本地文件(elasticsearch-users 命令管理)
API keys Basic Bearer token,无需用户名密码
Service tokens Basic 服务间认证
ldap Gold LDAP/Active Directory
saml Gold SAML 2.0 SSO
oidc Gold OpenID Connect
pki Gold 客户端证书

一个请求到达时,ES 按配置顺序尝试各 realm,直到某个 realm 认证成功。

1
2
# 查看当前认证用户
GET _security/_authenticate

Layer 3:授权(Authorization)

授权回答"你能做什么"。ES 使用 RBAC(基于角色的访问控制)。用户不直接持有权限,而是通过角色间接获取——一个用户可以绑定多个角色,权限取并集:

graph LR
    U1[User: log_reader] --> R1[Role: read_only_logs]
    U1 --> R2[Role: kibana_user]
    U2[User: admin] --> R3[Role: superuser]

    R1 --> P1[Index: logs-*<br/>read]
    R1 --> P2[Field: message,<br/>timestamp, level]
    R1 --> P3[Doc: level=error]
    R2 --> P4[Cluster: monitor]
    R3 --> P5[Cluster: all]
    R3 --> P6[Index: all]

    style U1 fill:#4a90d9,color:#fff
    style U2 fill:#4a90d9,color:#fff
    style R1 fill:#50b86c,color:#fff
    style R2 fill:#50b86c,color:#fff
    style R3 fill:#50b86c,color:#fff

Role 包含两类权限:

权限类型 粒度 示例
Cluster privileges 集群级操作 monitor, manage, manage_security
Index privileges 索引级操作 read, write, create_index, manage

Index privileges 可以细化到字段级(Field Level Security)和文档级(Document Level Security):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 创建一个只读 role
POST _security/role/read_only_logs
{
"indices": [
{
"names": ["logs-*"],
"privileges": ["read"],
"field_security": {
"grant": ["message", "timestamp", "level"]
},
"query": {
"term": { "level": "error" }
}
}
]
}

这个 role 只能读取 logs-* 索引中 level=error 的文档,且只能看到 messagetimestamplevel 三个字段。

1
2
3
4
5
6
# 创建用户并绑定 role
POST _security/user/log_reader
{
"password": "change-me-123",
"roles": ["read_only_logs"]
}

Layer 4:审计日志

审计日志记录认证和授权事件——谁在什么时候做了什么操作,是否成功。需要在 elasticsearch.yml 中启用:

1
xpack.security.audit.enabled: true

审计日志默认输出到 <ES_HOME>/logs/<cluster_name>_audit.json

License 影响

功能 Basic(免费) Gold Platinum
原生认证(native/file)
TLS 加密
RBAC
API keys
LDAP/SAML/OIDC
Field/Document Level Security
审计日志

Basic license 覆盖了生产环境的基本安全需求。企业级需求(LDAP 集成、细粒度权限、审计)需要 Gold 或 Platinum。

模式提炼:安全层的洋葱模型

1
network → encryption → identity → permission → audit
系统 加密 认证 授权 审计
ES TLS (transport + HTTP) Realm chain RBAC (cluster + index) Audit log
MySQL TLS User/Password, PAM, LDAP GRANT/REVOKE Audit plugin
MongoDB TLS SCRAM, x.509, LDAP Role-based Audit log
Kafka TLS, SASL SASL (PLAIN/SCRAM/GSSAPI) ACL Authorizer log

工程迁移表

概念 Elasticsearch MySQL MongoDB Kafka
认证方式 Realm chain (native/LDAP/SAML) User/Password, PAM SCRAM, x.509 SASL
权限模型 RBAC (Role → Privileges) GRANT (User → DB.Table) RBAC (Role → Actions) ACL (Principal → Topic)
字段级安全 Field Level Security (Gold+) Column-level GRANT 无内置
文档级安全 Document Level Security (Gold+) Row-level (Views/Policies) 无内置
默认安全 8.x 默认启用 默认无加密 默认无认证 默认无认证

常见误解

误解一:ES 默认是安全的(所有版本)。 只有 8.x 起默认启用安全。7.x 及之前需要手动配置。很多旧版集群在内网环境裸奔,没有任何认证和加密。

误解二:有了 TLS 就足够了。 TLS 保护传输层,防止窃听和篡改。但没有认证的话,任何知道集群地址的人都可以访问。TLS + 认证 + 授权三层缺一不可。

误解三:API key 和用户密码一样。 API key 是无状态的 Bearer token,适合服务间通信和 CI/CD。它可以设定过期时间、限定权限范围,比用户密码更适合自动化场景。

练习

  1. GET _security/_authenticate 查看当前认证用户信息和 role。

  2. 创建一个只有 read 权限的 role,绑定到一个新用户。用新用户尝试写入数据,验证权限被拒绝。

  3. 查看 GET _xpack/usage?filter_path=security 了解当前集群的安全功能使用情况。

系列导航

上一篇 下一篇
性能模型:搜索延迟、写入吞吐与调优思路 生产运维:集群扩缩、监控指标与故障排查

参考资料