Crowdsec Terraform

cs-tf.md

The objective of this module is to :

1. Allow users to provision crowdsec in AWS infra via terraform. Initially it'll target the serverless setup.
2. Abstract details and provide out of the box functional UX via simple terraform config.

The module interface would look like:

module "crowdsec"{

    # TERRAFORM SPECIFIC CONFIG
    source = ...
    name = ....

    # AWS SPECIFIC CONFIG 
    network_configuration = {
    security_groups = [<SECURITY_GROUP_IDS>] 
    subnets         = [<SUBNETS_IP>]
    }
    enable_service_discovery = true|false # This sets DNS records allowing users to access LAPI at crowdsec.local
    api_gateway_arn = "arn:foo" # This would be used to deploy the crowdseced lambda authorizer.

    # CROWDSEC SPECIFIC CONFIG 

    collections = [] # eg ["crowdsecurity/apache2"]
    scenarios = [] # eg ["crowdsecurity/http-probing"]
    parsers = [] # eg ["crowdsecurity/nginx"]
    bouncer_keys = [] # TBD

    machines = [  # This can be used for allowing other agents to connect to this. For this POC, this won't be required
        {
            login = "ec2-agent",
            password = "blah"
        }
    ]

    acquis = <<-EOF # The content at /etc/crowdsec/acquis.yaml would be replaced with this. 
        source: ...
        ....
    EOF

    config = <<-EOF # The content at /etc/crowdsec/config.yaml would be replaced with this. 
        ....
        db_config:
            .....
        ....
    EOF

    profiles = <<-EOF # The content at /etc/crowdsec/config.yaml would be replaced with this.
        ....
        ....
    EOF

}

The following is the internal working of the crowdsec terraform module.

1. Using the config from AWS SPECIFIC CONFIG section a FARGATE crowdsec instance would be created. Using the api-gateway-arn a lambda authorizer would also be provisioned which communicates with the FARGATE instance.

2. The config from CROWDSEC SPECIFIC CONFIG would be used in the following ways: a. The collections, scenarios, parsers, machines and bouncer_keys would be transformed and provided as env variables to the ECS task. The docker start script would then pick up these env variables and install the components accordingly.

   b. For acquis, config, profiles fields, an S3 bucket would be created and files (acquis.yaml, profiles.yaml, config,.yaml) would be uploaded. At the container startup, the start command would be overrided to download this files and update contents of /etc/crowdsec[acquis,profles,config].yaml.