gruntwork-newsletter

Gruntwork Newsletter, February 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…
Gruntwork Newsletter, February 2021
YB
Yevgeniy Brikman
Co-Founder
Published March 4, 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 months, we updated all Gruntwork Terraform repos so that you can use them directly from the Private Module Registry in Terraform Cloud / Enterprise, released the version 1.3.0 upgrade for the CIS AWS Foundations benchmark modules, made progress on the Terraform 0.14 upgrade, released the Helm provider 2.0 update, added new features to Terragrunt, created a new module for managing AWS quota increases, and much more. Read on for all the details.

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

Gruntwork Updates

Use the Gruntwork IaC Library with the Private Module Registry in Terraform Cloud / Enterprise!

Motivation: Many of our customers wanted to be able to add Gruntwork repos directly to the Private Module Registry (PMR) in Terraform Cloud (TFC) or Terraform Enterprise (TFE), but this wasn’t working due to PMR’s requirements that (1) all repos to meet a certain naming convention and (2) all repos to have Terraform code in the root.

Solution: We’ve updated our repos to meet these requirements, so you should now be able to add any Gruntwork repo directly to your Private Module Registry! To do so, open up the Private Module Registry in your web browser, and click “Add module”:

Next, pick your version control provider (or connect a new one):

Pick the Gruntwork repo you wish to add from the list:

Click “Publish Module”:

In a short while, the new module should now be accessible in PMR:

All Gruntwork code lives in submodules in the modules folder, so to see those, click the Submodules drop-down:

To allow Gruntwork repos to work with PMR, we had to do the following:

  1. Rename our repos. We renamed all of Gruntwork repos that have Terraform code to match HashiCorp’s repo naming requirements: namely, the repos must be called terraform-<cloud>-<name>. For example, we renamed module-vpc to terraform-aws-vpc and package-kafka to terraform-aws-kafka. GitHub should handle the rename transparently, automatically redirecting all Git operations, both on the web and CLI, automatically, so there should be no impact on your usage.
  2. Placeholder tf file. We’ve added a placeholder .tf file to the root of every repo. This file doesn’t do anything—all the real Terraform code is in the modules subfolder—but it allows the repos to work with PMR.

Note that PMR has a few limitations. First, it can’t render AsciiDoc files, which we use for documentation in some repos, so the docs might not show up. Second, PMR only supports sub-modules directly in modules folder and examples directly in the examples folder, whereas we have some repos (e.g., terraform-aws-service-catalog) that have the code in nested folders (e.g., modules/networking/vpc), so PMR doesn’t properly render sub-modules in those cases. Hopefully, this will be fixed in PMR in the future.

What to do about it: If you’re a Terraform Cloud or Terraform Enterprise user, give it a shot, and let us know what you think!

CIS AWS Foundations Benchmark version 1.3.0 upgrade

Motivation: In September, 2020, version 1.3.0 of the CIS AWS Foundations Benchmark was released, and our customers were interested in updating their infrastructure to be compliant with the new security controls and recommendations.

Solution: We’ve updated the Gruntwork Compliance offering to be compatible with version 1.3.0 of the benchmark! We updated all our modules, created some new modules, published a blog post on what changed between 1.3.0 and 1.2.0, and released an upgrade guide.

What to do about it: If you’re a Gruntwork Compliance customer on version 1.2.0 of the benchmark, follow our upgrade guide to update your infrastructure to be compliant with version 1.3.0 of the benchmark. If you’re starting with the benchmark from scratch, check out our How to achieve compliance with the CIS AWS Foundations Benchmark guide to get started.

Terraform 0.14 upgrade process

Motivation: In our last newsletter, we announced that all our code had been updated to Terraform 0.13; since then, we’ve been working on updating everything to work with Terraform 0.14.

Solution: We’ve updated Terragrunt and Terratest to work with Terraform 0.14 and we’re now in the process of updating and testing the rest of our repos with these new changes.

What to do about it: For now, sit tight! We’ll announce when the 0.14 upgrade process is done, and provide update instructions.

