We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Open Source
        Avoid vulnerable dependencies
      • Snyk Code
        Secure your code as it’s written
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Fix misconfigurations in the cloud
    • Platform
      • What is Snyk?
        See Snyk’s developer-first security platform in action
      • Developer Security Platform
        Secure all the components of the modern cloud native application in a single platform
      • Security Intelligence
        Access our comprehensive vulnerability data to help your own security systems
      • License Compliance Management
        Manage open source license usage in your projects
    • Self-paced security education with Snyk Learn
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Customer success
      • Support portal & FAQ’s
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Self-paced security education with Snyk Learn
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
Cloud Native SecurityDevSecOps

4 tips to manage multiple Terraform versions

Stephane JourdanMay 27, 2020

Editor’s note: This post originally appeared on CloudSkiff.com. CloudSkiff joined Snyk in October 2021.

There are a lot of reasons why you may need to use multiple Terraform versions locally, like having different environments (structured deployments) with separate versions, working on several projects for different customers, ensuring backward compatibility of your code by running it with several versions, etc. Here are a few very basic tips for keeping multiple Terraform versions clean and organized.

Start by using locally an environment / Terraform version manager

Using a version manager makes it way less painful to deal with multiple Terraform versions locally, and will make sure that:

  • Switching between projects is quick
  • The development environment is the closest possible to production.

tfenv is a good one, inspired by rbenv. Basically, tfenv will allow you to install a specific version of Terraform and switch to it by default. It will also enable you to list and keep track of all Terraform versions installed on your laptop. Plus it has a few convenient commands, such as tfenv install min-required that will recursively go through your terraform files to determine the minimally required version.

Explicitly set your Terraform versions

When they happen, Terraform upgrades can hurt. They hurt, even more, when you have a random exception that you don’t understand and discover that they are happening because you are running the wrong Terraform version on that specific machine.

By explicitly setting the required Terraform version, you will get a clean, explicit error if you try to run an apply with the wrong environment.

terraform {
required_version = "0.12.10"
}
Manage multiple Terraform versions

Set module versions as well

Moving parts are one of the programmer’s worst enemies, and that applies to Infrastructure as Code too. Terraform modules bring a lot of reusability and composability, but they can also become messy to handle.

Setting module versions makes it easier to control when what part of your infrastructure will change if there is a module upgrade. You get a guarantee that for a given commit in your codebase, you always deploy the same thing.

module “blabla” {
source = “module_name”
version = “1.2.3”
}

It also enables to progressively roll out module upgrades: you can have the old version in production, create a dev branch where you upgrade the module, test in your dev environment, then merge on to the master if it passes testing.

The more modules you use, the more likely it is that one of them causes an issue at some point — so this becomes more and more critical as your codebase grows.

Prevent local apply / deter commits on master

Don’t forget your workflow! Running apply locally can be dangerous as soon as two users collaborate on the same Terraform file: if two updates happen shortly one after the user, the first one may be overridden by the second one. Besides, you never know what can happen on your laptop, and we’ve heard stories of big state files getting messed up by a lost WiFi connection.

This is why a more production-ready workflow encourages running apply only from a central, versioned system such as through a CI/CD.

The next step, though, is to build that behavior into the process. For example, a user’s access rights will not enable them to make changes directly in production. Rather, only the CI/CD keys will have the rights to do that.

Similarly, it is very tempting to merge to master, even though we know it’s not a best practice. Locking the master will encourage users to go through the better, safer, pull-request then review process. Unless you are superhuman, and always read the Terraform plan and never make a mistake.

Some teams add additional steps there, such as linting or checking for docs updates that are a small investment in keeping the code clean in the long run.

Securing your Terraform code

Snyk IaC secures your Terraform configs (and Kubernetes, CloudFormation, and ARM templates!) as you code, with guided fixes so you can merge and move on. You can test as you write, monitor for changes in your git repositories, and automate testing in your build pipelines before deployment. Getting started with a Free plan takes minutes, while a breach from an IaC misconfiguration can cause damage to last a lifetime. Sign up and start securing your configs below.

Secure your Terraform configs for free

Snyk IaC scans your Terraform configs and offers guided fixes as you code.

Sign up for free

Log4Shell resource center

We’ve created an extensive library of Log4Shell resources to help you understand, find and fix this Log4j vulnerability.

Browse Resources
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • Pricing
  • Test with GitHub
  • API status
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Secure SDLC
  • Cloud Native Security
  • Cloud security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2022 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom