- Enforces access over HTTPS to all Fleet-terraform created buckets.
- Fixes vpc-flow-logs log retention; now allows configuring the
retention in days.
- Adds `var.enable_reencrypt_sweep` to control when lambda functions and
permission resources should be created.
- Adds `var.iam_role_name_prefix` to allow overriding the prefix used
for iam_role naming, when `var.enable_reencrypt_sweep = true`
## Summary
This PR extends the Fleet ECS modules to support:
- configurable Fleet server private key delivery via ecs or iam
- optional fleet_config.command overrides for Fleet task definitions
- caller-managed Fleet server private key secrets via
fleet_config.private_key_secret_arn
It also updates the external vuln scans addon to follow the same
private-key delivery and command behavior, and refreshes the generated
module documentation.
## What changed
- Added fleet_config.private_key_delivery_method with supported values:
- ecs (default): inject the private key as FLEET_SERVER_PRIVATE_KEY
- iam: inject the secret ARN as FLEET_SERVER_PRIVATE_KEY_ARN
- Added validation so only ecs or iam are accepted
- Added fleet_config.command support so callers can override the Fleet
container command when needed
- Added fleet_config.private_key_secret_arn support so callers can
supply an existing Secrets Manager secret instead of having this module
create and populate one
- Updated IAM policy wiring so private-key secret access and private-key
KMS decrypt permissions are granted to the correct role based on the
selected delivery method
- Updated module outputs so fleet_server_private_key_secret_arn returns
the effective ARN whether the secret is module-managed or caller-managed
- Updated addons/external-vuln-scans to consume the same private-key
delivery mode and optional command behavior from the passed fleet_config
- Updated byo-ecs documentation and regenerated README files
## Behavior
### Private key delivery
- ecs mode injects the secret value into the container and uses the ECS
execution role for private-key secret access
- iam mode injects the secret ARN into the container environment and
uses the Fleet task role for private-key secret access
### Command override
- When fleet_config.command is unset, the task definition omits command
- When fleet_config.command is set, the provided command is passed
through to the Fleet container
- This behavior now applies consistently to both the main ECS service
and external vuln scans
### Caller-managed private key secret
- When fleet_config.private_key_secret_arn is unset, the module creates
and populates the Fleet private key secret
- When fleet_config.private_key_secret_arn is set, the module uses the
provided secret ARN and does not create the secret, secret version, or
generated random value
## KMS note for external secrets
If a caller-managed private-key secret uses a CMK, the caller must also
provide the existing private-key KMS ARN input so the correct role
receives decrypt permissions for the selected delivery mode.
## Validation
Validated successfully with:
- terraform validate -no-color at repo root
- terraform validate -no-color in byo-vpc
- terraform validate -no-color in byo-vpc/byo-db
- terraform validate -no-color in byo-vpc/byo-db/byo-ecs
Also verified that existing module-managed private-key resources plan as
non-destructive state-address moves when transitioning to the new
counted resources:
- 0 to add
- 0 to change
- 0 to destroy
## Highlights
- Upgrades Aurora from `terraform-aws-modules/rds-aurora/aws` `7.6.0` to
`9.16.1`
- Bumps the Terraform minimum version from `>= 1.3.8` to `>= 1.5.0`
- Adds CMK support across newly exposed RDS, Redis, VPC, ECS, and Fleet
surfaces
- Adds additive per-key `extra_kms_policies` support across the root ->
`byo-vpc` -> `byo-db` -> `byo-ecs` path
- Moves software-installers KMS policy ownership out of
`addons/cloudfront-software-installers` and back into `byo-ecs`
- Extends monitoring and ECS integration to work with CMK-encrypted DB
password secrets
- Adds migration tooling and docs for Aurora storage KMS replacement and
CloudWatch Logs KMS cutovers
## Aurora module upgrade: `7.6.0` -> `9.16.1`
This PR keeps a single Aurora module path on upstream `9.16.1` and
updates the Fleet wrapper modules to preserve compatibility where
possible while exposing the new KMS and observability capabilities.
Notable changes handled in the wrapper:
- `security_group_rules`
- upstream moved from older SG rule addressing to the newer
`security_group_rules` model
- added `moved` handling for the confirmed SG rule address rename to
avoid unnecessary destroy/create churn
- `manage_master_user_password`
- the wrapper continues to own the DB password flow
- Aurora is kept on `manage_master_user_password = false`
- Secrets Manager integration remains wrapper-managed rather than
switching to upstream-managed password behavior
- `final_snapshot_identifier`
- wrapper support was added so old behavior is preserved
- if unset, the legacy generated naming pattern is still used
- callers can now override it explicitly
- Observability / Database Insights wiring
- cluster-level Performance Insights / Database Insights configuration
was added to match Aurora's current control surface
- monitoring behavior was aligned to cluster-level management for
consistency with the Aurora module and Database Insights requirements
- `backtrack_window`
- added optional pass-through support for Aurora MySQL backtracking
- validated as `null` or `0..259200`
## Terraform version bump
This PR raises the Terraform minimum version from `>= 1.3.8` to `>=
1.5.0`.
Reason:
- deprecation warnings for legacy KMS `enabled` flags now use Terraform
`check` blocks
- `check` blocks require Terraform `1.5+`
This was done so published interfaces can remain backward-compatible for
existing `enabled` users while still warning during plan/apply and
preferring `cmk_enabled`.
## KMS surface expansion and pass-through
This PR adds or expands CMK support for:
- Aurora storage
- Aurora password secret
- Aurora observability / Performance Insights
- Aurora exported log groups
- Redis at-rest encryption
- Redis log groups
- VPC flow log CloudWatch log groups
- ECS cluster log groups
- Fleet private-key secret
- Fleet Fargate ephemeral storage
- Fleet application logs
- Fleet software installers
It also adds additive `extra_kms_policies` support across those
module-owned CMK surfaces so callers can append narrowly scoped
statements without replacing the inherited base policy.
During validation of the cron-monitoring integration, I found that the
root module schema was still dropping some nested KMS attributes before
they reached `byo-vpc`. This PR now carries those fields all the way
through to their final destinations, including:
- `rds_config.*.extra_kms_policies`
- `redis_config.*.extra_kms_policies`
- `ecs_cluster.cloudwatch_log_group.kms.extra_kms_policies`
- `fleet_config.private_key_secret_kms.extra_kms_policies`
- `fleet_config.fargate_ephemeral_storage_kms.extra_kms_policies`
- `fleet_config.awslogs.kms.extra_kms_policies`
- `fleet_config.software_installers.extra_kms_policies`
- `fleet_config.software_installers.cloudfront_distribution_arn`
- `vpc.flow_log_cloudwatch_log_group_kms.extra_kms_policies`
## DB password secret KMS handoff to monitoring
`byo-vpc` now exposes:
- `rds_password_secret_kms_key_arn`
The monitoring addon now accepts:
- `cron_monitoring.mysql_password_secret_kms_key_arn`
The monitoring addon also now exposes:
- `cron_monitoring_lambda_arn`
- `cron_monitoring_lambda_role_arn`
This is needed so the cron-monitoring Lambda can decrypt the Fleet DB
password secret when that secret is encrypted with a customer-managed
KMS key.
Expected wiring:
```hcl
module "monitoring" {
# ...
cron_monitoring = {
# ...
mysql_password_secret_name = "${local.customer}-database-password"
mysql_password_secret_kms_key_arn = module.main.byo-vpc.rds_password_secret_kms_key_arn
}
}
```
## Software installers KMS ownership change
This PR changes the software-installers KMS contract:
- `addons/cloudfront-software-installers` no longer manages the
software-installers KMS key policy
- `byo-ecs` now owns the software-installers CMK policy, including
required service / principal statements
- `fleet_config.software_installers.cloudfront_distribution_arn` is the
static input used to add the CloudFront KMS statement without
introducing a module cycle
- `byo-ecs` also adds the explicit Fleet task-role KMS statement
required under the narrower external key-policy model
- the CloudFront addon exposes `cloudfront_distribution_arn` for
visibility, but that output should not be fed back into `byo-ecs`
because that would create a dependency cycle
Important compatibility note:
- if software installers uses KMS at all, it must use a customer-managed
key
- CloudFront requires a key-policy statement on that key
- the AWS-managed default key cannot be modified to attach that policy
## Other notable items
- Added and expanded migration docs for RDS and Redis KMS adoption
- Added `byo-vpc/scripts/rds_storage_kms_migration.sh` to automate
Aurora storage-KMS migration workflows
- Added `scripts/cloudwatch_logs_kms_migration.sh` to help identify and
optionally remove pre-cutover log streams after associating a new KMS
key with a CloudWatch Logs group
- Normalized `cmk_enabled` usage while preserving deprecated `enabled`
compatibility only for previously published interfaces
- Refactored `addons/logging-alb` KMS policy handling to support
`kms_base_policy` and align it with the structured KMS statement model
used elsewhere
- Reduced repeated KMS policy boilerplate within modules where it was
materially duplicated
## Compatibility notes
- Existing published KMS interfaces that previously used `enabled` still
accept it, but now warn and prefer `cmk_enabled`
- New KMS surfaces are `cmk_enabled`-only
- Software-installers KMS policy ownership moved from
`addons/cloudfront-software-installers` to `byo-ecs`
## Validation
Validated module stacks after the refactors:
- `root`
- `byo-vpc`
- `byo-db`
- `byo-ecs`
- `addons/monitoring`
- `addons/cloudfront-software-installers`
- `addons/logging-alb`
- Fixes
`FLEET_S3_SOFTWARE_INSTALLERS_CLOUDFRONT_URL_SIGNING_PUBLIC_KEY_ID`
where the value is currently set to `var.key_group_id` instead of the
required `public_key_id`.
- Updates the cloudfront s3 origin to use the the regional s3 bucket
endpoint over the legacy global s3 bucket endpoint.
- Added variable validations to detect when `key_group_id` is added
without `public_key_id`, vice versa.
Closes: https://github.com/fleetdm/fleet-terraform/issues/149
- Updates `mysql_password_secret_name` for documented monitoring example
in `addons/monitoring/.header.md` & `addons/monitoring/README.md` to
address `inconsistent final plan`
- Pins nested module, `module.cloudfront_software_installers`, to
`5.2.0`
- Adds support for `var.key_group_id` to use an existing Cloudfront Key
Group
Robert Fairburn