-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad requests from spaces saved object client during kibana startup #120422
Comments
Pinging @elastic/kibana-security (Team:Security) |
We are seeing the exact same issue log error when we try to import dashboards/visualizations into the cloud on 7.16.2... |
We see it when we try and use the saved objects import API with object exported with the export API. |
Is there a way to reproduce this issue? I don't get the error when importing and exporting saved objects on 7.16.0 so finding it quite difficult to try and work out what the problem could be. The issue is definitely usage stats related. We'd need to understand which user is making the request to |
@asazallesmilner are you importing the saved objects into the same space as they were exported from? The logs given in the issue's description don't give us much to go on here, we ideally need verbose logs. The steps to reproduce also don't mention exporting an importing saved objects so we need more info on how you came across the bug please.
|
Pinging @elastic/kibana-core (Team:Core) |
Closing the loop on this issue based on an offline discussion we had a month ago. This error can occur when a consumer uses In a nutshell: in this issue (and likely the separate problem that @asazallesmilner is experiencing), the Spaces SOC wrapper is probably throwing the 400 Bad Request error based on the second error condition that Thom mentioned above: kibana/x-pack/plugins/spaces/server/saved_objects/spaces_saved_objects_client.ts Lines 326 to 338 in 280e937
This can happen if the user is trying to search across multiple spaces, and the Spaces SOC wrapper finds 0 spaces that the user is authorized to see for this purpose: kibana/x-pack/plugins/spaces/server/saved_objects/spaces_saved_objects_client.ts Lines 370 to 384 in 280e937
The user needs to be authorized to use the Saved Objects Management feature to be able to use the import API. kibana/x-pack/plugins/security/server/spaces/secure_spaces_client_wrapper.ts Lines 36 to 38 in 280e937
The problem in this issue appears to be happening because a usage data collector is attempting to use the current user's credentials to search for visualizations across all spaces, but if the current user is not authorized to access the Saved Objects Management feature in any space, this error will happen. kibana/src/plugins/visualizations/server/usage_collector/register_visualizations_collector.ts Line 27 in 280e937
kibana/src/plugins/visualizations/server/usage_collector/get_usage_collector.ts Lines 36 to 43 in 280e937
I believe the solution for this problem is to make sure that consumers of the usage collector use a saved objects client that uses the system user's credentials, not the end user's credentials. @asazallesmilner I'm not sure why you're experiencing the same problem on import, we don't use the Otherwise if you're having trouble with setting up your environment/roles/privileges/etc and you have a question, feel free to ask for support in our Discuss forum: https://discuss.elastic.co/c/elastic-stack/kibana/7 But let's please keep this issue on-topic, it is focused on Cloud deployments that run into this error because of usage collection 👍 |
@TinaHeiligers I can replicate this error in the 7.17 branch by hitting One way to easily reproduce this.
Click to expand and see Kibana server logs
If I start a fresh Kibana deployment on Cloud and check the server logs, without interacting with Kibana at all, I see the same four errors (repeated 3x): Interestingly, if I check the Cloud proxy logs, they are completely empty. I suspect that if we have an internal service that is hitting the stats API, it won't get routed through the Cloud proxy, so it won't show up in the logs there. So maybe there is something in Cloud that is hitting this endpoint with the Then I had the bright idea to restart my instance with debug logs enabled, and this is what I found (filtering out ES query logs):
So it seems like some internal service is calling I can reproduce these errors on the Kibana server one time after a restart by calling: Subsequent calls don't generate the errors. |
Def something we should look into. @afharo this is another issue we need to investigate. |
@jportner thanks for finding what the underlying issue is. It makes perfect sense! FYI, we've been planning to run these requests using the
The fact that the subsequent calls don't generate the errors makes me worry... I think it's a bug introduced by #117084. @Bamieh what do you think? |
By that I assume you mean you've been meaning to run those requests using the internal saved objects client (without the Security SOC wrapper / without checking the end user's privileges)? Makes sense 👍 |
@afharo We are caching usage for 4 hours so any failed collectors will not be reported until the next caching cycle. This is not a bug but by how we've implemented the caching logic which worked at the top level of the service. It makes sense to disable caching for unencrypted requests to resolve this. |
I tried to replicate this scenario myself and I noticed something wrong with how Metricbeat is working: Metricbeat is requesting IMO, it should always append that parameter if the version of Kibana supports it ( cc @elastic/beats @elastic/cloud-applications-solutions can you help me with figuring out why this could happen. |
I can help with debugging the cloud configs. |
@gigerdo and I spent a good amount of time yesterday troubleshooting this! Thank you kindly for your support and invaluable insights from the Cloud POV 🧡 ! We confirmed that Metricbeat is reporting the URL without The culprit for raising those errors is the internal I'll go ahead and close this issue. Feel free to reopen if there are any open questions I may have missed. |
@afharo did the updated Metricbeat actually make it into production? We're still seeing the errors, though we're not sure if they are still caused by the old Metricbeat or by something else now. |
Closing this issue based on my last comment. Please, feel free to reopen if you think we should spend more time in it. |
bad bot. Closing again. |
Kibana version: 7.16.0
Elasticsearch version: 7.16.0
Server OS version: Cloud
Original install method (e.g. download page, yum, from source, etc.):
Staging
Describe the bug:
Upon Kibana startup we see multiple bad request errors in the log.
Steps to reproduce:
Expected behavior:
No errors in logs
Provide logs and/or server output (if relevant):
cc: @jportner @TinaHeiligers
The text was updated successfully, but these errors were encountered: