Terraform defines desired state. Kubernetes reconciles workload state. Cloud consoles expose state. None of those systems decides whether infrastructure state is allowed to change. The CI-CD pipeline does — or more precisely, the CI-CD pipeline is the only system in most environments that can hold that authority. That distinction — between storing state and having authority over state change — is the one most infrastructure teams haven't made explicitly. It's the gap that explains where drift originates, why security posture degrades without a visible trigger, and why "we have IaC" and "we have control" are not the same statement.
Automation is not authority. A pipeline that automates deployment is not automatically a control plane. It becomes one when infrastructure cannot change without it. Most pipelines are on the wrong side of that line — fast, convenient, and bypassable by anyone with cloud console access or a local Terraform install. That is a deployment tool with an opt-in usage policy, not a control plane.
What a Control Plane Actually Is
A control plane is not the system that stores state. It is the system that has authority over state change.
That definition changes the answer to a question most infrastructure teams think they've already answered. Terraform manages state, but apply authority belongs to whoever runs it — a developer's local terminal, a shared CI runner, a manually triggered workflow. The authority is in the hands holding the keyboard, not in the tool. Kubernetes has genuine reconciliation authority over workload state within the cluster, but it has no authority over the infrastructure beneath it. The cloud console has no authority at all in the architectural sense: it exposes every possible change to anyone with sufficient IAM permissions, enforces no policy, applies no approval gate, and produces an audit log that records what happened without recording whether it was supposed to.
What a CI-CD Control Plane Actually Does
Four functions define a control plane. The question for any system is which of those four it actually performs — and whether it performs them with authority or just with access.
| Function | Terraform alone | Kubernetes alone | CI-CD pipeline |
|---|---|---|---|
| Observes current state | Partial — declared state + provider read | Yes — cluster state via etcd | Yes — if designed for drift detection |
| Evaluates desired vs current | Yes — plan | Yes — reconciliation loop | Yes — pre-flight and policy checks |
| Enforces delta | Yes — apply | Yes — controller | Yes — pipeline execution |
| Gates who has authority to trigger enforcement | No | No | Yes — if designed for it |
The pipeline's fourth row is the one that matters. Gating who has authority to trigger enforcement is what separates a deployment tool from a control plane.
Four Ways Pipelines Fail as Control Planes
The failures are the defaults — the way pipelines are configured when nobody has explicitly designed them as control planes.
01 — Pipeline is bypassed. Console changes, terraform apply from a local machine, kubectl exec into a production pod — every manual change is a control plane failure. Drift doesn't originate from incorrect IaC. It originates from changes the pipeline never saw.
02 — Pipeline enforces syntax, not policy. A pipeline that validates HCL and runs terraform plan is a linter with deployment privileges. A control plane enforces policy: no public IPs in regulated environments, required tagging, approved image registries, quota constraints. Without policy at the gate, the IaC can be correct and the architecture still wrong.
03 — Pipeline is a single lane. No environment promotion gates, no approval workflow, no blast radius containment between dev and production. A bad merge or credential compromise affects every environment simultaneously.
04 — Pipeline has no memory. Most pipelines are stateless executors. They know what was deployed, when, and by whom. They don't know what exception was approved, what policy was waived, or why the previous rollback happened. A control plane without operational memory executes state transitions without context.
⚠ Common mistake: A pipeline that can be bypassed isn't a control plane. It's a deployment tool with an opt-in usage policy.
Designing the Pipeline as the Authority
Four requirements. None require a specific toolchain. All require an explicit architectural decision.
Pipeline-as-the-only-path — including break-glass. Every change goes through the pipeline. Break-glass is not an exception to the control plane — it is a controlled path with elevated requirements: separate approval tier, scoped credential set, automatic incident logging. Emergencies require more rigorous tracking, not less.
Policy at the gate, not at the dashboard. OPA/Conftest, Sentinel, or Checkov runs before apply as a blocking step. A monitor records what happened. A gate determines what is allowed to happen.
Environment promotion with explicit gates. Dev → staging → production is not automatic. Each promotion has its own approval requirement, policy check, and blast radius boundary.
Operational memory built in. Pipeline execution context is stored and queryable: what changed, who approved it, what policy checks passed, what exceptions were granted and under what authority.
The Highest-Privilege System You're Not Treating That Way
Most environments treat the cloud account as the highest-privilege boundary. It usually isn't. The CI-CD system is.
The pipeline holds credentials to every cloud provider account, every Kubernetes cluster, every deployment target simultaneously. It can mutate every environment. It is reachable from developer identity. And it is frequently governed less carefully than the production environment it manages: secrets stored as environment variables rather than federated tokens, service accounts that don't rotate, pipeline configs any repository contributor can modify.
A compromised CI-CD system is not a compromised deployment tool — it is a compromised control plane with credentials to the entire infrastructure estate. OIDC federation eliminates the static secret surface. Least-privilege service accounts scoped per environment limit blast radius. Audit logging on every execution — including failed runs and bypassed gates — makes lateral movement visible.
Diagnostic: "Is your CI-CD system governed to the same standard as the production environment it can modify?"
Architect's Verdict
The teams treating IaC tooling as the infrastructure control plane have correctly identified where state is managed and misidentified where authority lives. Terraform does not decide whether a change is allowed. Kubernetes does not decide whether the infrastructure beneath it can be modified. The CI-CD pipeline is where infrastructure change authority actually lives — or in most environments, where it lives nowhere in particular, which is how drift accumulates, blast radius grows, and security posture degrades without a specific incident to point to.
Most pipelines were built as deployment automation and inherited control plane responsibilities they were never designed to carry. A system that can be bypassed by anyone with console access, enforces no policy beyond syntax validation, retains no operational memory, and is governed less carefully than the environments it manages is not a control plane. It is a convenient path that anyone with sufficient access can walk around.
Automation is not authority. The pipeline becomes a control plane the day infrastructure cannot change without it.
Originally published at rack2cloud.com
Top comments (0)