Can I stop control access to Stack Management and spaces based on LDAP groups?

1

Hi

I have users that can either be in “UserGroupA”, “UserGroupB” or “AdminGroup”.
At the moment, UserGroupA users have access to IndexA and UserGroupB users have access to indexB and admin users have access to all indexes.
This side of things all works fine in terms of restricting access to index data.

The big problem I have at the moment is that all users can access Stack Management settings and create and delete whatever they like, which obviously isn’t an acceptable setup.

I have tried using “kibana_access: ro” for the user groups, which does remove access to Stack Management but it also doesn’t allow those users to configure things such as dashboards within their own spaces.

What I want to achieve is:
UserGroupA has access to create and modify things within UserSpaceA only but no access to Stack Management.
UserGroupB has access to create and modify things within UserSpaceB only but no access to Stack Management.

I just wondered whether I can achieve anything close to this using the basic license? Or something that functionally achieves a similar outcome? Perhaps with deny rules on Stack Management actions etc?

Edit:
I’ve been looking at the logs and seeing what different types of requests look like.
Looks like I might be able to restrict users to only their own ‘spaces’ using the x-ror-kibana-request-path header?
But I can’t see anything unique in the logs when I access the ‘Stack Management’ page to be able to set a deny rule for it.

Edit edit:
Perhaps instead of trying to stop users accessing Stack Management I could try to stop them accessing sub menus within it, such as “Index Management”. I could see if there is a deny rule that I can, e.g. on an action such as “indices:admin/get”.

2

kibana_access: rw should give the user access to CRUD for dashboards, but no control over cluster ops.

3

I’m giving it a test using these rule blocks:

- name "UserGroupA access"
  proxy_auth: 
    proxy_auth_config: "proxy1"
    users: ["*"]
  ldap_authorization: 
    name: "ldap1"
    groups: ["UserGroupA"]
  indices: ["IndexA"]
  kibana_access: rw

- name "UserGroupB access"
  proxy_auth: 
    proxy_auth_config: "proxy1"
    users: ["*"]
  ldap_authorization: 
    name: "ldap1"
    groups: ["UserGroupB"]
  indices: ["IndexB"]
  kibana_access: rw

Logging in as a user in UserGroupA, I can see the red “rw” icon in the top right hand corner of the GUI, but I can still access Stack Management, delete data streams, index templates and index lifecycle policies etc.

Am I doing something wrong?

(Using “Free-1.40.0_es8.2.2”)

Edit:

Just a second related question (in case the first approach doesn’t work)…
I have been testing the following blocks:

- name "forbid index admin actions"
  type: forbid
  actions: ["indices/admin/*"]

and…

- name "forbid index admin actions"
  type: forbid
  headers: ["x-ror-kibana-request-path:*/api/index_management/*"]

Both approaches work. But, when following the forbidden link, users are redirected to the login page with the url appended with “?autologin=false”.
I don’t want to redirect users out of the application, I’d just want the user to be redirected to the home page, or at least with “?autologin=true” set so that they aren’t displayed with a log in screen. How do I change this behaviour?

Edit edit:

I’m not even sure forbidding based on x-ror-kibana-request-path will work 100% as it seems like some of the request paths are used legitimately elsewhere in the application. So I will stick to trying to use the ‘actions’ method.

4

Apologies for the double post - I just thought it would be useful to summarise and update my question after having worked through some of these issues a little bit.

It seems as though I can restrict access to admin functions using forbid blocks on actions ("indices/admin/*") and I can probably restrict access to spaces using forbid blocks on headers (“x-ror-kibana-request-path”) and I also have the option of using “kibana_access: rw”.

But the default behaviour in each of these cases, when a forbidden action is triggered, is for kibana to return to the login page.

Is there any way for me to redirect to an “unauthorised page” or at least just return to the application homepage when something is forbidden? Just looking for any ideas.

5

There should be a custom logout URL to be configured, but if you use it to point to homepage, then you won’t be able to logout ever (unless manually typing the actual logout /logout page in the browser).

I think what you need is hiding the management app, but that’s a pro feature.

1 Like
6

Thanks @sscarduzio, I have figured out a workaround although it does come with some downsides, one of which being that the log out function doesn’t work properly, as you mentioned.
Pro features would definitely solve my problem in a much nicer way.

1 Like
7

Happy to help @joemo2023.