Cloud-native vs On-Premise in regulierten Branchen: Muster statt Dogmen

Problem zuerst: In sicherheitskritischen und regulierten Umgebungen zählen Datenhoheit, Auditierbarkeit und kontrollierte Betriebsbedingungen mehr als bunte Cloud-Diagramme. Der Effekt in der Praxis: Viele moderne Architektur- und Betriebsprinzipien sind hochrelevant (deklarativ, automatisiert, beobachtbar), aber die klassische Interpretation „läuft in einer US‑Hyperscaler‑Region, skaliert unendlich und bezieht zehn externe SaaS‑Dienste“ ist schlicht nicht zulässig. Wer hier Cloud-native ernst nimmt, übersetzt Prinzipien in on-premise-fähige Muster – inklusive Air-Gap, Härtung, reproduzierbaren Builds, stabilem Lifecycle über 10+ Jahre und dem Verzicht auf intransparente Abhängigkeiten.

Dieser Beitrag beschreibt erprobte Architektur- und Betriebs-Patterns, konkrete Technologie-Entscheidungen, Trade-offs und Anti-Patterns aus Projekten in Defense, Railway, Manufacturing und Aviation. Kein Hype, kein „one-size-fits-all“ – sondern ein Baukasten, der unter DSGVO, (teilweiser) Air-Gap und strengen Qualitätssicherungs-Anforderungen funktioniert.

Was „Cloud-native“ on-prem wirklich bedeutet

Cloud-native ist kein Ort, sondern ein Arbeitsmodus:

  • Deklarativ statt klickbunt: Infrastruktur, Plattform und Anwendungen werden als Code versioniert und ausgerollt.

  • Immutable und reproduzierbar: Artefakte sind deterministisch baubar; Laufzeitumgebungen werden nicht manuell verbogen.

  • Beobachtbar und testbar: Telemetrie, Traces, Metriken und Policies sind erste Bürger.

  • Lose gekoppelt, aber nicht zwangsläufig 50 Microservices: Entkopplung entlang klarer Domänen, erst dann Service-Schnitt.

Übertragen auf on-prem heißt das: Wir bauen eine Plattform, die diese Eigenschaften ohne externe Cloud-Abhängigkeit liefert – inklusive GPU‑Support, Netzwerksegmentierung, Identitäten, Artefakt- und Policy-Management, Telemetrie und ML/LLM‑Betrieb.

Anforderungsprofil in regulierten Branchen

Typische harte Randbedingungen:

  • Datenhoheit und Zweckbindung: Keine Abflüsse in Drittstaaten, nachvollziehbare Datenflüsse, Datenminimierung.

  • Latenz und Verfügbarkeit: Realtime‑Teile mit deterministischer Latenz; Offline‑Fähigkeit bei WAN‑Ausfall.

  • Auditierbarkeit: Vollständige Revisionsspur, reproduzierbare Builds, attestierbare Artefakte, SBOM.

  • Air-Gap-Varianten: Vom „tight control outbound only“ bis „physisch getrennt, nur signierte Offline‑Updates“.

  • Lebenszyklus >10 Jahre: Austauschbare Komponenten, wartbare Toolchains, konservative Upgrades.

  • Sicherheit by default: Verschlüsselung in Ruhe und Transit, mTLS intern, minimale Angriffsflächen.

  • Keine US‑Cloud‑Abhängigkeit: Keine Kontroll- und Zugriffsmöglichkeiten Dritter außerhalb EU‑Rechtsrahmen.

Architekturprinzipien: Muster statt Dogmen

1) „Cloud-native on-prem“-Plattform

  • Container-Orchestrierung: Kubernetes on-prem als Standard, aber bewusst dimensioniert. Für Edge‑Nodes K3s/MicroK8s; im Rechenzentrum Upstream K8s mit Distribution (z. B. RKE2, OpenShift) je nach Governance- und FIPS‑Bedarf.

  • GitOps statt ClickOps: Argo CD oder Flux. Für Air‑Gap werden Repos gespiegelt; Deployments aus signierten, geprüften Artefakten.

  • Artefakt- und Registry-Management: Private OCI‑Registry (Harbor, Quay) inkl. vulnerabilitäts-scans, policy enforcement und Notary/cosign‑Signaturen. Für Air‑Gap: Offline‑Mirror und kuratierte Base‑Images.

  • Identitäten und Zugriffe: Keycloak/AD on‑prem, SCIM‑Provisionierung, OIDC für Services, RBAC bis auf Namespace‑Ebene. Notfallpläne bei IdP‑Ausfall.

  • Netzwerk und Isolierung: eBPF‑CNI (z. B. Cilium) mit NetworkPolicies; mTLS zwischen Services (SPIFFE/SPIRE) statt „Flat VLAN“. Service Mesh nur, wenn nötig – Linkerd mit FIPS-Builds ist oft leichter als Istio.

  • Observability: OpenTelemetry Collector, Prometheus, Tempo/Jaeger, Loki, Grafana – alles on‑prem. Mandantenfähigkeit und Datenklassifikation für PII/PIA beachten.

