Error when accessing Discover as a read only user without index patterns / default index pattern

[flash1293]

Kibana version: master

Elasticsearch version:

Server OS version:

Browser version:

Browser OS version:

Original install method (e.g. download page, yum, from source, etc.):

Describe the bug: Discover throws "Unable to update UI setting" errors when accessed as a read user without having any index patterns configured

Steps to reproduce:

1. Setup fresh instance
2. Create read only user
3. Log in as user and go to dashboard
4. Error popup:

Unable to update UI setting

Request failed with status code: 403

The errors comes up because it tries to set defaultIndex to null

It also fails if there are index patterns, but none is set as default:
Steps to reproduce:

1. Setup fresh instance
2. Install sample data
3. Create read only user
4. Go to advanced settings and remove the default index pattern
5. Log in as user and go to dashboard

It seems like this is the problematic code path: src/legacy/core_plugins/kibana/public/discover/controllers/discover.js line 144 - it relies on the default index pattern if none is specified in the url, but if there is none, it continues executing, but the loaded value is undefined.

Expected behavior:

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

[elasticmachine]

Pinging @elastic/kibana-app

[kertal]

I've tried to reproduce it, but so far without success. When I create a user with readonly rights to Discover, without data I can't leave the following page, so I can't navigate to Discover.

I created a role with just read access to discover, maybe you did it differently? thx!

[kertal]

Note: reproduced it by modifying the default pattern setting in Advanced Settings

thx @flash1293

[kertal]

just some knowhow, what caused this 503, it's the following:

kibana/src/legacy/core_plugins/kibana/public/management/route_setup/load_default.js

Line 89 in fcc4c48

config.set('defaultIndex', defaultId);

Kibana's trying to set and persist the defaultIndex if none is given. that happens before the Discover route

[flash1293]

Maybe we should do that on the server - not sure where exactly though.

[slhck]

Is there some workaround for this? In other words: How can I get a read-only user with access to a subset of index patterns to actually open the Discover view?

For clarification, I want to set up a cluster with different read-only users with access to different index patterns, which are not the default.

So for example, I have the index patterns:

• analytics-* (default)
• analytics-foo-*
• analytics-bar-*

And I have users foo and bar, each with a respective foo and bar role that grants read access to the respective index patterns (but not the analytics-* pattern). Also, the users have access to a general space (analytics) that allows visibility of Discover.

When I click the Discover button as the foo user, a request is made to https://example.com/s/analytics/api/kibana/settings. with the value {"changes":{"defaultIndex":null}}, which returns a 403. Consequently, this error is shown and nothing happens:

Can I somehow redirect the user to that page, set a default index for that user/role, or do anything else, or am I stuck with allowing all users to read the default index?

I should mention that this only occurs when using a space different from the Default space.

[flash1293]

@slhck

Can I somehow redirect the user to that page, set a default index for that user/role, or do anything else, or am I stuck with allowing all users to read the default index?

The default index pattern is a per-space setting, so the restricted users can't have their own default.

For now a possible workaround would be to create separate spaces for these different read-only users where they have access to the default index pattern of the space.

E.g. if you have 5 index patterns pattern1* to pattern5* (pattern 1 being the default) and a user group can only see pattern3* upwards, create a separate restricted-analytics space with only index patterns pattern3*, pattern4* and pattern5* (pattern 3 being the default) and grant this user group only access to that restricted space.

[slhck]

Thanks for the hints. However, when you say:

create a separate restricted-analytics space with only index patterns pattern3*, pattern4* and pattern5* (pattern 3 being the default)

How do I create a space with "only index patterns X Y Z"? I thought each space can see all patterns, and the only options I get when creating spaces are its name and some other attributes (https://www.elastic.co/guide/en/kibana/master/spaces-api-post.html). Also, there seems to be no way to set a default pattern per space. I can only set it for the entire cluster (in the index pattern management).

[flash1293]

@slhck This is a super confusing part of Kibana - index patterns really mean two things, just a string that references a set of actual data indices in Elasticsearch (you are right about them, they are global and not bound to spaces) and the saved object index patterns configured in Kibana that also contain a bunch of meta information (e.g. which field is the time field). The latter kind of index patterns are saved objects and thus exist only in one space. If you create a separate space and switch to it, all of the index patterns in Management > Index patterns will be gone and you can re-create just the ones you need for that space (and set one of them as default). Keep in mind that this has nothing to do with the visibility of the data itself (but judging from your previous comments you have already set up everything correctly there).

Also, there seems to be no way to set a default pattern per space. I can only set it for the entire cluster (in the index pattern management).

If you go to Management > Index patterns, you only see the index pattern saved objects for your current space

[slhck]

Oh okay, that is confusing indeed. So in other words, if I created a dedicated space for each of the (restricted) users, then – as a higher-privileged user – created the respective index patterns in those spaces, the restricted users would only see their own index patterns, but not the other users'? In that case, that would solve my problem. I think it was masked by the fact that I only ever opened the (lower privilege) spaces through lower privilege users. Thank you for the feedback and apologies for (ab)using this thread. (But I guess it's slightly related, since Google brought me here.)

[flash1293]

@slhck Exactly, you have to set up the space as a higher privileged user once for your read only users (configuring index patterns and maybe dashboards/visualizations). Then, if you grant your restricted users only access to that one space, they won't ever see the index patterns / dashboards / visualizations for the data they can't access anyway.

[jportner]

This bug has reared its head again with the 8.0 upgrade that converts data views to become share-capable (#100489). That change regenerates IDs for saved objects that were created in a custom space before upgrading to 8.0.

What's happening here is that the advanced settings have stored the old ID for the default index default data view, so when a read-only user views a dashboard and gets redirected to the new URL, the Kibana client attempts to (1) fetch the default data view and then (2) update the default data view, so the user runs into 403 errors. Example:

@elastic/kibana-data-discovery we can add a migration for the config saved object (which is what persists advanced settings) to avoid this particular scenario. If you think that's appropriate, I can create a separate GH issue for that.

[kertal]

@elastic/kibana-data-discovery we can add a migration for the config saved object (which is what persists advanced settings) to avoid this particular scenario. If you think that's appropriate, I can create a separate GH issue for that.

Yes, this makes sense absolutely, also we should fix this old bug, thx for reminding 👍

[jportner]

Yes, this makes sense absolutely

Opened a new issue here: #133241 (comment)

also we should fix this old bug, thx for reminding 👍

🙌

[kertal]

thx @jportner