Filtering indices and use Ldap

Enterprise Support
1

ROR Version: Enterprise 1.56.0_es7.15.1 :unicorn:

Kibana Version: 7.15.1

Elasticsearch Version:7.15.1

Steps to reproduce the issue
1 step:
I need all ldap users to be able to log into kibana. My config:

    - name: "all user"
      type: allow
      ldap_authentication:
        name: "ldap"
      kibana_access: rw

2 step:
A group appears in ldap that should only see certain indexes. My config:

    - name: "filter index"
      indices: ["*kibana*", "*:*index*]
      kibana_access: rw
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        groups: ["team1"]

    - name: "all user"
      type: allow
      ldap_authentication:
        name: "ldap"
      kibana_access: rw

Expected result:
Users from the group stop seeing logs from other indexes.

Actual Result:
Users from the group see all logs. To solve the problem, I added one more rule.

    - name: "filter index"
      indices: ["*kibana*", "*:*index*]
      kibana_access: rw
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        groups: ["team1"]

    - name: "team1 forbid"
      type: forbid
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        groups: ["team1"]

    - name: "all user"
      type: allow
      ldap_authentication:
        name: "ldap"
      kibana_access: rw

But now I am getting a lot of errors when opening an index in Kibana.

Is it possible to remove errors from kibana?

2

This rule (I intentionally removed the kibana rule to make the example simple):

    - name: "filter index"
      indices: ["*kibana*", "*:*index*]
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        groups: ["team1"]

means:

allow requests to *kibana* or *:*index* when user belongs to "team1" LDAP group

the next rule:

  - name: "all user"
      type: allow
      ldap_authentication:
        name: "ldap"

means:

allow all requests when user can be authenticated with LDAP

You wrote:

Users from the group see all logs.

I would expect that it’s going to work like that because it’s ACL, so when matching one block fails, the next one will be checked.

I guess that putting the “allow all” block at the end of the ACL is not so good idea.

3

How can I make sure that all users have access to Kibana, but some users have reduced rights.

Do you have any ideas on how this can be done?

4

I think if I make a group, put all the users there and add it at the end, the result will not change.

5

I think you have to define first what exactly means “reduced rights”.

6

“reduced rights” - Can only see certain indexes and not receive errors in kibana. For example: index1 and index2

Other users can see all indexes.

7

Do you have any ideas on how this can be done so as not to see errors?
The problem is still relevant for me.

8

Hi, I’ve created a ROR-sandbox based simple docker environment that shows a case similar to yours: [RORDEV-1147] reproduction by coutoPL · Pull Request #35 · beshu-tech/ror-sandbox · GitHub.

Could you check it, please? In the PR’s description, you will find an instruction on how to run it. I see no issues. Could you please show me what doesn’t work? Or point out what is different in your case.

9

Use:

    - name: "team1"  #And these users should see only part of the indexes.
      indices: ["index1"]
      kibana_access: rw
      ldap_auth:
        name: "ldap1"
        groups: ["team1"]

    - name: "all user"   #All Ldap users can log into Kibana
      kibana_access: rw
      ldap_auth:
        name: "ldap1"

If there is no forbid section it does not work.
And if there is, then users from team1 see a large number of errors in Kibana.

10

I would like the config above to work just like this:

    - name: "user"
      type: allow
      auth_key: user:pass
      indices: ["index1"]
11

I think the example I provided fulfills the requirements you described here:

You are talking about “large number of errors in Kibana”. I’m asking you to tell me what to do to see these errors. Did you run the reproducer? If so, what to do to experience the Kibana problems?

If there is no Kibana problems in this configuration, tell me, from business point of view, why it’s doesn’t fit your requirements

12

Errors appear when opening an index that is prohibited to you.

image
image678Ă—1206 114 KB

I would like there to be an error that the index does not exist.

13

how do you “open” the index?

14

These index patterns were created by other users who have access to these logs.
We do not have divisions into spaces for users.

15

oh, ok, I got the problem now. First of all the user should not be able to see the index pattern they are not allowed to see. It can be solved with a custom kibana index per group. Like this: ror-sandbox/ror-demo-cluster/conf/readonlyrest.yml at 029be185dd4146f46bf49f215e258ff6f6437e48 · beshu-tech/ror-sandbox · GitHub

Sadly in ROR 1.56.0 there is a bug related to this problem. We have it already solved in RC of 1.57.0. I’ve added the new plugins to the repo if you would like to try it.

16

Oh, I see several errors here that at first glance cannot be solved.

  1. default index which is prohibited.
  2. index-pattern *aaa* will be hidden because it is not in the allowed list
    index: logs-bbb-aaa
    allowed to see *logs-bbb*

I hope you managed to solve these problems?

17

TBH I don’t fully understand the problems you mentioned above.
Please describe deeply what you want to achieve and what are the limitations you see now. Examples welcomed.

18

I’ll look at version 157. and I’ll tell you more.
Maybe I’m wrong.