We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies from this website. If you would like to change your preferences you may do so by following the instructions here

Cloud Compliance with AreBOT: Designing Complex Compliance Policies

This is a follow-up to our series of posts on cloud compliance in AWS environments. First, we discussed the pros and cons of using the AWS Config service to ensure that all resources have the desired configurations. Then, we briefly introduced AreBOT, the tool we developed here at kreuzwerker to simplify the design, evaluation, and enforcement of compliance rules in complex AWS clouds.

In this post, we will take a closer look at the configuration language to define compliance policies using AreBOT.

A configuration file to rule them all

All the AreBOT components and tasks are specified in a single, easy-to-read configuration file. Let's consider a case scenario to show how to write one.

The admins of an AWS cloud infrastructure want that all Elastic Compute Cloud (EC2) instances, Security Groups, and Elastic Block Store (EBS) volumes are tagged with a "ProjectName". The value of this tag must apply an internal naming convention. Furthermore, security standards require that data on EBS volumes is always encrypted. The cloud infrastructure spans two AWS accounts and resources may reside in different regions. In case of compliance violation, the admins want to be immediately alerted via e-mail.

This scenario can be easily accommodated using the simple yet powerful AreBOT configuration language. First, we formulate the compliance policy for the EC2 resources, which needs to specify two rules for tag-compliance, one rule for data encryption compliance, and the actions to take in case of violations.

Please note that action elements can share the same name if they are in different policy scopes. For instance, the actions notify_admins specify different behaviors depending on their respective policy - in our case, the list of recipients who receive email notifications.
Finally, the configuration file must indicate which are the AWS accounts (allowed to be) monitored by AreBOT. This can be easily done as follows.

A couple of comments about the above are in order. First, arebot_role_arn indicates the IAM role in the AWS account that supplies AreBOT the credentials to do its job. Second, all_events_queue specifies the Amazon SQS queue that collects data about resource's configuration changes (as Amazon CloudWatch events), and that is polled by the AreBOT compliance checker (for more details, see our previous post).

Conclusion and How to Get More Information

In this post, we showed how easy is to configure AreBOT to enforce compliance requirements in a rather simple but realistic scenario. All in all, the process took us few minutes and less than 50 lines of configuration code. Without our tool, and using only AWS services, the same scenario would have required the implementation of a Lambda function for each compliance rule, a proper setting for the AWS Config service, and an additional Lambda function to customize email notifications. And, it goes without saying, these operations had to be repeated for each AWS account to monitor. That's indeed a lot of work saved, don't you think?

If we got you curious about AreBOT and cloud compliance, let's continue this discussion at DevOpsDays Berlin - 2017! It would be a great opportunity to meet in person and share our thoughts and ideas with you.

Or, you know, just stay tuned on this blog for the next posts of this series.

As a seasoned Computer Science researcher, Guido has spent the last five years contributing his broad knowledge to this field throughout Europe, within the framework of the international research and innovation centre IRIXYS