Elasticsearch Proxy Bundle Laravel Package

Product Decisions This Supports

• Search-layer authorization architecture: Whether tenant/user isolation for Elasticsearch lives in the application (query rewriting), a sidecar proxy (this pattern), or native engine security. This package is evidence that the "authorization proxy" pattern is real and buildable — it terminates client credentials and centralizes access decisions in front of the cluster.
• Build vs. buy vs. borrow: Use it as prior art to scope a build. Reading/forking it is days; designing tenant isolation from scratch is weeks. It also frames the buy option: Elasticsearch/OpenSearch native document- and field-level security, or a gateway with ext_authz + OPA.
• Feature scoping for multi-tenant SaaS: If any roadmap item requires per-tenant search results from shared indices (search, reporting, admin consoles), the isolation mechanism is a prerequisite, not a follow-on. This package shows the surface area that decision touches: index naming, filter injection, credential handling, audit logging.
• Compliance posture: For SOC 2 / GDPR conversations, "we rely on an unmaintained 2020 proxy for access control" is a finding. The decision this informs is whether access control is an owned, tested component or an inherited one.
• Platform vs. product-team ownership: A central proxy makes search authz a platform capability with one enforcement point — cheaper to audit, but a shared bottleneck and single point of failure.

When to Consider This Package

Consider it only as reference material, or as a fork you fully own, when:

• You are on Symfony (this is a bundle depending on Symfony's HttpKernel/DI — it will not drop into Laravel without significant rework).
• You are pinned to Elasticsearch 6.x/7.x and cannot adopt native security features or a modern gateway.
• You need a short-lived stopgap and have someone who can read, audit, and maintain the authorization logic themselves.
• You want a concrete example of query rewriting and tenant-filter injection to validate your own design.

Look elsewhere when:

• You are a Laravel shop — dependency mismatch, no AppKernel, no bundle registration.
• You need maintained security code. Zero stars, zero dependents, and no release since 2020 means no battle testing and no one shipping fixes; treating it as a Composer dependency is an audit liability.
• You are on Elasticsearch 8 / OpenSearch — API and security model have moved; native DLS/FLS or a policy engine (OPA, Cedar) is the better bet.
• You need vendor support, SLA, SSO integration, or field-level masking.

How to Pitch It (Stakeholders)

Summary: xola/elasticsearch-proxy-bundle is an MIT-licensed Symfony bundle from Xola that puts an authorization proxy in front of Elasticsearch. It is useful to us as a reference design, not a dependency.

For executives: This is not a purchase decision — it's a de-risking input. It shows a proven-in-production-at-one-company approach to keeping tenants from seeing each other's search results, which is a compliance-critical capability. We still own the code and the security review either way.

For engineering: The pattern — centralize authz, rewrite/inject tenant filters, terminate cluster credentials at the proxy — is worth a short spike before we commit to a design. Do not composer require it: last release 2020, no dependents, no maintainer, and it targets Symfony + ES 6/7. Read it, fork it if the logic fits, or use it to justify native ES/OpenSearch security or an OPA-based gateway.

Recommendation: Evaluate as prior art in week one of the search-isolation effort; make the real decision between native engine security and application-layer query enforcement, and record why.