bigywater.tech
Elasticsearch · 168

匿名访问与最小权限原则

本机真实验证匿名访问配置指向一个尚未创建的角色时请求依然401,证明配置点名角色名字不等于自动生效;创建只给cluster:monitor的最小化anon_role后,不带凭证查cluster健康能用但查索引数据真实被拒绝;随后故意把anon_role改宽成对所有索引给read权限,同一条不带任何凭证的查询真实直接读出了本应保密的文档内容,用这个本系列最后一篇文章最直白的真实证据,印证了匿名访问机制本身并不危险,危险的是配置给匿名角色的权限范围——这正是最小权限原则贯穿全部168篇真实实验背后最终想落地的那条准则。

角色不存在时的匿名请求
真实依然401,配置点名不等于自动生效
最小权限anon_role
查health能用,查索引数据真实被拒绝
改宽成*的read权限后
同一条匿名查询真实直接读出保密数据

做的事:本机真实配xpack.security.authc.anonymous.roles指向一个叫anon_role的角色,但这个角色本身真实还没被创建

代码真实配置: xpack.security.authc.anonymous.roles: anon_role (真实此时还没有调用_security/role去真实创建这个角色) 真实不带任何凭证发请求: GET /_cluster/health

验证:真实依然收到401要求认证——光在配置里点名一个角色名字,这个角色不存在就真实什么都不会发生

实测 · 本机 Elasticsearch 8.15.0 执行输出
→ 401 security_exception: "action [cluster:monitor/health] requires authentication"

这个真实结果提醒了一个容易被误解的点:匿名访问真实不是靠配置里写了个角色名字就自动生效,这个角色真实必须先用_security/role这个接口真正创建出来、填上真实的权限内容,匿名访问机制才会真实开始生效。

真实创建这个anon_role,严格按照最小权限原则,只给cluster:monitor,不给任何index权限

代码PUT /_security/role/anon_role {"cluster":["monitor"],"indices":[]} 真实不带凭证测两种请求: GET /_cluster/health GET /anon_test/_search

验证:不带凭证查cluster/health真实能用了,但查索引数据依然真实被拒绝

实测 · 本机执行输出
GET /_cluster/health(不带凭证) → 真实成功返回集群健康信息
GET /anon_test/_search(不带凭证) → 401: "requires authentication"
  (不是403,因为配置了authz_exception:false,故意不暴露"你是匿名用户但权限不够"这个信息)

真实故意把anon_role改宽,给它配上对*索引的read权限,看匿名访问的真实边界会发生什么变化

代码PUT /_security/role/anon_role { "cluster":["monitor"], "indices":[{"names":["*"],"privileges":["read"]}] } 真实再测同一条不带凭证的查询: GET /anon_test/_search

验证:同一条不带任何凭证的查询,真实直接读出了索引里那条本来应该保密的文档内容

实测 · 本机执行输出
GET /anon_test/_search(真实不带任何凭证)
→ 真实成功: {"hits":{"hits":[{"_source":{"secret":"should not be anonymously readable"}}]}}
  ← 真实任何人不需要任何密码就能读到这条数据
这个真实结果是本系列整整168篇文章里最直白的一次安全警示:匿名访问这个机制本身真实不危险,危险的是给匿名角色配的权限范围——本次实测真实只改了一行配置(把indices从空数组改成对*通配符给read权限),集群里原本受security保护的全部数据,真实瞬间对任何能连上这个端口的人、不需要任何用户名密码就变得完全可读。这正是"最小权限原则"真实想强调的核心:权限配置真实应该默认什么都不给,只在真实明确需要的时候才按最小范围精确授权,而不是先给一个宽泛的默认值图省事,指望"反正也没人会去读"这种真实站不住脚的假设。

收尾:真实把anon_role改回最小权限的配置,确认同样的查询立刻又被真实挡住了

代码PUT /_security/role/anon_role {"cluster":["monitor"],"indices":[]} 真实再测: GET /anon_test/_search

验证:真实立刻又变回401,被挡住了

实测 · 本机执行输出
→ 401: "action [indices:data/read/search] requires authentication"
  ← 真实权限收紧之后立刻恢复了保护

分步演示:从不存在的角色名字真实不生效,到最小权限下的真实安全边界,再到权限放宽后的真实数据泄露

每一步都是本文在一个真实独立搭建、开启security的Elasticsearch 8.15.0节点上跑出来的原始结果,测完即销毁。

匿名访问本身不危险,危险的是给匿名角色配的权限范围——一行配置的疏忽就能让全部数据不设防
这一步新验证的匿名访问与最小权限场景

    本文用到的工具

    • 真实独立搭建的Elasticsearch 8.15.0节点(开启security,测完即销毁)
    • 真实的 xpack.security.authc.anonymous 配置与 _security/role API
    京ICP备2026067502号-1京公网安备11010502063487号