-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
all users can delete indexes and modify Advanced settings, not possible to prohibited that #11647
Comments
I agree with this, re index patterns at least - it is a significant issue. ELK devs - please could you give some indication of when this might be resolved? |
We have to make sure to keep the following concepts straight:
Deleting an index pattern does not delete the indices matched by the pattern. A Is it correct to say that this enhancement request is for the ability to assign |
"Is it correct to say that this enhancement request is for the ability to
assign
different permissions to users to read and write index pattern definitions,
similar to what is already possible with the data indices?"
I hate the word 'enhancement' as it indigates in this particular case that
system is designed to work so that all users are like superusers.
It is Security risk (huge!) if users are able to delete index patterns and
modify advanced settings.
"Advanced settings" already sounds so that normal user should not have any
access to that.
There are separate user roles like Kibana_system and superuser who should
have then only access to modify those settings.
Kibana_user role should be role for "dummy" users who will have very
limited READ access rights to system, nothing else.
Now it is like next to God.
…On Tue, May 9, 2017 at 12:28 PM, Felix Stürmer ***@***.***> wrote:
We have to make sure to keep the following concepts straight:
- The *data indices* hold the documents that are supposed to be
visualized in
Kibana. They can be protected from unauthorized access on the database
level
using the comprehensive security mechanism that is part of x-pack.
- The *index patterns* are a unit of configuration for Kibana, that
are stored
in the Kibana index (.kibana by default). Since they are read and
written by
the Kibana server process, they are currently readable and writable by
any
Kibana user. This is something that is being worked on (see #4453
<#4453>).
Deleting an index pattern does not delete the indices matched by the
pattern. A
user does not have to have write permissions to an index that contains
data to
be visualized.
Is it correct to say that this enhancement request is for the ability to
assign
different permissions to users to read and write index pattern definitions,
similar to what is already possible with the data indices?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#11647 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AbNaMX_3_-H8KbebjmW4d458L6DoOsQ9ks5r4DHCgaJpZM4NTy-1>
.
|
Elasticsearch version: 5.2.2
Description of the problem including expected versus actual behavior:
All users with basic role 'kibana_user' can go and delete any index patterns even the user won´t be able to see the data from Vizualizer or Discover.
Case there there is more than 1 indexes (Indexes A, B and C) and user has 2 roles, 1 for special index (Index A) and another is 'kibana_user'.
So if the user has only read access for special index (Index A), but because 'kibana_user' is having delete access rights, it means that user is able to delete all indexes (Index A, B and C) even user does not have specified access for those (Index B and C).
Without role 'kibana_user' user is not able to see any of those indexes. So 'Kibana_user' has to give to ALL users, which means that ALL users gets DELETE access rights..
Quite big security risk..
I would say role 'kibana_user' should only have read access right, nothing else.
Then new roles can be created and suitable access rights granted separatelly.
The text was updated successfully, but these errors were encountered: