A while back I wrote up a post on the quick install of Forseti Security. I had a chance to mess around with the 2.0 version and wanted to note a few things down here and talk about how I’m trying out the idea of Security Policy as Code.
The install is pretty seamless and I’m not going to go into too much detail. Behind the scenes the install script does a bunch of deployment manager stuff. Again, at a high level it creates a few service accounts, Google Cloud SQL instance, Google Cloud SQL database, Storage Buckets and Google Compute Engine VM instances.
Forseti 2.0 RC2 architecture has changed in that a client and a server compute instance is created. This is really a security consideration in itself. You may have a use case where you want to allow someone access to run Forseti scans without allowing access to the server itself. You can now do that on the client side.
Security Policy as Code (& configuration)
In this current state I’m just managing the rules. I’ll get configuration going but I have some secrets to deal with. That being said config would be completed pretty much the same way.
The setup is simple, I have a GitHub project with the configs and rules hooked up to Travis CI, another CI would work but I prefer Travis CI for this type work. The service account you’re using for Travis CI will need the following roles:
Compute Admin (can probably slim this down some..)
Service Account User
This will allow the service account to ssh into the server and execute the:
This script will copy the rules from the bucket that the former part of the push.sh copied from your github project. The service account will also need proper bucket permissions.
I could see some sort or rules/config validation engine to be valuable for this type approach for example a way to run via the client pointing to a new config rule. Testing and validating config before it gets to the server. For now I’m just validating the yaml using yamllint that way I can at least be sure I didn’t jack up my yaml.
So that’s the idea, you can see how a community with wide range of policies could be valuable here. While some policies could meet the needs specific to your org, others could be generic/reusable and shared. Grab the policies you need commit them to your own repo, push them out and execute a forseti run. Easy Peasy..