Terraform Helm provider 2.x upgrade

Motivation: In December, version 2.0 of the Helm provider for Terraform was released, and our customers wanted to be able to use Gruntwork EKS code with this new provider.

Solution: We updated the terraform-aws-eks repo to work with Helm provider 2.0! Note that support for helm provider 1.x is dropped, so you will need to update your provider blocks to ensure they pull in the 2.x series of the provider.

What to do about it: Check out the v0.32.0 release of terraform-aws-eks for upgrade instructions. For an example of updating the Reference Architecture to this new version, check out the Acme examples pull requests: https://github.com/gruntwork-io/infrastructure-live-multi-account-acme/pull/45 and https://github.com/gruntwork-io/infrastructure-modules-multi-account-acme/pull/51.

Terragrunt improvements: run-all and log levels

Motivation: For a long time, Terragrunt users have been requesting two features: (1) a way to execute arbitrary Terraform command across multiple modules and (2) a way to configure Terragrunt’s log levels.

Solution: We’ve added support for both of these features!

  1. Terragrunt now supports a run-all xxx command which will run xxx across all modules it finds in the current working directory or below. For example, running terragrunt run-all apply in folder /live/stage will run terraform apply in all sub-folders of /live/stage. This new run-all command is a more generic version of the (now deprecated) apply-all, destroy-all, and other hard-coded commands that existed before.
  2. You can now configure Terragrunt’s log level with the new --terragrunt-log-level <LEVEL> option. The default level is info, which should be considerably quieter than before. You can use debug or trace to increase the amount of log output or error or fatal to decrease it.

What to do about it: Take these new features for a spin in Terragrunt v0.28.6 or above and let us know what you think!

New module: request-quota-increase

Motivation: AWS has limits built-in on how many resources you can create, such as how many EC2 instances or VPCs you can create in a region. When you hit these limits, the typical way to deal with them is to request an increase by sending a message to AWS Customer Service, and then waiting, sometimes up to a week.

Solution: We’ve created a new request-quota-increase module that allows you to programmatically request quota increases for supported resources! Here’s an example usage to request an increase in the quotas for NAT Gateways and NACL rules:

module "quota-increase" {
source = "git::git@github.com:gruntwork-io/terraform-aws-utilities.git//modules/request-quota-increase?ref=<VERSION>"
resources_to_increase = {
nat_gateway = 20
nacl_rules  = 40
}
}

This is a great module to include when setting up new AWS accounts to ensure all the quotas are configured as necessary for your expected usage. Moreover, it’s a safe, idempotent module, for if your current quota is higher than what you request, no worries, it won’t change anything.

What to do about it: Check out the new module and the corresponding example and start managing your service quotas.

Service Catalog Updates

