Describe the issue:
When an unauthenticated user logs in to view the indices, Kibana prompts the Message saying No Permission.
After that, the correct index selected, still the error message visible. We have to click explicitly ‘ok’ to cancel the error prompt.
Steps to reproduce:
Deploy elk 7.0.1 chart with some users having limited permissions.
Login with admin user and create some index patterns.
Log in with unauthenticated user which have limited permissions and try to view the indices, Kibana prompt the Message saying No Permission.
Now use the correct index for which user has permissions the error message is still there.
Expected behavior:
When we select the correct index the error message should disappear.
This happens because the user tries to read some index(es) that he has no permission to read. In some cases, Kibana uses a wildcard as an index name if no index name is given. Search Guard can be run in do not fail on forbidden mode. With this mode enabled Search Guard filters all indices from a query a user does not have access to. Thus not security exception is raised. You can enable it in the following way.
If there is a permission error, usually the corresponding Elasticsearch error is more useful. Could you please look at the Elasticsearch log, find the related error, and paste it here?
Hi @srgbnd
Thanks for the response.
I have tried do_not_fail_on_forbidden: true parameter under sg_cofig. Now when an unauthenticated user logs in to view the indices, Kibana prompts the Message saying “Internal Server Error”.
If we click on the index for which user have permission the prompt is still there. That prompt remains until we click explicitly on “ok” button. The prompt should be disappear if we select the correct index for which user have permssion.
The only different which I see in client logs are with do_not_fail_on_forbidden parameter there are no logs coming for “Internal Server Error”. Without that parameter, we can see “no permission” logs in client pod.
Our expectation is the prompt for no permission should disappear when we select the correct index .
If the user clicks Ok to close the error callout and switches back to the index he has permissions for, there is no error. If the “correct” index pattern is preferred, the user navigate to other pages and goes back to the Discover page and there is no error.
Do you have the same behaviour? If yes, it is expected. This error is the Kibana error, we don’t control this error. It disappears after the timeout you see in the right (270s) or after the user clicks the Ok button.
Hi @srgbnd
One doubt in newest Kibana/SG versions. After doing this “The user switches to the index pattern he has no permission to search” if user select the correct index(for which he has permission). That error prompt still be there ?
If there was an error, Kibana pops the related error toast. There is one toast per error. If the user has the error already and switches to the “correct” index pattern the toast doesn’t disappear immediately. It either disappears after a timeout or when the user closes it. There is no other error on the page.
Hi @srgbnd
On what parameter this “timeout” decided? Because in older kibana/SG version it shows for 300s and in newer version there is no timeout coming.
but the time comes up on error prompt is 300s. In that case both time should be same ?
So the parameter “toastLifeTimeMs” is for timeout or for some another purpose ?
The red message at the top of the page which is saying Internal Server Error in v7.0 is not in the EuiGlobalToastList. The toast list is a completely different UI component. It always looked this way Elastic UI
Practically the toast is there until the user closes it:- I have validated it even there was no countdown time but after some the error prompt disappears itself.