Kibana: Saved object authorization - Phase 1

[tbragin]

Currently, Kibana does not support any fine-grained access control in the UI, so all dashboards, visualizations, and saved searches are available to every authenticated user. This may present a problem when Kibana is used by multiple groups that wish to share a single Kibana instance and restrict who can see each of these saved objects.

To be clear, a reasonable workaround at this time is to set up multiple Kibana instances, one per group. However, as the number of groups gets large and dynamic, this may not be an ideal approach.

Here we propose an initial cut at proposed functionality and workflow for sharing one Kibana instance among multiple groups with different access rights. At a high-level this enhancement will allow for two things:

• Saved objects (views, dashboards, searches) can be grouped
• Users will have access to these groups

From an interaction perspective, we propose to explore using the concept of object tags to group Kibana objects (#1052).

• Saved objects can be tagged
• Users can also be associated with tags
• Anyone can create new tags and associate them with user groups
• If a user is associated with a tag, this user has all access to the saved object (view, modify, delete, etc..)
• If a user is associated with a tag, this user can also add this tag to any object he already has access to (users can delegate rights to objects they have access to)
• If a user is associated with a tag, this user can also add any other user to this tag (users can modify membership of groups they are a part of)
  When a user creates a new object and does not assign a tag to it, the “everyone” tag is automatically assigned and the object is visible to everyone
• If a user wants a private object, he can create a new tag only associated with himself
• There is a static “everyone” tag that every user gets. Assigning this tag to an object makes it accessible to everyone.

Out of scope for this phase:

• No fine-grained capabilities, such as create, update, delete, view (all-or-nothing access to objects)
• No special superuser privileges, such as ability to restrict access to administrative actions, such as modifying advanced settings, adding index patterns, etc..
• No fine-grained access to parts of saved objects (e.g. particular buttons, parts of a specific visualization, etc..)

Related issues: #1559, #3904

[surbhi26]

+1

[chandlermelton]

tbragin: you mentioned a workaround using multiple kibana instances. that would work for me as i only have two groups. one gets full access, the other would be limited to certain types of logs such as access logs.

for this setup, would i need to save access logs to an additional index that the second kibana instance connects points to?

[Malu44]

Does this approach works with Shield?

Currently we use multiple Kibana instances with different .kibana-index to split our groups.
User in the group should see different dashboard / data.
For every new group we've to setup an new instance. This would be a big issue for our customer.
Due to organizational requirements this generate costs.

[rashidkpc]

via @dannymeijer in #4714

In our use-case we are looking to start deploying Kibana to a very broad user base. To prevent issues with people 'accidentally' breaking something for someone else (for example, deleting someone else's dashboard) we want to be able to define authorization levels.

I was thinking something like this (as an example):

A regular user:
Can discover and use any of the stored visualizations, but you don't want a regular user to 'mess anything up'. Unable to save or manage objects.
A privileged user:
Has some more rights than a regular user. Can create dashboards and manage some of the settings, but nothing too extensive.
Power users:
people that can modify everything.
Problem (as far as I can tell with the current releases) is that the level of lockdown is not to this level of detail that I am explaining. For example, I am able to remove the settings plugin, which gives me some security that the the settings will not get messed with. But this also removes the functionality/ability for users to manage saved objects (since it is nested within the settings plugin).

Another example of this is visualizations. I don't want regular users to create and store visualizations (they are just stopping by to check out content that is already there) - but disabling the visualization plugin will not just remove the visualizations tab; it completely disables all and every visualizations.

I hope I was extensive enough with examples to portray what I am talking about. The solution I had in mind would involve having the ability to customize in a more detailed level what users are presented with, maybe in the form of tags or buckets that you can predefine.

A requirement for this to work is obviously that the authentication framework is in place (issue #3904 / #4419 / #4634).

[TinLe]

+1

If this can be tied to LDAP/AD where we already have different groups defined, that would be very nice.

[gustavomr]

+1
with LDAP!

[sand0id]

+1
We're in the same situation as @Malu44, so would be great to integrate this with Shield

[Kudo]

+1

[tehsphinx]

+1

[tulku]

+1

[cdenneen]

+1

[schast]

+1

[davidw2]

+1

[dev-rke]

+1

[etfeet]

+1

[raphaele81]

+1

[jonatansver]

+1!!
People that are meant to only warch my dashboard for analisys and getting information change my dashboards and visualizations(most of them think the changes are local) and i must import a backup every now and then.....
Group permissions will be great!

[basicNew]

+1, this is so much needed.

[cjfpainter]

+1

[resyst-it]

+1

[ppf2]

+1 Setting up separate Kibana instance is not a good option for deployments with a service offering for thousands of customers, etc..

[ericodom]

+1

[gnom1gnom]

+1000

[marcinkubica]

Already doable with embeded dashboard.

Though it needs layout locking and the top bar display with timepicker.

On Wednesday, 25 November 2015, gnom1gnom [email protected] wrote:

+1000

—
Reply to this email directly or view it on GitHub
https://github.com/elastic/kibana/issues/4453#issuecomment-159556182.

Sent from Gmail Mobile

[megastef]

How does this work with the limitation having only one kibana_index per Kibana Server?
I think each user needs his own index patterns, as he might not have access to all indicies.
Can Index-Patterns be filtered per user?

[jmendiara]

+1

[palmerabollo]

+1

[DirtyPeanut]

+1

[debelyoo]

+1

[lentregu]

+1

[veeruborra]

+1

[Hronom]

+1

[IGI-111]

+1

[GerySt]

+1

[srpatatas]

+1

[pankajkumar]

+1

[rachorzzz]

+1

[zindello]

+1 this would put Kibana on a level playing field with Graylog2 which I'm looking to avoid using due to the complexities of deployment.

[hkarpf]

+1

[sergiolr100]

+1

[mattibf]

+1

[pemontto]

+1

[ilu]

+1

[hariwalters]

+1

[sleeper-service]

Noticed it's not there in Kibana 5 either.
+1

[vincent-ollivier-everysens]

+1

[developersloth]

+1

[amitripshtos]

+1

[FlorentGuillin]

+1

[GemsWest]

+1

[simpleuser99]

+1

[kunwon1]

+1

[guidodobboletta]

+1

[aremai]

+1

[abdalians]

+1

[vinodtalati]

+1

[yuwtennis]

+1

[mgoritzk]

+1

[urtens]

+1

[sergiolr100]

Hi all,

could be this a possible solution?

I used 5.2.0 version. In Kibana-Management-Users, create an user (user1) and specific role for this user (role1).

This user only must have access to the index "example-*", and only their visualizations, dashboards, searches...

== ROLE1 ==

Name: Role1
Cluster privileges: None
Index privileges:

| Indices: example-*
| Privileges: read, view_index_metadata
| Granted Fields: *

+

| Indices: .kibana
| Privileges: read, view_index_metadata
| Granted Fields: *
| Granted Documents Query

{
  "bool" : {
      "should" :  [
              { "term" :  { "_id" : "default_index" } },
              { "term" :  { "_id" : "5.2.0" } },
              { "term" :  { "_id" : "example-*" } },
         { "term" :  { "_id" : "DASHBOARD1" } },
         { "term" :  { "_id" : "DASHBOARD2" } },
         { "term" :  { "_id" : "..." } },
         { "term" :  { "_id" : "VISUALIZATION1" } },
         { "term" :  { "_id" : "VISUALIZATION2" } },
         { "term" :  { "_id" : "..." } },
         { "term" :  { "_id" : "SEARCH1" } },
         { "term" :  { "_id" : "SEARCH2" } },
         { "term" :  { "_id" : "..." } }
      ],
      "minimum_should_match" : 1
  }
}

You can create a neutral default index empty for all users. PUT /start

Regards

[AlexandrTuniev]

Any updates on this ?

[xycloud]

+1

[looofi]

плюс один

[vg15]

@sergiolr100

Well I like the solution but facing some issue. Extremely sorry that I am asking query here .
So my role is like
Rolename :- Management
Cluster privileges: None
Index privileges:
| Indices: management
| Privileges: read, view_index_metadata
| Granted Fields: *

| Indices: .kibana_management
| Privileges: read, view_index_metadata
| Granted Fields: *
| Granted Documents Query

{
  "bool" : {
      "should" :  [
{ "term" :  { "_id" : "management" } },
{ "term" :  { "_id" : "5.2.2" } },
{ "term" :  { "_id" : "7a386190-19e5-11e7-90e2-a52016cb5a60" } }
      ],
      "minimum_should_match" : 1
  }
}

With above I cannot see data/document in the discover page, however with elastic user who created this index (management) can see the document/data in the discover page . FYI i have merged both above settings in a single role only also here ID is my visualization ID even this is not showing any data.

[drakkhen]

+1

[AndreAga]

+1

[guyboertje]

Apache Shiro inspired me to create Rushiro https://github.com/guyboertje/rushiro for an e-commerce Rails platform that I worked on a few years back.

From what I have seen of the AWS permission system, it too is inspired by Shiro.

------ extract
The permission part has several pipe separated sections, you are completely free
to choose the schema, but remember that evaluation is on a left to right basis.

One suggestion might be: Domain|Action|Instance

• Domain - aka resources, e.g. webpages, db entities, domain models or services
• Action - entries from the set of actions available for the domain (crud, rw, use/manage)
• Instance - these entries are 'labels' you have given to instances of the domain,
  e.g. a particular webpage, a uuid or unique id of a db record
  Note: Multiple comma separated entries are allowed, as is the * wildcard

example: this hash is processed into a hierarchy of objects

perm = {
  allows: {
    individual: [
      "feature|create,read,update|feat-x",
      "page|*|posts",
      "company|read"
      "company|update|5b90a720-e6b0-012e-dc18-782bcb979e60"
    ],
    organization: [],
    system: []
  },
  denies: {}
}

access_control = AllowBasedControl.new(perm)
access_control.permitted?("company|read|5b90a720-e6b0-012e-dc18-782bcb979e60") ==> true
access_control.permitted?("feature|delete|feat-x") ==> false

------ extract

[arult]

Hi @tbragin
Any update on this enhancement? When and which version of Kibana we can see this? Will this be available as open source?

[dfinkbeiner]

What is the issue # in GitHub to enhance kibana to provide real fine grained access to kibana objects (where some users will have read, others can have full access) based on roles/group memebership? I can't find any. If that issue doesn't exist yet, it should. The approach used in this issue with tags that you can assign to objects still gives all users with that tag the same access level (full access) - not what a lot of people want. Thanks.

[mostrovoi]

Best solution I found so far regarding this issue:

https://github.com/wtakase/kibana-own-home

[CamiloSierraH]

+1

[StephanBenning]

+1

[georgezoto]

+1

[dbroeh]

+1

[drakkhen]

Our company has figured out how to solve this problem: give up on ELK and just use Splunk. ELK is fine for a few people on a close-knit team but Splunk has way better user account-related functionality for a larger team or multiple teams.

[tudro]

+1

[patrickmhoge]

+1

[jeffrey-e]

+1, would love to see this feature be implemented in any proper form!

[Sjaak01]

+1 but three years in and I don't believe anything has been done on this front?

We want to give outside access to our Kibana instance but fine grained access to dashboards is a MUST. Even internally this is kind of a necessity and I suppose that goes for everyone using Kibana outside of a small team.

[timroes]

cc @elastic/kibana-security please feel free to close and refer to a more up to date issue, if there is any

[kobelb]

Superseded by https://github.com/elastic/kibana/issues/18473