Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

aws: allow user specification of fields to retain in the cloudtrail data stream#14236

Merged
efd6 merged 4 commits intoelastic:mainfrom
efd6:13500-cloudtrail_interim_solution
Jul 4, 2025
Merged

aws: allow user specification of fields to retain in the cloudtrail data stream#14236
efd6 merged 4 commits intoelastic:mainfrom
efd6:13500-cloudtrail_interim_solution

Conversation

@efd6
Copy link
Contributor

@efd6efd6 commentedJun 17, 2025
edited
Loading

Proposed commit message

aws: allow user specification of fields to retain in the cloudtrail data streamStorage of the response_elements, request_parameters and additional_eventdatais a potentially significant cost, but different users have differentrequirements for their present, so there is no ideal approach. Giventhat it is likely that this optimisation will be a common desire,provide a UI option to allow users to easily configure this behaviourwithout the requirement of adding processors to remove the fields in an@custom pipeline. Note also that there is a TODO in the pipelineaddition here to move from a remove after creation model, spendingfruitless work, to a non-creation model, which would not be possible toimplement in an @custom pipeline.

Checklist

  • I have reviewedtips 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'schangelog.yml file.
  • I have verified that Kibana version constraints are current according toguidelines.
  • I have verified that any added dashboard complies with Kibana'sDashboard good practices

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Screenshots

@efd6efd6 self-assigned thisJun 17, 2025
@efd6efd6 added enhancementNew feature or request Integration:awsAWS Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations] labelsJun 17, 2025
@efd6efd6force-pushed the13500-cloudtrail_interim_solution branch from7d17abf to40b1eebCompareJune 17, 2025 06:35
@efd6efd6 changed the titleaws: allow user-specification of fields to retain in the cloudtrail data streamaws: allow user specification of fields to retain in the cloudtrail data streamJun 17, 2025
@elastic-vault-github-plugin-prod
Copy link

elastic-vault-github-plugin-prodbot commentedJun 17, 2025
edited
Loading

🚀 Benchmarks report

Packageaws 👍(13) 💚(8) 💔(1)

Expand to view
Data streamPrevious EPSNew EPSDiff (%)Result
waf6666.675649.72-1016.95 (-15.25%)💔

To see the full report comment with/test benchmark fullreport

@elasticmachine
Copy link

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

@andrewkrohandrewkroh added the Team:Obs-InfraObsObservability Infrastructure Monitoring team [elastic/obs-infraobs-integrations] labelJun 18, 2025
@efd6efd6force-pushed the13500-cloudtrail_interim_solution branch 2 times, most recently fromaebfd82 tof5e0b91CompareJune 23, 2025 00:46
Comment on lines 199 to 202
Cloudtrail `response_elements`, `request_parameters` and `additional_eventdata` data can
be placed in keyword and text fields as JSON, and in flattened fields. Depending on requirements
This configuration determines which fields will be retained in the final document. The Minimal
option retains the minmal set of fields required for the Security Detection Engine rules.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Suggested change
Cloudtrail `response_elements`, `request_parameters` and `additional_eventdata` data can
be placed in keyword and text fields as JSON, and in flattened fields. Depending on requirements
This configuration determines which fields will be retained in the final document. The Minimal
option retains theminmal set of fields required for the Security Detection Engine rules.
Cloudtrail `response_elements`, `request_parameters` and `additional_eventdata` data can
be placed in keyword and text fields as JSON, and in flattened fields. Depending on requirements
this configuration determines which fields will be retained in the final document. The Minimal
option retains theminimal set of fields required for the Security Detection Engine rules.

efd6 reacted with thumbs up emoji
- text: Flattened
value: flattened
- text: Neither
value: none
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Isminimal not applicable for this input?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

No, I just forgot to add it; it came in later.

kcreddy reacted with thumbs up emoji
@efd6efd6 requested a review fromkcreddyJune 30, 2025 03:36
Copy link
Contributor

@kcreddykcreddy left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM after resolving conflict. Thanks!

efd6 added3 commitsJuly 2, 2025 17:28
…ata streamStorage of the response_elements, request_parameters and additional_eventdatais a potentially significant cost, but different users have differentrequirements for their present, so there is no ideal approach. Giventhat it is likely that this optimisation will be a common desire,provide a UI option to allow users to easily configure this behaviourwithout the requirement of adding processors to remove the fields in an@Custom pipeline. Note also that there is a TODO in the pipelineaddition here to move from a remove after creation model, spendingfruitless work, to a non-creation model, which would not be possible toimplement in an@Custom pipeline.
The fields were identified by running the following shell script in thethe security_detection_engine/kibana/security_rule directory.for f in *; do  jq 'select(.attributes.required_fields != null)|.attributes.required_fields|.[]|select(.name != null)|select(.name|contains("cloudtrail.flattened"))|.name'<$fdone|sort|uniqThe test for this is derived from the test-copy-object-json.log testcase which includes one of the required fields and a number of otherfields under cloudtrail.flattened. So comparing the test added here tothat demonstrates whether is works.
@efd6efd6force-pushed the13500-cloudtrail_interim_solution branch fromc784f79 to3253fb8CompareJuly 2, 2025 07:58
Copy link
Member

