Kibana 与 Elasticsearch 权限边界

做的事：本机真实查内置的kibana_system这个role的完整定义，看它的权限范围真实有多大

代码GET /_security/role/kibana_system

验证：真实数出来62条index权限规则，几乎全部精确对应.kibana、.fleet、.ml这些Kibana内部系统索引，唯独有一条真实是对星号*通配符生效的

kibana_system真实的index权限规则共62条，节选:
→ [".kibana*",".reporting-*"] -> ["all"]
→ [".monitoring-*"] -> ["read","read_cross_cluster"]
→ [".fleet-agents*"] -> ["all"]
→ ...(真实还有近60条都是类似的具体系统索引前缀)
→ ["*"] -> ["view_index_metadata","monitor"]   ← 唯独这一条真实对所有索引生效

这个真实数据揭示了kibana_system这个内置账号权限设计的核心思路：对Kibana自己内部需要完整读写的那些系统索引（.kibana*、.fleet*、.ml*等），真实给了all这种完整权限；但对集群里任何其他索引（包括真实业务数据用的索引），真实只给了view_index_metadata和monitor这两个非常有限的权限——意味着Kibana的这个系统账号真实只能看到"这个索引长什么样、健康状况如何"，看不到真实的业务数据内容。

真实建一个普通的业务索引，写入一条数据，拿绑定kibana_system的真实用户去测mapping、stats和search这三种访问方式

代码真实写入business_data索引: {"secret":"classified business data"} 真实建用户kibanasvc绑定kibana_system这个role 真实分别测: GET /business_data/_mapping GET /business_data/_search GET /business_data/_stats

验证：查mapping和stats真实都成功了，但用_search去读这条文档的实际内容，真实直接被拒绝

GET /business_data/_mapping → 真实成功，返回了字段结构
GET /business_data/_stats   → 真实成功，返回了监控统计数据

GET /business_data/_search  → 403 security_exception:
  "action [indices:data/read/search] is unauthorized for user [kibanasvc]
   with effective roles [kibana_system] on indices [business_data],
   this action is granted by the index privileges [read,all]"

分步演示：从kibana_system角色定义里唯一对*通配符生效的最小权限规则，到mapping/stats成功而search被拒绝的真实边界

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