fullstop.

The latest documentation is available in the Fullstop github project page.

fullstop. AWS overview

../_images/fullstop.png

fullstop. Architecture overview

../_images/fullstop-architecture.png

Aim of the project is to enrich CloudTrail log events.

In our scenario we have multiple AWS accounts that need to be handled.

Each of this account has CloudTrail activated and is configured to write in a bucket that resides in the account where also fullstop is running. (Right now in AWS it’s not possible to read CloudTrail logs from a different account)

Fullstop will then process events collected from CloudTrail.

To enrich CloudTrail log events with information that comes from other systems than AWS, we should only configure fullstop to do so.

Fullstop can even call the AWS API of a different account, by using a cross-account role. The account that is running fullstop should therefore be trusted by all other accounts in order to perform this operations.

../_images/fullstop-cross-account-role.png

Command Line Client

Fullstop comes with a convenience command line client:

$ sudo pip3 install --upgrade stups

First configure your Fullstop CLI for your AWS account IDs:

$ fullstop configure
# enter Fullstop URL and your AWS account IDs

For example, you can list all recent violations in your configured AWS accounts:

$ fullstop list-violations --since 7d -l 50

Resolving Violations

You can resolve batches of violations with the resolve-violations command which has similar filtering/matching options as list-violations.

$ fullstop resolve-violations -t <VIOLATION-TYPE> -l 100 --since 7d '<comment>'

Filtering by applications / versions is also possible. Multiple values must be comma-separated:

$ fullstop resolve-violations -t <VIOLATION-TYPE> --applications my-app --application-versions 1.0,1.1 '<comment>'

Parts of the meta field can also be matched for more finegrained control, for example:

$ fullstop resolve-violations -t WRONG_AMI -m ami_name=another-ami 'My boss wants me to do this'