Use open source modules for lambdas

[nitrocode]

This will eliminate a lot of code from the repository

Here are all the unique resources in this module.

✗ rg ^resource -ttf | cut -d'"' -f2 | sort | uniq
aws_cloudwatch_event_rule
aws_cloudwatch_event_target
aws_cloudwatch_log_group
aws_dynamodb_table
aws_iam_role
aws_iam_role_policy
aws_kms_alias
aws_kms_key
aws_lambda_alias
aws_lambda_function
aws_lambda_permission
aws_sfn_state_machine
aws_sns_topic
aws_sns_topic_subscription
null_resource
random_string

One module from antonbabenko (terraform-aws-modules) which would clean up a lot of terraform and shell scripts for building is https://github.com/terraform-aws-modules/terraform-aws-lambda

If we wanted to, we can use a lot more modules from either antonbabenko (terraform-aws-modules) or cloudposse

• https://github.com/cloudposse/terraform-aws-cloudwatch-events
• https://github.com/cloudposse/terraform-aws-cloudwatch-logs
• https://github.com/cloudposse/terraform-aws-dynamodb
• https://github.com/cloudposse/terraform-aws-iam-role
• https://github.com/cloudposse/terraform-aws-kms-key
• https://github.com/cloudposse/terraform-aws-lambda-function
• https://github.com/cloudposse/terraform-aws-sns-topic
• https://github.com/cloudposse/terraform-aws-step-functions

[paulschwarzenberger]

While I accept that this approach would make the code simpler, it would also become less transparent, less self-contained, and more time consuming for prospective or current users of the repository to assess and audit the code, and make sure it doesn't contain anything insecure or even malicious.

We also have no guarantee of continued support of these modules, which don't appear at first glance to be especially popular, and as an OWASP project, we should stay reasonably independent of commercial companies.

I therefore don't believe we should go down the cloudposse route.

However, if there's an existing official Hashicorp / AWS module which is very popular, well supported and widely used, that might be worth considering, for example if we were using a VPC I wouldn't be adverse to using the AWS VPC module

[nitrocode]

@paulschwarzenberger just so you are aware, the "AWS" VPC module is not actually an official aws module. It's run by antonbabenko through the open source organization terraform-aws-modules. I've used his modules in the past too and if that is more reasonable for an OWASP project, happy to use those. The less code we have, the easier it is to maintain.

Honestly though, you can make the same argument for all the other dependencies such as github action dependencies and python dependencies within this repo. Why should we use a python pip packages? We should build our own within this repo so it's easier for users to navigate the code. But that would be ridiculous, no? 😄

[paulschwarzenberger]

Thanks, I agree with most of what you say - my main concern is making sure that the modules being used are well supported, widely used, and popular (as evidenced by GitHub stars, downloads, etc), and have already been in use for a reasonably extended period of time. This ensures ongoing support, and increases the likelihood that if there was a problem with the module, someone is likely to notice and take action.

I'd suggest adoption of additional modules should be done on a case by case basis in a gradual way, in those cases where use of the module provides the greatest benefit.

[nitrocode]

Yes agreed. Thanks for understanding.

Perhaps we can find modules with some objective parameters like you mentioned?

For example, we can also see download stats, number of forks, number of contributors, openssf scorecard, etc here

https://library.tf/modules?query=lambda

The big reduction in code will be to use a module for lambdas.

https://library.tf/modules/terraform-aws-modules/lambda/aws/latest
https://github.com/terraform-aws-modules/terraform-aws-lambda
https://scorecard.dev/viewer/?uri=github.com/terraform-aws-modules/terraform-aws-lambda

Could we reopen for this use case?

[paulschwarzenberger]

Sure, particularly as some of these seem to include packaging of dependencies. However we'd need to check how well they provide a solution to #21 for both local testing and GitHub Actions with an approval step

[nitrocode]

For reference, this is how the upstream terraform-aws-modules lambda module packages using the requirements.txt

https://github.com/terraform-aws-modules/terraform-aws-lambda/blob/5da19e5827002cd7155d83178e7e5c906e2d0c19/package.py#L690-L695

I don't think the github action approval step would be impacted by using an upstream module vs raw terraform code.

[fzipi]

I second using this module for lambda. It will cleanup a lot of the code that is used for maintenance also, so we can focus on domain protect instead.

IMHO, Anton Babenko's modules are the reference for using TF + AWS.