-
Notifications
You must be signed in to change notification settings - Fork 489
[Cloud Security] add observer.vendor to cloud_security_posture #10945
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
Conversation
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.
@JordanSh in the designs we have the Source
column as Elastic CSPM
. But as in the latest sync we discussed having vendor and product separately in the future and the fact that logically observer.vendor: Elastic
makes more sense I added just Elastic
as value for both findings and vulnerabilties. Wdyt? Having conditional logic to have Elastic CSPM
and Elastic KSPM
based on the posture type is not complicated, but it doesn't look like the correct values for the vendor field
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.
Makes sense to me, currently I used Elastic CSP
for both cspm and kspm, but Elastic
works as well. I do think that the final decision should be made by our product. Maybe we can set an early meeting just to discuss this topic instead of waiting for the weekly sync
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.
as discussed at the last sync we are going with the value Elastic
🚀 Benchmarks reportTo see the full report comment with |
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.
Values that are always the same in every event are best set through a constant_keyword
mapping with a static value. It's better for storage efficiency.
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.
that makes sense, one question though, what is the process of changing this value in the future in case it is needed? If i understand correctly the constant_keyword mapping would reject any other value and it will be a breaking change to the mapping which is complicated to implement. What is the update strategy in such cases?
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 see that there are a lot of already existing cases where observer.vendor is set through the pipeline, so I'm assuming it's not a big performance concern. I'd leave it as keyword
for now as from the product side we have ongoing discussion for the values of the observer.vendor, so I don't want to corner ourselves with setting constant_keyword
now
💚 Build Succeeded
History
|
|
Package cloud_security_posture - 1.11.0-preview06 containing this change is available at https://epr.elastic.co/search?package=cloud_security_posture |
Package cloud_security_posture - 1.11.0 containing this change is available at https://epr.elastic.co/package/cloud_security_posture/1.11.0/ |
…ic#10945) * add observer.vendor to cloud_security_posture * add PR to the changelog
…ic#10945) * add observer.vendor to cloud_security_posture * add PR to the changelog
Proposed commit message
As per elastic/kibana#188802 we want to use
observer.vendor
field to differentiate between native and 3rd party integration in our workflowsChecklist
changelog.yml
file.Author's Checklist
How to test this PR locally
Related issues
Screenshots