Gruntwork Newsletter, May 2021

Published in

Gruntwork

24 min readJun 3, 2021

Once a month, we send out a newsletter to all Gruntwork customers that describes all the updates we’ve made in the last month, news in the DevOps industry, and important security updates. Note that many of the links below go to private repos in the Gruntwork Infrastructure as Code Library and Reference Architecture that are only accessible to customers.

Hello Grunts,

In the last couple of months, we had a number of major new releases: Reference Architecture 2.0 and CIS Reference Architecture 2.0 are out, the Service Catalog and the CIS Service Catalog are generally available, and we’ve open sourced git-xargs! We also updated the entire IaC Library to work with Terraform 0.15, enabled encryption by default in all modules, made progress on the Ubuntu 20.04 upgrade, and made many other fixes and improvements.

As always, if you have any questions or need help, email us at support@gruntwork.io!

Gruntwork Updates
DevOps News
Security Updates

Gruntwork Updates

Introducing: Reference Architecture 2.0

Motivation: We launched version 1.0 of the Gruntwork Reference Architecture back in 2016 as a way to get a production-grade, end-to-end tech stack for AWS, 100% managed as code, in about 1 day. Since then, we’ve launched many new products and made major improvements to Terragrunt, so it was time for the Reference Architecture to get a refresh.

Solution: We’re excited to announce the general availability of version 2.0 of the Gruntwork Reference Architecture! You now not only get a production-grade, end-to-end tech stack for AWS, 100% managed as code, in about 1 day, but now it is built on top of the Gruntwork Service Catalog, includes the Gruntwork Landing Zone, and has a fully-integrated CI / CD pipeline for apps and infra built on top of Gruntwork Pipelines. It is, without a doubt, the best way to go to production on AWS.

What to do about it: Check out the announcement blog post for all the details!

The Gruntwork Service Catalog is now generally available

Motivation: The Gruntwork Service Catalog is a collection of battle-tested infrastructure as code modules that are designed to be deployed directly to production, without having to write any code yourself. We launched a private alpha of the Service Catalog back in August, 2020, and many customers have been asking for access.

Solution: The Service Catalog is now generally available to all existing and future Gruntwork customers! This allows you to launch production-grade services in minutes. For example, here’s how you can use the eks-cluster service to deploy a production-grade EKS cluster with a single Terragrunt configuration file:

# Use off-the-shelf code from the Gruntwork Service Catalog
terraform {
  source = "git::git@github.com:gruntwork-io/aws-service-catalog.git//modules/services/eks-cluster?ref=v0.0.5"
}# Pull in outputs from your VPC
dependency "vpc" {
  config_path = "../../networking/vpc"
}# Configuration for the eks-cluster service
inputs = {
  cluster_name          = "example-eks-cluster"
  cluster_instance_type = "m4.large"
  cluster_instance_ami  = "<YOUR AMI ID>"
  
  # Deploy a a separate ASG per subnet / availability zone.
  autoscaling_group_configurations = {
    for subnet_id in dependency.vpc.outputs.private_app_subnet_ids :
    subnet_id => {
      min_size   = 3
      max_size   = 5
      subnet_ids = [subnet_id]
      tags       = []
    }
  }    # ... (other params omitted) ...
}

Plug the code above into a file called terragrunt.hcl, run terragrunt apply, and you have a production-grade EKS cluster in minutes! Note: Terragrunt is not required; all the code above works with pure Terraform and Terraform Cloud / Terraform Enterprise too!

What to do about it: Check out the announcement blog post for an overview of the Service Catalog. If you’re an existing customer, you should now have access: check out the terraform-aws-service-catalog repo! If you’re not a customer and are interested in getting access, sign up today!

Introducing: CIS Service Catalog and CIS Reference Architecture 2.0

Motivation: As per the announcements above, the Gruntwork Service Catalog and version 2.0 of the Gruntwork Reference Architecture are both generally available. Now, it’s time to bring this new functionality to the Gruntwork CIS Compliance offering.

Solution: We’re happy to announce the general availability of the CIS Service Catalog and CIS Reference Architecture 2.0!

The CIS Service Catalog is a collection of battle-tested infrastructure as code modules that meet the CIS AWS Foundations Benchmark requirements out-of-the-box, and are designed to be deployed directly to production, without having to write any code yourself.
The CIS Reference Architecture 2.0 is a version of Gruntwork’s Reference Architecture—a production-grade, end-to-end tech stack for AWS, 100% managed as code, that we can deploy in your AWS accounts in about 1 day—that is compliant with the CIS AWS Foundations Benchmark out of the box.

This is the fastest way to launch infrastructure in AWS that is compliant with the CIS AWS Foundations Benchmark.

What to do about it: Check out the announcement blog post for all the details!

Introducing git-xargs: a command line tool for updating multiple Github repositories quickly and efficiently.

Motivation: At Gruntwork, we have a small team maintaining hundreds of GitHub repos, and we frequently needed a way to make updates across all of them: e.g., update the CI / CD config, README, or license in each repo.

Solution: We created a tool to solve this problem called git-xargs and we’ve open sourced it under the Apache 2.0 license! git-xargs is a command-line tool (CLI) for making updates across multiple Github repositories with a single command. You give git-xargs a script to run and a list of repos, and it checks out each repo, runs your scripts against it, commits any changes, and opens pull requests with the results. At the end of each run, you get a detailed report on exactly what happened with each repo.

What to do about it: Read our announcement blog post to learn more about the tool, its genesis, and see a quick demo, or go directly to the git-xargs repository itself to download the latest release and start using it to help manage your own repos!

It’s time to upgrade to Terraform 0.15!

Motivation: A few months ago, HashiCorp released version 0.15.0 of Terraform. It brought several new features, but also some backwards incompatible changes.

Solution: We’ve updated the Infrastructure as Code Library to work with Terraform 0.15, and it’s ready for you to take it for a spin! We’ve tested all our modules with Terraform 0.15, fixed all the incompatibility issues we ran into, released new versions of all the repos, and put together a migration guide for you to follow (which includes a version compatibility table).

Important note on Terraform 0.12 deprecation: To make upgrading easier, we’ve maintained compatibility with Terraform 0.12 in all of our repos up to this point. However, we are now starting to use Terraform 0.13 features in our modules (e.g., variable validation, for_each and depends_on in modules), so we recommend that all users upgrade to at least Terraform 0.13. That said, if you can, you should upgrade all the way up to 0.15 so you’re not falling far behind.

What to do about it: You can now update all of your repos to use Terraform 0.15 and the new versions of the Gruntwork repos. Follow our migration guide and let us know how it goes!

Encryption by default

Motivation: Security remains priority 0 for Gruntwork, and a big part of that is ensuring that all the defaults are secure.

Solution: We’ve enabled encryption by default throughout the Infrastructure as Code Library. This means that whenever possible, our modules default to enabling encryption for data in transit and at rest, including EBS volumes, RDS databases, Elasticache Redis clusters, Redshift databases, and AMIs built by Packer.

What to do about it: Below is a list of repos that have been updated and the new versions to update to. Note that if you had previously deployed infrastructure with encryption disabled, these updates will be backward incompatible and must be handled with caution. For example, enabling encryption on an RDS database or EBS volume that was previously unencrypted will cause the database or volumes to be destroyed and recreated, and will lead to data loss. Review the release notes in the links below to learn more:

Ubuntu 20.04 progress

Motivation: Last month we announced our plans to update to Ubuntu 20.04, which is the latest LTS release for Ubuntu since April 23rd, 2020.

Solution: We continue to work towards supporting Ubuntu 20.04 in our library. This month, the following modules have been confirmed to work with Ubuntu 20.04 (and the release where the confirmation was made):

