Managing Multi‑Tenant Dashboards in Kibana with Spaces

Problem: One Kibana, Many Teams

In a typical observability stack, a single Kibana instance serves dozens of teams, each with its own dashboards, visualizations, and saved objects. Without isolation, a user can accidentally view or edit another team’s work, or worse, see data they shouldn’t. Kibana’s Spaces feature was introduced to solve this exact problem by giving each team its own logical workspace within the same deployment.

Thesis: Spaces let you share a Kibana deployment safely and move it between clusters

Spaces create isolated work environments that keep dashboards, visualizations, and other saved objects separate. They integrate with Elasticsearch security, can be exported and imported, and are stored in the same .kibana index that powers Kibana. By following a clear workflow, operators can give teams independent access while keeping the underlying data shared.

1. What Spaces Are

• Each Space has an ID (e.g., dev), a name (e.g., Development), and an optional description.
• Saved objects inside a Space are prefixed with that Space’s ID, so they don’t collide with objects from other Spaces.
• Spaces do not isolate the data indices; they only isolate the UI objects. Index-level security must still be enforced via Elasticsearch roles.
• The metadata for all Spaces lives in the .kibana index under the kibanaSavedObjectMeta field.

2. Creating and Assigning Spaces

Spaces can be created and managed either through the Kibana UI or via the Saved Objects API. The following steps illustrate the UI path, which is most common for operators.

1. Open Kibana and click the gear icon (Management) → Spaces → Create space.
2. Fill in:
   • Space ID: prod (must be unique and URL‑safe)
   • Name: Production
   • Description: optional
3. Click Create.
4. Navigate to Manage → Users & Roles.
   • Click Add user.
   • Enter the USERNAME and choose the prod Space from the dropdown.
   • Save.

To perform the same steps via API, run the following in Dev Tools or with curl (replace placeholders):

POST /api/spaces/space
{
  "id": "prod",
  "name": "Production",
  "description": "Production dashboards"
}

Assign a user to the space via the UI or by updating the user’s role in the kibana_user role. The role must include the space:prod permission.

3. Exporting and Migrating Spaces

Because Spaces are stored as saved objects, you can export a Space’s content and import it into another Kibana cluster. This is handy for cloning a workspace or moving from staging to production.

POST /api/saved_objects/_export?type=space&includeReferencesDeep=true
{
  "objects": [
    {
      "type": "space",
      "id": "prod"
    }
  ]
}

The API returns a zip file containing the Space and all referenced objects. To import:

POST /api/saved_objects/_import
Content-Type: multipart/form-data

--boundary
Content-Disposition: form-data; name="file"; filename="space_prod.zip"
Content-Type: application/zip

<binary data>
--boundary--

After import, verify by opening the target Kibana instance, selecting the prod Space, and ensuring dashboards load. Remember that the export does *not* include the underlying Elasticsearch indices; you must migrate those separately.

4. Trade‑offs & Best Practices

• Storage Growth: Each Space adds metadata to the .kibana index. Large numbers of Spaces can inflate index size and affect backup/restore times. Monitor .kibana size with GET .kibana/_stats.
• Permission Risks: Mis‑assigning a user to the wrong Space can expose dashboards or allow edits. Test role assignments in a staging environment before applying to production.
• Data Isolation: Spaces do not separate data indices. If a team should not see certain indices, enforce that with Elasticsearch roles and index‑level permissions.
• Feature Support: Some Kibana plugins may not be Space‑aware. Verify plugin compatibility before enabling Spaces in a production environment.

5. Next Steps

1. Audit existing dashboards and decide which belong in separate Spaces.
2. Create a Space per team or per environment (dev, test, prod).
3. Assign users and verify access via the UI or API. Use GET .kibana/_search?pretty to confirm the Space’s metadata is present.
4. Export Spaces for backup or migration.
5. Monitor .kibana index growth and adjust your backup strategy accordingly.

By following this workflow, you can keep dashboards cleanly separated, enforce proper permissions, and move workspaces between clusters with minimal friction.