-
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
[Security Solution] [Detections] EQL Rule Creation #76831
Changes from 11 commits
cce81d4
9d5ce1c
3e1a793
f71af23
2314ba3
e162d53
872bbe6
3a47b2f
1611b52
8d88dcb
c85ffcf
5094b04
a9a6703
ef64b1f
3759011
35b00cd
b9b590b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -130,7 +130,7 @@ export type Query = t.TypeOf<typeof query>; | |
export const queryOrUndefined = t.union([query, t.undefined]); | ||
export type QueryOrUndefined = t.TypeOf<typeof queryOrUndefined>; | ||
|
||
export const language = t.keyof({ kuery: null, lucene: null }); | ||
export const language = t.keyof({ eql: null, kuery: null, lucene: null }); | ||
export type Language = t.TypeOf<typeof language>; | ||
|
||
export const languageOrUndefined = t.union([language, t.undefined]); | ||
|
@@ -294,6 +294,7 @@ export const toOrUndefined = t.union([to, t.undefined]); | |
export type ToOrUndefined = t.TypeOf<typeof toOrUndefined>; | ||
|
||
export const type = t.keyof({ | ||
eql: null, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. does it make sense from a schema perspective to have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rw-access that's an interesting point. In general, a rule's type could be derived from its other fields, and we're mainly using it as a shortcut for that determination. I don't believe there's currently any ambiguity that the Another consideration is Since both the querying and the alert generation are unique to EQL, I'm inclined to promote that "up" to the rule There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, I think EQL is very special snowflake compared to Lucene/KQL, because of the complexity in its response format. Like you said, I think that it makes sense that even though the schema of the rule itself is otherwise identical to KQL/Lucene, it's processed very differently. Great point. I wonder if that adds some more precision to what Thanks, this gave me some mental clarity. It could be worthwhile to communicate some of that reasoning in the "Rule type" part of the UI. I think "Use KQL or Lucene to detect issues across indices." makes me think about cluster health. Maybe "Use KQL or Lucene to alert when documents match a condition" could help, but I'll defer to you and the UX team. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Those are great points! I've opened a ticket to discuss our qualification of the different rule types and how we present that to the user: #77250 |
||
machine_learning: null, | ||
query: null, | ||
saved_query: null, | ||
|
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.
@sebelga I haven't yet added a test to encompass this change, but you can read about the errant behavior in 9d5ce1c. My first thought was simply to assert that
React.createElement
is called when a custom component is used, but I'd appreciate your thoughts!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 would prefer to test the different use cases instead of the implementation. So I would have a dummy form with 3 types of fields (or more if there are more use cases) and make sure they render correctly (are present in the DOM)
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.
Do you mind explaining what you mean by "Cannot switch between UseField components"?
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.
@sebelga in this PR we're swapping between two different field components based on which rule type the user has chosen. link. This causes react warnings if the components are not invoked with React.createElement.
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.
@sebelga tests added here: a9a6703
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.
Cool thanks for the tests @rylnd !
For the swap of components, we took the habit of adding a
key
to theUseField
being swapped. To make sure the component unmounts and re-mounts.