-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Actions] Introduce the isSystemAction
property to actions
#160753
Conversation
isSystemAction
to actions
Pinging @elastic/response-ops (Team:ResponseOps) |
isSystemAction
to actionsisSystemAction
property to actions
45e2605
to
b070bd9
Compare
@elasticmachine merge upstream |
…ana into system_actions_registration
Pinging @elastic/uptime (Team:uptime) |
@@ -61,6 +61,7 @@ export const fetchConnectors = async (): Promise<ActionConnector[]> => { | |||
is_preconfigured: isPreconfigured, | |||
is_deprecated: isDeprecated, | |||
is_missing_secrets: isMissingSecrets, | |||
is_system_action: isSystemAction, |
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 it possible to move this util to actions plugin? or reuse?
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 think it is better if the action plugin exposes a function that does the API call and the transformation as we do in cases. I think the recommendation is to not call the APIs of other plugins directly but use a thin client. This way the team can do changes in the API without affecting other teams. This will also be helpful when versioning our endpoints. @pmuellr Is there any issue for that?
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'm not aware of explicit issues covering this - sounds like a nice addition to the client-side actions plugin. If I understand correctly. Open an issue?
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.
Ok, I will open an issue. @shahzad31 What do you think of this approach (addressing it on another PR)?
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.
Done #160902
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @cnasikas |
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 !!
Probably a follow up to discuss using client to fetch list of connector !!
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 !!
Probably a follow up to discuss using client to fetch list of connector !!
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-threat-hunting-explore changes LGTM!
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! Verified upgrading existing connectors still loads, exporting/importing works and listing all connectors via the API shows the new property.
Hey @cnasikas, could you please provide links to product tickets or any other context for what this change is related to and what does |
Hey @banderror! Sorry my mistake, I should have put them in the description. This is one of many PRs to support System (Response) actions in the actions' framework like OsQuery, Isolating a host, etc. Here is the issue #160367. At the bottom, you can find all related tickets. |
|
||
export type SystemAction = Omit<ActionConnectorProps<never, never>, 'config' | 'secrets'> & { | ||
isSystemAction: true; | ||
isPreconfigured: false; |
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.
If you imagine we end up changing isPreconfigured
to isInMemory
or similiar, we'd end up probably wanting isPreconfigured
to be true
, whenever isSystemAction
is true. That way, we won't have to change any of our current isPreconfigured
checks, that are typically to check if it's persisted as an SO or not.
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 don't know how this will play out in the UI yet. I suspect that we would like to have the separation. I will keep your suggestion in mind when the time comes. In the backend, we should have the separation as we treat the preconfigured and the system actions a bit differently.
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
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.
Detection Rule Management changes LGTM 👍
Thanks for providing the context info, I read the #160367 ticket and have a few questions.
-
Do you or @patrykkopycinski already have a plan for migrating Response Actions from Security Solution to the Framework? Or is this on any team's roadmap? I saw [Research] Supporting response actions with alerting and connectors #155644 but it doesn't have any version labels etc.
-
Is there any clarity around exporting/importing system actions? In Security Solution, we have our own Detection API endpoints for exporting and importing rules. With rules, we also export and import connectors, if any of the rules have actions related to them. Do you have any recommendations for how should we handle system actions in these endpoints? I'd assume we should skip exporting them and ignore them or return an error on import.
Here's a function that is called when the detection rule export endpoint gets the connectors to be exported:
Lines 46 to 57 in df408bd
const filterOutPredefinedActionConnectorsIds = async ( | |
actionsClient: ActionsClient, | |
actionsIdsToExport: string[] | |
): Promise<string[]> => { | |
const allActions = await actionsClient.getAll(); | |
const predefinedActionsIds = allActions | |
.filter(({ isPreconfigured }) => isPreconfigured) | |
.map(({ id }) => id); | |
if (predefinedActionsIds.length) | |
return actionsIdsToExport.filter((id) => !predefinedActionsIds.includes(id)); | |
return actionsIdsToExport; | |
}; |
@@ -81,6 +81,7 @@ export interface ActionResult<Config extends ActionTypeConfig = ActionTypeConfig | |||
config?: Config; | |||
isPreconfigured: boolean; | |||
isDeprecated: boolean; | |||
isSystemAction: boolean; |
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.
It would be great to start documenting at least public interfaces that are exported from the Framework -- for us on the solution side it's often hard to navigate the Framework's code, but we need to do it from time to time.
Here we could add a JSDoc comment with a description of the field and a link to #160367.
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.
Good point! I will do it in the following PRs as I will probably introduce more types.
Thank you @banderror! We target 8.10 for the system actions. The migration should be handled by the Security solution team. @patrykkopycinski and the team are aware of our work. We are working with @kobelb to find a seamless backward compatibility migration path. We will let you know about it soon. Regarding, import/export we will not support it for system actions as they should always be available in every deployment (they are created on Kibana startup on the fly). I was not aware of this functionality in Security Solution. I will address it myself in the following PRs when I do the same for the import/export from the stack management. Thanks for letting me know! |
Summary
This PR introduces the
isSystemAction: boolean
to theActionResult
type. It also, adds the same to theActionType
type. I added validation to verify that system actions cannot be registered at the moment. More PRs are going to follow to incrementally build the feature.Related: #160367
Checklist
Delete any items that are not applicable to this PR.
For maintainers