terraform-aws-service-catalog

  • v0.15.3: Updated the vpc service to expose several optional parameters available in the underlying vpc-app module that were not exposed before, including parameters for setting custom tags, enabling/disabling subnet tiers, and configuring the Default Security Group and Default Network ACL ingress/egress rules.
  • v0.15.4: Updated the landingzone/account-baseline-root & landingzone/account-baseline-security modules to include the new iam-access-analyzer module in order to be compliant with CIS 1.3.0.
  • v0.16.0: Updated a number of underlying dependency versions.
  • v0.17.0: You can now configure the update timeout for the elasticsearch module using the new update_timeout input variable. Bumped the terraform-aws-ci version number in the mgmt modules. This is mainly to pick up a fix for the jenkins module related to the default snapshot_id value. Removed a depends_on clause from the ecs-cluster module which was causing recent Terraform versions to exit with an error. Updated the eks-core-services module to the 2.x version of the Helm provider. Updated the required_version constraint on the k8s-namepsace to >= 0.12.26. This was missed during the Terraform 0.13 upgrade.
  • v0.17.1: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.17.2: All nested module dependencies have been updated to the latest upstream versions. We’ve also resolved warnings related to deprecated variable interpolation syntax. Refer to the release notes for specific version updates.
  • v0.18.0: Update dependency gruntwork-io/terraform-aws-ecs v0.24.1 => v0.25.0 (ECS module release notes).
  • v0.18.1: Updated various module dependencies (refer to the release notes for the full list). The ec2-baseline module will now remove the ec2-instance-connect package if ssh-grunt is enabled. For more information on why this is, see here.
  • v0.18.2: You can now configure tmpfs volumes in your kubernetes services using the scratch_paths input variable.
  • v0.18.3: Update default terragrunt version installed in jenkins to v0.28.3. Fix labels for scheduling EKS core services on fargate
  • v0.18.4: Adds the ability to grant KMS key permissions for the Jenkins IAM role.
  • v0.18.5: Allows specifying disallow list of availability zones for EKS. Also, exposes deletion_protection parameter for Aurora.
  • v0.18.6: Expose tagging capabilities for the EKS cluster control plane.
  • v0.18.7: Expose labels and annotations for kubernetes namespaces.
  • v0.18.8: Fix RDS port docs to not mislead about default port. bastion-host module can now be deployed with no domain.
  • v0.18.9: You can now set custom tags for the rds module.
  • v0.18.10: Fix malformed required_providers block in VPC module.
  • v0.18.11: Fixes a bug in the ecs-cluster module to allow SSH from CIDR blocks to work correctly.
  • v0.18.12: Bump AWS provider version for ACM. Fix destroy ordering of resources for eks-cluster.
  • v0.19.0: Fixes issue with AWS Config SNS topics. Update dependency gruntwork-io/terraform-aws-security to v0.45.0. Update dependency gruntwork-io/terraform-aws-ecs to v0.25.1. Expose custom_tags for public-static-website. Bump k8s-service module to helm 2.x provider.
  • v0.20.0: The default kubernetes version has been updated to 1.19. Better Fargate support for ECS modules.
  • v0.20.1: Allow creating bastion-host with no domain name. Allow specifying custom tags with RDS and Aurora. Allow specifying custom database parameters for RDS and Aurora. Add ability to manage service linked role for elasticsearch in the module. Disable ‘data’ when not using config or cloudtrail in account-baseline-root . Add ability to configure encryption at rest and custom tags on elasticsearch.
  • v0.20.2: Update dependency gruntwork-io/terraform-aws-security to v0.45.1 (fix for ap-northeast-3 in multi region modules).

terraform-aws-cis-service-catalog

  • v0.9.1: Adds a new module cleanup-expired-certs to ensure that all expired SSL/TLS certificates stored in AWS IAM are removed as per the 1.19 requirement of the CIS AWS Foundations Benchmark. Also, adds metric filter and alarm for AWS Organizations changes, as per the 4.15 requirement of CIS AWS Foundations Benchmark.
  • v0.9.2: Configures data event logging for cloudtrail buckets, as per the 3.10 and 3.11 requirements of CIS AWS Foundations Benchmark.
  • v0.9.3: Adds two new modules vpc-app-network-acls and vpc-mgmt-network-acls, that forbids access from 0.0.0.0/0 on remote administrator ports, as per the 5.1 requirement of CIS AWS Foundations Benchmark.
  • v0.10.0: Refactor the NACL modules to allow specifying different CIDR blocks per subnet tier for allowing remote admin (e.g., SSH/RDP) access. This is important as the IP addresses you see in public subnets will be different than those in private subnets.

Open Source Updates

kubergrunt

  • v0.6.9: Fix bug where the cleanup routine did not work in accounts without the default VPC configured.
  • v0.6.10: eks sync-core-components now supports k8s 1.19.

