Multitenancy - Admin user to make Kibana changes as a tenant

i_zeratul · March 9, 2021, 10:01pm

My company is a ReadonlyREST Enterprise subscriber.

I am using LDAP to authenticate customers to my ELK cluster.
The users belong in a specific tenant LDAP group.
I also have a tenant admin LDAP user called “kibana-tenant-admin” who is part of ALL the tenant LDAP groups.

Requirements:

All customer users in the LDAP groups tenant1 and tenant2 to not be able to see and access the “Stack Management” section in Kibana.
The “kibana-tenant-admin” user who is part of the LDAP groups tenant1 and tenant2 should be able to switch to these groups → Access the “Stack Management” section in Kibana → Create index patterns and other Kibana objects for these tenants.
By doing this users from tenant1 will only see Kibana objects (like index patterns, dashboards, etc.) created for tenant1 and users from tenant2 will only see Kibana objects (like index patterns, dashboards, etc.) created for tenant2.

Why am I using an LDAP admin user for this ?
Because from what I see a local admin user is not able to switch between the tenant LDAP groups and create Kibana objects (like index patterns, dashboards, etc.) in their .kibana* indices.

The code that I have so far:

- name: "Kibana Tenant Admin"
  ldap_auth:
    name: "ldap1"
    users: ["kibana-tenant-admin"]
    groups: ["allusers","tenant1","tenant2"]
  indices: [".kibana*","tenant1*","tenant2*"]
  kibana_access: rw
  kibana_index: ".kibana_tenants"

- name: "tenant1 Indices"
  ldap_auth:
    name: "ldap1"
    groups: ["tenant1"]
  indices: [".kibana*","tenant1*"]
  kibana_access: rw
  kibana_index: ".kibana_tenant1"
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "ml", "infra:home", "apm", "uptime", "siem", "monitoring", "kibana:management","kibana:stack_management"]

- name: "tenant2 Indices"
  ldap_auth:
    name: "ldap1"
    groups: ["tenant2"]
  indices: [".kibana*","tenant2*"]
  kibana_access: rw
  kibana_index: ".kibana_tenant2"
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "ml", "infra:home", "apm", "uptime", "siem", "monitoring", "kibana:management","kibana:stack_management"]

This code seems to give customer users in tenant1 and tenant2 LDAP groups access to the “Stack Management” section of Kibana, which is what I don’t want.

sscarduzio · March 9, 2021, 11:09pm

I just tested this rule on 7.8.1 and I successfully hide stack management from the sidebar of a RW user

My version string is Enterprise-1.27.1-20210228_es7.8.1

The only thing that can go wrong is what ACL block is matching in the login phase of tenant1/2. Are you able to capture the login call from the ES logs? A log line like this:

[2021-03-09T23:03:49,128][INFO ][t.b.r.a.l.AccessControlLoggingDecorator] [n1_it] ALLOWED by { name: ‘Infosec’, policy: ALLOW, rules: [groups,kibana_access,kibana_hide_apps,kibana_index] req={ ID:1485241707-1626433912#748, TYP:RRUserMetadataRequest, CGR:Infosec, USR:admin, BRS:false, KDX:.kibana_infosec, ACT:cluster:ror/user_metadata/get, OA:127.0.0.1/32, XFF:172.17.0.1, DA:127.0.0.1/32, IDX:<N/A>, MET:GET, PTH:/_readonlyrest/metadata/current_user, CNT:<N/A>, HDR:Authorization=, Connection=keep-alive, Content-Length=0, Host=localhost:9200, x-forwarded-for=172.17.0.1, x-ror-current-group=Infosec, x-ror-kibana-request-method=get, x-ror-kibana-request-path=/switch-group, HIS:[KIBANA_SERVER-> RULES:[auth_key->false] RESOLVED:[group=Infosec]], [PERSONAL_GRP-> RULES:[groups->false] RESOLVED:[group=Infosec]], [ADMIN_GRP-> RULES:[groups->true, kibana_access->true] RESOLVED:[user=admin;group=Infosec;av_groups=Administrators]], [Infosec-> RULES:[groups->true, kibana_access->true, kibana_hide_apps->true, kibana_index->true] RESOLVED:[user=admin;group=Infosec;av_groups=Infosec;kibana_idx=.kibana_infosec]], }

i_zeratul · March 10, 2021, 9:08am

I updated to the latest build. It seems the Kibana GUI doesn’t show this string though.

[root@server ~]# cat /usr/share/kibana/plugins/readonlyrest_kbn/package.json
{
“name”: “readonlyrest_kbn”,
“version”: “1.27.1”,
“ror_version”: “enterprise-1.27.1_es7.8.1”,
“ror_build_time”: “Sun, 28 Feb 2021 23:14:34 GMT”,
“ror_valid_for_days”: “99999”,
…

tenant1:

Bob
Julie
kibana-tenant-admin

tenant2:

Billy
Kate
kibana-tenant-admin

The problem is I don’t think my configuration is correct.

When the kibana-tenant-admin logs in, he should see the “Stack Management”. When Kate logs in, she shouldn’t see “Stack Management”. They are both members of the same tenant2 LDAP group.

Can you give me a code snippet for the Kibana Tenant Admin rule block and where to place it (before or after the human users LDAP groups) ?

sscarduzio · March 10, 2021, 12:02pm

@i_zeratul Kibana plugin install/uninstall system is rubbish. Many times it does not re-generate the optimized frontend files. I recommend to reinstall Kibana from scratch with the new plugin

I think the requirements are clear to me: you have two customer groups If you are customer, you only can see your tenancy and you should not see the Stack Management app.

If you are the admin, you can switch between the admin tenancy “.kibana_tenants”, and the other two customer tenancies.

My questions:

are the other apps hidden for the customers, and just he stack management is not hiding?
can you show the login log line for the customer? Like described in my prev message?

Another useful thing would be to put readonlyrest_kbn.logLevel: debug in kibana.yml and see the identity object with kibanaHiddenApps list.

i_zeratul · March 10, 2021, 11:47pm

I figured it out.

I am now using a local admin user and a local group.

- name: "Tenant 1 Admin"
  groups: ["tenant1_admin"]
  verbosity: error
  kibana_access: rw
  kibana_index: ".kibana_tenant1"

The tenant1 LDAP group customer users create Kibana objects in the index “.kibana_tenant1”. This local admin user also creates Kibana objects in the index “.kibana_tenant1” and therefore they are visible to the tenant1 LDAP group customer users.

Hmm, I installed Kibana from scratch this time because our cluster is not in production yet. It seems it only updated the string in the Kibana UI to “Enterprise-1.27.1_es7.8.1” for the admin user. All other users still see “Enterprise-1.24.0_es7.8.1”. In the future can we still use kibana plugin remove/install to perform upgrades ? It is less intrusive and less prone to errors than cleaning up Kibana entirely on the server.

sscarduzio · March 11, 2021, 10:55am

Looks like a browser cache issue then?

We have tied hands on this, Kibana plugin system is out of our scope. And far too customized and convoluted to be worth to contribute to (for me, at least). Add this to the fact they claim to ditch it after 8.0.

We long ago moved to ephemeral docker containers for our QA, and hopefully our customers find a similar way to automate their work.

i_zeratul · March 11, 2021, 11:19am

You are right. I tested on my Firefox browser where I clear the local cache and cookies and here it is fine.

I will discuss with my colleagues. This should be doable for us as well.

Thank you again for your help