Object Level Security

[kobelb]

Object Level Security

ACL

To enable OLS, an ACL with the following format will be attached to all securable objects:

{
  "owner": 123456789,
  "read": {
    "users": [ { id: 123456789, can_share: true } ],
    "roles": [ { id: "role_one", can_share: false } ]
  },
  "write": {
    "users": [ { id: 123456789, can_share: true } ],
    "roles": [ { id: "role_one", can_share: false } ]
  }
}

The users and roles above reference Elasticsearch users and roles. In addition to the Elasticsearch roles, we will utilize a role of * to denote all authenticated users.

If the user has write they will implicitly be granted read. When a user or role is assigned read or write they will be able to specify whether this user or role will be able to share the securable object with others. If the user has read and they can share the object, they will only be able to add other users and roles to read. If the user has write and they can share the object, they will be able to add other users and roles to write and read.

Implicit read permissions

When a user has read access to a Dashboard, they will implicitly be granted read access to all related Visualizations and Saved Searches. The same logic will apply once Index Patterns themselves are made securable and if a user has read access to a Visualization or Saved Search, they will be implicitly granted read access to the Index Pattern.

This simplifies the access model and allows users to assign access to the object that they intuitively wish to share without having to concern themselves with the graph of related objects. It also simplifies the technical implementation so we don’t have to explicitly assign access to the related objects and then determine if/when it should be removed when a parent object’s ACL is modified.

When a user is implicitly granted read access to a Visualization or Saved Search, it won’t show up in the user’s list of Visualizations or Saved Searches, it will only be accessible in the Dashboard UI/API. This is similar to how we’ll implement it technically, we’ll allow users to gain access to the related objects via the Dashboard, which will implicitly be granting them read access.

Summary

OLS will make Saved Searches, Dashboards, Visualizations, Index Patterns and other Kibana applications (Machine Learning, Graph, Timelion) saved objects securable based on the previously described ACL.

When an object has no owner, it emulates the way that Kibana currently functions without OLS where all authenticated Kibana users have full permissions. This is purely to support migrations from older versions of Kibana that didn’t have OLS, or users that were running Kibana without security and then enabling security with OLS. An additional “Claim unowned object” privilege will be added to the kibana_user role, and the user will have to have this privilege to claim these unowned objects.

The introduction of owned Index Patterns necessitates the addition of per-user Kibana Advanced Settings, as the default index pattern is defined here. An additional section will be added to the Advanced Settings page to allow a user to override any advanced setting, the same capability will be added to the index management page.

When a securable object has no owner, they will see a dialog similar to the following allowing them to make themselves the owner:

A securable object with no owner will be represented by the non-existence of an ACL.

When a securable object has an owner, they will see a dialog similar to the following allowing them to transfer ownership and define which users and roles can read/write the object:

System administrators will always be able to transfer ownership amd modify the ACL of a securable object, incase a user erroneously claims ownership of an owned object.

All users that have a role granting them a Kibana custom privilege for the specific Kibana instance will be listed, and all roles that have a Kibana custom privilege for the Kibana specific instance will be listed as well.

It should be noted that for Kibana to be able to fully enumerate users, we will have to introduce the concept of user profiles in Kibana (that could potentially power the user specific settings) or have Elasticsearch create users for non-native realms. Currently, Elasticsearch is unable to enumerate all users for SAML/LDAP/etc. realms as these are powered by role mappings.

The list of Saved Searches, Dashboards, Visualizations and Index Patterns will have an owner column added, similar to the following:

From this phase forward, all new securable objects will be owned by the creator and they will have to share them with others. This same logic applies to objects that are imported. They will be owned by the user importing them, and can then be shared.

Additional Kibana applications (Graph, Timelion) will be modified to support a similar mechanism of claiming/transferring ownership, and listing the current owner.

In the future, there’s potential for the Kibana admin to be able to define default permissions for different users, or to use RBAC to limit users being able to create private or public securable objects. However, this level of control will not be introduced in this phase, as it might not be needed and it increases the complexity and implementation time.

[elasticmachine]

Pinging @elastic/kibana-security

[swtrux]

When is this feature coming? It is really needed.

[legrego]

Hey @swtrux,

This is a highly requested feature, but it is also a very complex undertaking. We don't have a definitive timeline for implementing this, but you're at the right place to watch for updates. If you have any requirements that aren't already captured above, feel free to describe your use-case, and we'll take your feedback into consideration when we go to implement this.

[james1465]

The feature would allow one of my customers to realise two use cases that are important to them:

1. Users building a dashboard in private and only allowing other users to see it when it is ready
2. The user who creates the dashboard being the only person who is able to modify it.

They would also want to have a superuser role, where the members of that role can view and edit any object regardless of ownership settings. Would that be possible as part of this feature?

[alinazemian]

It would be great to know if there is any plan to bring this in any 7.x versions or it might be possibly something for 8.x? This is an important feature for us. Currently, the only way we can do this is by limiting users per workspace. This has caused a lot of headache for us to manage redundant workspaces when it comes to updating different objects, dashboards, etc. Knowing when this can be possible will help us to understand if we need to spend our time on automating how we are managing different workspaces or possibly just wait for a new release that will fix this entirely.

[carlopuri]

This feature will be very useful to manage dashboards access... Now with Spaces the access to common dashboards with the various users/dashboards combinations it's a nightmare and we still have errors (we are humans) due to manual update...
So please, add this feature in a future release.... thanks a lot!

[mschuessler]

Are there any plans to implement this. I have the exact same use case as @james1465 . Would appreciate an official statement on this.

[azasypkin]

Are there any plans to implement this. I have the exact same use case as @james1465 . Would appreciate an official statement on this.

OLS isn't on our immediate roadmap, but we've recently resurrected the discussion around private saved objects, which should hopefully cover the use cases mentioned in #39259 (comment). There are no timelines yet though.