Kibana Multitenancy Issue

1

Hello,

We are having an issue when trying to use multitenancy with Kibana.
The config we are using is the following:

 readonlyrest:
   prompt_for_basic_auth: false
   access_control_rules:
   - name: "Full Admin Kibana"
     groups: ["full-admin"]
     indices: ["*"]
     kibana_access: "admin"

  - name: "Full Admin Users"
    groups: ["full-admin"]
    indices: ["*"]
    actions: ["*"]

  - name: "Allow p11001 0"
    groups: ["p11001_admin"]
    actions: ["indices:admin/*", "cluster:admin/*"]

  - name: "p11001 Admin Group Kibana"
    groups: ["p11001_admin"]
    indices: [".kibana_p11001_admin", "p11001*"]
    kibana_index: ".kibana_p11001_admin"
    kibana_access: "rw"

  - name: "p11001 Admin Group 0"
    groups: ["p11001_admin"]
    indices: ["p11001*"]
    actions: ["*"]
 
proxy_auth_configs:
- name: "px1"
  user_id_header: "x-forwarded-user"
users:
- username: "fulladmin"
  groups: ["full-admin"]
  auth_key_sha256: "auth_key"
- username: "abcd"
  groups: ["p11001_admin"]

proxy_auth:
   proxy_auth_config: "px1"
   users: ["abcd"]

The issue we are having is that when in the Allow group we add "cluster:admin/*", the user “abcd” won’t be able to login because it won’t have any default space available(the kibana_index: “.kibana_p11001_admin” won’t be created).

If we add anything else after admin/ (e.g."cluster:admin/i*" or "cluster:admin/ilm/*") the user will be able to login.

We want the user to be able to access all the actions under cluster:/admin, without specifying all of them in the ROR config.

Also, we are using ES + KB 7.6.2 with Enterprise ROR 1.22.1.
Any help will be appreciated.

2

Hi @Diana,
It’s not clear to me what is the requirement (in plain english) you are trying to implement here.
In general, we don’t recommend using actions rule in ACL blocks that are designed to support a Kibana user session because the list of actions to allow would be very long, and the result would be sloppy. More on this in the docs

3

Hello,

I will try to be more clear. What we are trying to do is :
the user in the group p11001_admin should have available all actions on the cluster. For example, ILM will be forbidden if not specified in the actions with cluster:admin/ilm/. This should involve all actions that don’t include indexes. As we don’t want to specify ALL of them, we would like to add the action cluster:/admin/ which doesn’t seem to have the expected behaviour.

4

I have the impression it’s all much easier than you think. Let’s take an example:

- name: ThisCanDoAnything
  groups: ["full-admin"]
...
users:
- user: fulladmin
  groups: [full-admin]
  auth_key_sha256: xxxxxxxx

Notice the absence of actions, indices, or any other rule. No rule, no constraint.

You might have the impression the above principle does not stand, when you add “kibana_access” rule, but that’s an illusion because “kibana_access” (even with “admin” value) has significant limits, including limiting cluster management. The “admin” value in fact means: you can edit kibana objects AND edit ROR configuration. It should have been called “ror_admin” in hindsight…

What you are looking for, is maybe “kibana_access: unrestricted” (which is basically equivalent to not specifying the kibana_access rule at all).

5

Hello,

ok, i understand your point. But, let’s forget the fulladmin group, out clients won’t have access to this group. The point here is that the clients will have an admin group, in this case p11001_admin which should:

  • have access to cluster management functions
  • not have access to modify the ROR config
6

OK now I get what you mean!

The above is going to allow ONLY those two actions groups, but not the other actions that are necessary for a user to use Kibana normally.

What you want is to allow the normal Kibana session, AND those two additional action groups. So what we do this case is to dupicate the said ACL block:

  - name: "Allow p11001 0 additional actions"
    groups: ["p11001_admin"]
    actions: ["indices:admin/*", "cluster:admin/*"]

  - name: "Allow p11001 0"
    groups: ["p11001_admin"]
    kibana_access: rw

The first one will allow those extra management actions you require, the second one will give the user the possibility to use Kibana in a read-write mode, but without the ROR admin permission (and no ROR settings button will show up either).

I hope this helps