You could also do all of the above in one command by running kitchen test. Next, we can run the tests using kitchen verify and see the results:įinally, we can destroy the infrastructure using kitchen destroy. It will also validate the Terraform configuration files and finally run the Terraform apply: It will verify the Terraform client version, initialize the Terraform working directory as well as create and switch to a workspace: This is going to do all kinds of work for you. Now we can run kitchen converge and see what we have: 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. I took me a bit of learning out loud to get this squared away, but with some help, I was able to get it. This has to do with the attribute and Terraform output mapping I talked about earlier. The other thing is the lines twenty-four and twenty-five. We can talk about that a bit more when we set up the workflow in GitHub Actions. In this example, I'm using the billing ID as a secret in GitHub. Lines three and four are a way you can pass -var="foo=bar" to Terraform from inside Kitchen-Terraform. However, I do want to touch on a couple of things. You can read the documentation about the kitchen.yml if you want to know more. The last thing we need to do is tell Kitchen-Terraform what to do! We do this by creating a kitchen.yml file: Then to call a specific control, we add it into the cis_benchmark.rb like so: I'll touch on why that's important when we look at the kitchen.yml file. Kitchen-Terraform can do attribute and Terraform output mapping. 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. First, you add the repository you depend on: 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. The integration directory will hold your profile with the Chef Inspec DSL controls you want to run against a test fixture.įor this post, we will focus only on the cis_benchmark.rb and the inspec.yml files. I also have a shared directory for common code across numerous test fixtures if needed. There could and most likely will be more if we can't cover multiple test scenarios in a single fixture. In this example, we only have one root module or test fixture we are testing against. 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. 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. You'll need to have a fixtures directory. The directory structure is essential when using Kitchen-Terraform. In this post, we will cover Kitchen-Terraform. 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 the spirit of continuous integration, we want to be able to have team members integrate their work. In the last post we covered "local" development.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |