Closed uri-weisman closed 1 year ago
fyi @kfirpeled @JordanSh
Hi @uri-weisman,
Thanks for this interesting post.
I would like to share two thoughts I have in mind:
You wouldn't able to change the processor name, since it will cause a breaking change. For example, a new integration with an older agent will run an old Cloudbeat. The old Cloudbeat wouldn't know what is the add_identifier
and will cause Cloudbeat to crush.
Do we really want to couple all the identifiers together? I mean, we can use multiple small processors, each of which will be responsible for a small thing. That way, if you have an EKS cluster for example you could enable both the add_cluster_id
processor and to add the add_account_id
processor.
@ofiriro3 - I agree, creating a new processor seems to be the better option, thanks for sharing your thoughts.
Hey, just to be align, we agree here that the field name will be cloud.account.id
right?
Yes
verified
Motivation For k8s deployments (EKS/Vanilla) we use the
add_cluster_id
processor to enrich the events by adding acluster_id
field. Currently, for understandable reasons, the processor is disabled for the CSPM integration, meaning we're not sending a global identifier for the findings which makes it hard to aggregate them.Definition of done What needs to be completed at the end of this task
add_cluster_id
processor / create a new one to add a global identifier (account_id) to the AWS CIS findings.Out of scope What should not be included in this task
Related tasks/epics Reference related issues and epics