Re-do of #189

what

• set initProcessEnabled = true in container definition if user has opted to enable ecs_exec (it is optional, but recommended by AWS)

why

• it will remove zombie processes in containers after exec is run • because AWS recommended it

what

Allow lambda configuration author to optionally declare lambda:InvokeFunction lambda permissions directly in this module.

More complex permissions configurations could still be done outside of this module.

why

This co-locates permissions related to the lambda in the module configuration (where we also declare lambda IAM role permissions), which can help a reader understand where the lambda is invoked from, e.g. in cases where the actual event sources are declared in a different root configuration.

In our specific use case, we use terragrunt to deploy the lambda function (straight from terraform registry module), so this feature would also help us avoid having to create a wrapper module just to add the necessary permission resources.

questions

1. Because we support terraform 0.14+ (no default value support for optionals), we scope this to just the specific action lambda:InvokeFunction and keep the number of attributes a user has to fill in, small. Does this look like a sane approach (looks like it could cover a lot of ground already, judging by examples)?
2. Because we support terraform 0.14+, we can’t do replace_triggered_by. Not entirely sure if that is a problem though, since we just attach the permission to the function itself (and not an alias or version)
3. The resource for_each is keyed by list index, which isn’t ideal, since it would force recreations if items are shuffled/inserted

references

Slack discussion, cc/ @osterman

what

• add Origin Access Control feature
• add var.origin_access_type to enable Origin Access Identity or Origina Access Control policy
• add aws_cloudfront_origin_access_control.default resource
• add origin_access_control_id argument to origin config on aws_cloudfront_distribution.default • update example code • update README

why

• provide the ability to make use of an Origin Access Control
• retain default origin access identity behavior • AWS recommends using origin access control • Origin Access Identities are flagged in AWS Security Hub

references

• Closes #244 • https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

what

A patch to pass the context instead of just vars to the CloudWatch submodule.

why

This module is only setting the context vars instead of the whole context, leaving up to the submodule to set its own context.
By settings the context (as advised by cloudposse) the root deployment are passed to the submodule, and an upper/camel/pascal case function_name will be consistent with the Cloudwatch group name.

references

• Closes #73

Describe the Bug

#74 actually breaks aws_cloudwatch_log_group names

module.lambda_cloudtrail_lookup[0].module.cloudwatch_log_group.aws_cloudwatch_log_group.default[0] must be replaced

-/+ resource “aws_cloudwatch_log_group” “default” { ~ arn = “arn:aws:logs:us-east-1:012345678910:log-group:/aws/lambda/compromised-keys-cloudtrail-lookup” -> (known after apply) ~ id = “/aws/lambda/compromised-keys-cloudtrail-lookup” -> (known after apply) ~ log_group_class = “STANDARD” -> (known after apply) ~ name = “/aws/lambda/compromised-keys-cloudtrail-lookup” -> “namespace-environment-stage-/aws/lambda/compromised-keys-cloudtrail-lookup” # forces replacement + name_prefix = (known after apply) ~ tags = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-cloudtrail-lookup” } ~ tags_all = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-cloudtrail-lookup” # (15 unchanged elements hidden) } # (2 unchanged attributes hidden) }

# module.lambda_delete_key[0].module.cloudwatch_log_group.aws_cloudwatch_log_group.default[0] must be replaced -/+ resource “aws_cloudwatch_log_group” “default” { ~ arn = “arn:aws:logs:us-east-1:012345678910:log-group:/aws/lambda/compromised-keys-delete-key” -> (known after apply) ~ id = “/aws/lambda/compromised-keys-delete-key” -> (known after apply) ~ log_group_class = “STANDARD” -> (known after apply) ~ name = “/aws/lambda/compromised-keys-delete-key” -> “namespace-environment-stage-/aws/lambda/compromised-keys-delete-key” # forces replacement + name_prefix = (known after apply) ~ tags = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-delete-key” } ~ tags_all = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-delete-key” # (15 unchanged elements hidden) } # (2 unchanged attributes hidden) }

# module.lambda_notify_security[0].module.cloudwatch_log_group.aws_cloudwatch_log_group.default[0] must be replaced -/+ resource “aws_cloudwatch_log_group” “default” { ~ arn = “arn:aws:logs:us-east-1:012345678910:log-group:/aws/lambda/compromised-keys-notify-security” -> (known after apply) ~ id = “/aws/lambda/compromised-keys-notify-security” -> (known after apply) ~ log_group_class = “STANDARD” -> (known after apply) ~ name = “/aws/lambda/compromised-keys-notify-security” -> “namespace-environment-stage-/aws/lambda/compromised-keys-notify-security” # forces replacement + name_prefix = (known after apply) ~ tags = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-notify-security” } ~ tags_all = { ~ “Name” = “namespace-environment-stage-compromised-keys” -> “namespace-environment-stage-/aws/lambda/compromised-keys-notify-security” # (15 unchanged elements hidden) } # (2 unchanged attributes hidden) }

Plan: 3 to add, 0 to change, 3 to destroy.

Expected Behavior

name should be not changed
https://github.com/cloudposse/terraform-aws-lambda-function/pull/74/files#diff-dc46acf24afd63ef8c556b77c126ccc6e578bc87e3aa09a931f33d9bf2532fbbR15

Possible solution: Provide all context variables except name

Steps to Reproduce

1. Create https://github.com/cloudposse/terraform-aws-lambda-function/blob/main/examples/complete/main.tf on v0.5.5
2. Update to v0.6.0

Screenshots

No response

Environment

No response

Additional Context

No response

what

• The existing module only allows a user to associate the route table of a private subnet with a network interface or a nat gateway. • By adding the tgw_id argument, users of the subnet module can automatically create a route table with routing between a private subnet and a transit gateway.

why

• As a best practice, a user may create an AWS account for centralized networking. • To allow traffic to route from account B to account A (centralized networking account), a Transit Gateway is needed. • If a user creates a subnet using this module, the tgw_id feature will allow the user to directly associate the route table in the private subnet to an existing transit gateway. • Example architecture:
ec2 -> private subnet rtb -> tgw -> private subnet rtb-> natgw -> public internet
|——–AWS Account B——|——-AWS Account A———-|

References

Multi account practices

what

Implementation of the aws_lambda_event_source_mapping resource, allowing to set a Kinesis stream, DynamoDB stream, or SQS queue as a trigger for lambda. I’ve porpousely kept things simple allowing only a few variables:

• source_mapping_arn pointing to the arn of the triggering resource (eg, the lambda execution role) • source_mapping_batch_size allowing to tune the number of events we pass to the function. • source_mapping_starting_position, because it’s usually required and terraform complains if it’s unset • source_mapping_starting_position_timestamp, if someone wants to use AT_TIMESTAMP in Kinesis.

why

It’s useful to get lambda triggered by other resources without having to set just one resource in another module.