Elasticsearch query plans shift authorization to the query layer

At a glance

What this is: This is a technical guide to Cerbos PlanResources for Elasticsearch, showing how partial evaluation turns authorization policies into query plans and native query DSL.

Why it matters: It matters because IAM and security teams increasingly need authorization to scale with search and analytics workloads without pulling unauthorized data into application memory first.

By the numbers:

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

👉 Read Cerbos' guide to query plans for Elasticsearch authorization

Context

Externalized authorization moves access control out of application code and into a policy decision layer, which is the right pattern when applications need consistent decisions across many services. The problem appears when teams still fetch data first and filter later, because that model leaks cost, complexity, and exposure into the app tier. In identity terms, query-time enforcement becomes part of the control plane, not a post-processing step.

For IAM and NHI programmes, the harder question is not whether policies exist, but where they are enforced and how faithfully they follow the data path. A query planner that can translate policy into native search filters changes how teams think about least privilege, because the authorization decision must align with the shape of the dataset, the schema, and the access path.

Key questions

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. That approach scales better, reduces unnecessary data access, and lets the database enforce the same access boundary that the policy engine defines. The key control is accurate field mapping between policy attributes and Elasticsearch index fields.

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. In Elasticsearch, arrays of objects require nested query handling so conditions apply to the same object instance. Without that, a query can match across unrelated nested values and expose data incorrectly.

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. That creates unnecessary blast radius and makes the authorization layer harder to scale. Query-time enforcement avoids reading records the user should never see.

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.

Technical breakdown

Partial evaluation and query plans in externalized authorization

Partial evaluation takes a policy and resolves the parts that are known at decision time, while leaving resource-dependent conditions as an expression tree. In Cerbos, PlanResources returns a plan rather than a yes or no answer for a specific record. That lets the application convert authorization logic into a database-native filter instead of iterating over every row and calling a check API repeatedly. The important design point is separation of concerns: policy authors define access intent, and the query engine executes that intent at scale.

Practical implication: Model authorization so the database can enforce filterable conditions directly instead of post-fetch screening in application code.

Elasticsearch nested queries and authorization over nested objects

Nested object support matters because real authorization data rarely sits in flat fields. Arrays such as tags, permissions, or scoped attributes require the decision engine to preserve object boundaries when translating policy logic. The adapter maps collection operators like exists and all into nested queries so the database evaluates each nested document correctly. Without that translation, a policy can appear to match across fields that never coexisted in the same nested object, which breaks access semantics and can overexpose records.

Practical implication: Map nested fields explicitly so policy conditions preserve object-level meaning when they reach Elasticsearch.

AST-to-DSL translation and operator mapping

The adapter returns an abstract syntax tree that can be mechanically translated into Elasticsearch Query DSL, including logical, comparison, string, existence, and collection operators. Field maps bridge policy attribute paths to index field names, while operator overrides let teams adapt to schema choices such as keyword versus text fields. This is not just an implementation detail. It is the point where policy intent, schema design, and search behaviour meet, and mistakes here create silent authorization drift rather than obvious failures.

Practical implication: Treat field mapping and operator overrides as part of the authorization design review, not as routine integration glue.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Policy-to-query translation exposes a named governance gap: authorization after data retrieval. That pattern was designed for small result sets and simple checks. It fails when data volume, nested structures, and relevance scoring make post-fetch filtering expensive or incomplete. The implication is that access governance must be designed around the retrieval path, because authorization that happens after exposure is already late.

Elasticsearch field mapping becomes part of the security model, not just the integration layer. The adapter depends on correct mapping between policy attributes and indexed fields, plus special handling for nested structures. If those mappings drift, the query plan can still execute while enforcing the wrong boundary. Practitioners should therefore review schema changes with the same discipline they use for policy changes.

Search authorization needs a query-layer least-privilege model. When access control is embedded in native filters, the engine can evaluate what the user may see without loading unrelated records into application memory. That reduces the blast radius of an overly broad query and aligns authorization with the actual data path. Teams should design for query-layer enforcement wherever large result sets or analytics workloads are involved.

Named concept: identity-aware query planning. This article shows that authorization decisions can be compiled into query plans and executed where the data lives, rather than being rechecked row by row in application code. That matters because identity governance now has to account for search architecture, nested data, and policy translation fidelity. Practitioners should govern the plan, not just the policy text.

From our research:

• 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.
• Search-layer governance also connects to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, especially where access paths change with schema or workload design.

What this signals

Identity-aware query planning: as search and analytics workloads absorb more authorization logic, the real governance question becomes whether policy translation still matches the data path after schema changes, nested object expansion, and field renaming. Teams should watch for control drift whenever access rules move from code to query.

The operational signal is simple: if your programme cannot explain where authorization is enforced in the retrieval path, it cannot prove least privilege at scale. That matters for NHI-heavy environments as much as for human access models, because the same misalignment between identity, data shape, and enforcement point drives exposure.

For practitioners

• 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. This prevents silent mismatches between policy intent and query execution.
• 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.
• Review operator overrides as security decisions If your schema uses text fields, custom analyzers, or non-default field types, verify eq and contains overrides against authorization examples rather than treating them as formatting tweaks.

Key takeaways

• Externalized authorization only scales when policy intent survives translation into native query filters.
• Nested objects and field mapping are security controls, not implementation details.
• Teams that enforce access after data retrieval widen exposure before the decision is made.

Key terms

• Externalized Authorization: A pattern that moves access control decisions out of application code and into a dedicated policy layer. The application asks a decision engine whether an action is allowed, while the policy engine evaluates identity, resource, and context at runtime. This makes authorization more consistent across services and easier to govern.
• Partial Evaluation: A policy evaluation technique that resolves the parts of a decision known at query time and leaves the rest as a structured expression. In practice, it turns access policy into a query plan that a database or search engine can execute directly. This is especially useful when the resource set is large or dynamic.
• Nested Query: A database search construct that evaluates conditions against objects inside an array as complete units rather than flattening them into independent fields. In Elasticsearch, nested queries preserve object boundaries, which is essential when access rules depend on multiple attributes belonging to the same nested record.
• Query Plan Adapter: Software that converts a policy expression tree into the native query syntax of a specific database or search engine. It bridges authorization policy and data retrieval so the enforcement point stays close to the data path. The security value depends on accurate schema mapping and operator translation.

Deepen your knowledge

Query-layer authorization and policy translation are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving access control into search and analytics workflows, this is a useful place to ground the governance model.

This post draws on content published by Cerbos: query plan adapters for Elasticsearch authorization. Read the original.