OpenSearchCon Europe 2026

The current index authorization model in OpenSearch has a few quirks and weaknesses; these will be mostly noticeable when working in OpenSearch Dashboards or similar applications with users which have only limited access to indices. Thus, if you do not take care and forget to flip certain switches, you will encounter quite a few "Forbidden" errors in OpenSearch Dashboards.
Over the past year, we have been working on a new index authorization concept for OpenSearch. The goal is a more logical and intuitive authorization model that provides a smoother and more predictable user experience.

This new approach is expected to be introduced as an optional feature in an upcoming OpenSearch release and is planned to become the default in OpenSearch 4.

In this talk, we will explain the new authorization concept, highlight its advantages, and provide practical guidance for cluster administrators on how to roll it out safely without causing service interruptions.

Cost-effective data tiering in OpenSearch has traditionally meant moving older indices to warm storage that is optimized for density rather than mutability. In practice, this comes with no write support and intrusive migration workflows that rely on forced segment merges, serial processing, and heavy CPU and IO usage—frequently impacting production workloads and operational stability.

In this talk, we introduce Writable Warm, a new tiering architecture designed for remote-storage-backed clusters that removes the read-only constraint while simplifying operations. Instead of heavyweight migrations, Writable Warm relies on fast shard relocation, block-level data access, and lazy recovery to support sustained writes and reads on warm data.

We will walk through the core design decisions behind block-level fetching, replica-aware recovery, and concurrent seamless migrations, and explain how eliminating forced merges improves stability and predictability at scale. Attendees will learn how this approach enables faster tier transitions, better resource utilization, and meaningful cost reductions—without changing application behavior or operational workflows.

The Norwegian Labor and Welfare Administration (NAV) manages 1/3 of Norway’s state budget. Supporting their "product-first" paradigm for 20,000 employees required a shift from legacy monoliths to a centralized, self-service observability stack. NAV partnered with Aiven to migrate their logging infrastructure to a managed OpenSearch environment. Aiven has been a strategic partner of NAV by hosting some of NAV’s most critical data services for many years. As a founding member of the OpenSearch Foundation with active maintainers, Aiven provided a unique advantage in helping NAV adopt OpenSearch for their application logging.
This technical deep-dive covers:
* Migration Architecture: High-throughput logging from on-premise to a managed service with zero-downtime
* Scalability & Performance: Shard rebalancing, customized scaling, and automated snapshots
* Data Pipeline: 60TB of log data, and OpenTelemetry traces with Data Prepper
* Operational Stability: Self-healing nodes and alert integrations with Slack.
We will cover usage scenarios of OpenSearch dashboards and take a close look at how Aiven delivers and operates OpenSearch as a managed service at Nav’s scale.

Every infrastructure outage tells the same story: a YAML mistake years in the making, hiding in plain sight until production burns. Teams patch symptoms, not causes because today's tools treat manifests as dumb text.

This talk reveals how OpenSearch becomes your infrastructure's immune system: a semantic search engine that understands Kubernetes YAML intent, not syntax. We transform manifests into queryable configuration graphs, parsing what matters-resource quotas, RBAC permissions, network policies, dependency chains rather than line counts.

Attendees will learn how OpenSearch can be used as a preventive debugging tool for infrastructure, enabling teams to detect configuration risks earlier and reason about changes with greater confidence.