Gruntwork release 2018-04
Guides / Update Guides / Releases / 2018-04
This page is lists all the updates to the Gruntwork Infrastructure as Code
Library that were released in 2018-04. For instructions
on how to use these updates in your code, check out the updating
documentation.
Here are the repos that were updated:
Published: 4/17/2018 | Release notes
Published: 4/3/2018 | Release notes
BACKWARDS INCOMPATIBLE RELEASE
- redis_with_snapshotting_without_auth_token
- redis_with_snapshotting_with_auth_token
- redis_without_snapshotting_without_auth_token
- redis_without_snapshotting_with_auth_token
To update your existing Redis cluster ensure you use terragrunt state mv <old_address> <new_address>
to ensure that your cluster isn't deleted when you run terraform apply
For example:
To update a Redis cluster that was deployed using the redis_without_snapshotting
resource to one of the new resources, you'll simply run:
terragrunt state mv module.redis.aws_elasticache_replication_group.redis_without_snapshotting module.redis.aws_elasticache_replication_group.redis_without_snapshotting_without_auth_token
Published: 4/29/2018 | Release notes
Published: 4/28/2018 | Release notes
https://github.com/gruntwork-io/module-data-storage/pull/40, https://github.com/gruntwork-io/module-data-storage/pull/41: The aurora
module now exposes two new input variables:
monitoring_role_arn
: specify an IAM role to associate with the Aurora DB.
monitoring_interval
: enable enhanced monitoring. Note that enhanced monitoring requires IAM permissions. If you don't specify monitoring_role_arn
yourself, the aurora
module will add the appropriate permissions automatically. If you do specify a custom monitoring_role_arn
, make sure it has the IAM permissions required for enhanced monitoring.
This release also fixes a bug in v0.6.1 where the monitoring_role_arn
param was not properly used in the rds
module.
Published: 4/25/2018 | Release notes
https://github.com/gruntwork-io/module-data-storage/pull/39: The rds
module now exposes two new input variables:
monitoring_role_arn
: specify an IAM role to associate with the RDS DB.
monitoring_interval
: enable enhanced monitoring. Note that enhanced monitoring requires IAM permissions. If you don't specify monitoring_role_arn
yourself, the rds
module will add the appropriate permissions automatically. If you do specify a custom monitoring_role_arn
, make sure it has the IAM permissions required for enhanced monitoring.
Published: 4/30/2018 | Release notes
Published: 4/3/2018 | Release notes
Published: 4/19/2018 | Release notes
Fix an issue where the pip
upgrade was breaking the aws-cli
install process
Published: 4/27/2018 | Release notes
The main motivation for locking down EC2 metadata is as follows:
- EC2 metadata gives you the credentials you need to assume any IAM role associated with the EC2 instance, and thereby, get all the permissions available in that IAM role.
- Locking down the metadata to, for example, only the root user, makes sure that if a hacker breaks into your server with a privileged user, they cannot get the full power of the IAM role.
Published: 4/17/2018 | Release notes
Published: 4/27/2018 | Release notes
https://github.com/gruntwork-io/module-vpc/pull/41, https://github.com/gruntwork-io/module-vpc/pull/42:
-
The vpc-mgmt-network-acls
module now allows all inbound and outbound traffic within the private subnet and between the public and private subnet. Before, all inbound traffic was allowed, but outbound traffic was limited solely to TCP.
-
The vpc-app-network-acls
module now allows all inbound and outbound traffic from/to the mgmt VPC. Before, all inbound traffic was allowed, but outbound traffic was limited solely TCP.