Source: infoq.com. Original post date: April 16, 2020.
Overview
HashiCorp released an alpha version of the Terraform Operator for Kubernetes, enabling teams to manage infrastructure-as-code by calling Terraform Cloud directly from within a Kubernetes cluster. After installing the operator, teams can synchronize Terraform workspaces using standard Kubernetes manifests and expose Terraform outputs to applications through ConfigMaps. At the time of the alpha release, the operator was scoped exclusively to Terraform Cloud.
Why a Terraform Operator for Kubernetes?
The primary use case is for development teams who want to provision supporting infrastructure — such as an AWS SQS queue, a database, or a cache — using the same Kubernetes interface they already use to deploy applications. Rather than context-switching between Kubernetes tooling and Terraform CLI workflows, the operator brings Terraform workspace management into the Kubernetes control loop.
This approach is especially useful for platform engineering teams who want to give application developers a self-service path to infrastructure provisioning without exposing the full complexity of Terraform workflows.
Getting Started
To begin using the Terraform Operator, you need:
- A Terraform Cloud account (both free and paid tiers are supported).
- A Terraform Cloud API token created in your organization settings.
- The token stored as a Kubernetes Secret in the target namespace.
- The operator installed via Helm.
Once the operator is running, you can create, update, and delete Terraform workspaces using Kubernetes manifests, just as you would manage any other Kubernetes resource.
How It Works
Terraform Modules, Not Templates
A key design decision in the operator is that Terraform module definitions live outside the Kubernetes manifest. Developers define the module in Terraform (e.g., a module that provisions an SQS queue), and the Kubernetes manifest only supplies the input variable values for that module. This keeps manifests clean, reduces the number of Custom Resource Definitions (CRDs) needed in the cluster, and enforces a clear separation between infrastructure definition and infrastructure parameterization.
Workspace Reconciliation
The operator includes a Terraform Workspace Controller that continuously reconciles the Kubernetes workspace CRD with the corresponding workspace in Terraform Cloud. When a change is detected in a Terraform workspace object, the controller picks it up and applies it automatically using the terraform apply -auto-approve flag. Sensitive values such as AWS secret keys are excluded from this reconciliation loop.
Accessing Outputs via ConfigMaps
Once Terraform completes provisioning, the module outputs (for example, an SQS queue endpoint URL) are written to a Kubernetes ConfigMap. Application pods running in the same namespace can reference these values directly, keeping the application configuration tightly coupled with the infrastructure it depends on without requiring manual coordination.
Deleting Resources
Infrastructure lifecycle management extends to deletion. To destroy a provisioned resource, you simply delete the corresponding Kubernetes workspace object:
kubectl delete workspace sqs-queueCode language: JavaScript (javascript)The operator handles the corresponding Terraform destroy operation in Terraform Cloud.
Security Considerations
The operator is namespace-scoped by design. This limits the blast radius of any misconfiguration or compromised token. Access to Terraform Cloud is controlled via Kubernetes Secrets, and access is restricted to the namespaces where the operator is deployed. Teams can further validate changes before they are applied by integrating HashiCorp Sentinel policies within their Terraform Cloud organization.
Alpha Scope and Limitations
At the time of this alpha release, the operator supports Terraform Cloud only. Rosemary Wang, Developer Advocate at HashiCorp, explained the reasoning in a virtual office hour session:
We scoped it to Terraform Cloud usage because we wanted to make sure we understand the behavior of it and didn’t want to add too much logic into the operator.
Rosemary Wang, Developer Advocate, HashiCorp
Users of the open-source Terraform version who need support for alternative backends (such as AWS S3) were encouraged to open a GitHub issue in the operator repository describing their use case, so the HashiCorp team could evaluate community demand before expanding backend support.
On-Premises Infrastructure Support
One notable capability mentioned at the time of release is that the Terraform Operator supports provisioning infrastructure for on-premises environments, not just cloud or SaaS providers. This distinguishes it from service broker API approaches that may be limited to cloud-native or hosted services.
Summary
The HashiCorp Terraform Operator for Kubernetes brings infrastructure lifecycle management into the Kubernetes control loop, giving teams a unified interface for both application and infrastructure delivery. By leveraging existing Kubernetes primitives — Secrets, ConfigMaps, and CRDs — it integrates naturally into GitOps and platform engineering workflows. While the alpha was scoped to Terraform Cloud, the underlying pattern — declarative infrastructure managed as Kubernetes resources — represents a significant step toward converged application and infrastructure management on Kubernetes.