-
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
[ML] Adding capabilities checks to shared functions #70069
[ML] Adding capabilities checks to shared functions #70069
Conversation
@elasticmachine merge upstream |
Pinging @elastic/ml-ui (:ml) |
Pinging @elastic/apm-ui (Team:apm) |
9ab59b5
to
41b1d6e
Compare
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.
APM changes look good.
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.
Security Solution changes LGTM; I was able to generate signals from anomalies via an ML Detections rule.
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.
Looks good overall, just added a question about await
without try/catch
blocks and a types.
export type HasMlCapabilities = (capabilities: MlCapabilitiesKey[]) => void; | ||
|
||
export function hasMlCapabilitiesProvider(resolveMlCapabilities: ResolveMlCapabilities) { | ||
return (request: KibanaRequest) => { |
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.
Is there a way you could make use of the HasMlCapabilities
type to enforce it? Looking at the code like this I'm unsure why the type HasMlCapabilities
is a function without async
and the return function in the provider uses async
.
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.
HasMlCapabilities
should really return Promise<void>
here. i'll update it.
I'll also add HasMlCapabilities
as the return type of this returned function to make it more explicit.
x-pack/plugins/ml/server/lib/capabilities/check_capabilities.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/ml/server/lib/capabilities/check_capabilities.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/ml/server/lib/capabilities/check_capabilities.test.ts
Outdated
Show resolved
Hide resolved
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 for the infra
plugin where the checks are not disabled. 👍
} | ||
|
||
if (capabilities.every((c) => mlCapabilities![c] === true) === false) { | ||
throw Error('Insufficient privileges to access feature'); |
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.
I was wondering if we could use a custom Error
subclass here to enable the routes to translate it into a 403 instead of 500 error. 🤔
We're doing something like that in the infra
plugin here:
kibana/x-pack/plugins/infra/server/lib/log_analysis/errors.ts
Lines 16 to 21 in e8cf08f
export class NoLogAnalysisMlJobError extends Error { | |
constructor(message?: string) { | |
super(message); | |
Object.setPrototypeOf(this, new.target.prototype); | |
} | |
} |
Alternatively, a custom marker attribute on the Error
subclass could also be used for identification.
What do you think?
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.
yes, I like this idea.
added in fbac69f
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.
awesome, thank you ❤️
@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.
LGTM
* [ML] Adding capabilities checks to shared functions * small refactor * disabling capabilities checks for functions called by SIEM alerting * testing git * removing comment * using constant for ml app id * tiny type clean up * removing check in ml_capabilities * fixing types * removing capabilities checks from ml_capabilities endpoint * updating types * better error handling * improving capabilities check * adding custom errors Co-authored-by: Elastic Machine <[email protected]>
* [ML] Adding capabilities checks to shared functions * small refactor * disabling capabilities checks for functions called by SIEM alerting * testing git * removing comment * using constant for ml app id * tiny type clean up * removing check in ml_capabilities * fixing types * removing capabilities checks from ml_capabilities endpoint * updating types * better error handling * improving capabilities check * adding custom errors Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Adds capabilities checks to all shared ML functions.
Checks are the same as the kibana endpoint equivalents. e.g.
/api/ml/results/anomalies_table_data
andgetAnomaliesTableData
both requirecanGetJobs
.All plugins calling our shared functions now need to supply a
request
object.Note, due to limitations in alerting, the functions called by SIEM (
jobsSummary
andmlAnomalySearch
) currently have their capabilities checks disabled.Once alerting can supply a real
request
object, these checks can be reinstated.Functional tests will be added in a follow up PR.
Note, also include some small refactoring to replace
ILegacyScopedClusterClient
withLegacyAPICaller
Unit or functional tests were updated or added to match the most common scenarios
This was checked for breaking API changes and was labeled appropriately