In the last post we covered "local" development. In the spirit of continuous integration, we want to be able to have team members integrate their work. If you remember, the violations we had from running the inspec-gcp-cis-benchmark profile, we've got some work to do! We will do that using Kitchen-Terraform and run the workflow in GitHub Actions. In this post, we will cover Kitchen-Terraform.
The directory structure is essential when using Kitchen-Terraform. My current structure looks like this:
You'll need to have a
This directory is where your Terraform root modules will live or in Kitchen-Terraform language, "test fixtures." It will call the child module, the module we are developing. That language aligns with the module documentation, so in our case, the child module is in the root of the repository, and it's the module we are publishing through GitHub for reuse. In this example, we only have one root module or test fixture we are testing against. There could and most likely will be more if we can't cover multiple test scenarios in a single fixture. I also have a shared directory for common code across numerous test fixtures if needed.
For this post, we will focus only on the
cis_benchmark.rb and the
inspec.yml files. Since Google did all the heavy lifting for us by writing the controls for the specific benchmarks we are testing for, 3.1 Networking and 4.4 VMS, we can add them very quickly. First, you add the repository you depend on:
NOTE: The input
gcp_project_id is what the inspec-gcp-cis-benchmark profile expects in order to know what project to run the tests against. Kitchen-Terraform can do attribute and Terraform output mapping. I'll touch on why that's important when we look at the
Then to call a specific control, we add it into the
cis_benchmark.rb like so:
The last thing we need to do is tell Kitchen-Terraform what to do! We do this by creating a
You can read the documentation about the kitchen.yml if you want to know more. However, I do want to touch on a couple of things.
Lines three and four are a way you can pass
-var="foo=bar" to Terraform from inside Kitchen-Terraform. In this example, I'm using the billing ID as a secret in GitHub. We can talk about that a bit more when we set up the workflow in GitHub Actions.
The other thing is the lines twenty-four and twenty-five. This has to do with the attribute and Terraform output mapping I talked about earlier. I took me a bit of learning out loud to get this squared away, but with some help, I was able to get it. To make a long story short, this is how I mapped my Terraform output of
project_id to the attribute needed to run the inspec-gcp-cis-benchmark profile.
Now we can run kitchen converge and see what we have:
Next, we can run the tests using kitchen verify and see the results:
In the next post, I will talk about running the testing workflow through GitHub Actions!