terraform-aws-security adds S3 lifecycle controls and fixes fail2ban metrics

terraform-aws-security, Gruntwork’s collection of AWS security modules, now exposes the S3 lifecycle minimum object size setting through its logging bucket wrappers. This week’s activity also fixes fail2ban CloudWatch reporting on Ubuntu 24 and adds package installation retries to the ssh-grunt build.

S3 lifecycle defaults reach the module inputs

The October 15 change adds transition_default_minimum_object_size to the Config, CloudTrail, and GuardDuty bucket wrappers. Config and CloudTrail callers can pass it through the higher level modules too. The stated intent is practical: let existing buckets keep varies_by_storage_class explicitly.

The new string input defaults to null. Its description lists all_storage_classes_128K and varies_by_storage_class as the supported values. Leaving it unset delegates the choice to the provider default. That distinction matters when reviewing a plan: adding the input does not itself pin your preferred lifecycle behavior.

The CloudTrail variable declaration also notes that explicit object size filters take precedence over the default transition behavior. Check those filters alongside the new setting when investigating why particular objects qualify for archival.

For contributors, the change includes both the generated Config module and its generation template. That keeps the new argument in the source used to regenerate the regional module calls. Much of the large diff is repeated argument wiring and alignment across regions.

Ubuntu fail2ban restores its CloudWatch action

The Ubuntu fix addresses two separate problems. First, fail2ban’s short daemon PATH could miss AWS CLI v2. The CloudWatch action configuration now sets an explicit path that includes /usr/local/bin and appends command output and errors to /var/log/fail2ban.log.

The Ubuntu dependency installer also places the AWS CLI executable in /usr/bin. Together, these edits address command discovery and make failed metric submissions visible in the fail2ban log.

Second, the Ubuntu jail configuration replaces its hardcoded iptables-multiport action with %(banaction)s, followed by the CloudWatch action. The commit identifies the old configuration as a problem with fail2ban 1.0 and Ubuntu 24’s nftables default. Ban and unban events still publish BannedIPAddresses and UnbannedIPAddresses, with an InstanceId dimension. This repairs the reporting path while retaining those metric names.

Package retries for ssh-grunt builds

The ssh-grunt Dockerfile now retries the apt update and installation sequence up to three times. It waits five seconds after a failed attempt, checks that an attempt succeeded, and removes apt lists afterward. Installation also uses --no-install-recommends.

The packages remain sudo, cron, and rsyslog. These retries address transient package fetch failures during image builds. The final success check still fails the build if every attempt fails.

One detail deserves care when reading the commit message: it mentions moving to Go 1.26 on Bookworm, but the actual Dockerfile diff retains golang:1.24-bookworm. The observable change here is package installation handling; the diff does not establish a Go toolchain upgrade.

How to prepare

• Review lifecycle plans for Config, CloudTrail, and GuardDuty buckets. If preserving varies_by_storage_class is your intent, pass it explicitly through the new input and inspect the resulting plan.
• On an Ubuntu 24 test instance, exercise a controlled ban and unban after updating the fail2ban configuration. Check both CloudWatch metrics and /var/log/fail2ban.log for submission errors.
• If you build ssh-grunt images, verify the retry behavior in your build pipeline. This activity window contains one commit and establishes no release version, so check that your pinned source includes it.