-
Notifications
You must be signed in to change notification settings - Fork 43
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
Add support for namespace suffixes #2291
base: main
Are you sure you want to change the base?
Conversation
This pull request does not have a backport label. Could you fix it @kubasobon? 🙏
|
📊 Allure Report - 💚 No failures were reported.
|
@@ -55,6 +56,7 @@ type Config struct { | |||
BundlePath string `config:"bundle_path"` | |||
PackagePolicyId string `config:"package_policy_id"` | |||
PackagePolicyRevision int `config:"revision"` | |||
Index string `config:"index"` |
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.
Our integration has the correct ECS data_stream
fields defined, and we could use those to build the index, like so {data_stream.type}-{data_stream.dataset}-{data_stream.namespace}
.
However, the namespace
field is empty for current release of the integration. The Policy/Config also comes with the index
field, which contains a ready-to-use index name in the correct format.
@kfirpeled Do you know where does index
field come from and is it reliable enough for us to use?
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.
How I understand is that a integration has the permissions to to publish to a specific index. See the policy template once you install it. So essentially the integration already knows where you can publish to. The index template is decided by the integration
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, that I know :) I wanted to know if there is anything preventing us from relying on the index
field.
DefaultNamespace = "default" | ||
VulnerabilityType = "vuln_mgmt" | ||
AssetInventoryType = "asset_inventory" | ||
defaultFindingsIndexPrefix = "logs-cloud_security_posture.findings" |
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.
Why is this called default it doesn't mention any namespace?
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.
This is why it's a prefix. The whole index is constructed as {prefix}-{namespace}
. The prefix can vary - see the prefix for Vulnerability events.
@@ -55,6 +56,7 @@ type Config struct { | |||
BundlePath string `config:"bundle_path"` | |||
PackagePolicyId string `config:"package_policy_id"` | |||
PackagePolicyRevision int `config:"revision"` | |||
Index string `config:"index"` |
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.
How I understand is that a integration has the permissions to to publish to a specific index. See the policy template once you install it. So essentially the integration already knows where you can publish to. The index template is decided by the integration
Summary of your changes
This pull request allows Cloudbeat to publish events to non-default namespaces. For example, findings are sent to the
logs-cloud_security_posture.findings-{namespace}
Data Stream. Until now, the{namespace}
always defaulted todefault
, regardless of Agent Policy. After merging this change, Cloudbeat will respect the Agent Policy and set publish events to the appropriate stream.Screenshot/Data
CSPM using non-default namespace
Non-default Data Streams present when running modified cloudbeat
Findings published to the new Data Stream successfully
EDIT:
Vulnerabilities published to the new Data Stream successfully
Related Issues
Closes #2289
Checklist
I have added the necessary README/documentation (if appropriate)