Terraform OS Detection



In some rare cases it is important to know on which Operating System Terraform is being executed. Since there is (yet) no functionality that solves this, this small hack can help in these situations.

It is important to note that once there hopefully will be an official function by Terraform this hack will become unnecessary.

The situation is the following: We have a functionality in our Terraform code which runs perfectly fine on our build servers which run on Linux.

However, some users run the code on Windows where it fails.

We have found a fix for this, but now we need Terraform to know whether or not it is being run on Linux or Windows.

Let’s get into it.

Create a printf.cmd file with this content:

@echo off
echo {"os": "Windows"}

We want Terraform to run this file when under Windows which clearly returns to Terraform that we are on Windows. Linux should somehow ignore this file. More on that now:

Create a data.tf file with this content:

data "external" "os" {
  working_dir = path.module
  program = ["printf", "{\"os\": \"Linux\"}"]
}

Now comes the magic:

We created a external data resource in Terraform which allows us to run commands outside of Terraform.

working_dir sets the working directory of the program. It is required for this scenario and tells Windows that it should look for a program here in this folder.

program This is the essential hack: Under Windows the OS will look for an executable called printf in the working directory, which it finds as printf.cmd. Remember Windows ignores file extensions! It will pass the second argument ({\"os\": \"Linux\"}) of program = ["printf", "{\"os\": \"Linux\"}"] to the executable printf.cmd, which simply ignores them because it does not expect any. Instead, printf.cmd will simply return "{os": "Windows}" as we defined in the first code snippet.

Now here is the catch: Linux will before looking for a program printf in the working directory look for a program called printf under its binaries. Et voilà Linux has its binary printf which simply prints what you give it as an argument (printf). As we have defined here (program = ["printf", "{\"os\": \"Linux\"}"]) we give to printf the argument {\"os\": \"Linux\"} and therefore it will print exactly that: That we are under Linux, ignoring the printf.cmd file in the working directory.

Now all that is left is to access the results:

Create a locals.tf file with this content:

locals {
  os = data.external.os.result.os
  check = local.os == "Windows" ? "We are on Windows" : "We are on Linux"
}

As you can see with defining the local variable os we execute our data resource data "external" "os" from before and by using result we can get its result. os by now should be either Windows or Linux. With check we can then check if the underlying OS is either Windows or Linux.

In the scenario it is now possible to detect on which OS Terraform is being run and we can implement the fix.

Credits:

Janos Pasztor for the idea and concept.

To my colleague Philipp , who impresses me with his sharpness every other day and with whom I came up with this solution.


tl;dr:

printf.cmd:

@echo off
echo {"os": "Windows"}

data.tf:

data "external" "os" {
  working_dir = path.module
  program = ["printf", "{\"os\": \"Linux\"}"]
}

locals.tf:

locals {
  os = data.external.os.result.os
  check = local.os == "Windows" ? "We are on Windows" : "We are on Linux"
}

Similar Posts You Might Enjoy

(Prevent) Hacking into a CloudService - About security, ECS and terraform AWS UserGroup Hannover Online Meetup Feb, 4th 2021

Yoni: Oftentimes, when we think about protecting resources in the cloud, we immediately think about the typical ways in - via public-facing applications or abuse of credentials. In this talk, we will look at one additional way: through the work unit parameters of a service. During the development of Indeni’s Cloudrail SaaS product, Yoni was responsible for trying to find ways to hack into the service. One of the ways he found, raises questions about how secure ECS workloads really are. - by Yoni Leitersdorf , Gernot Glawe , Malte Walkowiak

Consistent Style Across Editors

Consistent Style Across Editors Sometimes, common themes occur if working on a project with multiple people and different development environments. One of the unexpected, time-consuming problems is related to editor configurations. But it is pretty easy to unify things, if you know where to look… - by Thomas Heinen

Spice up your Cloudformation Development life

Pure CloudFormation coding only with vi can be hard work. But since CloudFormation still is the lingua franca of AWS infrastructure as code, the ecosystem keeps evolving. Even if you only use it indirectly, there are some tools to spice up your development. Hot diagrams, more aroma with compliance checks or bittersweet automated testing. Ready to taste it? Here we go. - by Gernot Glawe