Question
Kibana Spaces: enforcing permission checks on cross-space saved object references
Kavi Vale
0 reputation · 19 Jan 2023, 10:01 UTC
36.7K views1
Loading…
0 reputation · 19 Jan 2023, 10:01 UTC
Kibana Spaces isolate saved objects by default, yet dashboards and visualizations can hold references to objects (such as data views) that live in a different space. The documented behavior does not clearly state whether Kibana re-validates the requesting user's privileges on the referenced object's space at render time.
Assume a Kibana 8.x deployment using Spaces for multi-tenancy, with SpaceA and SpaceB, a data view defined in SpaceB, and a dashboard in SpaceA that references it. A role grants a user access to SpaceA only. The goal is a configuration where that user either cannot resolve the cross-space reference at all, or the reference fails closed rather than silently returning data from SpaceB's indices.
The uncertainty is whether any supported setting, role definition, or feature privilege enforces strict isolation here, or whether the only reliable boundary is to avoid cross-space references entirely. Behavior may differ across 8.x releases, so answers should note the version tested.
Does Kibana validate space-level read privileges when resolving a cross-space saved object reference, and is this documented? Is there a supported configuration to make such references fail closed? If not, what is the recommended isolation pattern short of running separate Kibana instances?
33275 reputation · 19 Jan 2023, 13:47 UTC
Kibana does not perform a separate, render-time privilege re-check specifically for cross-space saved object references. Instead, the saved objects repository enforces isolation by filtering on the current space namespace. In a standard Kibana 8.x deployment, a reference to an object that exists only in another space will not resolve for a user who lacks access to that space; the reference fails closed by default. There is no documented, supported configuration in Kibana 8.x to add an extra render-time privilege check beyond this namespace filtering.
The namespace-filtering rule is the primary enforcement mechanism. If a data view is explicitly shared into or copied to SpaceA, it becomes a local object in that space, and access is then governed by the user's SpaceA privileges. Silent data leakage from an unshared object in SpaceB is not expected default behavior. However, exact resolution behavior can vary across 8.x minor releases, and some object types or legacy references may resolve differently than the general rule. Because of this version sensitivity, treat the default fail-closed behavior as reliable but verify it on your specific version.
kibananamespaces field does not include SpaceA.Short of running separate Kibana instances, the supported pattern is to avoid cross-space references entirely. Use the copy-to-space or share-to-space workflows to place required objects, such as data views, into each consuming space. This ensures that every reference resolves against a local object whose access is governed by the user's privileges in that space. Do not rely on undocumented internal APIs or direct Elasticsearch access to bypass Kibana space checks, as this can create security gaps.
The exact 8.x minor version in use would change the recommendation only if release notes indicate a regression or a change in reference resolution for that version.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.