Notifications
Clear all
Topic starter
10/06/2026 11:36 pm
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
12/06/2026 5:52 am
Query-time authorization is where policy correctness becomes data-path correctness. Once access rules are translated into Elasticsearch filters, authorization no longer lives only in the application layer. That shifts the control problem from whether a policy exists to whether the query path faithfully preserves it across nested objects, operator semantics, and schema mappings. Practitioners should treat search authorization as an identity control plane decision, not a convenience layer.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Should security teams treat field mapping as part of authorization design?
A: Yes. Field mapping is not just an integration task because the policy engine only enforces what the query translation preserves. If policy attributes map incorrectly to index fields, the resulting query can enforce the wrong boundary while still appearing to work. Treat schema changes and policy changes as one review surface.
👉 Read our full editorial: Elasticsearch query plans shift authorization to the query layer
