kibana multi-tenancy authz

Search Guard
#1

Hi,

I am currently reconfiguring my sg_config for troubleshooting purposes.
In the process I realized I have difficulty understanding the permissions regarding kibana_user.
The example file contains the following role: sg_kibana_user. It applies to indices .kibana and .kibana-6.
In the context of MT, do I have to repeat that setting for all tenants, e.g. .kibana.*foo and .kibana.*foo-6 ?
If yes, what’s the correct syntax? ?kibana?foo or ?kibana?*foo etc.?

thanks

#2

No, you do not provide any permissions for the tenant indices in the configuration. This is handled internally by Search Guard. Having .kibana and .kibana-6 in the sg_kibana_user role is just a safeguard to support different upgrade scenarios.

···

On Friday, August 3, 2018 at 10:50:41 AM UTC+2, Fabien Wernli wrote:

Hi,

I am currently reconfiguring my sg_config for troubleshooting purposes.
In the process I realized I have difficulty understanding the permissions regarding kibana_user.
The example file contains the following role: sg_kibana_user. It applies to indices .kibana and .kibana-6.
In the context of MT, do I have to repeat that setting for all tenants, e.g. .kibana.*foo and .kibana.*foo-6 ?
If yes, what’s the correct syntax? ?kibana?foo or ?kibana?*foo etc.?

thanks

#3

I see. This raises two more questions:

  1. What about the kibana_own_index role, what’s its purpose? Is the Private tenant a special case?
  2. In the sg_kibana_user role, must the “indices: ‘?kibana’” value match the kibana.yml and sg_config setting for the kibana index?
#4

We do not ship a kibana_own_index role, where did you see it? We do ship a role called sg_own_index. This is to demonstrate variable substitution in index names. Here we use the username of the currently logged in user as index name:

sg_own_index:

cluster:

  • CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

  • INDICES_ALL

``

The private tenant is a special case in regards that you do not have to specify it in any role. Every Kibana user has access to this tenant, unless it is disabled. So we have two default tenants, global and private, and then an arbitrary number of tenants per role.

···

**

Yes, the the Kibana index name in the sg_kibana_user role must match the Kibana index name in kibana.yml and sg_config. Unless you are working with aliases. Aliases are resolved by Search Guard automatically.

On Friday, August 3, 2018 at 5:11:15 PM UTC+2, Fabien Wernli wrote:

I see. This raises two more questions:

  1. What about the kibana_own_index role, what’s its purpose? Is the Private tenant a special case?
  2. In the sg_kibana_user role, must the “indices: ‘?kibana’” value match the kibana.yml and sg_config setting for the kibana index?
#5

Thanks for the clarification. I misread the sg_own_index role I thought it was for the private kibana index.

Cheers