Terratest, Github Actions & Checkov

Varun Tomar
4 min readJul 14, 2021

I work as part of a DevOps team, So, I get to work on different types of projects. Recently, I had the chance to work on Terraform, GitHub Actions, Terratest, and BridgeCrew Checkov. I am sure everyone knows Terraform. So I am not going to talk about it.

GitHub Actions

Having worked with Spinnaker, Jenkins, Azure DevOps, and AWS CodePipeline. I am pretty comfortable with the CICD process. GitHub actions are event-driven. It requires more planning and structure as everything is distributed. Questions like how to manage multiple microservices deployments need to be answered before using Actions. GitHub Actions uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called .github/workflows.

How to GitHub Actions

Create a directory.github/workflows at the root of the repo. For this use case let's create a file unit_test.yml in the workflows directory. Put the below content:

name: Unit Tests
on:
push:
branches:
- main
- develop
paths-ignore:
- 'README.md'
- 'LICENSE'
- '.gitignore'
- '**.md'
pull_request:
paths-ignore:
- 'README.md'
- 'LICENSE'
- '.gitignore'
- '**.md'
jobs:
go-tests:
name: Unit Tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-go@v1
with:
go-version: 1.14
- uses: hashicorp/setup-terraform@v1
with:
terraform_version: 1.0.1
- name: Download Go Modules
working-directory: tests
run: go mod download
- name: Set ssh keys for github remote download
working-directory: tests
run: |
mkdir ~/.ssh
echo "${{ secrets.SSH_GITHUB }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
- name: Run Go Tests
working-directory: tests
run: |
go test -v
env:
# TF ENVIRONMENT
TF_AWS_BUCKET: "${{ secrets.AWS_BUCKET }}"
TF_AWS_PROFILE: "${{ secrets.AWS_PROFILE }}"
TF_AWS_BUCKET_REGION: "${{ secrets.AWS_BUCKET_REGION }}"
# AWS CREDENTIALS
AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
  • name: Refers to the name of the action. (Optional — The name of the workflow as it will appear in the Actions tab of the GitHub repository).
  • push: Refers to when trigger the action, in this case when changes are pushed to this repo.
  • branch: Refers to the name of the branch where changes should be merged for the action to trigger.
  • jobs: A job is a set of steps that execute on the same runner. Multiple jobs run on different runners.
  • runs-on: Refers to the environment where this action will run.
  • steps: A step is an individual task that can run commands in a job. A step can be either an action or a shell command. Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
  • uses: actions/setup-go@v1: This action installs the go software package on the runner, giving you access to the go command.
  • run: go mod download: Runs the go modcommand.
GitHub actions multiple jobs

This is how it will look in the UI of GitHub Actions.

Terratest

As with any code, Terraform module needs to be tested. With every change that we make we need to ensure it does not break pipelines. I think Terratest is the best available option to test Terraform. Terratest is written in golang, you just need to know the basics to run tests.

List of example tests: link

Terratest AWS lambda

BridgeCrew Checkov

There are other alternatives to scanning terraform for misconfiguration. I prefer checkov. I am using pre-commit hooks for running checkov.

- repo: https://github.com/bridgecrewio/checkov.git
rev: '1.0.864' # change to tag or sha
hooks:
- id: checkov
verbose: true
args:
- -d . --framework terraform -o output_format json
  • skip_check: This tells what checks to skip when BridgeCrew scan Terraform files for misconfiguration. In the case of lambda, I wanted to skip X-ray tracing is disabled.
  • output_format: Use output format as JSON as it highlights errors in case you need to troubleshoot.

GitGuardian:

For my secrets, I use GitGuardian. It has saved my life a number of times. Highly recommend the tool.

You can view all the code in the Github repo: here

Conclusion

As things move to the cloud ensuring the security of the infrastructure is crucial. Every project is different, use your toolset as per your requirements and long-term vision. Good luck with deployments.

--

--