Elasticsearch 7.x 如何实现大规模用户/分组场景下的文档访问限制？

现有三类备选方案的核心适配局限 #

• 原生RBAC路线：ES 7.x的单集群原生角色承载上限仅为数千量级，当用户组规模达到“任意2名用户即可成组”的水平时，组数量会突破千万甚至亿级。一方面大量自定义角色会快速挤占集群元数据的堆内存配额，另一方面角色匹配计算的开销会随角色数量线性上升，完全不具备生产可行性。
• 原生ABAC路线：ES 7.x的原生用户实体和Kibana空间、审计日志强绑定，单集群原生用户的稳定承载上限为10万级，数十万规模的业务用户会直接耗尽安全域的元数据配额。同时ES原生用户体系和你方定义的非ES业务用户没有天然映射能力，适配改造成本极高。
• 文档字段拼AND子句路线：该路线不依赖ES原生权限体系，但常规实现存在明显的性能坑——如果直接在文档里存储所有关联的用户ID、用户组ID，在百万级单组规模下，单文档的权限数组长度会突破数KB，直接拉高倒排索引体积，严重拖慢查询性能。

适配业务场景的可落地实现路径 #

非原生依赖的优化版权限过滤方案（生产验证成熟） #

• 彻底放弃在文档侧存储全量关联权限实体的设计，调整为文档存权限标签、查询侧带权限集合的反向映射逻辑：
• 全量关联的公开文档，统一打固定权限标签 perm:public，所有查询默认覆盖该标签的过滤条件。
• 单用户关联的文档，打标签 perm:user_{对应用户ID}，查询时根据当前上下文的用户ID，匹配对应权限标签。
• 用户组关联的文档，只打组ID对应的权限标签 perm:group_{组ID}，查询时根据当前用户关联的所有可访问组ID列表，作为terms过滤条件注入查询。
• 性能优化细节：所有权限过滤块全部设置为filter上下文，不参与查询打分，完全依托ES的倒排索引缓存能力；1000万规模的单索引下，只要单用户关联的组ID列表不超过1000个，整体查询耗时可稳定在百毫秒级。
• 避坑提醒：绝对不要把百万级用户组的成员列表回写到文档字段中，否则会直接导致单文档字段值过长，触发ES的内存和存储性能瓶颈。

基于ES文档级安全的轻量定制方案 #

• 完全绕开ES原生对角色、用户实体的数量限制，仅保留一个全查询场景共用的低权限服务账户，所有业务侧的用户身份、用户组关系全部在自有业务系统中维护，不需要在ES安全域内创建任何和业务用户、业务组对应的实体。
• 依托ES 7.x的查询拦截扩展能力，在查询进入分片执行前的阶段，自动把当前用户对应的可访问权限标签集合，注入到原查询的最外层filter上下文，对业务上层调用完全透明，完全匹配你方提到的“单一服务账户on behalf不同用户发起查询”的使用模式。
• 这种实现既复用了ES原生的安全链路，又把鉴权计算的开销降到最低，完全可以支撑数十万用户、千万级自定义用户组的规模。

超大单组规模的性能兜底 #

• 针对单组规模达到100万的超大群组，不要把全量组ID放到查询的terms条件中，配套开启两个优化能力：
• 给权限标签字段开启doc_values和eager_global_ordinals全局缓存，把权限集合的匹配开销降到最低。
• 把超大组对应的权限标签和文档路由键绑定，查询时直接根据当前用户所属的超大组列表，定位需要查询的分片范围，跳过无关分片的计算。

定制化方案选型建议 #

• 不需要引入重权重的第三方权限组件，整套权限逻辑的核心是查询侧的过滤条件拼接，完全可以在业务服务层实现，无额外组件运维成本。
• 如果需要降低业务侧的代码侵入度，可以在业务服务和ES集群之间加一层轻量代理，把权限拼接逻辑放在代理层统一处理，实现业务侧零改造。

内容的提问来源于stack exchange，提问作者Oleg Kaplun