Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Add a lifecycle configuration to the two CloudTrail log buckets

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#203 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
75/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
aws, terraform
Domaine
cloud, infrastructure

Piste de recherche

Le travail se trouve dans terraform/cloudtrail.tf. Commencez par lire les ressources de bucket existantes et l'issue liée #191. Ajoutez une ressource aws_s3_bucket_lifecycle_configuration pour chaque bucket, en suivant les instructions détaillées pour le filtre, le statut et la condition de comptage. Après application, vérifiez avec aws s3api get-bucket-lifecycle-configuration.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

complexity: small feature: security role: DevOps Engineer size: 2pt
Overview

We need to give the two CloudTrail log buckets a lifecycle configuration, because neither has one and so audit logs accumulate forever with no stated retention period. The management-events bucket already holds objects going back to October 2022. This is a governance decision more than a cost one — see the sizing below, which is deliberately honest that the money at stake is small.

Action Items
  • Apply the agreed retention period: expire objects after 365 days in both buckets. Settled 2026-09-23 (Alex) with the cost figures below already known, so this is not a number to re-litigate when the assignee notices the saving is small. No compliance regime requiring a longer period has been recorded for Hack for LA; if someone identifies one, raise it here before applying rather than changing the number quietly.
  • Do not add a storage-class transition. This is the counter-intuitive part and it is why the rule should be expiration-only. Glacier tiers bill a 128 KB minimum per object, and these objects are far smaller — averaging 946 bytes in the backend-logs bucket and 13 KB in the management-events bucket. Transitioning would bill 55 GB and 230 GB respectively instead of the real 0.4 GB and 21.3 GB, taking the pair from $0.53/month to $1.14/month, plus a one-off ~$43 in transition requests for 2.17 million objects. The obvious lifecycle rule makes this cost more than twice as much as doing nothing.
  • Add an aws_s3_bucket_lifecycle_configuration resource for each bucket in terraform/cloudtrail.tf, alongside the existing per-bucket resources. Both must carry count = var.iam_only ? 0 : 1 like every other resource in that file, and reference aws_s3_bucket.tf_backend_logs[0].id and aws_s3_bucket.management_events[0].id.
  • Include an abort_incomplete_multipart_upload rule in both, at 7 days. CloudTrail does not generally leave incomplete uploads, but they are invisible in the console and billed as storage, so this is the cheap standard guard.
  • Give each rule an explicit filter {} and an explicit status. A lifecycle rule with no filter is an error in AWS provider v6, and the failure message is not obvious.
  • Update the file-header comment near the top of terraform/cloudtrail.tf, which lists a bucket lifecycle configuration as one of four things deliberately left out by #191. Remove that one from the list; leave the other three as they are.
  • Confirm the plan shows 2 to add, 0 to change, 0 to destroy. Both buckets carry prevent_destroy, so anything touching the bucket resources themselves is wrong.
  • After the PR merges and the apply runs, confirm both configurations exist: aws s3api get-bucket-lifecycle-configuration --bucket <name> on each should return the rules rather than NoSuchLifecycleConfiguration.
  • After the PR merges, be aware the first expiration sweep is not immediate — S3 evaluates lifecycle rules asynchronously, usually within 24–48 hours, and deletions are then visible as a falling object count. Do not read an unchanged count an hour after apply as a failure. Re-check the day after.
  • Sanity-check the blast radius before merging, not after. At 365 days, the management-events bucket loses roughly three of its four years of history on the first sweep, and that deletion is permanent. Confirm that is genuinely intended, and that nobody is relying on 2022–2023 CloudTrail history, before this applies.
Resources/Instructions
  • terraform/cloudtrail.tf — the only file this touches. It already declares, per bucket, the bucket, its policy, its public access block and its encryption configuration, so the lifecycle resource slots in beside those.
  • devops-security#191 — imported both buckets as-is and names the missing lifecycle configuration as deferred work.
  • aws_s3_bucket_lifecycle_configuration
  • S3 lifecycle transition constraints — the source for the 128 KB minimum billable object size that makes a transition rule counter-productive here.

Current state, measured 2026-09-23 (from CloudWatch AWS/S3 daily metrics, not a full listing):

Bucket Trail Objects Size Oldest object Standard cost
aws-cloudtrail-logs-035866691871-4b8654bf devops-security-tf-backend-logs 419,197 378 MB 2024-02-13 ~$0.01/mo
aws-cloudtrail-logs-035866691871-6539ef03 management-events 1,754,593 21.3 GB 2022-10-30 ~$0.52/mo

The cost case is small and that is understood. The two buckets together cost about $6.41 a year, and the management-events bucket has grown at roughly 0.45 GB/month over nearly four years. Expiring at 365 days saves a few dollars annually and no more. The reason this was ticketed is to have a deliberate, written retention period for audit logs and to stop unbounded growth — not to save money. That trade was made with these figures in hand, so an assignee who rediscovers the small saving has not found a reason to close the ticket.

Langage dominant
TypeScript
Étoiles
1
Forks
14
Merge moyen
4 h 56 min
PR mergées (30 j)
10

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de hackforla/devops-security

Toutes les issues de hackforla/devops-security

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.