Give access to client for the index patterns creation

1

Hello,
I have an issue and would really appreciate any help.

Actually, I would like to give access to our clients to only create index patterns by themself in Kibana.

We think that may be we have 2 options but don’t really know how to work on them:
Option 1: expose the Management —> Index Pattern via the GUI to the client. But make sure that he could only create index pattern while opening the Management option. We don’t want him to touch or do anything else over there.
Option 2: If we can’t do it through the GUI, can we create index patterns using API and give the command or what we’ve found to the client, so that, he will do it on command line.

2

Hi @christelle, are you an Enterprise user?
Are we talking about a read-only tenancy? with Management kibana app disabled?

Can you maybe share the current ACL configuration?

3

Hi @sscarduzio , Yes I am an Enterprise user.
yes exactly, I would like to hide everything under Management to only give access to the index patterns creation. So that, our user will only do that without touching anything.

Here is the group we’ve created:
- name: Accept requests from users defined in group admin on index2
groups: [“dev”]
kibana_access: admin
# kibana_hide_apps: [ “Management|Stack Management|Index patterns” ]
kibana_hide_apps: [ “Management|Stack Management” ]

then we add users to that group:
users:

- username: admin21
  auth_key: admin21:xyzzz
  groups: ["dev"]
4

@Dzuming what do you think? We have more or less the infrastructure to allow this (see kibana management submenu in ror panel). But we do not have a real way to let administrators select what should go in there. :thinking:

5

Exactly, we have the infrastructure but we don’t have a mechanism to explicitly say, show me only this subtab from a Management tab.

  1. We can Declaring every single management page to be hidden, but it sounds frustrating and like a lot of work from admin perspective.
    kibana_hide_apps: [ "Management|Stack Management|Saved objects", "Management|Stack Management|Tags", "Management|Stack Management|Spaces", ... ].
  2. We can introduce the “regex” concept and let the user declare in the kibana_hide_apps to hide everything except specific subtabs like
    kibana_hide_apps:[ "Management|Stack Management|(?!Index patterns)"]
6

Going full regex would be extra powerful, but in other rules with similar intents we have used the negation symbol ~.

For example:

  • headers_or: ["x-myheader:val*","~header2:*xy"]
  • headers_and: ["hdr1:val_*xyz","~hdr2:xyz_*"]
  • fields: ["~excluded_fields_prefix_*", "~excluded_field",]
  • response_fields: ["~excluded_fields_prefix_*", "~excluded_field", "~another_excluded_field.nested_field"]

With the notable exception of uri_re rule (one of the oldest rules introduced in ROR).

The reason we decided to stay away from full regex support was due to the absence of performance predictability guarantees. This is important mainly on the Elasticsearch plugin side, due to the high concurrency. On Kibana, this is not as critical, so we could technically afford allowing what you are proposing.

I have a concern regarding backwards compatibility because the current implementation uses the pipe | character as separator between app group and app name. Wouldn’t this be an issue for customers upgrading from current ROR to the newer ones?

7

I think if we extend our infrastructure to check if a specific group or name matches regex and leave pipe | functionality as it is, it will be ok.

8

What do you mean? How can you disambiguate if a pipe belongs to a regex or is a separator between app group and app name?

9

Sorry, I was inaccurate. I meant we can use something like regular expression literal pattern Regular expressions - JavaScript | MDN, and then, we can indicate regular expression by enclosed between slashes
[ "Management|Stack Management|/?!Index pattern/"]. We know that we need to treat expression between /{expression}/ as a regular expression

10

At this point why not telling users to either do a they do now (string with pipe), or wrap the string in slashes if they want regexp engine to evaluate their string? Benefit: we would just have two distinct parsers: it will save us from handling pesky edge cases with unclosed slashes, people having the accidental pipe inside the regexp, etc.

I.e.

  • “Management|Stack Management” → valid form 1, translated to → /^Management\|Stack Management.*$/
  • “/^Management|Stack Management|(?!Index pattern)/” → valid form 2 (detected begins & ends with ‘/’) → evaluted as regexp
1 Like
11

Thanks for your inputs. I ma little bit new with this, I have to take some time to process and apply. I will test what you suggested.

I was wondering if we can give this access using api on 1.30 version?
Lastly, I’ve tried this with no success:
curl -X GET “http://10.50.50.205:5601/api/index_patterns” -H ‘kbn-xsrf: true’ -u admin1:******
Found. Redirecting to /logout?nextUrl=/api/index_patterns%

12

Hey @christelle nothing to test yet :slight_smile:
Until now, this was just a “live” internal discussion between me and @Dzuming (he’s a ROR engineer) on what’s the best way to interpret your requirement to later extend an existing feature that would actually fulfill your needs.

13

Oupps, okay. I will wait till the end then. :sweat_smile: :sweat_smile:

1 Like
14

A little update: this task was created in the backlog and @Dzuming will implement this as part of ROR PRO/Enterprise 1.33.0 (the merge window for 1.32.0 is closed, as we plan to release it this week).

About the other question:

We don’t yet support passing directly basic auth credentials, if they want they could try use their browser’s ROR cookie as credentials.