@romuletsromulets left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks good overall.

Question. I'm actually not sure what is thehttpjson stream. But why apply hbs changes to s3 and cloudwatch, but not to httpjson?

Comment on lines +1730 to +1739
required_flattened_fields:
- aws.cloudtrail.flattened.additional_eventdata.SSEApplied
- aws.cloudtrail.flattened.request_parameters.cidrIp
- aws.cloudtrail.flattened.request_parameters.dryRun
- aws.cloudtrail.flattened.request_parameters.fromPort
- aws.cloudtrail.flattened.request_parameters.includeDeprecated
- aws.cloudtrail.flattened.request_parameters.policyArn
- aws.cloudtrail.flattened.request_parameters.serialNumber
- aws.cloudtrail.flattened.request_parameters.withDecryption
- aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I personally worry about this duplicated list from the detection engine. This will be easily missed in future iterations. Do you have thoughts on process to avoid it? Or maybe can we automate fetching this list on pre-commit? Or automate tests to verify consistency?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is the consequence of the technical debt that has been built up by the unconstrained use of fields in the detection rules. Fixing this would require a significant refactor and I think is outside the scope of this change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I agree fixing is outside. But what is the strategy to keep consistency in the list with the rules over time?

imays11 reacted with eyes emoji
@efd6
Copy link
ContributorAuthor

efd6 commentedJul 2, 2025

Question. I'm actually not sure what is thehttpjson stream. But why apply hbs changes to s3 and cloudwatch, but not to httpjson?

This was left over when the HTTP JSON input was removed in#13246. There is#14200 to track this.

@efd6
Copy link
ContributorAuthor

efd6 commentedJul 3, 2025

/test

@elasticmachine
Copy link

💚 Build Succeeded

History

cc@efd6

@elastic-sonarqube
Copy link

@efd6efd6 merged commit9c3504d intoelastic:mainJul 4, 2025
7 checks passed
@elastic-vault-github-plugin-prod

Package aws - 3.10.0 containing this change is available athttps://epr.elastic.co/package/aws/3.10.0/

@efd6
Copy link
ContributorAuthor

efd6 commentedJul 6, 2025

Follow up issue:#14429

robester0403 pushed a commit to robester0403/integrations that referenced this pull requestJul 8, 2025
…ata stream (elastic#14236)Storage of the response_elements, request_parameters and additional_eventdatais a potentially significant cost, but different users have differentrequirements for their present, so there is no ideal approach. Giventhat it is likely that this optimisation will be a common desire,provide a UI option to allow users to easily configure this behaviourwithout the requirement of adding processors to remove the fields in an@Custom pipeline. Note also that there is a TODO in the pipelineaddition here to move from a remove after creation model, spendingfruitless work, to a non-creation model, which would not be possible toimplement in an@Custom pipeline.
efd6 added a commit that referenced this pull requestJul 16, 2025
In#14236 we allowed users to select which extended fields they wantedto retain in order to reduce storage costs in cases where they did notwhat the full set of capacities that the data stream can provide. Wedid not however prevent the work of collecting those unwanted fields.This change does that, avoiding retaining fields that will ultimatelynot be kept if possible.It is unfortunate that the wide variety of fields is needed at all, butresolving that depends on improving platform support for the diversityof fields that the data source provides and then making more efficientuse of those improvements in the detection rules. Until then, this iswhat we have.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@zmoogzmoogzmoog approved these changes

@romuletsromuletsromulets approved these changes

@kcreddykcreddykcreddy approved these changes

@ishleenk17ishleenk17ishleenk17 approved these changes

@strawgatestrawgateAwaiting requested review from strawgate

Assignees

@efd6efd6

Labels

enhancementNew feature or requestIntegration:awsAWSTeam:Obs-InfraObsObservability Infrastructure Monitoring team [elastic/obs-infraobs-integrations]Team:Security-Service IntegrationsSecurity Service Integrations team [elastic/security-service-integrations]

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@efd6@elasticmachine@zmoog@romulets@kcreddy@ishleenk17@andrewkroh

Comments


[8]ページ先頭

©2009-2026 Movatter.jp