terraform-aws-consul

  • v0.8.1: You can now enable encryption for the root volume using the new root_volume_encrypted input variable.
  • v0.8.2: You can now allow inbound API traffic on the HTTPS port by setting the new enable_https_port input variable to true. You can also customize the HTTPS port using the new input variable https_api_port.
  • v0.8.3: Updated the example code in the root of this repo to fix deprecation warnings with Terraform 0.13. There should be no difference in behavior.
  • v0.8.4: You can now configure a permissions boundary for the IAM role using the new iam_permissions_boundary input variable.
  • v0.8.5: Update the run-consul script to set two configs differently: first, we set disable_compat_1.9 = true in telemetry and second, to enable the UI, we set a ui_config block instead of the old ui attribute. Update all Consul examples and automated tests to use Consul 1.9.2.

terraform-aws-vault

  • v0.14.1: You can now configure a permissions boundary for the IAM role using the new iam_permissions_boundary input variable.
  • v0.14.2: When using a backend other than Consul, run-vault will now explicitly configure Vault to register itself as a service in Consul. Otherwise, if you're using some other backend, such as S3, service discovery won't work correctly. Updated the systemd config that run-vault sets up for Vault, including configuring reasonable defaults for StartLimitIntervalSec and StartLimitBurst, and setting LimitMEMLOCK to infinity to prevent memory from being swapped to disk.

terraform-aws-nomad

  • v0.7.1: You can now configure a permissions boundary for the IAM role using the new iam_permissions_boundary input variable.
  • v0.7.2: Fix a bug where nomad-cluster wouldn't handle an empty allowed_ssh_cidr_blocks input correctly. You can now configure the allowed outbound CIDR blocks via the new allow_outbound_cidr_blocks input variable.

Terragrunt

  • v0.27.0: This release updates Terragrunt to work with Terraform 0.14! Terragrunt now supports handling Terraform lock files. Check out the lock file handling documentation for details. Also, fixed a bug with Terragrunt always re-running init.
  • v0.27.1: This release fixes a bug where the generated code from remote_state blocks in generate mode was nondeterministic. The backend configuration is now deterministically generated in sorted key order.
  • v0.27.2: This release fixes a bug where --terragrunt-debug was not always interpreted correctly.
  • v0.27.3: Terragrunt will now copy the .terraform.lock.hcl file not only when you run the init command, but also on the providers lock command.
  • v0.27.4: Fix a bug in aws-provider-patch where it outputted invalid hcl in certain cases.
  • v0.28.0: Terragrunt now has improved logging! Each log message is now set with a different log level, and the default log level is set to warn, so by default, you'll get much less noise from Terragrunt's logging. You can configure the log level using the new --terragrunt-log-level argument.
  • v0.28.1: Terragrunt now has a generic run-all command that allows you to run arbitrary terraform commands against a terragrunt stack. For example, you can run terraform init against a stack using terragrunt run-all init.
  • v0.28.2: Fix a bug introduced via the new logging functionality in v0.28.0, where, depending on your log level, Terragrunt's interactive prompts may have been hidden. Interactive prompts should now be visible regardless of log level.
  • v0.28.3: This release introduces a further optimization to dependency output fetching where it will skip the init phase if it detects that the module has previously been locally initialized.
  • v0.28.4: Fix bug where run-all no longer allowed positional args.
  • v0.28.5: Terragrunt will no longer error and continue to run commands when you disable AutoInit but init is needed.
  • v0.28.6: In v0.28.0, when we switched Terragrunt to use a proper logger that supported different log levels, we set the default log level to WARN. The intention was to make Terragrunt's logging less noisy, but as an unintended side effect, we ended up suppressing some log messages that are important to see. This release changes the default log level to INFO and should fix most of the logging issues.

Terratest

  • v0.31.3: Add additional default retryable errors for terraform. Add support for Azure Cosmos DB. Refer to the cosmosdb.go file in the azure module for information on supported functions.
  • v0.31.4: KubectlOptions will now fall back to in-cluster authentication via service account token when it can't authenticate to the Kubernetes endpoint using the Config and Context.
  • v0.31.5: Add support for Azure KeyVault. Refer to the keyvault.go file in the azure module for information on supported functions.
  • v0.32.0: customerrors has been deprecated and removed starting this release. Please use go-multierror instead. aws.GetRandomStableRegion now includes eu-north-1.
  • v0.32.1: The files.CopyFolderToTemp and test_structure.CopyTerraformFolderToTemp methods now check if the folder they are copying exists, and report a clear error if it does not.
  • v0.32.2: Fix some transient test failures in this repo. This included adding a new error to terraform. DefaultRetryableTerraformErrors to deal with intermittent failures to download providers from the Terraform Registry.
  • v0.32.3: Added a new k8s.CreateNamespaceWithMetadata function that can be used to create a namespace and pass in the entire ObjectMeta to allow for more configuration (e.g., setting labels).
  • v0.32.4: Bump gruntwork-installer and gcp-helpers versions. Adding support to get details for TargetPrefix.
  • v0.32.5: Fix bug in azure.GetVirtualMachineTagsE where the return map is not properly initialized. Add support for Azure Storage. See storage.go for list of supported functions.
  • v0.32.6: Added functions to read Terraform variables from a vars file (e.g., .tfvars file): terraform.GetAllVariablesFromVarFile, terraform.GetVariableAsStringFromVarFile, etc. See the GoDoc for full details!
  • v0.32.7: Update Azure SQL examples: Ensure min password requirements are always met for Azure SQL resources. Add support for Azure Log Analytics. See loganalytics.go for the list of supported functions.
  • v0.32.8: Use hcl2 for GetAllVariablesFromVarFileE

terraform-aws-utilities

  • v0.3.2: Add a new module to request quota increase for an AWS resource.

helm-kubernetes-services

  • v0.1.6: Add the ability to configure securityContext at the pod level using podSecurityContext input value.
  • v0.1.7: Add the ability to configure tmpfs mounts using the scratchPaths input value.

fetch

  • v0.3.13: fetch should now properly handle pagination for tags, so you'll be able to fetch older tags from repos that have many tags.
  • v0.4.0: Added a proper logger to fetch. It defaults to INFO, but the desired verbosity can be specified with --log-level.
  • v0.4.1: Fixed the usage help text for --ref.

gruntwork-installer

  • v0.0.31: Update default fetch version. This pulls in fixes/improvements, including support for GitHub Enterprise, skipping Git tags that don't follow SemVer, and paginating on Git tags so that you can fetch older tags in repos with many tags.
  • v0.0.32: Improve the formatting and fix typos in the --help text.
  • v0.0.33: Update default fetch version to the latest, which has a fix for using the --branch argument.
  • v0.0.34: Update default fetch version to v0.4.1 which now includes a proper logger.

aws-sample-app

  • v0.0.3: Fixed the broken CircleCI builds and updated the app dependencies.

terraform-google-sql

  • v0.4.0: The cloud-sql module now supports deletion protection with the var.deletion_protection option. This release also bumps the Google provider version to 3.57.0.

Other updates

terraform-aws-security

  • v0.44.7: Fixed broken links on the website’s repo browser by using root-relative links for README & LICENSE file references.
  • v0.44.8: Added a new input to the private-s3-bucket module to configure CORS.
  • v0.44.9: Added checks to verify that ec2-instance-connect is not installed when installing ssh-grunt.
  • v0.44.10: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.45.0: Fixes opt_in_regions to work correctly when aggregating AWS config in multiple accounts. Updates account-baseline-app and account-baseline-security to send notifications to the SNS topic in the Logs account. This was the intended configuration but a bug caused the topics to always be created in each region of each account. This bug has been corrected.
  • v0.45.1: Fix bug where ap-northeast-3 was recently promoted to a full region, but is not yet supported by terraform.

terraform-aws-eks

  • v0.31.3: This release is a minor bugfix to use the latest kubergrunt (v0.6.9) required dependency.
  • v0.32.0: The core services modules are now compatible with helm provider 2.x. Note that support for helm provider 1.x is dropped. You will need to update your provider blocks to ensure they pull in the 2.x series of the provider in order to update to this release.
  • v0.32.1: The aws-auth-merger app now uses an informer for watching the config maps, making it more robust to connectivity issues and API refresh problems.
  • v0.32.2: You can now turn off the default Fargate IAM Role created by the eks-cluster-control-plane module using the create_default_fargate_iam_role input variable. You can now selectively control which Node Groups use the instance_types attribute on the Node Group or on the Launch Template by setting the instance_types attribute to null. You can now hard code the open ID connect provider thumbprint in the eks-cluster-control-plane module. This is useful if you are in an airgapped environment that requires HTTP requests to route through a proxy.
  • v0.32.3: Fix bug where the labels used to schedule the eks-k8s-cluster-autoscaler on fargate was incorrect. Allow deploying eks-k8s-cluster-autoscaler without any ASGs.
  • v0.32.4: Fix bug where workers module requires eks_control_plane_security_group_id when create_resources is false. Add support for stringing dependencies to the Control Plane service fargate profile.
  • v0.33.0: Bump default k8s version to 1.19. If you wish to use Kubernetes version 1.19 with EKS, you must update kubergrunt to version 0.6.10 or newer.

terraform-aws-ci

  • v0.29.6: Fixes a bug in the ecs-deploy-runner module where the IAM permissions to grant access to the repository_credentials_secrets_manager_arn Secrets Manager entry to the ECS task execution role was not being configured.
  • v0.29.7: Fix bug in jenkins-server where it errors out when snapshot_id is not provided.
  • v0.29.8: Fix an interpolation-only expression so we no longer get a deprecation warning from Terraform.
  • v0.29.9: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names. Also, update the default Dockerfile in ecs-deploy-runner to use Kubergrunt v0.6.9.
  • v0.29.10: Fixes a bug in the arg checker for ecs-deploy-runner. The EDR Dockerfile now installs kubectl so that it may be used with kubergrunt and EKS.
  • v0.29.11: Use correct version of terraform-aws-ci in Dockerfile for the deploy-runner.
  • v0.29.12: You can now configure IOPS for the Jenkins EBS volume by setting the new ebs_volume_iops input parameter.
  • v0.29.13: he default version of tools installed in the deploy runner has been updated: Kaniko - v1.5.1; Kubergrunt - v0.6.10; Kubectl - v1.19.1
  • v0.29.14: Fix tag handling for ref in kaniko (build-docker-image in ecs-deploy-runner).

terraform-aws-server

  • v0.10.0: All the modules now support Ubuntu 20.04. Note that starting this release, support for Ubuntu 16.04 is dropped. Fix a bug with CentOS 7.9 that prevented the public IP from being restored when attaching a new ENI to the instance.
  • v0.10.1: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.10.2: You can now force the single-server module to detach IAM policies from the IAM role on delete by setting the new input variable force_detach_policies to true.

terraform-aws-asg

  • v0.11.1: Custom tags you pass to the server-group module via the custom_tags input variable will now be applied to the IAM role too.
  • v0.11.2: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.

gruntkms

  • v0.0.9: Updated the version of the AWS Go SDK used in gruntkms to pull in the latest features, such as better support for AWS SSO in AWS CLI v2.

terraform-aws-elk

  • v0.7.1: Updated the elk-multi-cluster example to show how you can dynamically source the authentication hash from secrets manager when configuring readonlyrest in the Elasticsearch cluster.

terraform-aws-messaging

  • v0.4.2: You can now set custom tags for the dead letter queue using the new custom_dlq_tags input variable.
  • v0.4.3: You can now configure a custom KMS CMK to use with the sns module using the new kms_master_key_id input variable.

terraform-aws-data-storage

  • v0.17.2: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.

terraform-aws-cache

  • v0.10.2: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.11.0: Several months ago, AWS made a backward-incompatible change related to the Elasticache Replication Group Multi-AZ behavior, introducing a new MultiAZEnabled toggle. This means that, the last several months, if you deployed Redis with with enable_automatic_failover set to true, but did not have this MultiAZEnabled flag—which wasn't exposed in Terraform's AWS provider—Redis would be deployed into only a single AZ. This issue was fixed in AWS provider 3.26, and in this release, we now expose a new enable_multi_az variable in the redis module so that you can configure this property.
  • v0.12.0: AWS ElastiCache, and the Terraform AWS provider, have changed how reader endpoints work (context), which broke the read_endpoints output variable in the redis module. In this release, we've fixed this issue, and updated to use the new terminology and type from AWS / Terraform: the output variable is now called reader_endpoint and is a single value instead of a list.

terraform-aws-openvpn

  • v0.13.1: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.

terraform-aws-vpc

  • v0.12.5: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.13.0: In v0.12.3, we added support for managing the default network ACL. However, we also associated the default NACL with the subnets in the VPC. This caused a perpetual diff problem for users that manage the network ACLs separately, such as when using the vpc-app-network-acls module. In this release, we have updated the behavior to not explicitly apply the default network ACL by default.
  • v0.13.1: You can now get the ID of the default security group in the VPC using the default_security_group_id output variable.

terraform-aws-monitoring

  • v0.24.1: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.

terraform-aws-ecs

  • v0.24.1: We recently renamed most of our repos to follow the Terraform Registry convention of terraform-<cloud>-<name> (e.g., terraform-aws-vpc. In this release, we've updated all cross-references and links from the old names to the new names.
  • v0.25.0: This release removes the service_autoscaling_iam_role_arn output from the ecs-service module. This output should have been removed in the v0.24.0 release, but it was mistakenly left in place.
  • v0.25.1: Fix bug where the ecs-service module produces Error: Inconsistent conditional result types on the IAM role.

terraform-aws-load-balancer

  • v0.21.1: You can now configure the ACM cert statuses and types the alb module will search for using the new acm_cert_statuses and acm_cert_types input variables. This allows you to use the alb module with both AWS-issued and imported ACM certs.

terraform-aws-zookeeper

  • v0.8.1: You can now specify the CloudWatch metrics to enable for zookeeper-cluster using the new enabled_metrics input variable.

DevOps News

EKS now supports Kubernetes 1.19

What happened: Amazon has announced that EKS now supports Kubernetes version 1.19.

Why it matters: The Kubernetes 1.19 release include Ingress API and Pod Topology Spread reaching stable status, EndpointSlices being enabled by default, and immutable Secrets and ConfigMaps. Learn more about Kubernetes version 1.19 in the Kubernetes project release notes.

What to do about it: Update to v0.33.0 of terraform-aws-eks to use Kubernetes 1.19.

AWS Go SDK version 2 is now out

What happened: Amazon has released version 2 of the AWS Go SDK.

Why it matters: The highlights of this new release include a modular architecture (so you can pull in just the parts of the SDK you need), improved in CPU and memory utilization, simplified API clients, enhanced error handling, and improvements to pagination and waiters.

What to do about it: If you’re using the AWS Go SDK in your apps, update to this new version, and let us know what you think!

Security Uhpdates

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.

  • Apple has just released this last week the latest iOS version — 14.4. It fixes security zero-day vulnerabilities, that were reported to Apple by an anonymous security researcher. These vulnerabilities have impacted the OS kernel (CVE-2021–1782), allowing attackers to elevate their privileges within the OS; and the WebKit browser engine, enabling attackers to execute malicious code inside users’ Safari browsers (CVE-2021–1871 and CVE-2021–1870). It is believed that these vulnerabilities may be actively exploited, and can be combined together and potentially cause more harm. The devices that are most likely affected are iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation), as suggested by Apple. We strongly recommend that you update to iOS 14.4 on all your iOS devices, especially if you’re using one of the above mentioned devices.
  • A serious heap-based buffer overflow vulnerability was announced in sudo in CVE-2021–3156. It allows a local unprivileged user to elevate their privileges to root, and since the whole point of sudo is to carefully control privileged commands… well, it’s just not a good look. All OS vendors have published fixes in a coordinated release.