Each Terraform provider has its own set of resource types that describe entities in IaaS, PaaS, or SaaS applications. Providers are version-controlled abstractions of upstream APIs that provide vast control to engineers managing the Terraform resources.
But as they say, with great power…
That’s where policy-as-code and Checkov come in. Checkov, Bridgecrew’s open-source static analysis tool for infrastructure as code, makes it easy to put policy guardrails in place when developing infrastructure for one of the three major cloud providers: AWS, GCP, and Azure.
Checkov democratizes secure infrastructure development, helping educate you about secure code practices, and making you more productive and secure. And like IaC itself, policy-as-code can be iterated on and improved over time, reducing the need to fix or “harden” at a later stage of the development process.
When developing infrastructure across one of the three main CSPs, you can embed Checkov pre-commit, in your CI/CD pipeline, or even directly in your VS Code editor. With Checkov, you can verify and fix every misconfiguration before provisioning, or better yet, as you code.
But what if you’re using a Terraform provider used for PaaS products like GitHub Enterprise and Linode? No problem! 👌
Custom Terraform providers
Checkov now supports custom Terraform providers, each of which comes with a few pre-built policies. More importantly, Checkov supports the creation of your own policies for custom providers. That way, if someone on your team decides to provision a PaaS using Terraform, they absolutely can—and they can write a Checkov policy to guard it.
One example policy for the GitHub provider is “Ensure repository is private,” which is generally a best practice failsafe. Of course, that policy won’t be relevant 100% of the time—it can be perfectly valid that your repositories be public. The value of having a policy in place is that it brings awareness and pushes for the safer choice while still leaving the option for any policy to be skipped on purpose.
Some other examples, in this case for Linode, a popular web hosting and Kubernetes platform, are to “Ensure that SSH keys are set in authorized keys for an instance” and “Ensure that your data is encrypted.”
These are just a few examples of custom provider policies that we’ve already contributed to Checkov. There are more than 800 public Terraform providers that you can support with Checkov.
Writing your own policies for custom providers
It’s straightforward to add support for and write policies for a new Terraform provider. The steps below show how we added one for Linode, but you can adapt the process for any provider.
1. In GitHub, fork Checkov.
2. Create a new directory for your provider, for example: checkov/checkov/terraform/checks/resource/linode.
3. Add your new policy:
4. Add policies load loader in checkov/terraform/checks/resource/linode/__init__.py:
(Can be copied from here)
5. Include checks in Checkov runner in checkov/terraform/checks/resource/__init__.py.
This will ensure that this and any future Linode resource tests are included in Checkov runs:
6. Create and submit your PR.
There you go! 🏆
You can now create custom provider checks! And after your PR is merged, any new scan by Checkov will scan those custom providers for the policies you have added.
···
You can also contribute custom provider checks back to the community —just follow our contribution guidelines. We would love to see policies around major PaaS providers like Cloudflare, Digital Ocean, and Heroku! If you want to become an OSS contributor and get some sweet Bridgecrew swag, reach out to us in our Slack community.
