We approached the problem in a way very similar to what you suggested. The first problem we hit was what is mentioned in the above questen 4 (added later). We would like to create Search Guard roles, which only grant access to one (or multiple) tenants. But this is currently not possible, because for a role either a cluster or an index permission is required (error: “Please define at least cluster permissions or index permissions”). We currently use Elasticsearch 6.2, so it could be, that this problem is already fixed in new versions of Search Guard.
So we created a cluster permission, which we think is very minimal like this:
PUT /_searchguard/api/actiongroups/CLUSTER_HEALTH
{
“permissions”: [
“cluster:monitor/health”
]
}
``
Our use case is the following:
We have different applications sending their logs to Elasticsearch. For each application we create a Search Guard Kibana Tenant, which contains the respective Dashboards. We started to create a Search Guard role for each application (what you suggested as well). Now if you have for example a Super User or even an Admin role, which grants a access to multiple or even all Tenants, it would be conveniant to be able to grant this access with a wildcard. Something like this (using the mentioned permission from above):
PUT /_searchguard/api/roles/rw_tenant_foobar
{
“cluster”: [ “CLUSTER_HEALTH” ],
“tenants”: {
“foobar”: “RW”
}
}
PUT /_searchguard/api/rolesmapping/rw_tenant_foobar
{
“backendroles” : [
“Admins”,
“UserGroupA”
]
}
``
What I would like to do is this (no longer have the need for a workaround cluster permission, grant access to tenants with wildcard):
PUT /_searchguard/api/roles/rw_all_tenants
{
“tenants”: {
“*”: “RW”
}
}
PUT /_searchguard/api/rolesmapping/rw_all_tenants
{
“backendroles” : [
“Admins”
]
}
PUT /_searchguard/api/roles/ro_foo_tenants
{
“tenants”: {
“foo*”: “RO”
}
}
PUT /_searchguard/api/rolesmapping/ro_all_tenants
{
“backendroles” : [
“FooReaders”
]
}
``
Now I understand, that this permission alone will not work, because there is no way for Search Guard to know the list of all possible tenants. So what we have here is a very close link between the information, what entities (tenants) exist and the permissions to the existing tenants. I think, it would be better, if these two are not linked so closely (e.g. have a separate config file for the definition of the tenants or even allow the creation of new tenants over API, while keeping the permission part as it is today with the addition of wildcards).
In regards to grant an Admin access to a privat tenant of a user we did not yet test, if this works with tenant only roles. The problem here is, that if the users are authenticated by an external authentication provider, let’s say LDAP, then we do not necessarily know all the users in advance (or it could easily change over time with new users joining), so it would be very hard to maintain the access for the Admin users to all the private tenants without the wildcard permission. The reason, we would possibly like to have this is for support cases, where a user complains, that he has a problem with the his private dashboard, but no one except for him is able to see these dashboards, because they are private to this user.
For the advanced settings part I will create a Github issue.
BR
Lucas