DEV Community: Jobs

Setting Up MongoDB Atlas Cluster and Creating VPC Peering in AWS

Jobs — Mon, 02 Oct 2023 15:42:35 +0000

MongoDB Atlas is a fully managed cloud service for MongoDB. It provides a simple and cost-effective way to deploy, manage, and scale MongoDB databases.

AWS Virtual Private Cloud (VPC) peering allows you to connect your Atlas cluster to your VPC. This provides a private and secure connection between your Atlas cluster and your other AWS resources.

In this blog post, we will show you how to set up a MongoDB Atlas cluster and create VPC peering in AWS.

Prerequisites

Before getting started, you will need to have the following prerequisites:

An AWS account
A MongoDB Atlas account

Setting up a MongoDB Atlas cluster

To set up a MongoDB Atlas cluster, follow these steps:

Step 1: Create a MongoDB Atlas Cluster

Log in to your MongoDB Atlas account.
Click on "Clusters" in the left sidebar.
Click the "Build a Cluster" button to create a new cluster.
Choose the M10 cluster tier, which is a recommended starting point for most use cases.
Configure your cluster settings, including:
- Cluster name
- Cloud provider (AWS)
- Region
- Cluster tier
- Additional settings (authentication, backup, etc.)
Click the "Create Cluster" button to initiate the cluster creation process.

Step 2: Configure Network Access
To secure your MongoDB Atlas cluster, you need to configure network access:

In the MongoDB Atlas dashboard, navigate to "Network Access" under the "Security" section.
Click the "Add IP Address" button to whitelist the VPC CIDR block for secure access.

Step 3: Create a Peering Connection in AWS
This VPC peering allows private network communication between your resources in AWS and MongoDB Atlas cluster.

Log in to your AWS Management Console.
Navigate to the Amazon VPC dashboard.
In the left sidebar, click on "Peering Connections" under the "Peering" section.
Click the "Create Peering Connection" button.
Configure the peering connection as follows:
- Peering connection options: Select "Requester" (Your AWS VPC) and "Accepter" (MongoDB Atlas).
- Requester VPC: Choose your AWS VPC.
- Accepter VPC: Choose "Another AWS account" and provide the Atlas VPC details provided in the MongoDB Atlas dashboard.
- Provide a unique name for the peering connection.
Click the "Create Peering Connection" button.
In the peering connection details, click the "Actions" button and select "Accept Request" to approve the peering request in the MongoDB Atlas account.

Step 4: Configure Route Tables
To allow traffic to flow between your AWS VPC and MongoDB Atlas VPC, you need to update the route tables:

In the AWS VPC dashboard, navigate to "Route Tables."
Edit the route table associated with your AWS VPC.
Add a new route with the destination CIDR block of the MongoDB Atlas VPC, pointing to the peering connection as the target.
Save the changes.

Step 5: Test Connectivity
To ensure that the VPC peering connection is working correctly, test the connectivity between resources in your AWS VPC and your MongoDB Atlas cluster. Created a simple Python script on AWS Lambda that uses a VPC and private subnets to test whether the resources within the VPC can reach the MongoDB Atlas production environment through VPC peering.

Conclusion

In this blog post, we have shown you how to set up a MongoDB Atlas cluster and create VPC peering in AWS. This allows you to connect your Atlas cluster to your VPC and provide a private and secure connection between your Atlas cluster and your other AWS resources.

Creating an EventBridge Scheduler to Trigger a Lambda Function using Terraform

Jobs — Mon, 02 Oct 2023 15:12:13 +0000

EventBridge is a fully managed, serverless event bus service that makes it easy to connect applications together using events. It supports a broad set of event sources and targets, including AWS services, SaaS applications, and custom applications.

EventBridge Scheduler is a feature of EventBridge that allows you to schedule events to be delivered to targets at specific times or intervals. This makes it easy to automate tasks that need to be run on a regular basis.

In this blog post, we will show you how to create an EventBridge scheduler to trigger a Lambda function using Terraform.

Prerequisites

Before getting started, you will need to have the following prerequisites:

A Terraform installation
An AWS account with the necessary permissions to create and manage AWS resources

Creating a Terraform configuration

The first step is to create a Terraform configuration file. This file will define the resources that you want to create, such as the EventBridge scheduler and the Lambda function.

Here is a simple example of a Terraform configuration for an EventBridge scheduler to trigger a Lambda function:

# Lambda Function
module "lambda_function" {
  source                 = "terraform-aws-modules/lambda/aws"
  function_name          = var.function_name
  description            = var.description
  handler                = var.handler
  runtime                = var.runtime
  local_existing_package = var.local_path
  vpc_subnet_ids         = var.subnet_ids
  vpc_security_group_ids = var.security_group_ids
  attach_network_policy  = var.attach_network_policy
}

# EventBridge Scheduler
module "eventbridge" {
  source               = "terraform-aws-modules/eventbridge/aws"
  bus_name             = var.bus_name
  attach_lambda_policy = true
  lambda_target_arns   = [module.lambda_function.lambda_function_arn]
  schedules = {
    lambda-cron = {
      description         = "Run Lambda function based on given scheduled"
      schedule_expression = var.schedule_expression
      timezone            = var.timezone
      arn                 = module.lambda_function.lambda_function_arn
    }
  }
}

This configuration will create a new EventBridge rule that is scheduled to run based on given scheduled. The rule will target the var.lambda_function Lambda function.

Deploying the EventBridge scheduler

Once you have created the Terraform configuration file, you can deploy the EventBridge scheduler by running the following command:

terraform apply

This will create the EventBridge rule and the Lambda function in AWS.

