Wildcard access and access to all (non private) tenants, default values for new tenants

23 views
Skip to first unread message

Lucas Bremgartner

unread,
Jan 10, 2019, 1:54:56 AM1/10/19
to search...@googlegroups.com
Hi,

We are currently running a PoC with Search Guard and the multi tenancy feature provided for Kibana. So far it is working mostly well with the following open questions:
  • Is there a way to grant a user access to multiple tenants (even dynamically created ones), which share the same prefix without adding each tenant to the Search-Guard roles
  • Is there a way to grant e.g. admin users access to all (maybe restricted to non private) available tenants without listing all of them in a Search-Guard role (related/similar to the first question)
  • All the Kibana advanced settings (e.g. xPackMonitoring:showBanner, dateFormat) are stored in each Kibana tenant seperately. This of course makes sense and is also favored by us. But it would be beneficial, if a standard set of settings could be defined (something like a template), which is automatically applied, if a new Index for a new Tenant is created, such that the user experience is the (at least initially) the same in all tenants.
  • If I try to create a Search Guard role which includes only tenants (e.g. to solve/workaround the problem in questions 1 & 2), I get the following error: "Please define at least cluster permissions or index permissions". Why is it no supported to create a Search Guard role, which only controls access to tenants?
Any thoughts on this?

Kind regards

Update: Added question 4.

Lucas Bremgartner

unread,
Jan 14, 2019, 6:44:24 AM1/14/19
to Search Guard Community Forum
Are these questions better asked in Github issues on the respective repositories?

SG

unread,
Jan 14, 2019, 7:56:30 AM1/14/19
to search...@googlegroups.com


> Am 10.01.2019 um 07:54 schrieb Lucas Bremgartner <lucas.br...@gmail.com>:
>
> Hi,
>
> We are currently running a PoC with Search Guard and the multi tenancy feature provided for Kibana. So far it is working mostly well with the following open questions:
> • Is there a way to grant a user access to multiple tenants (even dynamically created ones), which share the same prefix without adding each tenant to the Search-Guard roles

That is currently not possible. Maybe you can solve it by creating the sg_roles.yml file via a script or use the REST API accordingly.
Depending on your exact use case you can also try to create "tenant only roles" and assign them to the respective users.

Can you describe the use case in more detail?

> • Is there a way to grant e.g. admin users access to all (maybe restricted to non private) available tenants without listing all of them in a Search-Guard role (related/similar to the first question)

No, but maybe the same approach like above might work

> • All the Kibana advanced settings (e.g. xPackMonitoring:showBanner, dateFormat) are stored in each Kibana tenant seperately. This of course makes sense and is also favored by us. But it would be beneficial, if a standard set of settings could be defined (something like a template),

You can file a feature request for that (as github issue).

> which is automatically applied, if a new Index for a new Tenant is created, such that the user experience is the (at least initially) the same in all tenants.
> Any thoughts on this?
>
> Kind regards
>
> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/358abb5e-2f29-4922-aa10-bd0aea968d63%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Lucas Bremgartner

unread,
Jan 17, 2019, 1:39:33 AM1/17/19
to search...@googlegroups.com
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

Lucas Bremgartner

unread,
Jan 17, 2019, 1:45:04 AM1/17/19
to Search Guard Community Forum
Created Github issue https://github.com/floragunncom/search-guard-enterprise-modules/issues/28 for the Kibana advanced settings default values.

Lucas Bremgartner

unread,
Jan 17, 2019, 1:55:45 AM1/17/19
to Search Guard Community Forum
Reply all
Reply to author
Forward
0 new messages