Cluster API für DevSecOps: Cluster-Flotten, deklariert und verteidigt

🇬🇧 Read in EnglishSeptember 17, 2026~5 min read

kubernetescluster-apidevsecopsgitopscloud-nativesecurity

August 14, 2026· ~15 min read

Kubernetes Security Tooling: Ein datengestützter Leitfaden zum Open-Source-Ökosystem im Jahr 2026

Datengestützte Untersuchung von Open-Source-Kubernetes-Security-Tools basierend auf einem Korpus von 2.080 Repositories – Scanning, Secrets, Policy, Runtime und Supply-Chain-Integrität.

kubernetessecuritytrivy

Ein Jahrzehnt lang haben wir Kubernetes beigebracht, unsere Anwendungen zu reconcilen — und haben die Cluster selbst weiterhin von Hand provisioniert und aktualisiert. Snowflake-Control-Planes, Upgrade-Runbooks mit Skip-Listen, ein Jenkins-Job von 2019, der Nodes über die Cloud-Konsole anlegt. Cluster API (CAPI) schließt diese Lücke: Sie wendet dasselbe deklarative, controller-reconcilierte Modell auf die Maschinen und Cluster an, auf denen unsere Workloads laufen. Für DevSecOps-Teams ist das mehr als Komfort — Patch-Kadenz, Drift, Supply Chain und Blast Radius werden zu Eigenschaften eines Git-Repositorys statt Stammeswissen.

Dieser Artikel betrachtet CAPI aus Security-Engineering-Sicht: Was ist das Modell, was haben die Releases 2026 (v1.12 bis v1.14) geliefert, und wie verdrahtet man Cluster-Provisionierung in eine GitOps- und Compliance-Pipeline?

Das Modell in fünf Minuten

CAPI teilt die Welt in einen Management-Cluster — ein normales Kubernetes-Cluster, das die CAPI-Controller betreibt und die Infrastruktur-Credentials hält — und die Workload-Cluster, die es als Kubernetes-Objekte anlegt und pflegt:

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

Die Kern-CRDs sind Cluster, Machine, MachineDeployment, MachineSet, KubeadmControlPlane (KCP) und MachineHealthCheck. Die Infrastruktur-Spezifika stecken hinter einem Provider-Contract — AWS, Azure, vSphere, OpenStack, Hetzner, metal3 und Dutzende mehr implementieren dieselbe API, sodass die Topologie oben portabel bleibt, während provider-spezifische CRDs die Cloud-Details tragen.

clusterctl ist das Werkzeug für Operatoren: clusterctl init installiert einen Provider in den Management-Cluster, clusterctl generate cluster rendert vollständiges YAML aus Templates, und clusterctl describe cluster liefert einen Live-Condition-Baum aller Maschinen.

Eine ClusterClass macht aus einer Cluster-Definition eine Flotten-Policy: Node-Größen, Images, Netzwerk-Plugins und Kubernetes-Versionen werden zu Feldern, die Teams setzen — alles andere ist zentral fixiert.

Was 2026 geliefert wurde: v1.12 → v1.14

Drei Releases in neun Monaten haben die Ökonomie des Flottenbetriebs verändert:

v1.12 (Januar 2026): In-Place-Updates und Chained Upgrades. Update-Extensions lassen CAPI existierende Maschinen mutieren statt sie neu anzulegen, und Chained Upgrades berechnen einen Upgrade-Plan und führen ihn in einer Operation aus — v1.35.0 auf einem v1.33.x-Cluster anzusetzen durchläuft die Minors jetzt automatisch. Die größte operative Ausrede für veraltete, verwundbare Kubernetes-Versionen ist verschwunden.
v1.13 (April 2026) und v1.14 (August 2026): Skalierung und Ergonomie. Memory-Footprint-Reduktionen der Controller, Stale-Controller-Mitigation, ClusterClass-Patches, die jetzt Metadaten (Labels/Annotations) setzen können, ein experimentelles clusterctl convert und ein separates, importierbares API-Modul.
Die API-Migrationsuhr tickt: v1beta1 ist seit v1.11 deprecated und wird in v1.16 (April 2027) nicht mehr geserved. Die Provider-Contract-Migration auf v1beta2 folgt demselben Zeitplan — prüfe jetzt den Status deines Infrastruktur-Providers, nicht erst im März 2027. Außerdem: Die Legacy-API-Ressourcen des Docker-Test-Providers fallen in v1.15 weg; CAPD bleibt Test-Provider, Punkt.

Zur Planung: Die aktuelle Support-Matrix (v1.12.11/v1.13.x) umfasst Management-Cluster auf Kubernetes v1.31–v1.36 und Workload-Cluster v1.29–v1.36.

Warum das ein DevSecOps-Control-Plane ist

