Multi-User Groups (AD) related Questions

1

@sscarduzio
We’re in the second week of using the licensed ROR for various use-cases that we need to support and had a questions about one of the scenarios and a UI usecase.

UI Use-Case
We have a requirement to not only hide specific apps in Kibana, which ROR does properly. In addition, we wanted to have an ability to use User-Groups to allow/deny access to specific dashboards (perhaps using prefixes or some other custom rule?). Am curious, is this something that is reasonable and can be supported?

UserGroup Stacking
From Above : We have an AD setup where one user can have multiple ADs associated with different levels of access.
So User XYZ123 may have AD-Group1 and AD-Group2. AD-Group1 has permissions to view 5 dashboards while AD-Group2 has permissions to view 10 dashboards. A user having both groups would be able to view 15 dashboards.
(Alternatively, a user group 1 may have access to 5 indices and user group 2 may have access to 10 indices - a user having both user groups should have access to 15 indices)
Would this scenario be supported?

Thanks

2

Hi @Daedelus,

To your first point: AFAIK dashboards are documents inside a “.kibana” index. you could create an additional block in your ACL, right above the one of the said user, which intercepts the read requests to the .kibana index, and has a “filter” rule, where you add a query that discards documents with _name = @{user}_bla_dashboard.

To your second point: requiring the belonging to group1 AND group2 could be done by defining another ldap connector setting up the right LDAP query (i.e. group_search_filter etc), but this requires LDAP wizardry skills I do not own. Nevertheless, the tools should be in place :slight_smile:

3

@sscarduzio
I apologize- looks like I wasn’t able to express the requirement. Here is what meant:
A User who has both view and readonly AD groups

- name: "::MY-VIEW-RESTRICTED-AD-GROUP::"
  indices: [".kibana", ".kibana_@{user}", "myapp-restricted-index*"]
  headers: ["x-forwarded-group:view,restricted"] -- USERGROUP COMBO#1
  kibana_access: "ro"
  proxy_auth:
    proxy_auth_config: "proxy1"
    users: ["*"]
  verbosity: info

A User who has both view and fraud AD groups

- name: "::MY-VIEW-FRAUD-AD-GROUP::"
  indices: [".kibana", , ".kibana_@{user}", "myapp-fraud-index-*"]
  headers: ["x-forwarded-group:view,fraud"] -- USERGROUP COMBO#2
  kibana_access: "admin"
  proxy_auth:
    proxy_auth_config: "proxy1"
    users: ["*"]
  verbosity: info
4

Oh right! You are using the headers rule to check groups.
Well, that is handier actually: the settings you provided should work, provided the proxy will sort the groups in that order when writing the header, and the users do not have a third group.

Ideally we should introduce the support for wildcards in headers values i.e.

headers: ["x-forwarded-group:*view,fraud*"]

When do you need this?

5

We’re piloting a release on the 12th but i don’t want to rush things if you have a cadence may not overlap with that? I’m also trying to think of different usecases that can work with the wildcard/multi-user group mappings. Here’s some combinations i can think of :

  • kibana_access + indices (would allow logical grouping of similar indices like the ex above)
  • kibana_access + kibana_hide_apps (would allow logic grouping of hiding apps for some user group ad combos, though this may be less used)
  • kibana_access + dashboard level access (the ui-use case we initially discussed)?

…from the top of my head. Please let me know if these scenarios make sense from ROR design perspective?

6

All these use cases make sense, BTW great product vision!
But would the wildcard support in headers rule be sufficient? I.e. can you guarantee the list of groups from the proxy is always sorted as declared in the rule?

I ask because this wildcard solutions is way way less complex than the next possible solution to this requirement.

7

Thats a great question @sscarduzio.
I dug around a bit and it looks like there’s no guarantee of sorting.

A thought here:
IF we are looking at AD group as additive, would the order matter in the ACL rule?
To me AD-Group1, AD-Group2 following an OR additive pattern would seem transitive. Please correct me if I’ve missed something?

8

Yes of course “AD-Group1,AD-Group2” and “AD-Group2,AD-Group1” should be equivalent, but in the current implementation we could have a very fast and easy win reusing the headers rule and evaluating the groups list as a string.

The proper, more specific implementation (using dynamic variables in the “groups” rule, would take much more effort and testing. That’s all.