2) Daten- und Sicherheits-Governance

  • Verschlüsselung: At-rest via dm-crypt/LUKS/SEDs, In-Transit via TLS 1.3/mTLS, Secret‑Management via Vault (HSM‑gestützt, wenn verfügbar).

  • SBOM und Supply Chain: Jede Komponente mit SBOM (Syft), Scans offline (Trivy/Grype Mirror), Signaturen (cosign) und attestierte Builds (SLSA‑Prinzipien mit on‑prem CA).

  • Policy Enforcement: Admission Controller (OPA Gatekeeper/Kyverno) erzwingen Labels, Ressourcenlimits, Rootless‑Container, Non‑latest Tags, approved Registries.

3) Event- und Datenflüsse

  • Messaging: NATS/Kafka je nach Latenz/Throughput; für Edge Sites NATS Leafnodes. Backpressure und Offline‑Puffer sind Pflicht.

  • Datenhaltung: Postgres (replikationsfähig, Patroni), Timeseries (VictoriaMetrics/Influx), Objektspeicher (MinIO) für Modelle und Artefakte. Klare Regeln für PII‑Isolation.

4) Betriebsprozesse

  • Change windows und progressive delivery: Blue/Green oder Canaries (Argo Rollouts/Flagger), auch on‑prem. Minimaler Blast Radius.

  • Runbooks und Drills: Etcd‑Backups, Registry‑Restore, Air‑Gap‑Update-Prozeduren regelmäßig testen.

  • Monitoring SLOs: Greifbare SLOs statt Wunschdenken: z. B. P99‑Latenz für Inferenz, Rebuild‑Zeit für Node, MTTR für IdP.

Kubernetes on-prem: Varianten und Trade-offs

  • Upstream K8s + RKE2/kubeadm:

Vorteile: Nah am Standard, flexibel, gute Air‑Gap‑Stories.
Nachteile: Mehr Betriebsverantwortung, Security‑Härtung in eigener Hand.

  • OpenShift:

Vorteile: Integrierte Security/Quotas/Operator‑Ökosystem, FIPS‑Optionen.
Nachteile: Lizenzkosten, Komplexität, eingeschränktere Freiheit.

  • K3s/MicroK8s:

Vorteile: Leichtgewichtig, Edge‑tauglich, kleiner Footprint.
Nachteile: Grenzen bei Multi‑Tenancy/Komplexität, weniger Enterprise‑Plugins.

  • Ohne Kubernetes?

Für klar abgegrenzte Workloads kann systemd‑nspawn/Podman mit Nomad ausreichend sein. Faustregel: Wenn Sie mehr als 5‑8 Services, Liveness-/Readiness‑Checks, Secrets‑Rotation und Rolling‑Updates brauchen, zahlt sich K8s meist aus.

Air-Gap-fähige Software-Lieferkette

  • Quellspiegel: Interne Mirrors für Git, Container‑Images, PyPI, apt/yum, Helm Charts. Nur kuratierte Upstream‑Fenster.
  • Reproduzierbare Builds: Pinned Versions, Lockfiles, hermetische Builder (Bazel/Nix optional), deterministische Build‑Container.
  • Signaturen und Policies: cosign‑Signaturen aus HSM‑Keys; Admission Policies blocken unsignierte Artefakte.
  • Vulnerability-Scans offline: Spiegel der CVE‑Datenbanken, tägliche Aktualisierung über offline‑Sync, Reports in CI gatekeepen Releases.
  • SBOM first: Syft/Anchore generieren SBOM pro Image; Abgleich gegen erlaubte Lizenzen und CVEs als Pipeline‑Gate.

Identität und Zugriffskontrolle ohne SaaS

  • IdP: Keycloak on‑prem mit FIPS‑Krypto und Offline‑Backup. Integration mit Active Directory. MFA über lokale Token‑Server.
  • Service‑Identität: SPIFFE/SPIRE, automatische Zertifikatsrotation, Workload‑Identity ohne statische Secrets.
  • Autorisierung: RBAC für Cluster, OPA Policies für Anwendungsrollen, Audit‑Logs zentral gesammelt und unveränderlich abgelegt (WORM‑Storage).