[Security Solution][Endpoint] server-side standard interface for response actions clients #171755
Conversation
keep PR speicific to introducing a well defined interface for Response Actions clients
paul-tavares
added
release_note:skip
|
Pinging @elastic/security-defend-workflows (Team:Defend Workflows) |
paul-tavares
changed the title
paul-tavares
changed the title
…onal-response-actions-data-persist
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
| ImmutableObject, | ||
| } from '../../../../../common/endpoint/types'; | ||
|
|
||
| export class EndpointActionsClient extends BaseResponseActionsClient { |
There was a problem hiding this comment.
FYI: testing of this client is covered by existing tests for both the Route handler for response actions and the individual service functions under services/actions/*
| file_size: 0, | ||
| }; | ||
|
|
||
| const createdFile = await fleetFiles.create(fileStream, actionPayload.endpoint_ids); |
There was a problem hiding this comment.
We should handle errors for create file failures.
There was a problem hiding this comment.
There is really nothing we have to do if this fails here, so we just would be re-throwing the error again. The catch() block below attempts to delete the file (since they can be large) if there is a failure after it is created/stored (ex. a failure while indexing the documents for the action request).
| @@ -17,7 +16,7 @@ import type { ResponseActionsApiCommandNames } from '../../../../../common/endpo | |||
|
|
|||
| export type CreateActionPayload = TypeOf<typeof ResponseActionBodySchema> & { | |||
| command: ResponseActionsApiCommandNames; | |||
| user?: ReturnType<AuthenticationServiceStart['getCurrentUser']>; | |||
| user?: { username: string } | null | undefined; | |||
There was a problem hiding this comment.
Q: Should we just change user to be not optional for automated actions.
| user?: { username: string } | null | undefined; | |
| user: { username: string } | undefined; |
else just optional user should be okay?
| user?: { username: string } | null | undefined; | |
| user?: { username: string } ; |
There was a problem hiding this comment.
I'm not sure what the impact would be. for now, i'm thinking that we just leave it as is since I was not trying to change much about the existing logic. are you ok with that?
There was a problem hiding this comment.
Yeah that sounds okay about not changing too much. We can clean it up as we go later.
paul-tavares
deleted the
task/olm-bi-directional-response-actions-data-persist
branch
Summary
PR introduces a standard interface for Response Actions clients - currently only Endpoint, but in the near future, other clients will be introduced like SentinelOne. This PR is in preperation for that feature in a post v8.12 release.
Changes include:
EndpointActionsClientclass (first Actions client using new standard interface)EndpointActionsClientfor processing response actionsuploadresponse action (previously a separate handler)uploadspecific API HTTP handler - no longer needed as common handler will now also processuploadresponse actionsNOTE: No changes in functionality as a result of this PR. Just preparation work needed to support Bi-Directional Response Actions.