The Packer template used to generate machine images now uses the clean_resource_name function when generating the artifact's image name (changed from clean_ami_name). Note that the clean_ami_name function was deprecated in Packer's 1.5.0 release.
The server-group module now exposes a new user_data_base64 parameter that you can use to pass in Base64-encoded data (e.g., gzipped cloud-init script).
You can now configure the health check max retries and time between retries for Jenkins using the new input variables deployment_health_check_max_retries and deployment_health_check_retry_interval_in_seconds, respectively. Changed the default settings to be ten minutes worth of retries instead of one hour.
Made several updates to the jenkins-server module:
Expose a new user_data_base64 input variable that allows you to pass in Base64-encoded User Data (e.g., such as a gzipped cloud-init script).
Fixed deprecation warnings with the ALB listener rules.
Updated the version of the alb module used under the hood. This new version no longer sets the Environment tag on the load balancer. Therefore, the jenkins-server module no longer takes an environment_name variable as an input variable, so if you're upgrading, you'll need to remove this variable.
This release introduces the ECS Deploy Runner stack, a collection of CLI utilities, modules, and scripts that can be used for implementing a secure Terraform / Terragrunt CI/CD pipeline. Refer to the overview documentation for more details. The following is a summary of the components:
infrastructure-deploy-script: A python script that can be used to run terraform or terragrunt on a module stored in a git repository.
ecs-deploy-runner: A terraform module to manage the ECS Deploy Runner stack. This module contains a Dockerfile for a docker container with the infrastructure-deploy-script and deploys an ECS task definition to run the container on ECS Fargate with an AWS Lambda function that exposes a minimal interface to invoke the deployment task.
ecs-deploy-runner-invoke-iam-policy: A terraform module to manage an IAM policy that grants the minimal permissions necessary to invoke the ECS Deploy Runner Invoker Lambda function.
infrastructure-deployer: A CLI utility to invoke and stream the logs of a deployment running in the ECS Deploy Runner stack.
This release also adds a new script to the terraform-helpers module, git-updated-folders, which can be used to get a list of all the folders that were updated between two git refs (branch, tag, or SHA).
When running with -t, go get will pull versions of packages that might
be needed for testing but not for the functionality of the dependency
that uses it. This can break our tests when those versions have
incompatibilities.
aws-config has been migrated to module-security as the module aws-config-multi-region. If you were using the aws-config module before, replace with the URL to module-security. See the migration guide for more details.
As a result of this change, both aws-config-multi-region and aws-securityhub has been enhanced with a new input variable opt_in_regions which allows you to restrict what regions AWS Config and SecurityHub are enabled in.
Allow specifying the Certificate Authority (CA) bundle to use in the aurora module via the ca_cert_identifier input variable.
Update the ca_cert_identifier input variable in the rds module to set the default to null instead of hard-coding it to rds-ca-2019. This means this module (and the aurora module) will now use whatever default is set by the underlying RDS resources in the AWS provider. This is why this release is marked as backwards incompatible.
You can now configure backtracking (in-place, destructive rollback to a previous point-in-time) on Aurora clusters using the backtrack_window variable.
Add logs:CreateLogGroup to the IAM permissions for the ECS task execution role. This is necessary for ECS to create a new log group if the configured log group does not already exist.
The ecs-service module now exposes task_role_permissions_boundary_arn and task_execution_role_permissions_boundary_arn input parameters that can be used to set permission boundaries on the IAM roles created by this module.
The IAM Role for Service Accounts (IRSA) input variables for the application modules (eks-k8s-external-dns, eks-k8s-cluster-autoscaler, eks-cloudwatch-container-logs, and eks-alb-ingress-controller) are now required. Previously, we defaulted use_iam_role_for_service_accounts to true, but this meant that you needed to provide two required variables eks_openid_connect_provider_arn and eks_openid_connect_provider_url. However, these had defaults of empty string and do not cause an error in the terraform config, which means that you would have a successful deployment even if they weren't set. This can be confusing because each of these services will silently fail since they will not have access to the AWS resources they need to manage. Starting this release the IRSA input variables have been consolidated to a single required variable iam_role_for_service_accounts_config.
The alb module no longer exposes an environment_name input variable. This variable was solely used to set an Environment tag on the load balancer. To upgrade to this version, you will need to remove the environment_name parameter from your code. If you wish to maintain the tag for backwards compatibility, set it in the custom_tags parameter as follows:
custom_tags = { Environment = "whatever value you were setting for environment_name before" }
This release fixes a bug in outputs.tf when removing a port from a listener. The call to zipmap() was not taking in to account removed ports, resulting in an error. We now use slice() to match the remaining ports to the ARNs.
Added a create_resources input variable to cloudwatch-custom-metrics-iam-policy so you can turn the module on and off (this is a workaround for Terraform not supporting count in module).
The cloudwatch-custom-metrics-iam-policy and cloudwatch-log-aggregation-iam-policy modules now output the JSON for the policies they create. This allows you to set create_resources = false to not create the standalone IAM policies and instead, add the JSON from those policies to an IAM entity of your choice (e.g., an IAM role).
The cloudwatch-memory-disk-metrics module now creates and sets up a new OS user cwmonitoring to run the monitoring scripts as. Previously this was using the user who was calling gruntwork-install, which is typically the default user for the cloud (e.g ubuntu for ubuntu and ec2-user for Amazon Linux). You can control which user to use by setting the module parameter cron-user.
All the modules under alarms now expose a create_resources parameter that you can set to false to disable the module so it creates no resources. This is a workaround for Terraform not supporting count or for_each on module. Note that this change is backwards incompatible solely because the route53-health-check-alarms module already exposed an identical enabled parameter, but for consistency with all our other modules and repos, we've renamed it to create_resources. If you were using this enabled parameter on the route53-health-check-alarms module, please rename it to create_resources now.
The run-cloudwatch-logs-agent.sh no longer takes in a --vpc-name parameter, which was only used to set a log group name if --log-group-name was not passed in. The --log-group-name is now required, which is simpler and makes the intent clearer. If you wish to preserve backwards compatibility with the log group name you were using before, set --log-group-name to ${vpc_name}-ec2-syslog.
This release introduces security baseline modules for AWS Landing Zone with examples of how to configure accounts including setting up AWS Config, AWS CloudTrail, Amazon Guard Duty, IAM users, IAM groups, IAM password policies, and more.
The following additional fixes are also included in this release:
The codegen generator go library has been updated to use name_prefix instead of name.
aws-config-multi-region has been updated to use name_prefix instead of name.
Previously, CloudWatch did not have the necessary permissions to deliver notifications to SNS. This release sets permissions correctly, and also fixes the associated GuardDuty test.
The kms-master-key module now exposes a customer_master_key_spec variable that allows you to specify whether the key contains a symmetric key or an asymmetric key pair and the encryption algorithms or signing algorithms that the key supports. The module now also grants kms:GetPublicKey permissions, which is why this release was marked as "backwards incompatible."
Issue #49 reported a number of errors when reducing num_availability_zones. Using the latest version of Terraform I was only able to reproduce one of them related to the VPC endpoint.