Add AWS CloudTrail Support#15227
Conversation
|
Pinging @elastic/siem (Team:SIEM) |
There was a problem hiding this comment.
Most of the mapping to ECS makes sense to me.
I agree with all the fields that are kept as custom fields under aws.* as well. I don't think you've missed any applicable ECS fields for those.
The only thing that's a hard no for me is populating event.category with a value from the source. This is one of the 4 ECS categorization fields, and they're meant to be populated by one of the allowed values defined here. We've just started publishing them in ECS 1.4 (prior to that the field was reserved), and more values are to come. If none of the allowed values for this fields are appropriate for your events (which I think is the case here), the field must be left empty.
There was a problem hiding this comment.
event.category should never be populated with a source value.
In ECS 1.4, we're publishing the first allowed values for this field and other (see this new section).
If none of the values published so far for this field (more to come), this event.category field must be left empty.
So you should capture json.eventType in a custom field.
There was a problem hiding this comment.
Thanks for making that adjustment. LGTM from ECS' POV :-)
You should likely get approval from another Beats maintainer as well, IMO. I only reviewed the mapping of the events.
Thanks for reviewing, that was a big help and gives me a little more confidence that I'm using ECS correctly.
It will be a bit before it is ready to merge, I still have to work out the S3 bucket parts.
webmat
left a comment
There was a problem hiding this comment.
Thanks for making that adjustment. LGTM from ECS' POV :-)
You should likely get approval from another Beats maintainer as well, IMO. I only reviewed the mapping of the events.
There was a problem hiding this comment.
Could you please add release: beta here please? I forgot to add it for previous filesets so I just created a PR to add it: https://github.com/elastic/beats/pull/15248/files
There was a problem hiding this comment.
Added release field. Thanks for catching this
b6d30ac to
f9e7419
Compare
There was a problem hiding this comment.
You can apply the user_agent processor to the Ingest Node configuration to parse the value.
There was a problem hiding this comment.
This should get copied over to the source.ip field when its an IP.
There was a problem hiding this comment.
Do we have a good test for an IP address(4 & 6)? The Cloudtrail docs say "For services in AWS, only the DNS name is displayed". So we have to tell the difference, seeing if geoip works almost does it, but geoip doesn't work for localhost and private IP space.
There was a problem hiding this comment.
Perhaps this should be an actual date type?
|
I have tested a configuration on filebeat 7.5.1 based on this PR. |
|
I just created #15357 to track the work on adding json support for S3 input. |
93d64bb to
98a2494
Compare
|
I hit an error when running this fileset: Original message: |
kaiyan-sheng
left a comment
There was a problem hiding this comment.
Also could you add this fileset does not support CloudTrail-Digest logs in the documentation please? Thanks!
ick, that is because sourcIPAddress contains a hostname and not an IP address, so the geoip processor doesn't like it. Thanks. |
Added that to asciidoc & readme. thanks. |
ecf5ef4 to
398ffa7
Compare
- maps all fields in CloudTrail events - requestParameters, responseElements, additionalEventData & serviceEventDetails are string representations - add event.original - add event.type - add event.kind - add event.outcome - run geoip processor - run agent processor - populated related.user array when possible - uses s3input - CloudTrail must write to S3 bucket, and send all Create Events to an SQS queue we listen to Fixes elastic#14657
398ffa7 to
0bb68e1
Compare
- maps all fields in CloudTrail events - requestParameters, responseElements, additionalEventData & serviceEventDetails are string representations - add event.original - add event.type - add event.kind - add event.outcome - run geoip processor - run agent processor - populated related.user array when possible - uses s3input - CloudTrail must write to S3 bucket, and send all Create Events to an SQS queue we listen to Fixes elastic#14657 (cherry picked from commit da7a697)
- maps all fields in CloudTrail events - requestParameters, responseElements, additionalEventData & serviceEventDetails are string representations - add event.original - add event.type - add event.kind - add event.outcome - run geoip processor - run agent processor - populated related.user array when possible - uses s3input - CloudTrail must write to S3 bucket, and send all Create Events to an SQS queue we listen to Fixes #14657 (cherry picked from commit da7a697)
Direct Field Mappings
Other mappings
To Do