Using Terraform to manage your infrastructure-as-code has become the standard. But Terraform alone is not enough. To ensure best practices, questions such as "How do we enforce policies?", "How do we lint our code?", and "How do we harden infrastructure security?" must be answered. This often requires integrating with 3rd-party tools or plugins. 

In this brief, we'll look at the top four plugins that users of Terraform and other IaC frameworks should integrate with their workflow in 2023. We'll explore what benefits each offers and how to get started on incorporating them into your workflow efficiently. By the end of this blog, you will have a better understanding of how to use third-party tools to inject best practices into your Terraform development process. Let's dive in!

Open Policy Agent / OPA by Styra

Open Policy Agent (OPA) is an open source, general-purpose policy engine that can be used to enforce various policies across your infrastructure as code. This tool can be used to ensure that security and compliance standards are being followed, such as limiting access to certain resources or enforcing specific naming conventions. (For example, limiting the number of GPU servers or even "don't deploy on Friday evening".)  OPA also allows for users to write custom policies in a simple language called Rego. It also has great community and pre-defined policies for users (see Awesome OPA)

Peter O'Neill, Community Advocate, Styra

Checkov by bridgecrew

Checkov is a static code analysis tool designed to help users identify security and compliance risks in their infrastructure as code deployments. It uses predefined security policies to detect common misconfigurations such as public access or sensitive data exposure. Checkov supports multiple IaC frameworks, including Terraform and CloudFormation, making it an ideal choice for organizations that use multiple providers

To get started with Checkov, users need to create a policy file written in yaml, which can be customized to their environment. The policy file should include the rules that users want Checkov to enforce in their Terraform deployments.

tfsec by Aqua

tfsec by Aqua provides advanced security scanning of Terraform templates, detecting configuration errors and best practices violations. It can be used to detect weaknesses in your infrastructure, as well as identify potential security risks that could lead to vulnerabilities. 

tflint

tflint is a linting tool for Terraform, used to check the syntax and structure of Terraform configuration files (written in the HashiCorp Configuration Language, or HCL) and to enforce best practices and conventions. It can help catch mistakes and improve the quality of Terraform code, making it easier to maintain and troubleshoot.

Plugins (FKA Integrations) now widely available in env0

To make it easy for our users and offer a native integration with tools into our platform, we're now offering a catalog of plugins supported by env0. Admins will be able to select their desired plugins, and simply add the snip to their relevant env0.yml as a substep entry, very similar to how you might define a step in your CI pipeline.

This will allow users to easily incorporate the tools they need, and get up and running in no time.

How to Implement Plugins in env0 - a Technical Walkthrough 


Previously, users would define integrations/tools/plugins as shown in the yaml file below:


version: 1
deploy:
  steps:
   terraformInit:
     before:
       - pip install --user j2cli
       - 'echo Generating s3 backend'
       - j2 backend.tf.j2 > backend.tf
       - 'echo -e "Generated \"backend.tf\": \n$(cat backend.tf)"'

Now, we've added a simpler, more streamlined way to integrate those 3rd party plugins

version: 2
steps:
terraformPlan:
  after:
    - name: Enforce networking policies # The name that will be shown on the step in UI
      use: https://github.com/env0/env0-opa-plugin@1.0.0
      input: # This is per plugin, and defined by author
        path: policies/networking.rego
        flags: --count 2 --e2e
    - pip install --user j2cli # Shorthand syntax example. In this case, step name would be the whole command
    - name: Generating s3 backend # An example on how to run multiple bash commands under a single step.
      run: |
        echo Generating s3 backend
        j2 backend.tf.j2 > backend.tf
        echo -e "Generated \"backend.tf\": \n$(cat backend.tf)"
    - name: Run checkov
      use: https://github.com/env0/env0-checkov-plugin@1.0.0
      input:
         directory: .
        flags: --compact
      env:
        CKV_FRAMEWORK: terraform

Under the previous implementation, users would see a single “Terraform Plan: After” step in the UI where all above commands will run under this step.

With today’s release of Plugins and the new env0.yml structure, each entry under the terraformPlan.after key will be presented as a step in UI. Any user that’s deploying an environment will be able to see the additional plugins added by the admin via the env0.yml file, and each step will show a successful or failed status.

How to create a new env0 Plugin

In order to create a new env0 plugin of yours, you must follow these guidelines:

  1. Create a new public Git repository.
  2. Add a new env0.plugin.yaml to it. This YAML file uses the following schema:
  1. name - Required - the name of the plugin
  2. icon - A URL to the icon of the plugin.
  3. inputs - An object defining the expected inputs for your plugin. The inputs attribute has its own schema as well:
  1. inputs.<id> - The identifier of the input. Has to be unique.
  2. inputs.<id>.description - Required - A short description of the input.
  3. inputs.<id>.required - a boolean value that states whether this input is required or not.
  1. run - An object defining what the plugin executes. Currently, the plugin environment only supports bash runtime. In order to execute commands
    use exec attribute, to define you execution commands
  1. Use it in an env0.yaml file.

