[Security Solution] Add alerts-as-data index names as alias to signals indices #119921
Conversation
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
marshallmain
added
Team: SecuritySolution
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
In testing I noticed Default columns: Adding other |
| if (await templateNeedsUpdate({ alias: index, esClient })) { | ||
| await esClient.indices.putIndexTemplate({ | ||
| name: index, | ||
| body: getSignalsTemplate(index) as Record<string, unknown>, | ||
| body: getSignalsTemplate(index, aadIndexAliasName) as Record<string, unknown>, |
There was a problem hiding this comment.
I haven't been following the latest Rule Preview efforts closely so just curious here, but why are we setting up the preview index with aliases to the AAD index? Looks like it's getting setup with the signals' fieldAliases as well (within getSignalsTemplate). Is this for querying compatibility with existing components?
There was a problem hiding this comment.
We don't need the index alias, I just wanted to avoid having conditional logic in getSignalsTemplate and this route is going away entirely in #116374 (it never shipped in 7.16 so we can remove this route without issue). Since we definitely do need the alias for the "regular" .siem-signals template, I didn't want to make the "alias" parameter optional and then have more confusion about when it is/isn't needed.
After #116374, the preview index/template logic will be handled by the RuleDataService.
The field aliases do matter though, as attempting to write to a field that is defined as an alias in the mapping will result in an error. This means for the new AAD indices since the signal.* fields are still defined (as aliases now) we'll still have conflicts if we try to copy user's source data into those fields.
There was a problem hiding this comment.
Ahh, perfect -- thanks for explaining! 🙂
There was a problem hiding this comment.
Checked out, performed upgrade test locally, and confirmed aliases are now appropriately set post-upgrade. Pre-8.x alerts now show in the Security Alerts table, and querying against the .alerts-security.alerts* Data View within Discover shows documents from the .siem-signals-* index as well.
Thanks for the fix and cleanup around spaceId here @marshallmain! 🙂 LGTM! 👍 🚀
Note: One nit on 'mis-match' of field aliases resulting in pre-8.x alerts not showing Severity/Risk Score. Chatted w/ Marshall and this will be addressed in another PR (write to new kibana.alert.* fields, and update the Alert Table's default columns).
…s indices (elastic#119921) * Add alerts-as-data index names as alias to signals indices * Update jest snapshot
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…s indices (#119921) (#120046) * Add alerts-as-data index names as alias to signals indices * Update jest snapshot Co-authored-by: Marshall Main <[email protected]>
…s indices (elastic#119921) * Add alerts-as-data index names as alias to signals indices * Update jest snapshot
Summary
Re-adds the index alias to
.siem-signalsindex template and updates theSIGNALS_TEMPLATE_VERSION. Updating the version will cause thecreate_index_routeto be called, applying the alias to existing indices as well as rolling over the index after updating the template.