[Cloud Posture] Handle 3P missing posture type

JordanSh commented 1 month ago

Summary

As part of our migrations for older findings that didn’t include the posture_type field, we used to assume all findings without this field are of type kspm and introduced a runtime mapping that adds safe_posture_type to all findings. this field is used to filter a bunch of our queries. With the introduction of 3P findings, it now creates an issue that 3P findings are assigned as kspm.

it effects user experience in the kubernetes dashboard which mistakenly shows 3P findings statistics.

We can either deprecate the entire process of creating a safe_posture_type, which also include reliant filters and queries. Or go with a quicker safer option of adding a filter in the dashboard to only show data from native csp dataset.

DOD

[x] Wiz findings are not shown in kubernetes dashboard
[x] KSPM workflows shown be verified to still work as expect after the change

I think it's a must-have for 8.16 because if we release any 3rd party integration with CDR support, it will break KSPM dashboards for the users who decide to enable these integrations. As the FF is quite soon and if we don't have enough time even for a quick solution, we can discuss mapping posture_type to cspm in the integrations we plan to release. Though I'd prefer fixing it on Kibana side

JordanSh commented 1 month ago

I think the reason we didn't map them as CSPM was that they include KSPM findings which are not driven directly from kubernetes right? this can cause some confusion, not sure if we can go on this route just yet. though it will be even more annoying to handle dashboard links differently between each finding vendor.

Time wise, IMO we shouldn't stress too much as we don't have serverless users and after feature freeze we can still fix bugs. I'd say all options are possible within this time frame.

maxcold commented 1 month ago

@JordanSh the main reason not to map everything to CSPM as posture_type is our concept and we want to get rid of it longer term, meaning there shouldn't be a separation between CSPM and KSPM. Therefore we didn't want to expose this to 3rd party integration owners, this field will never make it to ECS so asking to hardcode it to CSPM is just asking to play along with our hack and it doesn't scale well. The fact that some findings are k8s related and they will be marked as CSPM is fine by us as far as I recall from the discussions with product

maxcold commented 1 month ago

@JordanSh shared that the issue have limilted impact as currently we don't query 3rd party indexes for dashboards anyway. So it's shouldn't happen that 3rd party data will be ingested with this runtime mapping. But we agreed to still add some safety nets to it

orouz commented 2 weeks ago

verified

elastic / kibana

[Cloud Posture] Handle 3P missing posture type #195202

Summary

DOD

Related