Testing the EventBridge scheduler

Once the EventBridge scheduler has been deployed, you can test it to make sure that it is working properly. You can do this by waiting until the next time that the scheduler is scheduled to run and then checking to see if the Lambda function has been invoked.

Conclusion

In this blog post, we have shown you how to create an EventBridge scheduler to trigger a Lambda function using Terraform. This is a powerful way to automate tasks that need to be run on a regular basis.

You can also use EventBridge Scheduler to trigger other types of targets, such as Amazon Simple Notification Service (SNS) topics, Amazon Simple Queue Service (SQS) queues, and other EventBridge rules.

Setting up a Web Application Firewall (WAF) using Terraform

Jobs — Mon, 02 Oct 2023 14:51:36 +0000

Web application firewalls (WAFs) are an essential security layer for any web application. They protect your applications from common attacks, such as SQL injection, cross-site scripting, and denial-of-service attacks.

Terraform is an infrastructure as code (IaC) tool that can be used to automate the deployment and management of WAFs. This makes it easy to deploy consistent and secure WAFs across all of your environments.

In this blog post, we will show you how to set up a WAF using Terraform. We will use the AWS WAF v2 service as an example, but the same principles can be applied to other WAFs.

Prerequisites

Before getting started, you will need to have the following prerequisites:

A Terraform installation
An AWS account with the necessary permissions to create and manage WAF resources

Creating a Terraform configuration

The first step is to create a Terraform configuration file. This file will define the resources that you want to create, such as the WAF and its associated rules.

Here is a simple example of a Terraform configuration for an AWS WAF v2:

#######################################
# --- Resources ----
#######################################
resource "aws_wafv2_web_acl" "waf" {
  count = var.create ? 1 : 0
  name  = "${var.prefix}-${var.name}"
  scope = var.scope

  // default action
  default_action {
    allow {}
  }

  // AWSManagedRulesCommonRuleSet
  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 10

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesCommonRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesKnownBadInputsRuleSet
  rule {
    name     = "AWSManagedRulesKnownBadInputsRuleSet"
    priority = 20

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesKnownBadInputsRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesKnownBadInputsRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesAmazonIpReputationList
  rule {
    name     = "AWSManagedRulesAmazonIpReputationList"
    priority = 30

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesAmazonIpReputationList"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesAmazonIpReputationListMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesAnonymousIpList
  rule {
    name     = "AWSManagedRulesAnonymousIpList"
    priority = 40

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesAnonymousIpList"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesAnonymousIpListMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesSQLiRuleSet
  rule {
    name     = "AWSManagedRulesSQLiRuleSet"
    priority = 50

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesSQLiRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesSQLiRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesLinuxRuleSet
  rule {
    name     = "AWSManagedRulesLinuxRuleSet"
    priority = 60

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesLinuxRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesLinuxRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  // AWSManagedRulesUnixRuleSet
  rule {
    name     = "AWSManagedRulesUnixRuleSet"
    priority = 70

    override_action {
      none {
      }
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesUnixRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesUnixRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  tags = {
    Name = "${var.prefix}-${var.name}"
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = var.metric_name
    sampled_requests_enabled   = true
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_wafv2_web_acl_logging_configuration" "api_server_waf_log" {
  count                   = var.create ? 1 : 0
  log_destination_configs = [aws_s3_bucket.logs.arn]
  resource_arn            = aws_wafv2_web_acl.waf[count.index].arn
}

resource "aws_s3_bucket" "logs" {
  bucket = "aws-waf-logs-${var.prefix}-${var.name}"

  force_destroy = true

  tags = {
    Name = "aws-waf-logs-${var.prefix}-${var.name}"
  }
}

resource "aws_s3_bucket_acl" "acl" {
  bucket     = aws_s3_bucket.logs.id
  acl        = "private"
  depends_on = [aws_s3_bucket_ownership_controls.acl_ownership]
}

resource "aws_s3_bucket_ownership_controls" "acl_ownership" {
  bucket = aws_s3_bucket.logs.id
  rule {
    object_ownership = "ObjectWriter"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "sse_configuration" {
  bucket = aws_s3_bucket.logs.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "public_access_block" {
  bucket                  = aws_s3_bucket.logs.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

#######################################
# --- Variables ----
#######################################
variable "create" {
  description = "Controls if waf should be created"
  type        = bool
}

variable "prefix" {
  description = "The prefix of the resource name"
  type        = string
}

variable "name" {
  description = "The name of the waf resource"
  type        = string
}

variable "scope" {
  description = "The scope of the waf"
  type        = string
}

variable "metric_name" {
  description = "The name of the metric"
  type        = string
}

#######################################
# --- Outputs ----
#######################################
output "waf_arn" {
  value       = length(aws_wafv2_web_acl.waf) > 0 ? aws_wafv2_web_acl.waf[0].arn : ""
  description = "The arn of waf"
}

Deploying the WAF

Once you have created the Terraform configuration file, you can deploy the WAF by running the following command:

terraform apply

This will create the WAF and its associated resources in AWS.

Testing the WAF

Once the WAF has been deployed, you should test it to make sure that it is working properly. You can do this by sending a test request to your web application and verifying that the WAF blocks the request.

You can also use the AWS WAF console to test the WAF. To do this, go to the Web ACLs page and click on the name of your web ACL. Then, click on the Test tab and enter a test request.

Conclusion

In this blog post, we have shown you how to set up a WAF using Terraform. Terraform is a powerful tool that can be used to automate the deployment and management of WAFs. This makes it easy to deploy consistent and secure WAFs across all of your environments.