Turn on CloudTrail log file validation for the management-events trail
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- aws, terraform
- Domain
- infrastructure, security
Research direction
The work is in terraform/cloudtrail.tf. Find the aws_cloudtrail.management_events resource and change enable_log_file_validation to true. Update the two-line comment above it and the file-header comment list. Run terraform plan to confirm only that resource changes in-place. After merging, verify with the aws cloudtrail describe-trails and aws s3 ls commands provided.
Written by the indexing model from the issue text.
Description
Overview
We need to turn on CloudTrail log file validation for the management-events trail, so that both of the account's trails produce tamper-evident digest files. Today one trail has it on and the other has it off, which means the trail carrying the account's management events — the higher-value audit record of the two — is the one that cannot be proven unaltered.
Action Items
- In
terraform/cloudtrail.tf, changeenable_log_file_validationfromfalsetotrueon theaws_cloudtrail.management_eventsresource. It is on line 251 as of 2026-09-23 — line numbers drift, so find it by the resource nameresource "aws_cloudtrail" "management_events"rather than by number. - Update the two-line comment immediately above that resource, which currently reads that the inconsistency is "reproduced rather than resolved -- turning it on is a live change and its own ticket." That ticket is this one, so the comment should now say the two trails agree and that validation is on for both. Leave the rest of the file's commentary alone.
- Update the file-header comment near the top of
terraform/cloudtrail.tfthat lists four things deliberately not added by #191. Log file validation is one of the four; remove it from that list and leave the other three (KMS encryption, a CloudWatch Logs destination, a bucket lifecycle configuration) exactly as they are — each is still outstanding. - Confirm the plan shows exactly one resource changing, in place:
aws_cloudtrail.management_events[0]withenable_log_file_validation: false -> true. There must be no replacement and nothing else in the diff. A replacement would destroy and recreate a trail carryingprevent_destroy, so it would fail at plan time — but check rather than rely on that. - Note this resource is gated on
var.iam_only, so it is skipped entirely in a contributor's own AWS account and only applies in CI, whereiam_only = false. A local plan with the default variable will show no change at all; that is expected and is not evidence the edit is wrong. - After the PR merges and the apply runs, confirm both trails report validation on:
aws cloudtrail describe-trails --query 'trailList[].{Name:Name,Validation:LogFileValidationEnabled}' --output table. Both rows must readTrue. - After the PR merges, confirm digest files actually start being written, which is the real proof the setting took effect:
aws s3 ls s3://aws-cloudtrail-logs-035866691871-6539ef03/AWSLogs/035866691871/CloudTrail-Digest/ --recursive | tail. Expect nothing for up to an hour — CloudTrail writes the first digest on its own schedule, not at apply time — so this step is deliberately separate from the one above and may need coming back to later in the day.
Resources/Instructions
terraform/cloudtrail.tf— the only file this ticket touches. Themanagement_eventstrail is the second of the two declared in it; the first,tf_backend_logs, already hasenable_log_file_validation = trueand is the model.- devops-security#191 — imported both trails and both buckets as-is, and deliberately left this inconsistency in place. Its
cloudtrail.tfcomments name this as follow-on work. - Validating CloudTrail log file integrity — what the digest files are and how to verify one with
aws cloudtrail validate-logs. - Digest files are delivered to the same bucket as the logs, under
AWSLogs/<account>/CloudTrail-Digest/, and are billed as ordinary S3 objects. They are small and low-volume relative to the log files themselves, so this adds no meaningful storage cost.
Line numbers above were accurate on 2026-09-23 and may drift; locate the targets by resource name and by the quoted comment text instead.
- Dominant language
- HCL
- Stars
- 1
- Forks
- 14
- Avg merge
- 1h 3m
- Merged PRs (30d)
- 23
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hackforla/devops-security
-
complexity: small feature: security role: DevOps Engineer size: 2pt
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
hackforla/devops-security#203 ·
-
complexity: medium feature: maintenance role: DevOps Engineer size: 2pt
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
hackforla/devops-security#170 ·
-
complexity: prework Feature: Onboarding/Contributing.md role: missing size: 1pt
Difficulty 3/5 3-5 days Newbie friendliness 40/100
hackforla/devops-security#200 ·
-
complexity: small feature: AWS user request role: DevOps Engineer size: 1pt
hackforla/devops-security#198 · 1 assignee ·
-
complexity: prework Feature: Onboarding/Contributing.md role: DevOps Engineer role: missing size: 1pt
Difficulty 4/5 3-5 days Newbie friendliness 45/100
hackforla/devops-security#195 · 1 assignee ·
All issues in hackforla/devops-security
Similar issues
-
core dependencies
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
module: core
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
bigbluebutton/bigbluebutton#25849 ·
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rocky-data/rocky#2181 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100