[Cloud Security] add cloud_configuration_finding data stream to wiz

[maxcold]

Proposed commit message

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Screenshots

[elastic-sonarqube]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
84.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[maxcold]

@maxcold rename the file to match the data stream name

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[kfirpeled]

omit -default from the destination index, it is preserved for namespaces. which is not relevant here

[maxcold]

@kfirpeled It wasn't really important for the POC, for better or for worse it shows that the namespace question is still open. I will investigate if we can get around the problem of constant_keyword and have namespace-indifferent latest index or not

[maxcold]

as you suggested it should be possible to have keyword as a type for data_stream.namespace even though the schema restrict it with constant_keyword. Here is some discussion around why restrict it in the schema in the first place elastic/ecs#845 (comment) . Though going against ECS might impose some risks, eg. if the package-spec implements some validation for that in the future for some reason

[kfirpeled]

is it the unique_key?
shouldn't we have resource.id and rule.id as we use in current transform for findings?

[maxcold]

@kfirpeled yes, it should be a combination of the fields we care about same or similar to our native integration. I didn't intend this PR to be production ready and for POC it didn't make a difference really. there are a lot of things to fix if we want to release the cloud_configuration_finding data stream ourselves

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 0467921

Failed CI Steps

• Check integrations wiz

History

• 💔 Build #11975 failed f658333
• 💔 Build #10226 failed 314bd2a

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[maxcold]

Keeping this open as the POC it is a part of is still relevant. Will close after Wiz data stream is implemented

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[maxcold]

closing as transform has already been released and this POC is not relevant enymore