We’re looking at the posibility of implementing a sort of ELK hotel service at our corporation using Search Guard for ACLs etc.
For this we give our users access to the index patterns of say ‘user-*’. However we recently discovered a potential issue with aliases.
If user1 has indices with dates, such as user1-applicationname-2017.09.27 then user2 could potentially sabotage for user1 by creating an the index user2-test with the alias applicationname-2017.09.28 which would lead to user1’s application not being able to create the new index at midnight.
To get around this we tried to create an action group with minimum rights but it seems that as soon as a group has indices:admin/create they can create aliases and obviously denying that right won’t let them create indexes to begin with.
Is there any way to get around this?
Either by disallowing rights to alias actions or by seperating indexes and aliases in sg_roles.yml or something?
Our sg_action_groups.yml looks like this:
TEST_USERS:
- “indices:admin/create”
- “indices:admin/get*”
``
sg_roles.yml looks like this:
username:
indices:
‘username-*’:
‘*’:
‘?kibana’:
‘*’:
``
sg_roles_mapping.yml:
username:
users:
``
and sg_internal_users.yml:
username:
User Name
hash: xxxxxxxxxxxxxxxxxxxxxxxx
#password is: xxxxxxxxxxxxxx
roles:
``
Any help would be highly appreciated.
Yes, you can set the permissions so that a user can create any index matching their configured index name patterns, including wildcards, while at the same time disallow them from creating aliases.
The issue here is that alias privileges are cluster-level permissions, not index-level permissions.
For example:
Let’s say you have the following index-level permissions configured:
indices:
‘user1-*’:
‘*’:
‘?kibana’:
‘*’:
``
This will give the user the permission to create any index starting with “user1-”.
If you want to disallow aliases, have a look at the configured cluster-level permissions of that user. Look for permissions like:
And remove them from the cluster level perms. This will remove the privilege for creating aliases, so that the scenario you described can’t happen anymore.
(BTW: Very good catch though, thanks for reporting!)
···
On Wednesday, September 27, 2017 at 4:46:06 PM UTC+2, lmjoebju@gmail.com wrote:
We’re looking at the posibility of implementing a sort of ELK hotel service at our corporation using Search Guard for ACLs etc.
For this we give our users access to the index patterns of say ‘user-*’. However we recently discovered a potential issue with aliases.
If user1 has indices with dates, such as user1-applicationname-2017.09.27 then user2 could potentially sabotage for user1 by creating an the index user2-test with the alias applicationname-2017.09.28 which would lead to user1’s application not being able to create the new index at midnight.
To get around this we tried to create an action group with minimum rights but it seems that as soon as a group has indices:admin/create they can create aliases and obviously denying that right won’t let them create indexes to begin with.
Is there any way to get around this?
Either by disallowing rights to alias actions or by seperating indexes and aliases in sg_roles.yml or something?
Our sg_action_groups.yml looks like this:
TEST_USERS:
- “indices:admin/create”
- “indices:admin/get*”
``
sg_roles.yml looks like this:
username:
indices:
‘username-*’:
‘*’:
‘?kibana’:
‘*’:
``
sg_roles_mapping.yml:
username:
users:
``
and sg_internal_users.yml:
username:
User Name
hash: xxxxxxxxxxxxxxxxxxxxxxxx
#password is: xxxxxxxxxxxxxx
roles:
``
Any help would be highly appreciated.
Thank you for the reply!
That seems to have done half the trick…
I added a cluster section to the sg_roles.yml file which contains the same action group and now the user can’t create an alias through accessing the _aliases endpoint but it’s still possible to create an alias along with the creation of an index.
So this still works:
curl -XPUT -u johndoe ‘https://server:9200/johndoe-test?pretty’ -H ‘Content-Type: application/json’ -d’
{
“aliases”: {
“alias1”: {}
}
}
’
``
While this doesn’t work:
curl -XPOST -u johndoe ‘https://server:9200/_aliases?pretty’ -H ‘Content-Type: application/json’ -d’
{
“actions” : [
{ “add” : { “index” : “johndoe-test”, “alias” : “alias2” } }
]
}
’
``
Action group looks like this:
DOE_USER:
- “indices:admin/create”
- “indices:admin/get*”
- “indices:admin/delete”
``
And the role looks like this:
johndoe:
cluster:
indices:
‘johndoe-*’:
‘*’:
``
Also commented out every line of the sg_action_groups.yml file that contains any mention of alias just to make sure and changed sg_public to only contain monitor/main.
···
On Thursday, September 28, 2017 at 1:24:04 PM UTC+2, Jochen Kressin wrote:
Yes, you can set the permissions so that a user can create any index matching their configured index name patterns, including wildcards, while at the same time disallow them from creating aliases.
The issue here is that alias privileges are cluster-level permissions, not index-level permissions.
For example:
Let’s say you have the following index-level permissions configured:
indices:
‘user1-*’:
‘*’:
‘?kibana’:
‘*’:
``
This will give the user the permission to create any index starting with “user1-”.
If you want to disallow aliases, have a look at the configured cluster-level permissions of that user. Look for permissions like:
And remove them from the cluster level perms. This will remove the privilege for creating aliases, so that the scenario you described can’t happen anymore.
(BTW: Very good catch though, thanks for reporting!)
On Wednesday, September 27, 2017 at 4:46:06 PM UTC+2, lmjo...@gmail.com wrote:
We’re looking at the posibility of implementing a sort of ELK hotel service at our corporation using Search Guard for ACLs etc.
For this we give our users access to the index patterns of say ‘user-*’. However we recently discovered a potential issue with aliases.
If user1 has indices with dates, such as user1-applicationname-2017.09.27 then user2 could potentially sabotage for user1 by creating an the index user2-test with the alias applicationname-2017.09.28 which would lead to user1’s application not being able to create the new index at midnight.
To get around this we tried to create an action group with minimum rights but it seems that as soon as a group has indices:admin/create they can create aliases and obviously denying that right won’t let them create indexes to begin with.
Is there any way to get around this?
Either by disallowing rights to alias actions or by seperating indexes and aliases in sg_roles.yml or something?
Our sg_action_groups.yml looks like this:
TEST_USERS:
- “indices:admin/create”
- “indices:admin/get*”
``
sg_roles.yml looks like this:
username:
indices:
‘username-*’:
‘*’:
‘?kibana’:
‘*’:
``
sg_roles_mapping.yml:
username:
users:
``
and sg_internal_users.yml:
username:
User Name
hash: xxxxxxxxxxxxxxxxxxxxxxxx
#password is: xxxxxxxxxxxxxx
roles:
``
Any help would be highly appreciated.