Checkov Plugin - using checkov to run scans with env0

This env0 Checkov Plugin will allow you to run checkov scans on an IaC directory as a part of your custom flow. To use this plugin, you will need to use version 2 of env0.yml.

Here's the link to the Checkov git repo

Inputs

The Checkov plugin accepts the following inputs:

  • directory (required) - the path to the directory with the IaC code to scan (the root folder is your project's root folder)
  • flags - a string containing additional flags as one string

Checkov example

In this example we will run checkov scan on our tf folder before the "Terraform Plan" step of a deploy. We will call that step "My Step Name":

version: 2
deploy:
  steps:
    terraformPlan:
      before:
        - name: My Step Name # The name that will be presented in the UI for this step
          use: https://github.com/env0/env0-checkov-plugin
          inputs:
            directory: .
            flags: --framework terraform 

env0 OPA Plugin

This env0 OPA Plugin will allow you to run opa eval on a bundle directory as a part of your custom flow. To use this plugin, you will need to use version 2 of env0.yml.

Here's the link to the OPA git repo

Inputs

The OPA plugin accepts the following inputs:

  • path (required) - the path to your bundle directory (the root folder is your project's root folder)
  • query (required) - a query to eval with opa eval
  • flags - a string containing additional flags as one string

If you are used to using --input or --data you can bundle those into a bundle directory and use it. Read more about it here.

Example Usage

In this example we will run opa eval with our own bundle file after the "Terraform Plan" step of a deploy. We will call that step "My Step Name":

version: 2
deploy:
  steps:
    terraformPlan:
      after:
        - name: My Step Name # The name that will be presented in the UI for this step
          use: https://github.com/env0/env0-opa-plugin
          inputs:
            path: bundle-file-path
            flags: --fail --format=raw
            query: data.example.violation[x]

Conclusion

Users of terraform (and other infrastructure as code frameworks) often use other 3rd-party tools to help them establish best practices in their R&D organizations. These best practices vary from policy enforcements and code linters, to security hardening and more, (using such tools as Checkov, OPA, and tfsec.) To ease the integration of such tools, we've built a way for users to natively use these as plugins. Read the docs here and try out the new env0 plugins today!

Using Terraform to manage your infrastructure-as-code has become the standard. But Terraform alone is not enough. To ensure best practices, questions such as "How do we enforce policies?", "How do we lint our code?", and "How do we harden infrastructure security?" must be answered. This often requires integrating with 3rd-party tools or plugins. 

In this brief, we'll look at the top four plugins that users of Terraform and other IaC frameworks should integrate with their workflow in 2023. We'll explore what benefits each offers and how to get started on incorporating them into your workflow efficiently. By the end of this blog, you will have a better understanding of how to use third-party tools to inject best practices into your Terraform development process. Let's dive in!

Open Policy Agent / OPA by Styra

Open Policy Agent (OPA) is an open source, general-purpose policy engine that can be used to enforce various policies across your infrastructure as code. This tool can be used to ensure that security and compliance standards are being followed, such as limiting access to certain resources or enforcing specific naming conventions. (For example, limiting the number of GPU servers or even "don't deploy on Friday evening".)  OPA also allows for users to write custom policies in a simple language called Rego. It also has great community and pre-defined policies for users (see Awesome OPA)

Peter O'Neill, Community Advocate, Styra

Checkov by bridgecrew

Checkov is a static code analysis tool designed to help users identify security and compliance risks in their infrastructure as code deployments. It uses predefined security policies to detect common misconfigurations such as public access or sensitive data exposure. Checkov supports multiple IaC frameworks, including Terraform and CloudFormation, making it an ideal choice for organizations that use multiple providers

To get started with Checkov, users need to create a policy file written in yaml, which can be customized to their environment. The policy file should include the rules that users want Checkov to enforce in their Terraform deployments.

tfsec by Aqua

tfsec by Aqua provides advanced security scanning of Terraform templates, detecting configuration errors and best practices violations. It can be used to detect weaknesses in your infrastructure, as well as identify potential security risks that could lead to vulnerabilities. 

tflint

tflint is a linting tool for Terraform, used to check the syntax and structure of Terraform configuration files (written in the HashiCorp Configuration Language, or HCL) and to enforce best practices and conventions. It can help catch mistakes and improve the quality of Terraform code, making it easier to maintain and troubleshoot.

Plugins (FKA Integrations) now widely available in env0

To make it easy for our users and offer a native integration with tools into our platform, we're now offering a catalog of plugins supported by env0. Admins will be able to select their desired plugins, and simply add the snip to their relevant env0.yml as a substep entry, very similar to how you might define a step in your CI pipeline.

This will allow users to easily incorporate the tools they need, and get up and running in no time.

How to Implement Plugins in env0 - a Technical Walkthrough 


Previously, users would define integrations/tools/plugins as shown in the yaml file below:


version: 1
deploy:
  steps:
   terraformInit:
     before:
       - pip install --user j2cli
       - 'echo Generating s3 backend'
       - j2 backend.tf.j2 > backend.tf
       - 'echo -e "Generated \"backend.tf\": \n$(cat backend.tf)"'

Now, we've added a simpler, more streamlined way to integrate those 3rd party plugins

version: 2
steps:
terraformPlan:
  after:
    - name: Enforce networking policies # The name that will be shown on the step in UI
      use: https://github.com/env0/env0-opa-plugin@1.0.0
      input: # This is per plugin, and defined by author
        path: policies/networking.rego
        flags: --count 2 --e2e
    - pip install --user j2cli # Shorthand syntax example. In this case, step name would be the whole command
    - name: Generating s3 backend # An example on how to run multiple bash commands under a single step.
      run: |
        echo Generating s3 backend
        j2 backend.tf.j2 > backend.tf
        echo -e "Generated \"backend.tf\": \n$(cat backend.tf)"
    - name: Run checkov
      use: https://github.com/env0/env0-checkov-plugin@1.0.0
      input:
         directory: .
        flags: --compact
      env:
        CKV_FRAMEWORK: terraform

Under the previous implementation, users would see a single “Terraform Plan: After” step in the UI where all above commands will run under this step.

With today’s release of Plugins and the new env0.yml structure, each entry under the terraformPlan.after key will be presented as a step in UI. Any user that’s deploying an environment will be able to see the additional plugins added by the admin via the env0.yml file, and each step will show a successful or failed status.

How to create a new env0 Plugin

In order to create a new env0 plugin of yours, you must follow these guidelines:

  1. Create a new public Git repository.
  2. Add a new env0.plugin.yaml to it. This YAML file uses the following schema:
  1. name - Required - the name of the plugin
  2. icon - A URL to the icon of the plugin.
  3. inputs - An object defining the expected inputs for your plugin. The inputs attribute has its own schema as well:
  1. inputs.<id> - The identifier of the input. Has to be unique.
  2. inputs.<id>.description - Required - A short description of the input.
  3. inputs.<id>.required - a boolean value that states whether this input is required or not.
  1. run - An object defining what the plugin executes. Currently, the plugin environment only supports bash runtime. In order to execute commands
    use exec attribute, to define you execution commands
  1. Use it in an env0.yaml file.

Checkov Plugin - using checkov to run scans with env0

This env0 Checkov Plugin will allow you to run checkov scans on an IaC directory as a part of your custom flow. To use this plugin, you will need to use version 2 of env0.yml.

Here's the link to the Checkov git repo

Inputs

The Checkov plugin accepts the following inputs:

  • directory (required) - the path to the directory with the IaC code to scan (the root folder is your project's root folder)
  • flags - a string containing additional flags as one string

Checkov example

In this example we will run checkov scan on our tf folder before the "Terraform Plan" step of a deploy. We will call that step "My Step Name":

version: 2
deploy:
  steps:
    terraformPlan:
      before:
        - name: My Step Name # The name that will be presented in the UI for this step
          use: https://github.com/env0/env0-checkov-plugin
          inputs:
            directory: .
            flags: --framework terraform 

env0 OPA Plugin

This env0 OPA Plugin will allow you to run opa eval on a bundle directory as a part of your custom flow. To use this plugin, you will need to use version 2 of env0.yml.

Here's the link to the OPA git repo

Inputs

The OPA plugin accepts the following inputs:

  • path (required) - the path to your bundle directory (the root folder is your project's root folder)
  • query (required) - a query to eval with opa eval
  • flags - a string containing additional flags as one string

If you are used to using --input or --data you can bundle those into a bundle directory and use it. Read more about it here.

Example Usage

In this example we will run opa eval with our own bundle file after the "Terraform Plan" step of a deploy. We will call that step "My Step Name":

version: 2
deploy:
  steps:
    terraformPlan:
      after:
        - name: My Step Name # The name that will be presented in the UI for this step
          use: https://github.com/env0/env0-opa-plugin
          inputs:
            path: bundle-file-path
            flags: --fail --format=raw
            query: data.example.violation[x]

Conclusion

Users of terraform (and other infrastructure as code frameworks) often use other 3rd-party tools to help them establish best practices in their R&D organizations. These best practices vary from policy enforcements and code linters, to security hardening and more, (using such tools as Checkov, OPA, and tfsec.) To ease the integration of such tools, we've built a way for users to natively use these as plugins. Read the docs here and try out the new env0 plugins today!

Logo Podcast
With special guest
Andrew Brown

Schedule a technical demo. See env0 in action.

Footer Illustration