Proper way to configure access to Kibana indices

[i_zeratul]

My company is a ReadonlyREST Enterprise subscriber.

Kibana automatically creates several indices in elasticsearch.

.kibana_1
.kibana-event-log-7.8.1-*
.kibana_task_manager_1
.monitoring-kibana-*

I don’t know the exact purpose of these and to which of these indices I should give the normal users access. Should it be read-only or rw access and how should I specify this.
It seems if I don’t give the tenant access to .kibana_1, they are not able to access Kibana. They get stuck on the “Choose Space” screen and they can’t open anything else.

Each tenant has a separate Kibana index:

.kibana_<tenant_name>

The rule I use for tenants at the moment is the following:

- name: "Project X"
  ldap_auth:
    name: "ldap9"
    groups: ["some_group"]
  indices: [".kibana_1",".kibana-event-log*",".kibana_task_manager*",".kibana_project_x","project_x*]
  kibana_access: rw
  kibana_index: ".kibana_project_x"
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "ml", "infra:home", "apm", "uptime", "siem", "monitoring","kibana:management","kibana:stack_management"]

1. How do I give all tenants:
   ** Read-only access to: “.kibana_1”,“.kibana-event-log*”,“.kibana_task_manager*”
   ** Read-write access to “.kibana_<tenant_name>” (their own kibana index)

2. Will this access be enough for them to be able to create Kibana objects such as Index Patterns, Dashboards, Visualizations, Searches, …

[sscarduzio (Simone Scarduzio)]

Hi @i_zeratul. When started, kibana automatically make sure exists, or alternatively creates a .kibana_1 index with all the basic objects necessary for Kibana to work. And immediately creates an alias “.kibana -> .kibana_1”. They don’t create directly a .kibana index to facilitate automatic migrations in case of version upgrade.

As far as I know, the other indices (monitoring, task manager, event log) are not necessary in the tenant’s ACL block. They should be accessed by the kibana server directly with the kibana daemon’s unrestricted credentials. Do you have those in the ACL and in the kibana.yml (elasticsearch.username and elasticsearch.password)?

The access to .kibana (or .kibana_<tenant_name> for your tenants in your case) instead is vital for a kibana session, and has to appear in the indices rule (if you choose to have one) of the ACL block that represents the tenancies. In your example, you might want to refer to “.kibana” as an alias instead of “.kibana_1”.

[i_zeratul]

Thank you for the explanation. I fixed my rule to only include .kibana and .kibana_<tenant_name>. This works great.

I guess my only question left is: Do you think it is a security risk to allow read/write access to .kibana by the tenants or is this needed for readonlyrest to work correctly ?

[sscarduzio (Simone Scarduzio)]

Sorry I was not clear, you are supposed to allow “.kibana” index to a tenant, only if the tenant is assigned to the default kibana index. I.e. there is no kibana_index rule at all in the ACL block.

If the tenant is assigned to “.kibana_” index, then you should explicitly allow that index to be reached (in the indices rule).

i.e. this is ok:

- name: "Project X"
  ldap_auth:
    name: "ldap9"
    groups: ["some_group"]
  indices: [".kibana_project_x", "project_x*]
  kibana_access: rw
  kibana_index: ".kibana_project_x"

Or this:

- name: "Project Default"
  ldap_auth:
    name: "ldap9"
    groups: ["some_group"]
  indices: [".kibana", "project_x*]
  kibana_access: rw

But for all above to work, you need:

- name: "Kibana server credentials, with no restrictions"
  auth_key: kibana:kibana
  verbosity: error

And in kibana.yml

elasticsearch.username: "kibana"
elasticsearch.password: "kibana"

Obviously, change at least the password, and use encrypted auth_keyh rule like auth_key_sha512.

[i_zeratul]

This is what I was saying. With this rule it is not working correctly:

- name: "Project X"
  ldap_auth:
    name: "ldap9"
    groups: ["some_group"]
  indices: [".kibana_project_x", "project_x*]
  kibana_access: rw
  kibana_index: ".kibana_project_x"

The user is stuck at the Choose Space page (/spaces/space_selector#/home) and it’s not possible to access Kibana at all.

I do have an ACL rule for Kibana and I do have elasticsearch.username and elasticsearch.password in kibana.yml.

Without access to .kibana, the user doesn’t have access to Kibana.

[sscarduzio (Simone Scarduzio)]

Have you ever logged in the default tenancy at least once? In the old platform (ROR for Kibana 7.8.1 and below) we copy across the default space from the default kibana index, but the default space needs to be created in the first place.

[i_zeratul]

I can see it when I log in as the kibana or admin user.

I guess I needed to login as the kibana user initially. I don’t remember; probably I didn’t.
I guess I’ll add it as a step in our documentation for future setups. For this collector, we already have the tenancies.

[sscarduzio (Simone Scarduzio)]

Good! Sorry about this, it won’t be necessary anymore in the new platform (ROR for Kibana 7.9.x onwards).

PS: is the issue resolved now?

[i_zeratul]

No, I still need to allow access to .kibana as well.

But it’s not that big of an issue.