Event Driven Guardrails for AWS

Gogs 88fc9139ff Nonfunctional. Submodules. 5 years ago
bootstrap f534a963c4 Multi-account support. 5 years ago
sample 88fc9139ff Nonfunctional. Submodules. 5 years ago
Architecture.md 763d50e8b0 Rough draft of function. 5 years ago
Developer.md 0b0de6c8be Starting to take shape 5 years ago
LICENSE 1a3e48d466 Initial commit 5 years ago
README.md f534a963c4 Multi-account support. 5 years ago
Roles.md 1d4049c6e2 All the way to remediation Queue 5 years ago

README.md

Fred's Cloud Monitor (FCM)

Event Driven Guardrails for AWS

Provides a set of enforced guardrails to AWS configuration changes.

Goals

  • Widely decoupled design.
  • Serverless.
  • Receive input events from cloudtrail, AWS config, or manual sources.
  • Provide standard libraries to easily add additional functionality.
  • Encryption throughout
  • Simple configuration through command-line files.

Principal #1

The right way to protect your assets is to prevent them in the first place. While FCM provides automated remediation for a variety of possible misconfigurations, the better way to handle things is to prevent them in the first place through appropriate IAM policies.

FCM is reactive, which is always a worse solution than proactive prevention. That said, FCM can find and fix security issues that may have slipped through the cracks.

Important Note about Loop Prevention

To prevent loops, the analysis modules discard any event that comes in that was initiated by an assumedrole of fcm-* and has the string exec-env/AWS_Lambda in its userAgent. For this reason, it is imperative that you do NOT change the role names from this convention, or you could end up with an endless loop and the accompanying endless AWS bill.

TO BE VERY CLEAR: IF YOU CHANGE THE ROLE NAMES, YOU COULD BE RESPONSIBLE FOR A LOT OF AWS COSTS.

(there's got to be a better way to do loop prevention? SQS subscription filters?)

Dependencies

Requires python3 and terraform.

Credentials

At present, the only supported method of using credentials is to take advantage of the ~/.aws/config and ~/.aws/credentials files. Through these you can use static keys, sts assume role, or other supported methods.

You must have at minimum a profile called fcm-security-account. For example:

~/.aws/config:

[profile fcm-security-account]
output = table
region = us-east-2

~/.aws/credentials

[fcm-security-account]
aws_access_key_id = YOURKEYGOESHERE
aws_secret_access_key = YourAccessKeyGoesHere

Additional account profiles may be named whatever is appropriate for you.

Bootstrapping

To get started, terraform needs a centralized S3 bucket to store its state. This allows you to store FCM in git and allow updates from multiple individuals on their own workstations.

  1. Ensure you have valid credentials for AWS in one of the API's supported methods.
  2. Edit bootstrap/s3.terraform-state.tf and set your preferred region and a unique bucket name.
  3. Run the following to initialize a new S3 bucket in your account.

    cd bootstrap
    terraform init
    terraform apply
    

Sample

Review the files in sample/ for an example of what a generated function from event to remediation might look like.