Sns

[dylanratcliffe]

@jameslaneovermind I'm planning to merge this one, associate the lambda with the topic manually, then remove the topic. Should be able to tell us that it's a problem

[github-actions]

Expected Changes

s3-bucket › bucket-notification-test-example

--- current
+++ planned
@@ -1,14 +1 @@
-bucket: bucket-notification-test-example
-eventbridge: false
-id: bucket-notification-test-example
-lambda_function: []
-queue:
-    - events:
-        - s3:ObjectCreated:*
-      filter_prefix: ""
-      filter_suffix: ""
-      id: tf-s3-queue-20240305172641071600000001
-      queue_arn: arn:aws:sqs:eu-west-2:540044833068:example-notifications-from-s3
-terraform_address: module.scenarios[0].aws_s3_bucket_notification.new_bucket_notification
-terraform_name: module.scenarios[0].aws_s3_bucket_notification.new_bucket_notification
-topic: []

Blast Radius

Items	Edges
2	1

Open in Overmind

Risks

Unverified Provider Version Update [Low]

The .terraform.lock.hcl update introduces a new hash for the hashicorp/archive provider, suggesting a version change. Assuming the current configuration works with a specific version of the provider, updating it might introduce unforeseen issues, especially in processing the archiving of Lambda function code. It's important to verify this change's compatibility with the existing Terraform setup and the AWS environment.

+ "h1:qGT7b3uJm78Rb2YY7fFrY42a3bsi0Xbr2ghshaGqTms=",

Potential Lambda Runtime Incompatibility [Low]

The deployment specifies the use of nodejs20.x as the runtime for the Lambda function. Given the lack of details around the existing system's specific configurations and the absence of direct relationships with the new components, it remains critical to validate the compatibility of this runtime version concerning not only the application code but also any SDK or library versions used to interact with AWS services like SNS, S3, and SQS. Issues here could lead to runtime errors or unexpected behavior.

runtime = "nodejs20.x"

Lack of SNS to Lambda Invocation Permission [High]

The change adds a Lambda function and an SNS topic but does not explicitly configure permissions for the SNS topic to invoke the Lambda function. Given that the current state involves an S3 bucket (bucket-notification-test-example) triggering events to an SQS queue (example-notifications-from-s3), and there's no direct integration mentioned between the S3/SQS and the new SNS topic, the intended flow of notifications from S3 to Lambda via SNS might not function as expected without the aws_lambda_permission resource being uncommented and properly configured. This configuration is essential for secure and intended interaction between AWS services.

# resource "aws_lambda_permission" "allow_sns" {
# statement_id = "AllowExecutionFromSNS"
# action = "lambda:InvokeFunction"
# function_name = aws_lambda_function.example.function_name
# principal = "sns.amazonaws.com"
# source_arn = aws_sns_topic.example_topic.arn
# }

IAM Role Policy Too Permissive [Medium]

The assume role policy for the example_lambda_iam_role is configured broadly, allowing any Lambda service to assume this role. While this configuration is common, it's important to ensure that only the intended Lambda functions can assume this role, especially when integrating with other AWS services like SNS and SQS, to maintain security and intended functionality. The policy does not restrict the usage to specific Lambda functions or services, potentially allowing unintended access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com",
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}