terraform-aws-security (v0.47.0)

The following modules are on deck:

terraform-aws-ci
terraform-aws-service-catalog
terraform-aws-zookeeper
terraform-aws-kafka
terraform-aws-vault
terraform-aws-consul
terraform-aws-nomad
terraform-aws-elk
terraform-aws-couchbase

What to do about it: Keep an eye out for our releases and the monthly newsletter for continuous updates on the progress of Ubuntu 20.04 compatibility in our modules!

Open Source Updates

kubergrunt

v0.6.13: Starting this release, we will publish darwin/arm64 (support for M1 chipset) binaries and drop support for darwin/386.
v0.6.14: The eks oidc-thumbprint command now supports HTTP proxies.
v0.6.15: All commands that require AWS access will now properly support credentials configuration defined in ~/.aws/config.
v0.6.16: This introduces the eks drain subcommand which can be used to cordon and drain all the workers that are associated with the provided AWS Auto Scaling Groups. Refer to the command docs for more information.
v0.7.0: This adds support for Kubernetes version 1.20 in the sync-core-components command. In turn, support for Kubernetes 1.14 and 1.15 has been dropped.
v0.7.1: This adds support for skipping the specific components in the sync-core-components command. Review the updated command docs (kubergrunt eks sync-core-components --help) for more info.

terraform-google-network

