Control planes in BigConfig

Oct 29, 2025

A control plane acts as an API for provisioning and managing infrastructure. Well-known examples include AWS itself and Kubernetes (K8s).

A common pain point when using infrastructure-as-code (IaC) tools like Terraform (using HCL) and GitOps is the difficulty in transitioning or upgrading to an internal control plane. Teams that have invested significant time in writing Terraform’s HCL code traditionally face a complete rewrite to build a custom control plane API over their existing infrastructure definitions.

Transforming Terraform into a Control Plane

This limitation is no longer the case with BigConfig. We’ve demonstrated that a functional control plane can be created with as little as 200 lines of code, leveraging existing Terraform configurations.

Example Scenario: Secure AWS IAM User Management

Consider the need to create a control plane for managing AWS users. Directly exposing the comprehensive IAM API to engineers is a security risk and the GitOps approach is not scaling. Instead, a minimal API is required that allows engineers to only create, delete, and rename users.

The Key to Bridging the Gap

The secret to transforming any Terraform code into a control plane lies in how Terraform manages resource identifiers:

Terraform HCL Specification: Resources are defined with the syntax resource "<TYPE>" "<LABEL>". The <LABEL> is a static, user-defined identifier that acts as a primary key within the configuration file.
Terraform State: The Terraform state file maintains a crucial mapping between this static HCL <LABEL> and the actual primary key used by the cloud provider (e.g., the ARN in AWS).
Control Plane Requirement: In a control plane, the list of managed resources is dynamic, not static like in an HCL file. To function correctly, the equivalent of the Terraform <LABEL> must be persisted between invocations and generated automatically by the control plane logic, effectively mimicking the role of the HCL file’s label but in a dynamic context.

BigConfig addresses this by programmatically managing this dynamic labeling and state mapping, enabling the existing Terraform code to be driven by a new, restrictive, and secure API—the control plane.

Try the Control Plane CLI Locally

You can test this powerful concept right now, even without an AWS account:

Install the Control Plane CLI:

clojure -Ttools install big-config/control-plane '{:git/sha "aff7c186999c19ad2b4f07752abd13ec5b3b6651" :git/url "https://github.com/amiorin/big-config.git"}' :as ctlp

Create a convenient alias:
Terminal window
```
alias p="clojure -Tctlp"
```
Show the help
Terminal window
```
p help
```
Define a new user via the API (CLI) :
Terminal window
```
p create-user :name '"alice"'
```

Like any control plane, it maintains a desired state (saved locally). Let’s inspect the Control Plane State (not the Terraform state):

p print-state

The output shows how the user is now managed by a random UUID that is persisted across commands:

{:region "eu-west-1",
 :aws-account-id "251213589273",
 :module "users",
 :users {#uuid "ee39e089-9697-4db9-80d9-c931af720535" "alice"},
 :target-dir "dist"}

Finally, apply this desired state to your infrastructure using standard Terraform/OpenTofu commands:

# Run tofu plan
p diff-state

# Run tofu apply
p apply-state

This dynamic state management is powered by the Prevalent System design pattern and uses pure functions to handle state logic. You can explore the implementation details in the GitHub repository.

Show me the code

Conclusion

Terraform remains the go-to tool for modern DevOps and infrastructure management. While some platform teams have attempted to replace it with control planes, this demonstration showed the true strength of Terraform: its ability to abstract the low-level cloud provider APIs. This capability actually makes control plane implementation faster and more efficient rather than competing with it.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.