HashiCorp has moved to production the Terraform Cloud Operator for Kubernetes in Terraform Cloud. This product was first announced in March 2020 as an alpha product. At the time they stated that its main use cases were to allow the hardening and configuration of application-related infrastructure as a Terraform module and allowing the creation of these artifacts using a Kubernetes native interface, together with a second use case of automating Terraform Cloud workspace and variable creation using the same Kubernetes native interface. You can read about their hopes and aspirations for this product in this article. This article also gives a good overview of how to deploy the solution into Terraform Cloud, but for a more in-depth overview meander on over to the product page for their standard “Learn Tutorial” to get an interactive getting started experience.
So how well did they meet their initial target as defined in their alpha announcement, and what improvements have been implemented in the now GA product?
What’s New
It may seem a little bit incongruous to be asking what’s new for a new product, but as with most HashiCorp products, we have seen this grow from Alpha stage to GA, so unlike a new version of SAP or other legacy waterfall-based products, it is actually a valid statement when viewed from the position of the journey they have taken.
As already alluded too, the product is still tailored to the idea of using Kubernetes Resource Definitions to manage Terraform Cloud Workspaces, it has been expanded to support several features that are available from the Terraform Cloud API. So what features from Terraform Cloud’s API have to date been integrated into the new operator.
VCS backed workspaces
One of the first steps in configuring Terraform cloud is to enable your GitOps workflow tool. By adding these API calls to the Operator you can specify your VCS configuration when synchronizing your Workspace via your custom resource configuration. There is an excellent walkthrough of this process created by HashiCorp which shows how you install and configure a custom Workspace resource that connects directly to your Terraform Cloud workspace to enable your GitOps processes here
Terraform Cloud Agents
A Terraform cloud agent allows Terraform Cloud to communicate with isolated, private or on-premises infrastructure. This is particularly useful for local infrastructures like vSphere, Nutanix and Enterprise Networking providers, or anything in a protected enclave by enabling a simple connection between your local environment and Terraform Cloud to allow provisioning and management operations.
The GA of the Terraform Cloud operator offers the ability to configure your agent pools with your Workspace’s custom resource. After creating your agent pools in Terraform Cloud and registering them, they are made available in your Workspace manifest by adding an agentPoolID to it
Secure Outputs
The initial release of the operator used ConfigMaps, but this was changed to using secrets, to align with Kubernetes expectations on how sensitive information should be stored. Now rather than using a ConfigMap when the Workspace CR is installed, you will see a secret created in the namespace with the pattern <workspace-name>-outputs, which contains the outputs of your Terraform Cloud run. One thing to note is that if you have been using an older version of the agent any previously created ConfigMaps will not be deleted by the operator and will need to be manually deleted. This is in actuality a very significant improvement from a security perspective.
Terraform Enterprise
Finally, the Operator also has support for Terraform Enterprise, by setting an optional environment variable on the operator’s deployment you can specify your Enterprise Endpoint. By default the operator uses https://app.terraform.io, but if the TF_URL environment has been set it will examine the terraformrc.credentials key for the hostname corresponding to the variable stated in TF_URL
This behavior is consistent with Terraform Cloud Enterprise Go Client. if you need any further details then refer to the values.yaml file which is part of the Helm Chart package.
How do we use it?
We are not going to look too deeply here as we have already pointed to the official documentation on how to install and use, but installation is as simple as deploying a helm chart. which is incidentally available direct from their Helm Chart repository.
Obviously either set the variable $(RELEASE_NAMESPACE) or replace the entire variable string with your value.
$ helm repo add hashicorp https://helm.releases.hashicorp.com
$ helm search repo hashicorp/terraform
$ helm install --namespace ${RELEASE_NAMESPACE} hashicorp/terraform --generate-name
Why would we use it?
This is the million-dollar question, but before we can truly answer that question, we need to understand what a Kubernetes Operator is. A Kubernetes Operator is a method of packaging, deploying, and managing a Kubernetes application. The operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and manage instances of complex applications on behalf of Kubernetes users.
Therefore, simply put what HashiCorp has actually done here is to extend Terraform Cloud into Kubernetes. So as with most things, it is all about choice and how exactly the cat is skinned to use a proverbial saying. Some people like to configure their environments via a single pane of glass. Personally; I like Native Terraform. But it only goes so far. For application configuration, you need other tools, Ansible, Puppet and Kubernetes. But for application teams that have learnt to deploy on Kubernetes, it will come as no surprise to find that they prefer to use Kubernetes to manage their environments.
The Terraform Operator allows them to control several touchpoints that were previously unavailable to them and had to be managed outside of their application.
Summary
This is an interesting product in that it runs counter-intuitively to what you would expect. HashiCorp has taken their Terraform Cloud product and wrapped it in a Kubernetes Operator, rather than subsuming Kubernetes in their environment, but this makes absolute sense when looking from the side of the application. The ability to deploy more of your application under a single workflow and more importantly, under the control of the application owners makes for a more seamless and stable deployment. From an operational perspective, you have a single pane of glass for interaction.
Like all releases, it will be improved on as it moves down the roadmap but not a bad GA product to be fair.
