Cluster API for DevSecOps: fleets of clusters, declared and defended

We spent a decade teaching Kubernetes to reconcile our applications — then kept provisioning and upgrading the clusters themselves by hand. Snowflake control planes, skip-list upgrade runbooks, a Jenkins job from 2019 that creates nodes via cloud console. Cluster API (CAPI) closes that gap: it applies the same declarative, controller-reconciled model to the machines and clusters that run our workloads. For DevSecOps teams this is more than convenience — patch cadence, drift, supply chain, and blast radius all become properties of a Git repository instead of tribal knowledge.

This article looks at CAPI through a security-engineering lens: what the model is, what the 2026 releases (v1.12 through v1.14) shipped, and how to wire cluster provisioning into a GitOps and compliance pipeline.

The model in five minutes

CAPI splits the world into a management cluster — a normal Kubernetes cluster running the CAPI controllers and holding the infrastructure credentials — and the workload clusters it creates and maintains as Kubernetes objects:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: payments-prod
  namespace: payments
spec:
  topology:
    class: production-v1 # ClusterClass: the golden template
    version: v1.36.3
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - name: workers
          replicas: 6

The core CRDs are Cluster, Machine, MachineDeployment, MachineSet, KubeadmControlPlane (KCP), and MachineHealthCheck. Infrastructure specifics live behind a provider contract — AWS, Azure, vSphere, OpenStack, Hetzner, metal3 and dozens more implement the same API, so the topology above stays portable while DockerMachine-style provider CRDs carry the cloud details.

clusterctl is the operator's tool: clusterctl init installs a provider into the management cluster, clusterctl generate cluster renders full YAML from templates, and clusterctl describe cluster gives you a live condition tree of every machine.

A ClusterClass turns one cluster definition into a fleet policy: node sizes, images, network plugins, and Kubernetes versions become fields your teams set — everything else is pinned centrally.

What 2026 shipped: v1.12 → v1.14

Three releases in nine months changed the economics of running a fleet:

• v1.12 (January 2026): in-place updates and chained upgrades. Update extensions let CAPI mutate existing Machines instead of recreating them, and chained upgrades compute an upgrade plan and execute it in one operation — declaring v1.35.0 on a v1.33.x cluster now walks the minors for you. The single biggest operational excuse for running outdated, vulnerable Kubernetes just disappeared.
• v1.13 (April 2026) and v1.14 (August 2026): scale and ergonomics. Memory-footprint reductions for the controllers, stale-controller mitigation, ClusterClass patches that can now set metadata labels/annotations, an experimental clusterctl convert, and a separate, importable API module.
• The API migration clock: v1beta1 is deprecated since v1.11 and will stop being served in v1.16 (April 2027). The provider contract migration to v1beta2 is on the same schedule — check your infrastructure provider's status now, not in March 2027. Note also that the Docker test provider's legacy API resources are removed in v1.15; CAPD remains a test provider, full stop.

For planning purposes, the current support matrix (v1.12.11/v1.13.x) spans management clusters on Kubernetes v1.31–v1.36 and workload clusters v1.29–v1.36.

Why this is a DevSecOps control plane

Version currency as code. When a Kubernetes patch release fixes a CVE, your remediation is a one-line Git commit on a ClusterClass or Cluster resource; the controllers roll control planes and workers with the same care they use for creation. Chained upgrades make "jump the fleet from N-2 to current" a reviewable pull request rather than a quarterly war room.

Self-healing nodes. A MachineHealthCheck watches node conditions and unhealthy Machines get remediated automatically — replaced, drained, and rejoined by controllers instead of a human noticing a NotReady node three days later:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: workers-mhc
spec:
  clusterName: payments-prod
  maxUnhealthy: 40%
  unhealthyConditions:
    - type: Ready
      status: "False"
      timeout: 10m
    - type: Unknown
      status: Unknown
      timeout: 10m

GitOps and drift detection. clusterctl generate cluster output belongs in Git; Flux or Argo applies it and keeps applying it. Manual cloud-console changes to a node group get reverted on the next reconcile. ClusterClass gives you golden configurations; admission policies on the management cluster (ValidatingAdmissionPolicy, Kyverno) gate what teams may deploy — approved Kubernetes versions only, no 40-node clusters in the dev namespace.

Supply chain. CAPI's own releases are signed and shipped with SBOMs — verify them. Pin the controller images your provider deploys, mirror them into a private registry for air-gapped or egress-restricted environments, and keep the cert-manager dependency current (clusterctl tracks it closely; v1.12.x patches bumped it repeatedly).

Secrets and identity. Bootstrap data and infrastructure credentials live as Secrets in the management cluster. Scope provider credentials to the minimum (a role that can create one VPC's machines, not the account), prefer short-lived credentials, and isolate tenants with namespace-per-team RBAC so no one else can read another team's bootstrap secrets.

Blast radius. The management cluster is the crown jewel: whoever controls it controls every workload cluster it manages. Harden accordingly — Pod Security restricted, no tenant workloads, etcd encryption at rest, audit logging shipped off-cluster, and treat clusterctl move as a controlled operation (the v1.12.x line specifically hardened it).

A worked GitOps loop

# 1. Provision the management cluster (any tool) and init CAPI
clusterctl init --infrastructure aws

# 2. Render the workload cluster from a ClusterClass, commit it
clusterctl generate cluster payments-prod \
  --kubernetes-version v1.36.3 \
  --control-plane-machine-count 3 \
  --worker-machine-count 6 > clusters/payments-prod.yaml
git add clusters/payments-prod.yaml && git commit -m "payments-prod: new cluster"

# 3. Flux reconciles it; watch the fleet come up
clusterctl describe cluster payments-prod -n payments

From here, upgrades are edits: bump spec.topology.version in the PR, get a review, let the controllers execute the (possibly chained) upgrade. Rollback is git revert — and the previous state is a YAML file, not a screenshot.

Pitfalls

• Paused reconciliation. The cluster.x-k8s.io/paused annotation is a legitimate tool — and a classic security hole when someone pauses a cluster to "stabilize" it and the CVE patch never rolls out. Alert on paused resources older than a week.
• The pet management cluster. If the management cluster is hand-built, unbacked-up, and undocumented, your fleet's recovery point is fiction. The management cluster should itself be declaratively provisioned (it can even be self-managed), with clusterctl move rehearsed.
• Provider contract lag. The v1beta1 provider contract dies with the API in v1.16. If your provider hasn't shipped v1beta2 support, that's your critical path.
• Version skew games. Don't outrun the support matrix; with chained upgrades there is no longer a reason to.
• CAPD in production. The Docker provider is for laptops and CI, and its legacy API resources are gone in v1.15.

Take

Cluster API makes clusters what they should have been all along: reconciled, reviewable, disposable state. The 2026 releases removed the last good excuse — upgrade pain — for running stale Kubernetes. Treat the management cluster like production (because it is), put every Cluster in Git, and let the CVE-to-rollout path be a commit instead of a runbook.

Further reading

• Cluster API – Quick Start & Concepts
• Cluster API v1.12: In-place Updates and Chained Upgrades (kubernetes.io blog)
• Version support matrix (Cluster API Book)
• kubernetes-sigs/cluster-api releases