Kibana Spaces for Logical Multi-Tenancy: Minimal Design and Boundaries

The problem with sharing one Kibana

Teams want their own dashboards, data views and saved objects without running separate Kibana instances. The practical goal is logical isolation per team on a single Elasticsearch cluster and Kibana deployment, with least operational overhead and cost. Spaces provide UI-level separation, but data access is enforced by Elasticsearch Security, not by Kibana alone.

Requirements for team isolation

Isolation means three things: saved objects are visible only to the intended team, queries can only touch the indices the team owns, and changes in one space do not leak into another. Cost and operational overhead push toward sharing one cluster and one Kibana control plane.

Security must be enabled in Elasticsearch and Kibana must authenticate users against it. Without Elasticsearch Security, Spaces only hide UI elements; any user with API access can read all saved objects.

Smallest suitable design

The minimal design is one Kibana Space per tenant or team, with Kibana roles scoped to that space and Elasticsearch roles that grant index and field privileges for the data views used in the space.

Space per team. Create a dedicated space, e.g., team-platform and team-security. Saved objects such as dashboards, visualizations and data views live inside the space. Users are assigned to a Kibana role that lists the allowed space and the saved object types they can read or manage.

Role mapping. A Kibana role restricts space access and saved object privileges. An Elasticsearch role mapped to the same user or backend service grants index privileges for the concrete indices referenced by the data views in that space. The Kibana backend user that Kibana uses to talk to Elasticsearch must have read access to the .kibana* system indices for all spaces it serves.

Least privilege example. For a team that owns logs-platform-*:

• Kibana role: space team-platform, privileges read for dashboards and data views, manage for its own objects.
• Elasticsearch role: index privileges read and view_index_metadata on logs-platform-*, no access to logs-security-*.

Data views in the space must point only to indices the Elasticsearch role allows. If a data view references an unauthorized index, Kibana will render the object but queries will fail or return empty results.

Trust and data boundaries

Kibana trusts the Elasticsearch user identity. The UI boundary provided by Spaces is logical. The real enforcement boundary is Elasticsearch Security: index privileges, field privileges and document level security if enabled.

Saved objects are stored in Elasticsearch .kibana* indices. Space isolation is implemented via a space identifier in the saved object metadata and access control checks in Kibana. A misconfigured role can still allow a user to list objects in another space via the Saved Objects API.

The Kibana backend user is a shared trust anchor. If its privileges are too broad, Kibana can retrieve data on behalf of a user that the user should not see. Limit the backend user to the minimum .kibana* indices and avoid granting it broad cluster privileges.

Operational checks

Checks should be repeatable and auditable.

Review role definitions and space membership in Kibana Stack Management. Confirm each role is restricted to intended spaces and saved object types, and that no role has all_spaces unless for administrators.

Inspect Elasticsearch role mappings. Run from a machine with network access to Elasticsearch and a user with manage_security privilege:

curl -u admin:${ELASTIC_PASSWORD} https://elasticsearch:9200/_security/role/team-platform-role

Verify index patterns match the data views used in the space. Check that the Kibana backend user role includes access to the correct .kibana* indices but not to tenant data indices.

Simulate access with a test user in a non-production space. Log in as the test user and confirm dashboards render only allowed data and cross-space objects are inaccessible. This is a practical way to catch privilege drift.

Monitor Kibana audit logs and saved objects API errors for unexpected privilege use or cross-space access. Export saved objects periodically to detect unauthorized object creation.

Failure modes

Misconfigured index privileges allow cross-space data access. A data view in space A can reference an index the team should not see if the Elasticsearch role is too permissive. The UI will not block this.

Accidental space deletion loses saved objects. Deleting a space removes its saved objects from the .kibana* indices. There is no soft delete. Keep exported saved object backups for critical spaces.

Single control plane outage. All spaces share the same Kibana process and Elasticsearch cluster resources. An outage or performance issue affects every tenant.

Version sensitivity. Spaces privileges and saved objects permissions evolve across major Kibana releases. A role that works in one major version may behave differently after upgrade. Review release notes for security changes before upgrading.

When this design is insufficient

Redesign when requirements move beyond logical isolation.

True physical isolation is needed for regulatory data residency or strict blast radius requirements. Separate Kibana instances or separate clusters per tenant provide physical separation.

Document level security within a shared index is required. Spaces plus index privileges cannot isolate documents inside the same index. That requires Elasticsearch Document Level Security and careful field level controls.

Resource fairness or noisy neighbor problems become unacceptable. Shared cluster resources mean one team's heavy queries impact others. Separate clusters or dedicated node pools become necessary.

Limitations to remember: Spaces provide logical, not physical isolation. All tenants share the same Kibana process and Elasticsearch cluster. The design does not provide document level isolation within an index.