-
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
[Logs UI] Return 403s rather than 500s for ML privilege errors #74506
[Logs UI] Return 403s rather than 500s for ML privilege errors #74506
Conversation
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
@elasticmachine merge upstream |
1 similar comment
@elasticmachine merge upstream |
💚 Build SucceededBuild metrics
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 Reviewing on behalf of @elastic/logs-metrics-ui
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work as described 👍
Testing via the UI proved difficult because the jobs_summary
requests fail earlier such that the routes changed here are never called.
return response.customError({ | ||
statusCode: 403, | ||
body: { | ||
message: error.message, | ||
}, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though it's internally equivalent, did you consider using response.forbidden
for the sake of discoverability?
return response.customError({ | |
statusCode: 403, | |
body: { | |
message: error.message, | |
}, | |
}); | |
return response.forbidden({ | |
body: { | |
message: error.message, | |
}, | |
}); |
And thank you for the detailed commentary and helpful testing instructions! |
Yeah, UI testing was a bit gnarly 😬 Thanks for the review. I'm going to merge this now as there's a green build; I will do a mini-followup with the |
…ic#74506) * Add ML privileges error checks to all routes
… (#74859) * Add ML privileges error checks to all routes
Summary
This ticket fixes #70414. The changes here ensure that our routes that integrate with ML return a
403
status code, rather than500
, when there is a recognised ML privilege / capabilities based error.Testing
Overview
Note, due to limitations in alerting, the functions called by SIEM (jobsSummary and mlAnomalySearch) currently have their capabilities checks disabled.
, some of our ML integrated routes only callmlAnomalySearch
, so those routes currently have these checks disabled. However, I have added the changes to those routes regardless, so they're ready when the alerting changes take effect.Prerequisites
Testing changes
There are two ways you could test this, I have used the latter method.
You could disable the upfront privilege checks we do in the UI, and ensure the requests from that point fail as expected.
Testing the API directly. Below are all of the routes that are affected, and some curl requests that should help. Where I've included not working it's because of the caveat noted in the summary. These routes should still be checked though, as they have changes.
(The UI should, of course, also be tested to ensure it still works as expected - with a user who does and does not have ML privileges).
/api/infra/log_analysis/results/log_entry_anomalies_datasets
/api/infra/log_analysis/results/log_entry_anomalies
/api/infra/log_analysis/results/log_entry_categories
(not working yet)/api/infra/log_analysis/results/log_entry_category_datasets
(not working yet)/api/infra/log_analysis/results/log_entry_category_examples
/api/infra/log_analysis/results/log_entry_examples
/api/infra/log_analysis/results/log_entry_rate
(not working)