Spaces, Roles, and Saved-Object Security in Kibana

A Kibana Space is a namespace for saved objects — dashboards, Data Views, rules, maps. It's the right unit for "one product area, one team." Roles grant access to spaces and features.

The layered model

1. Elasticsearch role. What indices can the user read? Enforced in ES — nothing Kibana does can override this.
2. Kibana feature privilege. Within a space, what apps (Dashboards, Dev Tools, Alerting) can the user open, and at what level (all / read)?
3. Space membership. Which spaces does the role apply to?

All three must align. The most common misconfiguration: "why can analysts create alerts but can't see the target index?" — Kibana says yes; Elasticsearch says no; the alert silently returns zero hits.

Document-level and field-level security

For a real multi-tenant setup, don't try to express tenancy through Kibana alone. Use ES's DLS/FLS — a query attached to the role that filters every search automatically.

"indices": [{
  "names": ["events-*"],
  "privileges": ["read"],
  "query": { "term": { "tenant_id": "{{_user.metadata.tenant}}" } }
}]

Now an analyst in tenant A physically cannot see tenant B's data, regardless of which dashboard they open.

Shared dashboards across tenants

A dashboard saved in space shared-ops still resolves data through each user's role. The dashboard is shared; the rows in the charts aren't. This is the cleanest way to hand ops dashboards to customers without maintaining 40 copies.

Audit and rotation

• Enable the audit log. Every saved-object read/write is captured.
• Rotate API keys created for service accounts. A rule runs as the user who created it — deactivated users leave orphaned rules.
• Don't hand out the superuser role "just for now." It doesn't come back.