Don't recreate lambda's on every run

[jasonmcintosh]

Using a UUID right now to generate lambda URLs, which means every run of terraform recreates much of the infrastructure. Ideally instead, we'd use a version number or similar so the only time changes are made is when the files are truly updated.

[ventz]

Yea this really bothers me too. I remember some limitations into why it was needed -- I think around the attaching triggers/actions and the random IDs when these were created which was needed during "deploy time". Either way, if we can fix this, it would be great.

[jasonmcintosh]

SO looks like anonymous usage data to metrics.awssolutionsbuilder.com (AWS team of some sort) requires the UUID on each request. Here's sample code to generate a UUID. It's CLUDGY... maybe there's a cleaner way.

variable "version" {
  default = "1.0.2"
}

resource "random_shuffle" "id" {
  input = ["${uuid()}"]
  keepers {
    version = "${var.version}"
  }
  lifecycle {
    ignore_changes = "input"
  }
}

In the above, if you update version number to say 1.0.3 it'll regenerate the UUID, but otherwise won't.

[nelg]

If you would like to try my fork and branch of this project, it is setup to operate as a terraform module and does not re-create the lambda functions on every run. It's also newer, based on Security Automations Framework 2.2
https://github.com/nelg/aws-waf-security-automation/commits/as_a_module

[ventz]

@nelg Awesome awesome work!

There is so much to go through - I see the regional changes, updates to the new functionality for the WAF (everything not just GETs, to HTTP cookies/header adds, etc)

It will take us some time to go through/test. Completely willing to create a new branch (ex: v3?) until we test this out and before merging it o master. Unfortunately, other work and projects took over, and the time is spread very thin.

[nelg]

There is so much to go through - I see the regional changes, updates to the new functionality for the WAF (everything not just GETs, to HTTP cookies/header adds, etc)

Yeah, this is for regional waf (my use case), so if you need the ones for cloudfront, then I suspect a find and replace might be in order to get it to work.

There is one known bug, which is in the API gateway, the nested proxy for some reason does not attach. Attaching it in the AWS console to the badbotlambda function does solve it.

This module is then included in your project, something like:

# waf.tf

module "waf" {
    tags = { 
      mytag = "value"
    }
   customer = "projectname"
   CloudFrontAccessLogBucket = "bucketname"
   elb_association = "ALB ARN"
  aws_region = "ap-southeast-2"
  source = "https://github.com/nelg/aws-waf-security-automation.git?ref=as_a_module"
}

s3 bucket is used by lambda functions to read logs and write json data

[jasonmcintosh]

NICE piece of work here! I'd been looking at this as an upcoming project. We'd modified it internally to add deny by default unless in "WHITELIST" only access in our dev/staging areas - but had only done some of this on CloudFront. We'd started looking at solutions for Regional and was going to look at this - Thank you should save a huge chunk of time.

[jasonmcintosh]

FYI 2.3 was released :) .

[jasonmcintosh]

FYI got this:

* aws_api_gateway_deployment.ApiGatewayBadBotDeployment: 1 error(s) occurred:

* aws_api_gateway_deployment.ApiGatewayBadBotDeployment: Error creating API Gateway Deployment: BadRequestException: No integration defined for method

Digging...