Specific Group Settings

1

I have a group that I created for certain users. the users of that group should have the ability to create any visualizations/dashboards, mess around with discover on the index, etc.

I’d like them to be able to create/modify/delete their own indexes but not modify or delete the core data indexes.

I started by creating the group as outlined in the multitenancy docs.

name: “::thatgroup::”
groups: [“thatgroup”]
verbosity: error
kibana_access: rw
kibana_hide_apps - hiding apm, monitoring, uptime, ROR and infrastructure
kibana_index: “.kibana”

then the user is sha256 to the group.

I was getting errors trying to log in as the user so i added actions to the group.

actions:[“indices:admin/create”,"…"] - basically any error i added the action here. and most of the errors went away and the user is okay to log in but then when they try to add an index with Dev Tools i keep getting the error of

CGR:thatgroup
USR: [user not logged in]
ACT: indices:admin/create
PTH: /testy?pretty
authorization=Basic dGY

The user is connected via sha256 and the action is already in the action line for the group. What am I missing - and how do I limit the user to what I want them to be able to do?

2

Hi @mdnuts, may I ask you in every new topic, to add the context? Kibana/ES version, ROR version?
It would be great for support and future reference.

Also, please attach the whole log line you summarized (he one with USR: [user not logged in])

3

ROR is 1.17.6 - 6.7.1

I have to hand transfer and sanitize these
FORBIDDEN by default req={ ID:<sting>, TYP:CreateIndexRequest, CGR: TESTGRP, USR:[user not logged], BRS:false, KDX:null, ACT:indices:admin/create, OA:127.0.0.1/32, XFF:x-forwarded for=<src pc>, DA:127.0.0.1/32, IDX:<N/A>, MET:PUT, PTH:/testy?pretty, CNT:<N/A>, HDR:Connection=close, Content-length=0, Host=localhost:9200, authorization=Basic dGV<remainingstring>, x-forwarded-for=<srcpc>, x-forwarded-host=<mykibana>:5601, x-forwarded-port=50451, x-orwarded-proto=https, x-ror-current-group=TESTGRP, HIS:

  • which then lists all of the groups which all have false except for
    [::TESTGRP:: ->[groups->true, kibana_access->false]]}

the user is logged in first then tries to create an index in dev tools like PUT testy

4

Thanks @mdnuts for taking the time to transcript the log line. I see here two things:

  1. We are printing the log line of a request in its final state (FORBIDDEN), at this point we should have evaluated the authorization header, but still we print “USR: [user not logged]”, I see this as a bug. @coutoPL can you confirm?

  2. The configuration issue. You are most likely mixing “kibana_access” with “actions” rules in the same block. This prevents “kibana_access” from working properly. Please add another block identical to the current one, but without “kibana_access” and with the “actions” rule instead.

5

Ok so testing this.

############### Testing Group ################
name: “::thatgroup::”
groups: [“thatgroup”]
verbosity: error
actions: [“indices:admin/create”,“indices:admin/get”,“indices:admin/template/get”,“indices:admin/mappings/get”,“indices:admin/create”,“indices:data/read/search”,“indices:data/read/get”,“cluster:admin/rradmin/refreshsettings”]
kibana_hide_apps: [“apm”,“monitoring”,“uptime”,“readonlyrest_kbn”,“infra:home”,“infra:logs”]
kibana_index: “.kibana”
#########################

that resulted in the same error.
trying this:

############### Testing Group ################
name: “::thatgroup::”
groups: [“thatgroup”]
verbosity: error
kibana_access: rw
kibana_hide_apps: [“apm”,“monitoring”,“uptime”,“readonlyrest_kbn”,“infra:home”,“infra:logs”]
kibana_index: “.kibana”
#########################

gives me the same error.

6

No wait, what I mean is this:


- name: “::thatgroup::”
  groups: [“thatgroup”]
  verbosity: error
  kibana_access: rw
  kibana_hide_apps: [“apm”,“monitoring”,“uptime”,“readonlyrest_kbn”,“infra:home”,“infra:logs”]
  kibana_index: “.kibana”

- name: “::thatgroup extra_actions::”
  groups: [“thatgroup”]
  verbosity: error
 # kibana_access: rw
  actions: [“indices:admin/create”,“indices:admin/get”,“indices:admin/template/get”,“indices:admin/mappings/get”,“indices:admin/create”,“indices:data/read/search”,“indices:data/read/get”,“cluster:admin/rradmin/refreshsettings”]
  kibana_hide_apps: [“apm”,“monitoring”,“uptime”,“readonlyrest_kbn”,“infra:home”,“infra:logs”]
  kibana_index: “.kibana”
7

ok, did that change like you have it and the same error.

For kicks I set the verbosity to info and When the user logs in i see all

ALLOWED by {name: ‘::thatgroup extra_actions::’, policy: ALLOW, rules:[groups,kibana_access,indices,actions,kibana_hide_apps,kibana_index]
…

when i try in DevTools

PUT testy

i get the same error

8

@sscarduzio yes, we are aware of that. This is not bug, but we noticed that final state could not be enough for users. I reported it in RORDEV-23.

1 Like
9

can I make the user admin but then somehow fllter out the ability to modify what i’d consider core indexes?

10

You can create a block with “type: forbid”. Remember to be very specific (i.e. include “auth_key” rule as well) otherwise you end up blocking other random requests.

11

Ok, I’ll give it a shot on Monday

1 Like
12

can there be only one group with kibana_access: admin?
I was testing this by adding a group of testing_a with kibana_access: admin and a test user of testy who was part of the testing_a group. The test user couldn’t get to discovery. ROR keptputting errors of ACT:incides:data/read/msearch.

If I changed group membership from kibana_a to Admins - the test user could get to discovery just fine. The user wasn’t a member of anything else.

13

@mdnuts there is no limitation on how many groups or users can be associated to kibana_access: admin.

Probably you had some requests from one session getting matched by some ACL block that was declared before. You can inspect this removing “verbosity: error” from the blocks, using Kibana with the problematic user, and verifying that the requests are “ALLOWED” by the right block names.

Sometimes this can be fixed byre-ordering of the ACL blocks, or making the ACL blocks more specific.

14

you know, i think i missed kibana_index on the last one for that group.