The second of December marked the next major milestone in the progress of HashiCorp’s Infrastructure as Code product, Terraform. However, how many more minor releases are needed before it is deemed grown-up enough to receive the coveted 1.0 versioning? HashiCorp is notoriously cautious before assigning a version 1.0 to a product. In this post, we’ll look at Terraform 0.14, and whether we’re close to a 1.0 yet.
Versions 0.13 and to a similar extent 0.14 have been evolutionary rather than revolutionary, both versions, unlike version 0.12, have not introduced any breaking changes which required major rework of existing code. The two relatively subtle updates point towards the consolidation of key features leading to the big 1.0. This thought process appears to be borne out in the release blog written by Petros Kolyvas where he alludes to this very question, stating that it is “one of the final stepping stones to a 1.0 release of Terraform”.
So what’s new with 0.14?
Concise diff format
This at first glance appears an odd feature, but the release of 0.12 resulted in a considerably more verbose plan output than was seen in earlier releases. Terraform 0.14 now ships with a feature called “concise diff format” that purports to be a compromise between the 0.11 and earlier approach and the 0.12 approach, where a plan will show enough information to understand what objects are changing or being introduced, but without listing out all of the unchanged values.
You may be wondering what is the purpose of this feature. Consider an enterprise-size environment that has been deployed using Terraform and you are introducing a new service; when deploying a release under 0.12 or 0.13 you could face reams and reams of output, finding it hard or impossible to zero in onto the areas of change. When deploying code it is important to understand what is changing, where it is changing and removing the chaff of unchanged objects, will make it much easier to verify your plan meets your expected result before applying. This feature has the feeling that rather than being a Hashicorp driven change, it is a result of push back from the community.
You do not have to physically change anything for this feature to be used, as this new feature is on by default and is available when using terraform apply, terraform apply, and terraform show <planfile> where <planfile> is a previously saved plan output.
# test_resource.foo will be updated in-place
- resource "my_resource" "bibble" {
id = "bibble_123"
~ checksum = 2 -> (known after apply)
- mode = "test" -> null
name = "bibble Test"
tags = []
~ totals = {
- "bar" = 5 -> null
+ "baz" = 5
# (2 unchanged elements hidden)
}
~ values = [
- "alpha",
- "gamma",
+ "alpaca",
+ "goblin",
+ "zephyr",
# (23 unchanged elements hidden)
]
# (5 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}Redact sensitive console output
The second major feature of this release is security-focused. One of the major issues in Terraform is the fact that by default potentially sensitive information can be displayed in clear text during the application of a plan in the console output, another significant security risk is the fact that the same sensitive information can be stored in clear text in the State file.
This feature is a major step forward in increasing the security of the product as you can now mark input variables as sensitive, and have the resultant values redacted from the Terraform console output. This feature provides a method for users to help suppress the output of values from Terraform and infrastructure pipelines that use Terraform, into systems that may not have the same controls, e.g. logging and monitoring. Sensitive input variables provide a building block for protecting sensitive information.
Whilst this new feature goes some way towards closing what I consider to be a major gap in Terraform security and as such is welcomed, the presence of sensitive information in the state file is however the more worrying problem, as this also contains the sum of your entire deployed estate and still needs to be addressed. Currently, we only have workarounds where this is concerned. That said it is a major step in the right direction.
Creating a sensitive variable is as simple as setting the “sensitive” argument to true:
variable "my_information" {
type = object({
name = string
address = string
})
sensitive = true <--- new argument in place
}
resource "some_resource""a" {
name = var.my_information.name
address = var.my_information.address
}
Using this variable throughout your configuration will obfuscate the value from display in plan or apply output:
Terraform will perform the following actions:
# some_resource.a will be created
+ resource "some_resource""a" {
+ name = (sensitive)
+ address = (sensitive)
}
Plan:1 to add, 0 to change, 0 to destroy.
In some cases where a sensitive variable is used in a nested block, the whole block can be redacted. This happens with resources that can have multiple blocks of the same type, where the values must be unique:
Terraform configuration:
# main.tf
resource "my_resource""a" {
nested_block {
my_information = var.user_information # a sensitive variable
SomeOther_information = "not sensitive data"
}
}
Terraform CLI output:
Terraform will perform the following actions:
# some_resource.a will be updated in-place
~ resource my_resource""a" {
~ nested_block {
# At least one attribute in this block is (or was) sensitive,
# so its contents will not be displayed.
}
}
Dependency lock file for providers.
The final major feature in Terraform 0.14 is the new dependency locking for Terraform Providers. Now when a terraform init is run Terraform will now generate a new file .terraform.lock.hcl rather than the terraform.lock.tf file that was previously created. The change is that Terraform now records which provider versions were selected by the installation process, and further subsequent calls to terraform init will make those same selections.
Why would I want this?
This is another feature which on first look has you scratching your head as to why you would want it, surely you would want the latest and greatest vendor provider to be used with your deployment? However in a production environment or to be more accurate a live environment rather than a test and dev platform, the introduction of this new locking file will help to avoid situations where you might accidentally select a newer version of a provider and see different behavior that can not be attributed to an intentional change
How does it work?
When terraform init is run initially it will work on installing all of the providers needed for a configuration and by default install the latest and greatest unless there are restrictions written in the code. The terraform init command will then record to the new locking file the actual versions downloaded. As already alluded too if a particular provider has no existing record, Terraform will select the newest available version that matches any given version constraint, and then update the lock file to include that selection.
If a selected provider already has an entry recorded in the lock file, Terraform will re-select that stated version for installation, even if a newer version has become available. This behavior can be overridden by adding the -upgrade option when running terraform init, in which case Terraform will disregard the existing selections and once again select the newest available version matching any version constraints.
Summary
I get the feeling that something momentous is about to happen with Terraform. Hashicorp is definitely getting close to releasing the 1.0 version of Terraform. The 0.13 and the latest 0.14 are consolidation releases, stabilizing the language following the tidal wave of change that 0.12 brought. Start using Terraform 0.14 now and download the version for your particular platform here.
