v1.497.0

Fix Update changelog workflow @goruha (#1116)

what

• Fix modules path from components/terraform to modules

why

• It seems that components/terraform was testing value. In actual repo components are in modules directory

references

• DEV-2556 Investigate release issues with terraform-aws-components

v1.496.0

Lamdba Component Update @Benbentwo (#1115)

what

• Removed unused variables (the module never used several)
• Added several trigger_{type}.tf files to support Triggering the lambda via
  • S3
  • SQS
  • CronJob (Cloudwatch Event)
• Updated module to latest
• Added lookup support for bucket where code is stored via remote state lookup - or hardcoded bucket name.

why

• Module version was behind - several variables were planned to be used but never implemented.
• Triggers are commonly needed for lambdas, so we should bake a few into the component - eventually maybe these go to their own module
• Tried to keep backwards compatibility with all types (files / zip, image and s3 bucket)
• Removed formatting of bucket name in favor of component lookup. Formatting made bucket lookup in another region or stage difficult. Escape hatch of bucket_name still exists

references

• aws_cloudwatch_event_rule
• aws_s3_bucket_notification

v1.495.0

feat: adds version upgrade variable input to component @wavemoran (#1113)

what

• Adds the auto_minor_version_upgrade argument for the aws_elasticache_replication_group resource
• Updates the redis module version to 1.4.1

why

• auto_minor_version_upgrade argument is missing from the component
• Module is a few minor versions behind upstream

references

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elasticache_replication_group#auto_minor_version_upgrade
• https://github.com/cloudposse/terraform-aws-elasticache-redis/tree/main
• Release notes between 1.2.2 and 1.4.1
  • https://github.com/cloudposse/terraform-aws-elasticache-redis/releases/tag/1.2.3
  • https://github.com/cloudposse/terraform-aws-elasticache-redis/releases/tag/1.3.0
  • https://github.com/cloudposse/terraform-aws-elasticache-redis/releases/tag/1.4.0
  • https://github.com/cloudposse/terraform-aws-elasticache-redis/releases/tag/1.4.1

Delete ECS Partial Task Definitions Guide @milldr (#1111)

what

• Deleted ECS Partial Task Definitions guide

why

• These docs have been moved to cloudposse/docs

references

• cloudposse/docs#687

v1.494.0

Add explicit parameter store path @wavemoran (#1110)

what

• Add the exact AWS SSM Parameter Store path for IAM permissions

why

• When using the find.path value, ESO will begin the traversal at the exact path defined.
• ssm:GetParametersByPath needs permission to the "root" path, eg arn:aws:ssm:us-west-2:123456789012:parameter/app

references

• https://external-secrets.io/latest/guides/getallsecrets/#searching-only-in-a-given-path

v1.493.0

fix: Auth0 SSM Base Path @milldr (#1109)

what

• Corrected auth0/app to use var.ssm_base_path

why

• #1108 changed this variable name

references

• #1108

v1.492.0

fix: Correct recommended `var.name` for `auth0/app` @milldr (#1108)

what

• Update recommended name of the auth0/app components to avoid conflicts with the auth0/tenant component

why

• Both were using auth0 as name before. This results in both components using the same module.this.id, which they both use to write AWS SSM parameters. These were clobbering each other and breaking the provider authentication

references

• client engagement

v1.491.0

Correct Auth0 Parameter Intention @milldr (#1107)

what

• Removed duplicated SSM parameters for Auth0 Tenant
• Added SSM parameter for Auth0 App's Client ID wherever it's deployed
• Create client credentials for auth0 apps

why

• Originally the requested parameters were misunderstood. We want to create a client ID for each new Auth0 app. We don't need to duplicate the tenant parameters

references

• customer engagment

v1.490.0

Add `site-to-site-vpn` Terraform/OpenTofu component @aknysh (#1106)

what

• Add site-to-site-vpn Terraform/OpenTofu component

why

• The component provisions a Site-To-Site VPN with a target AWS VPC on one side of the tunnel. The other (customer) side can be any VPN gateway endpoint, e.g. a hardware device, other cloud VPN, etc.

  AWS Site-to-Site VPN is a fully-managed service that creates a secure connection between your data center or branch
  office and your AWS resources using IP Security (IPSec) tunnels. When using Site-to-Site VPN, you can connect to both
  your Amazon Virtual Private Clouds (VPC) and AWS Transit Gateway, and two tunnels per connection are used for
  increased redundancy.

  The component provisions the following resources:

  • AWS Virtual Private Gateway (a representation of the AWS side of the tunnel)

  • AWS Customer Gateway (a representation of the other (remote) side of the tunnel). It requires:

    • The gateway's Border Gateway Protocol (BGP) Autonomous System Number (ASN)
    • /32 IP of the VPN endpoint

  • AWS Site-To-Site VPN connection. It creates two VPN tunnels for redundancy and requires:

    • The IP CIDR ranges on each side of the tunnel
    • Pre-shared Keys for each tunnel (can be auto-generated if not provided and saved into SSM Parameter Store)
    • (Optional) IP CIDR ranges to be used inside each VPN tunnel

  • Route table entries to direct the appropriate traffic from the local VPC to the other side of the tunnel

references

• https://aws.amazon.com/vpn/site-to-site-vpn
• https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
• https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_VpnTunnelOptionsSpecification.html

v1.489.0

feat: memorydb component @dudymas (#1105)

what

• add component for memorydb module

why

• new module: terraform-aws-memorydb

v1.488.0

feat: Improvements for Auth0 Components @milldr (#1104)

what

• Add support for Auth0 Email Provider
• Add option to copy Auth0 creds into connect accounts
• Created auth0/connection component

why

• Email provider is deployed once per tenant, so it can be included with the auth0/tenant component
• It may be useful to have the Auth0 credentials accessible from each target account. By enabling var.create_auth0_ssm_parameters_enabled, you can now duplicate those AWS SSM Parameters into each account with an Auth0 App
• auth0/connection can be used to create an Auth0 connection. At this time only the email strategy has been validated, but this component is intended to be expanded for any strategy type

references

• https://registry.terraform.io/providers/auth0/auth0/latest/docs/resources/email_provider#import