Versionsaktualität als Code. Fixt ein Kubernetes-Patchrelease eine CVE, ist die Remediation ein Einzeiler im Git-Commit auf einer ClusterClass- oder Cluster-Ressource; die Controller rollen Control Planes und Worker mit derselben Sorgfalt wie bei der Erstellung. Chained Upgrades machen „die Flotte von N-2 auf aktuell heben" zu einem reviewbaren Pull Request statt einem quartalsweisen War Room.

Self-Healing-Nodes. Eine MachineHealthCheck überwacht Node-Conditions, und ungesunde Machines werden automatisch remediert — ersetzt, gedrained und wieder eingebunden von Controllern, statt dass ein Mensch drei Tage später ein NotReady-Node bemerkt:

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 und Drift-Erkennung. Die Ausgabe von clusterctl generate cluster gehört nach Git; Flux oder Argo wendet sie an — und wendet sie weiterhin an. Manuelle Cloud-Konsolen-Änderungen an einer Node-Group werden beim nächsten Reconcile zurückgesetzt. ClusterClass liefert Golden Configs; Admission-Policies auf dem Management-Cluster (ValidatingAdmissionPolicy, Kyverno) kontrollieren, was Teams deployen dürfen — nur freigegebene Kubernetes-Versionen, keine 40-Node-Cluster im Dev-Namespace.

Supply Chain. CAPIs eigene Releases sind signiert und kommen mit SBOMs — verifiziere sie. Pinne die Controller-Images, die dein Provider deployed, spiegle sie in eine private Registry für Air-gapped- oder Egress-restriktive Umgebungen und halte die cert-manager-Abhängigkeit aktuell (clusterctl pflegt sie eng; v1.12.x-Patches haben sie mehrfach angehoben).

Secrets und Identität. Bootstrap-Daten und Infrastruktur-Credentials liegen als Secrets im Management-Cluster. Skope Provider-Credentials aufs Minimum (eine Rolle, die Maschinen eines VPC anlegen darf, nicht des Accounts), bevorzuge kurzlebige Credentials und isoliere Tenants mit Namespace-pro-Team-RBAC, damit niemand die Bootstrap-Secrets eines anderen Teams lesen kann.

Blast Radius. Der Management-Cluster ist die Krone: Wer ihn kontrolliert, kontrolliert jeden Workload-Cluster, den er verwaltet. Härte entsprechend — Pod Security restricted, keine Tenant-Workloads, etcd-Verschlüsselung at rest, Audit-Logging außer Haus, und clusterctl move als kontrollierte Operation behandeln (die v1.12.x-Linie hat es eigens gehärtet).

Ein GitOps-Loop in der Praxis

# 1. Management-Cluster provisionieren (mit welchem Tool auch immer) und CAPI init
clusterctl init --infrastructure aws

# 2. Workload-Cluster aus einer ClusterClass rendern, committen
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: neues Cluster"

# 3. Flux reconcilt; beim Hochfahren zuschauen
clusterctl describe cluster payments-prod -n payments

Ab hier sind Upgrades Edits: spec.topology.version im PR anheben, Review bekommen, die Controller führen das (möglicherweise verkettete) Upgrade aus. Rollback ist git revert — und der vorherige Stand ist eine YAML-Datei, kein Screenshot.

Fallstricke

Pausierte Reconciliation. Die Annotation cluster.x-k8s.io/paused ist ein legitimes Werkzeug — und ein klassisches Sicherheitsloch, wenn jemand ein Cluster „zur Beruhigung" pausiert und der CVE-Patch nie ausgerollt wird. Alarmiere bei pausierten Ressourcen älter als eine Woche.
Der Pet-Management-Cluster. Ist der Management-Cluster handgebaut, ohne Backup und undokumentiert, ist der Recovery Point der Flotte Fiktion. Der Management-Cluster sollte selbst deklarativ provisioniert sein (er kann sich sogar selbst managen), mit geprobtem clusterctl move.
Provider-Contract-Rückstand. Der v1beta1-Provider-Contract stirbt mit der API in v1.16. Hat dein Provider v1beta2-Support noch nicht ausgeliefert, ist das dein kritischer Pfad.
Version-Skew-Spiele. Übertrette die Support-Matrix nicht; mit Chained Upgrades gibt es keinen Grund mehr dafür.
CAPD in Produktion. Der Docker-Provider ist für Laptops und CI, und seine Legacy-API-Ressourcen sind in v1.15 weg.

Fazit

Cluster API macht Cluster zu dem, was sie immer hätten sein sollen: reconcilte, reviewbare, entsorgbare State-Objekte. Die Releases 2026 haben die letzte gute Ausrede — Upgrade-Schmerz — für veraltetes Kubernetes beseitigt. Behandle den Management-Cluster wie Produktion (denn er ist es), leg jedes Cluster nach Git, und lass den Weg von CVE zum Rollout ein Commit sein statt ein Runbook.

Cart

Wishlist

Your wishlist is empty