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 AWS CloudTrail Support #15227
Add AWS CloudTrail Support #15227
Conversation
Pinging @elastic/siem (Team:SIEM) |
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.
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.
- rename: | ||
field: "json.eventType" | ||
target_field: event.category | ||
ignore_failure: true |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
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.
@@ -0,0 +1,104 @@ | |||
- name: cloudtrail | |||
type: group |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added release field. Thanks for catching this
b6d30ac
to
f9e7419
Compare
"source.address": "205.251.233.182", | ||
"user.id": "EX_PRINCIPAL_ID", | ||
"user.name": "Alice", | ||
"user_agent.original": "aws-cli/1.10.32 Python/2.7.9 Windows/7 botocore/1.4.22" |
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.
You can apply the user_agent processor to the Ingest Node configuration to parse the value.
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.
will do
"input.type": "log", | ||
"log.offset": 0, | ||
"service.type": "aws", | ||
"source.address": "205.251.233.182", |
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 should get copied over to the source.ip
field when its an IP.
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.
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.
filebeat/docs/fields.asciidoc
Outdated
-- | ||
The date and time when the temporary security credentials were issued. | ||
|
||
type: keyword |
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.
Perhaps this should be an actual date
type?
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.
yes it should
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:
|
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.
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