v0.7.0: This release fixes a GKE cluster creation issue due to a change in Google’s APIs that prevents the pod secondary range name having the same name as the services secondary range name.
v0.7.1: This release adds two new variables: var.public_services_secondary_cidr_block and var.private_services_secondary_cidr_block that allow the public and private services secondary IP CIDR ranges to be specified manually.
v0.8.0: This release fixes an issue (see #118) when creating GKE clusters using the gke-cluster module by using var.services_secondary_range_name instead of defaulting to var.cluster_secondary_range_name. It also adds additional options for the vpc-network module to each example in order to support backwards compatibility.

terraform-aws-consul

v0.9.1: We are now testing this repo with Ubuntu 20.04. Other than updates to docs, examples, and tests, the only change to a module required to make the code work was an install check in the setup-systemd-resolved module. There should be no change to behavior / functionality.
v0.9.2: Fix a bug where the consul-security-group-rules module couldn't handle an empty allowed_inbound_cidr_blocks list.
v0.9.3: Update install-consul to detect the CPU architecture type (e.g., amd64, arm64, etc) and automatically install the appropriate Consul binary for that architecture.
v0.10.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.10.1: You can now configure lifeycle hooks on the ASG created by the consul-cluster module using the new lifecycle_hooks input variable.

terraform-aws-vault

v0.16.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-nomad

v0.9.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-kubernetes-namespace

v0.3.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-couchbase

v0.6.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

Terratest

v0.33.0: Update Terratest to work with Terraform 0.15. There are no code or behavior changes, but marking this release as incompatible because from this release onwards, we are only testing with Terraform 0.15 and up.
v0.34.0: All Ingress related functions (see k8s/ingress.go) are now using networking.k8s.io/v1 API instead of extensions/v1beta1. Additionally, versions of the function that support networking.k8s.io/v1beta1 have also been introduced (e.g., k8s.GetIngressV1Beta1). With this change, support for Kubernetes 1.13 and lower have been dropped from terratest (networking.k8s.io/v1beta1 was introduced in Kubernetes version 1.14).
v0.34.1: terraform.InitAndValidate, terraform.InitAndPlan, and terraform.InitAndApply no longer makes a separate call to terraform.Get, which is not necessary in modern (0.11+) versions of terraform as the get operation is automatically handled in init.
v0.34.2: All Azure examples have been updated to work with Terraform 15.1; Add sovereign cloud support for azure/availabilityset module; Add sovereign cloud support for azure/monitor module.
v0.34.3: Fix bug in azure monitor module that led to compilation errors.
v0.34.4: [azure] Add sovereign cloud support for remaining modules: ActionGroup, Disks, MySQL, ResourceGroup, and SQLServer.
v0.34.5: Fixes import pathing in azure module to match the Azure SDK version defined in go.mod.
v0.34.6: Add support for sovereign cloud to the following azure service functions: Vnet/Subnet, Compute, PublicIP, LoadBalancer, NIC and NSG.
v0.34.7: Fix bug in terratest-log-parser that mixes result lines to different test log files.
v0.34.8: Add k8s.GetKubernetesClusterVersion to get cluster version.
v0.34.9: Replace *testing.T with testing.TestingT in WithDefaultRetryableErrors; Bump AWS SDK to add support for AWS SSO.
v0.35.0: The TgApplyAll, TgDestroyAll, and TgPlanAllExitCode methods will now all use terragrunt run-all xxx instead of terragrunt xxx-all commands (e.g., terragrunt run-all apply instead of terragrunt apply-all), as the latter are deprecated. Also, switch all the above methods to use -auto-approve instead of the deprecated -force.
v0.35.1: Replace *testing.T with testing.TestingT in the var file methods in the terraform package.

Terragrunt

v0.29.0: Update Terragrunt to work with Terraform 0.15. There are no code or behavior changes, but marking this release as incompatible because from this release onwards, we are only testing with Terraform 0.15 and up.
v0.29.1: Fixes bug where AWS profile based authentication was not fully honored when automatic s3 bucket creation was happening.
v0.29.2: Fixes bug where the default credentials chain for the get_aws_** functions ignored the config file (~/.aws/config).
v0.29.3: This release introduces --terragrunt-source-map, which can be used to provide multiple mappings to translate terragrunt source URLs in the config with another path. See the documentation for more information.
v0.29.4: You can now use the new --terragrunt-iam-assume-role-duration CLI Arg and iam_assume_role_duration config setting to configure the duration for the IAM role from --terragrunt-iam-role.
v0.29.6: Update the usage text for Terragrunt to reflect that options should go after the command. There should be no impact on Terragrunt’s behavior in this release.
v0.29.7: Fix a bug where Terragrunt would not properly assume the IAM role specified via the iam_role parameter if you were using AWS SSO.
v0.29.8: You can now control the --terragrunt-debug flag using the TERRAGRUNT_DEBUG environment variable.

terraform-aws-utilities

v0.5.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

go-commons

v0.9.0: This release renames the VERSION variable in the version package to Version to align with conventional Go style. The Version() func has also been renamed to GetVersion().
v0.9.1: Add new functions to interact with the AWS API using the AWS SDK for Go V2.

cloud-nuke

v0.1.30: cloud-nuke now supports nuking SQS queues.

helm-kubernetes-services

v0.2.1: Add support for overriding the deployment strategy using the new deploymentStrategy input variable.

Other updates

terraform-aws-service-catalog

v0.34.2: You can now control annotations and labels for the autoscaler service in eks-core-services using the new input variables cluster_autoscaler_pod_annotations and cluster_autoscaler_pod_labels, respectively.
v0.35.0: You can now selectively disable the services that are deployed with eks-core-services using the new enable variables: var.enable_fluent_bit, var.enable_alb_ingress_controller, var.enable_external_dns, and var.enable_cluster_autoscaler. NOTE: This feature depends on Terraform 0.13.0 and above. If you are using Terraform 0.12, you must first upgrade to Terraform 0.13 to take advantage of this.
v0.35.1: The ssl_policy on the ALB is now configurable.
v0.35.2: Fixed bugs in asg-service; Added module level flags to allow enabling and disabling of individual components of account-baseline; Add variable validation to ensure the alb_name input is less than 32 characters; Fix bug in ec2-baseline where it incorrectly detected that dpkg was not available; Add sensible defaults for ssh_grunt_iam_group and ssh_grunt_iam_group_sudo to the bastion-host and jenkins modules; You can now configure a PodDisruptionBudget for your Kubernetes service deployed with the k8s-service module using the min_number_of_pods_available input variable.
v0.35.3: In the Landing Zone, we added support for using the created Organization ID as the default for var.cloudtrail_organization_id. Now the account-baseline-root module can set up Cloudtrail both at the root-account level and organization-wide level!
v0.35.4: Added some kubernetes_role_binding resources to the services/k8s-namespace module so that you can now configuring RBAC entities with these levels of access to the Kubernetes namespace.
v0.35.5: In eks-cluster, we added the ability to configure worker_name_prefix for the EKS worker resources. This is purely a backward compatible feature so that when upgrading from the older version of the Reference Architecture (in which name_prefix was hard-coded) to the Service Catalog version of the Reference Architecture, you can avoid recreating resources due to the name change. In almost all other cases, you won’t need to set this variable.
v0.36.0: Update dependency gruntwork-io/terraform-aws-ci to v0.35.0. As a result of this, the ecs-deploy-runner now supports authenticating to git repositories over HTTPS.
v0.36.1: Exposes alternate SSH interfaces in all packer templates. Bumps various dependencies to latest version.
v0.36.2: k8s-service module now supports configuring Ingress grouping. Refer to the documentation for more information.
v0.36.3: A new lambdaservice has been released. Refer to the documentation for more information.
v0.36.5: You can now enable storage autoscaling in the rds module using the new max_allocated_storage input variable. Update dependency versions for terraform-kubernetes-namespace, terragrunt and terraform-aws-monitoring.
v0.37.0: Updates dependency gruntwork-io/terraform-aws-ecs to v0.29.0, which includes support for Terraform 0.15.x! Also updates the for-production examples and adds the security_group_id output to the RDS module.
v0.38.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x! Also, updated several underlying dependency versions.
v0.38.1: Update the aurora module to mark the password parameter as sensitive and the non-password parameters as nonsensitive. This is required for the module to work with Terraform 0.15, and was missed in the previous release.
v0.39.0: The account-baseline-app, account-baseline-security, and account-baseline-root modules have been updated to match the versions in terraform-aws-security.
v0.40.0: Remove dependency between Cloudtrail and Config their respective buckets, and rename the cloudtrail_s3_bucket_already_exists variable.
v0.40.1: You can now configure whether image tags are mutable or not in the ecr-repos module using the new image_tag_mutability field in the repositories input variable. Fix a bug in the rds module where it would create a new KMS key, but wasn't actually using it, and was using the default RDS key instead.
v0.40.2: Fix a bug in the vpc module where, if you disabled a subnet tier, it would still try to create NACLs for that subnet tier. You can now also independently control whether the NACLs for each subnet tier will be created using the new create_public_subnet_nacls, create_private_app_subnet_nacls, and create_private_persistence_subnet_nacls input variables. Finally, you can also control if the default security group is created using the new enable_default_security_group input variable.

terraform-aws-cis-service-catalog

v0.16.1: Updates the versions of several underlying modules.
v0.17.0: Use account’s name as key for for_each instead of account_id in SecurityHub
v0.17.1: Adds new Landing Zone services account-baseline-app and account-baseline-security. Also adds new variables to the cloudtrail service: kms_key_arn_is_alias and allow_kms_describe_key_to_external_aws_accounts.
v0.17.2: Updates the versions of several underlying modules.
v0.18.0: Updates some variables from Landing Zone modules, adding SecurityHub vars and example fixes. Also, renames benchmark_sns_topic_arn output from Cloudtrail module.
v0.18.1: Adds default values for the cleanup-expired-certs module from account-baseline-security and disables the Config bucket.
v0.18.2: Updates the versions of several underlying modules.
v0.19.0: Updates account-baseline-app and account-baseline-security READMEs. Also renames some variables to follow the convention.
v0.19.1: Updates the versions of several underlying modules.
v0.20.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.20.1: Adds new Landing Zone service account-baseline-root . Also removes the unused iam_group_name_cross_account_access_all variable.

terraform-aws-security

v0.46.7: You can now attach IAM policies (AWS managed, customer managed, and inline policies) directly to user in the iam-users module. Previously you were only able to attach IAM groups to the created users. Refer to the updated variable description for more details. iam-users module is now robust to changes in the Access Key.
v0.47.0: Starting this release, all the modules have been updated to test with Ubuntu 20.04. As a result of this, support for Ubuntu 16.04 has been dropped.
v0.48.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.48.3: Add required_providers block with aws provider to the private-s3-bucket module. This makes it possible to use the module across multiple regions without getting warnings with Terraform 0.15.
v0.48.4: Fix a bug in the private-s3-bucket module where the lookup for the expired_object_delete_marker parameter had an extra space in it. Fix a bug in the aws-config module where it would try to create an IAM role policy to manage the SNS topic, even if you disabled the SNS topic.
v0.48.5: You can now explicitly set the current AWS account ID in the aws-config module via the new current_account_id input variable. This helps work around rare issues with the aws_caller_identity data source returns the wrong value. The aws-config-multi-region module already had a current_account_id input variable, but now it will also pass through to the aws-config module under the hood.
v0.49.0: The Landing Zone modules (account-baseline-app, account-baseline-root, and account-baseline-security) have been removed from the terraform-aws-security repo. You can find them in terraform-aws-service-catalog.

terraform-aws-ci

v0.33.3: Bump to latest version of terraform-aws-asg to fully support terraform 0.14.
v0.34.0: infrastructure-deploy-script and ECS Deploy Runner now has support for private repo authentication over HTTPS for terraform. Refer to the updated documentation for more information. Note that you must update ecs-deploy-runner and ecs-deploy-runner-standard-configuration to this version to take advantage of the new feature.
v0.35.0: Add HTTPS auth support in build-packer-artifact and terraform-update-variable for accessing private git repos over HTTPS. Bump the version of kubergrunt and tools from terraform-aws-ci used in ecs-deploy-runner Docker containers.
v0.36.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x! Note that as part of the Terraform 0.15 upgrade, we’ve updated the Dockerfile for the ecs-deploy-runner to install Terraform 0.15.1 and Terragrunt v0.29.0 by default.

terraform-aws-ecs

v0.28.2: You can now enable Amazon ECS Exec for your Tasks by setting the new enable_execute_command input variable to true.
v0.28.3: The run-ecs-task command now supports overriding the task definition command. This is useful to run one off commands using the same task definition as your ECS service. Refer to the command docs for more info.
v0.29.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.29.1: Fix a bug in the ecs-service module where it was failing to create the Assume Role Policy in some cases where it needed to.

terraform-aws-eks

v0.36.1: Remove unused local variables in eks-iam-role-assume-role-policy-for-service-account; Fix bug where affinity was not properly configured for external-dns.
v0.37.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.37.1: You can now customize the helm release name and the service account annotations in the eks-k8s-external-dns module using the input variables release_name and service_account_annotations.
v0.37.2: You can now specify the AWS partition (using the aws_partition input variable) for the hard coded IAM ARNs used in the modules. This allows you to deploy these resources in alternative partitions, such as GovCloud.
v0.38.0: Expose ability to filter tags by prefix in map-ec2-tags-to-node-labels. You can read more about this feature in the README. The eks-cluster-workers module now relies on launch templates instead of launch configuration to manage the Auto Scaling Group. This means that you can now take advantage of advanced features like multi instances policy for mixed workload ASGs. (This is a backward incompatible change. Please read the migration guide for more info!)
v0.39.0: Update var.kubergrunt_download_url to latest kubergrunt version (v0.6.16); Bump to latest maintained cluster autoscaler version. Note that this release requires a redeployment of the cluster autoscaler.
v0.39.1: Expose the managed cluster security group ID in the output eks_cluster_managed_security_group_id.
v0.39.2: Expose ability to override pod labels for external-dns.
v0.40.0: The default Kubernetes version deployed by the control plane module has been updated to 1.20; The default cluster-autoscaler version has been updated to 1.20.
v0.40.1: Add support for skipping individual components during cluster upgrades. Note that you will need kubergrunt version v0.7.1 and above to take advantage of the skip feature.

terraform-aws-load-balancer

v0.25.0: The alb_name variable will now leverage Terraform-native variable validation to ensure you cannot supply a string that is longer than 32 characters. This character limit is imposed by the AWS API, but catching the issue on the client-side prevents runtime issues and helps you get to a working configuration faster.
v0.26.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-static-assets

v0.8.1: You can now specify lifecycle rules for the S3 bucket using the new lifecycle_rules input variable. You can now automatically generate a random suffix for the S3 bucket name by setting the add_random_id_name_suffix input variable to true.
v0.9.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.9.1: You can now configure the SSL protocol and origin protocol policy for CloudFront when it access the S3 bucket using the bucket_origin_config_protocol_policy and bucket_origin_config_ssl_protocols variables.
v0.10.0: Updated the s3-static-website module to create the S3 bucket for access logs using the private-s3-module under the hood. This adds several extra layers of protection for the access logs bucket, including blocking all public access, enabling encryption at rest, and requiring encryption in transit.

terraform-aws-server

v0.12.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.12.1: The single-server module now outputs the AMI ID via a new ami output variable.

terraform-aws-asg

v0.14.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.14.1: You can now configure the deletion timeout for the ASG in the asg-rolling-deploy module using the new deletion_timeout input variable.

terraform-aws-lambda

v0.11.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-vpc

v0.15.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.15.1: Add support for exposing client access directly in the nacls for the private app tier for NLB access. You can learn more about this feature in the updated README.
v0.15.2: Add enable_default_security_group to enable destroy the default security group.
v0.15.3: Added new modules for doing VPC peering across two AWS accounts that you own: use vpc-peering-cross-accounts-requester to send a peering request and vpc-peering-cross-accounts-accepter to accept it. See vpc-peering-cross-accounts for example usage.
v0.15.4: Exposes the format_log variable in the vpc-flog-logs module.

terraform-aws-messaging

v0.6.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-openvpn

v0.15.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!
v0.15.1: You can now specify the host used for conducting the ping test to identify the optimal MTU for the system using the --host-for-mssfix input parameter to openvpn-admin. As a part of this, the default domain used for the ping test has been switched to 1.1.1.1.
v0.15.2: The search algorithm for finding the optimal mssfix value when --mssfix is omitted to openvpn-admin has been optimized.

terraform-aws-zookeeper

v0.10.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x! Also, enable encryption for all EBS volumes by default.

terraform-aws-kafka

v0.9.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-data-storage

v0.20.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-cache

v0.15.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-elk

v0.9.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-monitoring

v0.27.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

terraform-aws-sam

v0.5.0: Terraform 0.15 upgrade: We have verified that this repo is compatible with Terraform 0.15.x!

gruntkms

v0.10.0: We now publish binaries for Mac / ARM.

DevOps News

EKS updates: Kubernetes 1.20 and Secrets Store CSI driver

What happened: Amazon has announced two upgrades for EKS: it now supports Kubernetes 1.20 as well as the Kubernetes Secrets Store CSI driver.

Why it matters: The Kubernetes 1.20 release brings a number of new features, including RuntimeClass and Process ID Limits reaching stable status, API Priority and Fairness being enabled by default, and kubectl debug reaching beta status. The Kubernetes Secrets Store CSI driver allows you to securely store and manage your secrets in AWS Secrets Manager, and retrieve them through your applications that are running on Kubernetes, without the need to write custom code.

What to do about it: Check out the Kubernetes 1.20 and Secrets Store CSI driver announcement blog posts for all the details. Note that we added support for Kubernetes 1.20 in version v0.40.0 of our terraform-aws-eks repo.

Default tagging of AWS resources in Terraform

What happened: The Terraform aws provider has added support for a default_tags block that you can use to apply tags to all your AWS resources.

Why it matters: In the past, if you wanted to enforce tagging conventions across all your AWS resources, you had to manually ensure every single resource and module applied the tags you wanted, which was complicated and error prone. With default_tags, you can now ensure all your resources are properly tagged in a single, centralized place:

provider "aws" {
  region = "us-east-1"  # Tags to apply to all AWS resources
  default_tags {
    TeamId    = "12345"
    ManagedBy = "Terraform"    
  }
}

This will result in the TeamId and ManagedBy tag being applied to every single AWS resource you deploy (except aws_autoscaling_group, which is not yet supported).

What to do about it: The default_tags block is available as of version 3.38.0 of the aws provider. Give it a shot!

New AWS services: App Runner and CloudFront Functions

What happened: AWS has launched two new services, AWS App Runner and CloudFront Functions.

Why it matters:

AWS App Runner is a fully managed (serverless) container service: you give it a Docker container to run, and it will automatically builds and deploys the web application, load balances traffic, scales on demand (including scaling to 0), and monitors application health. This seems to be a more streamlined way to combine CodeBuild, Fargate, ALB, Route 53, and CloudWatch.
CloudFront Functions allow you to run JavaScript functions across 225+ CloudFront edge locations across 47 countries. This gives you a way to do lightweight HTTP(S) transformations and manipulations with extremely low latency to your users. We’re not sure yet how these compare to Lambda@Edge.

What to do about it: Check out the AWS App Runner and CloudFront Functions announcement blog posts, take these new services for a spin, and let us know what you think!

Security Updates

Below is a list of critical security updates that may impact your services. We notify Gruntwork customers of these vulnerabilities as soon as we know of them via the Gruntwork Security Alerts mailing list. It is up to you to scan this list and decide which of these apply and what to do about them, but most of these are severe vulnerabilities, and we recommend patching them ASAP.

HashiCorp code signing GPG key compromised in supply chain attack

On April 24th, 2021, HashiCorp disclosed a security incident where their GPG key that was used to sign the binaries of all their tools (including Terraform and all plugins like providers, Packer, Vault, and Consul) was compromised in the CodeCov supply chain attack. The GPG key is only used to sign and verify the binaries using the SHA256SUM file that is published on their distribution site (releases.hashicorp.com and respective registries, like registry.terraform.io). This key is not used for MacOS code signing (notarization feature), Windows AuthentiCode, and Linux package code signing (e.g., deb and rpm package formats). The initial compromise of the CodeCov container happened on January 31st and only binaries published after that date are affected.

Currently there is no evidence that the GPG key was maliciously used, and there is no evidence that the respective distribution sites were compromised. The likelihood that the binaries you downloaded is compromised is extremely low, especially if you are using MacOS or Windows (and relying on the native code signing features of the OS), or if you are downloading the terraform binaries using the official Linux packages. Even the Terraform provider binaries (which are natively validated on download using the GPG key embedded in terraform) and terraform binaries downloaded using a version manager like tfenv are unlikely to have been compromised, as the primary way this would be exploited is in a Man-in-the-Middle attack where you are downloading the binaries from an untrusted source.

However, as a result of this, HashiCorp has rotated their GPG key for signing the binaries. As a result, all terraform and provider binaries going forward require validating against the new key. To avoid errors from validating provider binaries, we recommend updating your terraform binary to the latest patch release to ensure that you have the latest GPG key to validate the provider binary on download. Otherwise, you may run into errors during terraform init, where terraform is not able to validate the provider binaries that it is downloading.

The following patch releases have the latest GPG key:

We alerted our security mailing list of this vulnerability on April 29th, 2021.