-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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][Fleet] Install the security_detection_engine package automatically #97191
[Security][Fleet] Install the security_detection_engine package automatically #97191
Conversation
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/fleet (Team:Fleet) |
@@ -15,6 +15,7 @@ export const requiredPackages = { | |||
System: 'system', | |||
Endpoint: 'endpoint', | |||
ElasticAgent: 'elastic_agent', | |||
SecurityDetectionEngine: 'security_detection_engine', |
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.
What happens if this dependency is removed in the future -- is the package just gracefully uninstalled and SO's removed on upgrade?
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.
yeah you got it.
fleet manages all the SOs, so they will be removed during an upgrade/uninstall gracefully. the detection engine will then just use the rules compiled in
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.
maybe I misunderstood the question but if security_detection_engine
is removed from this list of required packages in the future, Fleet will not automatically uninstall the package if it's already installed
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.
Ahhh, so we can have lingering SO's from this package then? This would result in the rules installing from these SO's still, or would the fact the package is no-longer present short circuit that logic?
How can they be manually removed -- will it still show up in fleet until it's un-installed, or is there another way to perform this cleanup?
…cess/kibana into autoinstall-security-detection-pkg
…cess/kibana into autoinstall-security-detection-pkg
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.
Code LGTM
Does this indirectly mean, the detection rules are also installed the first time the user visits the Fleet page or /setup is called? I'm ok to add this for now but I'm also concerned that /setup takes longer and longer: #96026 |
I had the same thought @ruflin, this will add overhead to |
so for this package in particular the only "install" is just the creation of the detection rules SOs. hopefully the overhead of that is smaller and not too obtrusive? yeah I wish there was a way to make these dependencies conditional. requiring the user to navigate to a particular solution could be useful for both endpoint and this package |
…cess/kibana into autoinstall-security-detection-pkg
For some reason, pulling in the 0.18.0 At first, I thought it was just the Instead of fighting an unrelated change in this PR, I think it's most appropriate to change the KQL query acaa76a to something that allows the PR to pass tests. I switched to an This will unblock the PR, and we can investigate a potential 7.12 bug where there appears to be an inconsistency with this particular combination of:
We can look into this in a follow on PR, since it's completely unrelated to the scope of the PR, and only surfaced when |
…atically (elastic#97191) * Automatically install the security_detection_engine package via fleet * Update dockerImage to include the security_detection_engine package * Update api/fleet/setup install test * Update test data for Endpoint package * Fix JSON token * Update firis json entry in destination_index * Update destination_index structure * Update destination_index structure * Change KQL query to unblock testing * Restore KQL and fix JSON instead * update timestamps to pass tests
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…atically (#97191) (#97680) * Automatically install the security_detection_engine package via fleet * Update dockerImage to include the security_detection_engine package * Update api/fleet/setup install test * Update test data for Endpoint package * Fix JSON token * Update firis json entry in destination_index * Update destination_index structure * Update destination_index structure * Change KQL query to unblock testing * Restore KQL and fix JSON instead * update timestamps to pass tests Co-authored-by: Ross Wolf <31489089+rw-access@users.noreply.github.com>
…atically (elastic#97191) * Automatically install the security_detection_engine package via fleet * Update dockerImage to include the security_detection_engine package * Update api/fleet/setup install test * Update test data for Endpoint package * Fix JSON token * Update firis json entry in destination_index * Update destination_index structure * Update destination_index structure * Change KQL query to unblock testing * Restore KQL and fix JSON instead * update timestamps to pass tests
Summary
Related to https://github.com/elastic/security-team/issues/17
Continuation of #96698
Automatically install the
security_detection_engine
package alongside the Endpoint package. This will make security rule updates automatically available to users.Screenshot from a fresh snapshot build:
![image](https://user-images.githubusercontent.com/31489089/114787083-69967a00-9d3c-11eb-9c4f-45f447cb50fe.png)
Checklist
Delete any items that are not applicable to this PR.
For maintainers