After you've setup your environment, deploying BinaryAlert is as easy as:
$ ./manage.py deploy
deploy is equivalent to the following 3 operations executed in sequence:
$ ./manage.py unit_test # Unit tests ensure YARA rules compile correctly $ ./manage.py build # Build the Lambda ".zip" deployment package(s) $ ./manage.py apply # Update the infrastructure and deploy Lambda functions
Lambda Versions and Aliases
Each BinaryAlert Lambda function has a
Production alias which points to the most recent version of that function. Every time a deploy changes one of the Lambda deployment packages, a new version is published and the
Production alias is updated accordingly. For more information, see AWS Lambda Function Versioning and Aliases.
Add SNS Subscriptions
BinaryAlert sends YARA match alerts to an SNS topic. In order to receive these alerts, you must manually add a subscription to the generated
NAME_PREFIX_binaryalert_yara_match_alerts topic. SNS supports a variety of subscription endpoints, including email, SMS, and other Lambda functions. Email/SMS subscriptions must be confirmed by the destination, which is why this step can't be automated with Terraform.
By default, Terraform will save the state of the infrastructure locally in
terraform/terraform.tfstate. If you are deploying BinaryAlert in an enterprise environment, we recommend configuring Terraform remote state. For example, you can store the Terraform state in a versioned S3 bucket.
We recommend using the
manage.py wrapper script for most BinaryAlert management, but you can also run
terraform commands directly from the
$ cd terraform/ $ terraform plan # Show pending changes $ terraform show # Print the current state of the infrastructure
To teardown all of the BinaryAlert infrastructure:
$ ./manage.py destroy
Terraform will build a destroy plan which you must approve before the delete will proceed.
By default, the BinaryAlert S3 buckets can't be deleted until they are empty. You will be asked if you want to override this setting and delete all objects as well. If so, the new setting will be applied before building the destroy plan.
You can set
force_destroy = true in the
terraform/terraform.tfvars config file and
apply the change if you want to manually disable S3 delete protections.