v0.6.1

🐛 Bug Fixes

Bugfix: Revert Breaking Change in v0.6.0 @milldr (#79)

## what - Revert changes from #74 - Pass only `module.this.tags` to cloudwatch module, not `module.this.context` - Add tests and necessary output to catch this going forward

why

• If we pass everything then the resources created in the cloudwatch module will have new names!

references

• Resolves #78

🤖 Automatic Updates

Update .github/settings.yml @osterman (#77)

## what - Update `.github/settings.yml` - Drop `.github/auto-release.yml` files

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub

Update .github/settings.yml @osterman (#76)

## what - Update `.github/settings.yml` - Drop `.github/auto-release.yml` files

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub

v0.6.0

Change cloudwatch submodule to pass context @nnsense (#74)

## 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 inside the Cloudwatch submodule, leaving up to the submodule to set its own contex.

module "cloudwatch_log_group" {
  source  = "cloudposse/cloudwatch-logs/aws"
  version = "0.6.6"

  enabled = module.this.enabled

  iam_role_enabled  = false
  kms_key_arn       = var.cloudwatch_logs_kms_key_arn
  retention_in_days = var.cloudwatch_logs_retention_in_days
  name              = "/aws/lambda/${var.function_name}"
  tags              = module.this.tags
}

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

v0.5.6

Add support for declaring simple lambda permissions in-module @jpalomaki (#69)

## 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

🤖 Automatic Updates

Update .github/settings.yml @osterman (#70)

## what - Update `.github/settings.yml` - Drop `.github/auto-release.yml` files

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub

v0.5.5

Add lambda role name option @gadzooks (#66)

what

• Adds an option to set role name for lambda function

why

• Enable module consumers to set custom lamdba role names as per any additional requirements or naming standards

references

🤖 Automatic Updates

chore(deps): bump the go_modules group in /test/src with 6 updates @dependabot (#67)

Bumps the go_modules group in /test/src with 6 updates:

Package	From	To
github.com/hashicorp/go-getter	1.6.1	1.7.5
golang.org/x/crypto	0.0.0-20210513164829-c07d793c2f9a	0.0.0-20210921155107-089bfa567519
golang.org/x/net	0.0.0-20220127200216-cd36cc0744dd	0.1.0
golang.org/x/text	0.3.7	0.4.0
google.golang.org/grpc	1.38.0	1.50.1
google.golang.org/protobuf	1.26.0	1.28.1

Updates github.com/hashicorp/go-getter from 1.6.1 to 1.7.5

Release notes

Sourced from github.com/hashicorp/go-getter's releases.

v1.7.5

What's Changed

• Prevent Git Config Alteration on Git Update by @​dduzgun-security in hashicorp/go-getter#497

New Contributors

• @​dduzgun-security made their first contribution in hashicorp/go-getter#497

Full Changelog: hashicorp/go-getter@v1.7.4...v1.7.5

v1.7.4

What's Changed

• Escape user-provided strings in git commands hashicorp/go-getter#483
• Fixed a bug in .netrc handling if the file does not exist hashicorp/go-getter#433

Full Changelog: hashicorp/go-getter@v1.7.3...v1.7.4

v1.7.3

What's Changed

• SEC-090: Automated trusted workflow pinning (2023-04-21) by @​hashicorp-tsccr in hashicorp/go-getter#432
• SEC-090: Automated trusted workflow pinning (2023-09-11) by @​hashicorp-tsccr in hashicorp/go-getter#454
• SEC-090: Automated trusted workflow pinning (2023-09-18) by @​hashicorp-tsccr in hashicorp/go-getter#458
• don't change GIT_SSH_COMMAND when there is no sshKeyFile by @​jbardin in hashicorp/go-getter#459

New Contributors

• @​hashicorp-tsccr made their first contribution in hashicorp/go-getter#432

Full Changelog: hashicorp/go-getter@v1.7.2...v1.7.3

v1.7.2

What's Changed

• Don't override GIT_SSH_COMMAND when not needed by @​nl-brett-stime hashicorp/go-getter#300

Full Changelog: hashicorp/go-getter@v1.7.1...v1.7.2

v1.7.1

No release notes provided.

v1.7.0

What's Changed

• docs: provide logging recommendations by @​mickael-hc in hashicorp/go-getter#371
• Update aws sdk version by @​Jukie in hashicorp/go-getter#384
• Update S3 URL in README by @​twelvelabs in hashicorp/go-getter#378
• Migrate to GHA by @​claire-labry in hashicorp/go-getter#379
• [COMPLIANCE] Update MPL 2.0 LICENSE by @​hashicorp-copywrite in hashicorp/go-getter#386
• remove codesign entirely from go-getter by @​claire-labry in hashicorp/go-getter#408
• Add decompression bomb mitigation options for v1 by @​picatz in hashicorp/go-getter#412
• v1: decompressors: add LimitedDecompressors helper by @​shoenig in hashicorp/go-getter#413

New Contributors

• @​mickael-hc made their first contribution in hashicorp/go-getter#371

... (truncated)

Commits

• 5a63fd9 Merge pull request #497 from hashicorp/fix-git-update
• 5b7ec5f fetch tags on update and fix tests
• 9906874 recreate git config during update to prevent config alteration
• 268c11c escape user provide string to git (#483)
• 975961f Merge pull request #433 from adrian-bl/netrc-fix
• 0298a22 Merge pull request #459 from hashicorp/jbardin/setup-git-env
• c70d9c9 don't change GIT_SSH_COMMAND if there's no keyfile
• 3d5770f Merge pull request #458 from hashicorp/tsccr-auto-pinning/trusted/2023-09-18
• 0688979 Result of tsccr-helper -log-level=info -pin-all-workflows .
• e66f244 Merge pull request #454 from hashicorp/tsccr-auto-pinning/trusted/2023-09-11
• Additional commits viewable in compare view

Updates golang.org/x/crypto from 0.0.0-20210513164829-c07d793c2f9a to 0.0.0-20210921155107-089bfa567519

Commits

• See full diff in compare view

Updates golang.org/x/net from 0.0.0-20220127200216-cd36cc0744dd to 0.1.0

Commits

• See full diff in compare view

Updates golang.org/x/text from 0.3.7 to 0.4.0

Commits

v0.5.4

Add support for inline IAM policy @jpalomaki (#68)

what

Adds support for attaching an inline IAM policy to the function IAM role.

why

Useful for defining a (simple) IAM policy that is declared, and deployed, in-tandem with the Lambda function itself.

Our use case: we use terragrunt to deploy a simple function using this module (straight out of terraform registry), so we'd like to avoid having to create a wrapper module or a separate customer-managed policy, for adding some necessary (but simple) permissions.

references

No related GitHub issue (but I can create one if needed).

🐛 Bug Fixes

Use runtime node20 @kevcube (#58)

Node14 no longer supported, tests fail because of this

🤖 Automatic Updates

Update release workflow to allow pull-requests: write @osterman (#65)

what

• Update workflow (.github/workflows/release.yaml) to have permission to comment on PR

why

• So we can support commenting on PRs with a link to the release

Update GitHub Workflows to use shared workflows from '.github' repo @osterman (#63)

what

• Update workflows (.github/workflows) to use shared workflows from .github repo

why

• Reduce nested levels of reusable workflows

Update GitHub Workflows to Fix ReviewDog TFLint Action @osterman (#61)

what

• Update workflows (.github/workflows) to add issue: write permission needed by ReviewDog tflint action

why

• The ReviewDog action will comment with line-level suggestions based on linting failures

Update GitHub workflows @osterman (#60)

what

• Update workflows (.github/workflows/settings.yaml)

why

• Support new readme generation workflow.
• Generate banners

Use GitHub Action Workflows from `cloudposse/.github` Repo @osterman (#56)

what

• Install latest GitHub Action Workflows

why

• Use shared workflows from cldouposse/.github repository
• Simplify management of workflows from centralized hub of configuration

Add GitHub Settings @osterman (#51)

what

• Install a repository config (.github/settings.yaml)

why

• Programmatically manage GitHub repo settings

Update Scaffolding @osterman (#49)

what

• Reran make readme to rebuild README.md from README.yaml
• Migrate to square badges
• Add scaffolding for repo settings and Mergify

why

• Upstream template changed in the .github repo
• Work better with repository rulesets
• Modernize look & feel

v0.5.3

fix: Allow for custom_iam_policy_arns that are unknown at apply @natemccurdy (#46)

what

Replace the toset() in the aws_iam_role_policy_attachment resource's for_each attribute with a map of name:ARN pairs.

why

Prior to this patch, specifying custom_iam_policy_arns for IAM Policies that do not exist yet and would be created in the same Terraform run that creates the Lambda Execution Role would cause the following error:

│ Error: Invalid for_each argument
│
│   on .terraform/modules/foo.test_lambda/iam-role.tf line 81, in resource "aws_iam_role_policy_attachment" "custom":
│   81:   for_each = local.enabled && length(var.custom_iam_policy_arns) > 0 ? var.custom_iam_policy_arns : toset([])
│     ├────────────────
│     │ local.enabled is true
│     │ var.custom_iam_policy_arns is set of string with 3 elements
│
│ The "for_each" set includes values derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.
│
│ When working with unknown values in for_each, it's better to use a map value where the keys are defined statically in your configuration and where only the values contain apply-time results.
│
│ Alternatively, you could use the -target planning option to first apply only the resources that the for_each value depends on, and then apply a second time to fully converge.

This is due to the ARN's of those policies not being known at apply time and the usage of toset() in the aws_iam_role_policy_attachment resource's for_each parameter. As the set's values are unknown at apply time, Terraform can't create a dependency graph.

references

Similar issues with similar fixes in other CloudPosse modules:

• cloudposse/terraform-aws-s3-bucket#202
• cloudposse/terraform-aws-ecs-alb-service-task#194

🚀 Enhancements

fix: Add null/label context tags to the aws_lambda_function resource @natemccurdy (#44)

What

Use tags = module.this.tags on the aws_lambda_function resource.

Why

Prior to this, the aws_lambda_function resource was not getting tagged at all
when passing just the null/label context into the module.

For example, this would end up with a completely untagged Lambda function even
though I am passing the context from a standard null/label declaration:

module "test" {
  source  = "cloudposse/lambda-function/aws"
  version = "0.5.1"

  function_name = "${module.this.id}-test"
  attributes    = ["foo"]
  description   = var.lambda_description
  s3_bucket     = var.lambda_s3_bucket
  s3_key        = var.lambda_s3_key
  runtime       = var.lambda_runtime
  handler       = var.lambda_handler
  context       = module.this.context
}

To get any tags on the lambda, the tags attribute must be used:

module "test" {
  source  = "cloudposse/lambda-function/aws"
  version = "0.5.1"

  function_name = "${module.this.id}-test"
  attributes    = ["foo"]
  description   = var.lambda_description
  s3_bucket     = var.lambda_s3_bucket
  s3_key        = var.lambda_s3_key
  runtime       = var.lambda_runtime
  handler       = var.lambda_handler
  context       = module.this.context
  tags          = module.this.tags
}

This has a couple of problems:

1. The attributes list is missing from the resultant set of tags.
2. The requirement of passing an explicit tags attribute is not how other CloudPosse modules work.

Outcome

• The aws_lambda_function resource is tagged with the implicit tags passed in via context.
• Tags from the tags variable are still present, but are now merged with the tags from context.
• This module follows the convetion of other CloudPosse modules.
• People used to CloudPosse modules will have an easier time using this module.

v0.5.2

🚀 Enhancements

fix: Add context tags to the IAM resources @natemccurdy (#45)

what

Add tags = module.this.tags to each of the IAM resources so that they use the tags determined by the null/label context or the tags input.

why

Prior to this, the aws_iam_role and the aws_iam_policy created by this module did not include any of the tags passed via tags or via context.

v0.5.1

🚀 Enhancements

fix: addresses issues with lambda cloudwatch log group @Gowiem (#39)

what

• Updates CloudWatch log group name for required pattern

why

• AWS requires the log group pattern to be specific for Lambda to be able to log to it. From https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs:

You can insert logging statements into your code to help you validate that your code is working as expected. Lambda automatically integrates with CloudWatch Logs and pushes all logs from your code to a CloudWatch Logs group associated with a Lambda function, which is named /aws/lambda/.

references

• This is an update of #34 as that was blocked from editing. Closes #34

v0.5.0

Add ephemeral storage size option @drselump14 (#31)

What

• Adds an option to set ephemeral storage size via a new variable: ephemeral_storage_size
• Removes variables that were not used in the code:
  • event_source_mappings
  • ignore_external_function_updates
  • sns_subscriptions
  • cloudwatch_event_rules
  • cloudwatch_log_subscription_filters

Why

• Enables module consumers to set larger ephemeral disk space for their Lambdas
• Cleans up unused code.

Sync github @max-lobur (#37)

Rebuild github dir from the template

Fix link to examples in readme @sindrig (#25)

what

• Links to examples link to a non-existing page

v0.4.1

🚀 Enhancements

Update module versions, examples and tests @aknysh (#24)

what

• Update module versions, examples and tests
• Update README and LICENSE
• Fix TF code formatting

why

• Keep up to date