support for kibana_dashboard_only_user

[alex...@gmail.com]

Hi,
is there any way with SearchGuard to emulate behaviour of the kibana_dashboard_only_user role of X-Pack security?
I mean: is there any way with SearchGuard to create a dashboard_only user ?
(cfr. https://www.elastic.co/guide/en/kibana/current/xpack-dashboard-only-mode.html ) 

Thanks
Alessandro

[SG]

https://github.com/floragunncom/search-guard-kibana-plugin/issues/48

> Alessandro
>
> --
> 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/aeb8573e-6e5a-486b-aad6-61c5bcb95bd4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Neal Rauhauser]

I followed the instructions mentioned here and it does not yield a working Kibana only user. I examined the various files in sgconfig and I don't see the strings related to this type of account.

https://docs.search-guard.com/latest/kibana-read-only

This seems like it should be simple to do, but I've just started reading on roles and mappings and such. Anyone have a guide to making it work?

[Jochen Kressin]

The main difference between the X-Pack dashboard only mode and the Search Guard read-only mode is that with Search Guard you can basically use any role for it. With X-Pack, you need to use the built-in "kibana_dashboard_only_user" role.

The Search Guard approach is more flexible, but as a downside requires more steps:

1. Set up a Search Guard role for read-only mode

This can be basically any Search Guard role, but the most common use case is to create a role which has READ permissions for all indices used in the visualization/dashboards. For example, you can create a role that has READ permissions for all indices and types. In production, you might want to create a role with more restrictive permissions. As a starting point you could use the following role definition:

sg_kibana_read_only:
  cluster:
    - CLUSTER_COMPOSITE_OPS_RO
  indices:
    '*':
      '*':
        - READ

2. Assign the read-only SG role to users

Next, make sure that you assign this role to the respective Kibana users. This is where the role mapping comes into play. The roles_mapping.yml file tell Search Guard how to map users to Search Guard roles. This can be done by mapping the username or backend roles (e.g. LDAP groups, group claims in a JWT) to Search Guard roles:

https://docs.search-guard.com/latest/mapping-users-roles

You can double-check that the user is mapped correctly to Search Guard roles by following this troubleshooting article:

https://docs.search-guard.com/latest/troubleshooting-search-guard-user-roles

So for a read-only Kibana user, the mapping could look like:

sg_kibana_read_only:
  users:
    - jdoe

 In addition you should also assign the "sg_kibana_user" role. This role defines the minimum permissions any Kibana user needs to have:

sg_kibana_user:
  users:
    - jdoe

(This example is based on the username, but you can of course also work with backend roles here. Note that also wildcards and regular expressions are supported here).

3. Configure the read-only role in kibana.yml

As the last step, you need to tell Kibana which Search Guard roles should be assigned to the read-only mode. This is done in kibana.yml like:

searchguard.readonly_mode.roles: ["sg_kibana_read_only"]

This last step requires a restart of Kibana.