You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
@rashidkpc I appreciate that you moved it. However, I created this issue due to the fact that the issue you highlight mentions this:
"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..)"
I believe am requesting super-user priviledges and fine-grain control. or not? :)
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):
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).
The text was updated successfully, but these errors were encountered: