Introduced new module sign-binary-helpers that can sign executable files for MacOS and Windows.
Added new option --no-wait to infrastructure-deployer CLI. When passed in, it will instruct the infrastructure-deployer not to wait for the ECS task to finish and immediately exit without error.
Fixed bug where the systemd file was unchanged for Jenkins, so all configurations were overwritten at boot time. Now we create a systemd override file so Jenkins uses the updated config setup at install time.
Initial release of Steampipe Runner for Gruntwork Pipelines. This repo contains modules to configure Gruntwork Pipelines to continuously run Steampipe mod checks against an AWS account. Refer to the READMEs of the various modules for more information.
Exposed advanced external-dns parameters to tweak syncing behavior. These parameters are useful for avoiding the Route 53 API limits. Refer to the new README section for more details.
The default version of Kubernetes installed by the module has been updated to 1.22. As a result of this, the default version of addons were updated to support installation into 1.22. Specifically:
cluster-autoscaler: The default app version and chart version has been updated to 1.22.6 and 9.17.0.
aws-load-balancer-controller: The default app version and chart version has been updated to 2.4.1 and 1.4.1.
external-dns: The chart version has been updated to 6.2.4
aws-for-fluent-bit: The chart version has been updated to 0.1.15
Added the ability to use the OIDC Authentication feature of the AWS Loadbalancer, described in Authenticate users using an Application Load Balancer.
Because it always needs an action afterwards, the configuration is part of the forward, redirect and fixed_response listener rules.
Exposed the ability to configure the condition operator for GitHub Actions IAM role. This allows you to construct an IAM role that can be assumed by any repo in a particular org.
The tests in this repository have been updated for more stability.
[BACKWARD INCOMPATIBLE] Updated to use managed IAM policies instead of inline policies for all IAM roles. Managed IAM policies are more friendly for compliance checkers and is generally recommended by AWS as best practice.
Note that this is a backward incompatible change: a naive update to this version will cause the IAM policies to shuffle, which will result in a temporary downtime of IAM permissions. If you wish to avoid this, you can set the new var.use_managed_iam_policies to false.
Changed to add Terraform AWS 4.x provider support:
s3-static-website[BACKWARD INCOMPATIBLE]
Version changes only:
s3-cloudfront
Changes to support Terraform AWS 4.x provider in the s3-static-website module.
This release updates the s3-static-website module and other modules in this repo (s3-cloudfront and examples) that use s3-static-website.
If not using routing_rules/routing_rule, point your module source to this release (v0.14.0), run terraform init -upgrade, and run terraform apply.
When you run terraform apply there should be no destroyed or recreated resources. You will see newly created resources and sometimes in-place modifications.
Rename your usage of routing_rules to routing_rule.
Convert your JSON to hcl using json2hcl, or manually.
Convert the resulting keys from CamelCase to snake_case.
Please note: The AWS provider only supports one (1) rule in the routing_rule.
Alas we had no choice but to drop support for the AWS Provider 3.x style of routing_rules for an S3 bucket's website configuration. The AWS Provider 4.x style is called routing_rule and has a different format. Previously you could pass in a JSON string which would get interpreted by the provider. Now, you must pass in a map to this s3-static-website module, which will appropriately funnel values from that map into the block format expected by the provider. See the variable definition for more.
If you are not using routing rules, you have no backward incompatibilities with this upgrade. In this case, it is a functionally backward compatible upgrade, verified with partially automated upgrade testing. Upgrade testing was done to ensure that running init/plan/apply on pre-existing resources created by s3-static-website will not run into issues when you upgrade to this version of the module.
Besides routing_rules, no other configuration changes are needed for users of s3-static-website module. We handled the remaining provider upgrade changes within the module itself, so that your module configuration can remain the same.
We have verified there is no need to run terraform import as suggested in the Hashicorp upgrade guide.
However, you do need to bump the provider when upgrading. Read on.
Modules calling s3-static-website and s3-cloudfront have to bump the provider to at least 3.75.0 (>= 3.75.0). You will need to rerun apply to add the new S3 bucket resources created by the AWS 4.x provider. Note that because s3-static-website and s3-cloudfront now require a minimum AWS provider version of 3.75.0, you will need to run terraform init with -upgrade to pull the new provider version. See HashiCorp's guide on upgrading providers for more details.