Elasticsearch query plans and the authorization gap teams miss

TL;DR: Authorization can be enforced at the query layer by converting policy decisions into Elasticsearch query plans, reducing post-fetch filtering and letting the database apply access rules efficiently, according to Cerbos. The real shift is that identity-aware access control now has to align with query design, schema mapping, and nested data handling rather than code-only checks.

NHIMG editorial — based on content published by Cerbos: query plan adapters for Elasticsearch authorization

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should teams implement query-layer authorization for Elasticsearch search workloads?

A: Teams should translate policy decisions into native query filters and keep authorization out of post-fetch application logic.

Q: Why do nested objects create authorization risk in search systems?

A: Nested objects can break policy meaning if access conditions are evaluated as though every field lived in the same flat record.

Q: What breaks when authorization is done after data retrieval?

A: Post-fetch filtering wastes database and application resources, but the bigger issue is that it exposes data to the application before access is decided.

Practitioner guidance

• Map policy attributes to indexed fields explicitly Review every Cerbos attribute path against the Elasticsearch schema, including nested mappings, before relying on PlanResources in production.
• Validate nested-object policy semantics Test exists, all, and hasIntersection conditions against real nested documents so access control does not collapse across fields that belong to different objects.
• Keep authorization inside bool.filter Place translated authorization clauses in filter context so relevance scoring stays separate and the database can cache the access predicate efficiently.

What's in the full article

Cerbos' full engineering guide covers the operational detail this post intentionally leaves for the source:

• ElasticsearchQueryPlanAdapter examples for translating PlanResources results into Query DSL JSON.
• Nested object handling for exists, all, and hasIntersection conditions across real index mappings.
• Custom operator override patterns for text and keyword fields in production schemas.
• Compiler-style Result handling for AlwaysAllowed, AlwaysDenied, and Conditional outcomes.

👉 Read Cerbos' guide to query plans for Elasticsearch authorization →

Elasticsearch query plans and the authorization gap teams miss?

Explore further

View Full Forum →  |  NHI Foundation Course →