Defence-Grade Bare-Metal Kubernetes: Air-Gap-fähig, VS-NfD

Pexon Consulting | 12 Min. Lesezeit | 11.06.2026

TL;DR

Defence-Grade Bare-Metal Kubernetes ist Pexons Antwort auf die Compliance-Anforderungen, die Hyperscaler 2026 strukturell nicht erfüllen: Dedizierte Hardware in deutschem Rechenzentrum (Standort Augsburg), Air-Gap-fähig, Hardware Root of Trust mit TPM und Confidential Computing, FIPS-140-Krypto, Zero-Trust-Netzwerk, Supply-Chain-Security mit SBOM und Image-Signing, Compliance-zertifiziert für BSI IT-Grundschutz, BSI C5, VS-NfD und NATO RESTRICTED. Für KRITIS-Betreiber, Defence-Anbieter und Hochsicherheits-Workloads, bei denen Public-Cloud strukturell nicht in Frage kommt.

Warum Hyperscaler für Defence und höchste KRITIS-Stufe nicht reichen

Wir haben das in den letzten zwölf Monaten mehrfach erlebt: Eine Defence-Tech-Firma oder ein KRITIS-Betreiber wollte AI-Workloads auf Azure oder AWS deployen — die Compliance-Abteilung sagte nein. Beide Hyperscaler haben EU-Regionen mit DSGVO-tragfähigem Setup. Aber für VS-NfD-eingestufte Daten, NATO RESTRICTED oder die strikteste KRITIS-Tier-1-Klasse reicht das nicht. Der US-CLOUD-Act bleibt strukturell ein Risiko, das in den Compliance-Verträgen nicht weg-juristiert werden kann. Kundenreferenz: Kubernetes Multi-Cloud in 25 Monaten

Was diese Kunden brauchen, ist eine Plattform, die strukturell anders aufgebaut ist. Nicht „Cloud mit besseren Verträgen“ — sondern Bare-Metal-Hardware in deutschem Rechenzentrum, ohne juristische Reichweite ausländischer Behörden, mit nativer Air-Gap-Fähigkeit für die strengsten Workloads. Pexon Consulting bietet diese Plattform seit Anfang 2026 als „AI lokal Layer 1 — Defence-Grade Compute“ an, gehostet im eigenen Rechenzentrum in Augsburg.

Das ist nicht „noch ein Cloud-Pfad“. Das ist die strukturelle Antwort auf die Workloads, die in den nächsten 36 Monaten zwischen Defence-AI, KRITIS-Hochsicherheit und VS-NfD-Geheimschutz nicht in Hyperscaler-Cloud wandern werden — und trotzdem moderne KI-Workloads brauchen.

Die sechs Säulen der Defence-Grade-Plattform

Säule 1: Bare-Metal Kubernetes. Keine Virtualisierungs-Schicht zwischen Workload und Hardware. K8s läuft direkt auf der physischen Maschine, mit voller Kontrolle über CPU, Memory, Netzwerk und Storage. Wir bauen typisch mit Talos Linux als hardened K8s-Distribution, plus dedizierte GPU-Server für AI-Workloads (H100, H200, L40S je nach Workload-Profil). Performance-Vorteil gegenüber virtualisierten Setups: typisch 8-15% bessere AI-Inferenz-Throughput, weil keine Hypervisor-Steuer.

Säule 2: Air-Gapped Betrieb. Die Plattform kann vollständig vom Internet isoliert werden — kein eingehender oder ausgehender Traffic über öffentliche Netze. Updates erfolgen über einen kontrollierten Update-Pfad mit Image-Sneakernet (USB-Token mit verifizierten Image-Bundles). Für Workloads, die selten oder nie online sind, ist das die einzige strukturell saubere Antwort.

Säule 3: Hardware Root of Trust. Jeder Server hat ein TPM 2.0, das den Boot-Prozess attestiert. Confidential Computing (Intel TDX, AMD SEV-SNP) sorgt dafür, dass Memory-Inhalte selbst gegen Root-User auf dem Host-System geschützt sind. FIPS-140-Krypto-Module für alle Verschlüsselungs-Operationen. Das schließt eine Angriffsklasse aus, die in Standard-Cloud-Setups offen bleibt.

Säule 4: Zero Trust Network. mTLS zwischen allen Services, Mikrosegmentierung mit Cilium Network Policies, Policy-Enforcement über Open Policy Agent. Kein Service spricht mit einem anderen ohne explizite Erlaubnis. Bei einem Compromise eines Pods ist der Blast Radius minimiert.

Säule 5: Supply Chain Security. Jedes Container-Image wird signiert (Sigstore Cosign), mit SBOM (Software Bill of Materials) versehen, vor Deploy gegen Vulnerability-Datenbank gescannt. GitOps-Workflow mit Argo CD plus signiertes Commit-Verifikation. Bei Boot wird jede Software-Komponente gegen die Attestation geprüft — Manipulationen im Build oder Deploy fallen auf.

Säule 6: Hardened Runtime. Hosts laufen mit CIS-Benchmark-Hardening, Falco für Runtime-Security-Monitoring, Audit-Logs in dediziertem Log-Workspace. Jede privilege escalation, jeder unerwartete Netzwerk-Aufruf, jeder File-System-Zugriff außerhalb des erwarteten Patterns triggert einen Alert.

Air-Gapped Betrieb in der Praxis

Air-Gap klingt einfach — „Stecker raus“ — ist aber ein konkretes Engineering-Pattern. Wir bauen das in drei Phasen.

Phase 1: Vorbereitete Image-Bundles. Alle Container-Images, K8s-Updates, OS-Patches, Modell-Binaries werden in einem dedizierten Build-System gebaut, signiert, in Tarballs gebündelt. Diese Bundles sind die einzige Quelle für Software-Änderungen auf der Air-Gap-Plattform.

Phase 2: Kontrollierter Transport. Bundles werden auf verifizierte Hardware-Token (verschlüsselte USB-Sticks oder geprüfte Optical Media) übertragen, mit dokumentiertem Chain-of-Custody — wer hat wann was übertragen. Im Hochsicherheits-Setup ist das ein zwei-Augen-Prinzip mit Audit-Trail.

Phase 3: Verifizierter Import. Auf der Air-Gap-Plattform werden die Bundles über ein dediziertes Import-Tool geprüft (Signatur, SBOM, Vulnerability-Status), dann in die interne Container Registry und K8s-Cluster eingespielt. Automatisierter Rollback bei Fehler-Verifikation.

Bei einem KRITIS-Pilotkunden haben wir diesen Workflow für monatliche Update-Zyklen implementiert. Update-Bundle-Größe typisch 8-15 GB pro Monat, Import-Zeit 25-45 Minuten, vollautomatischer Rollback bei Verifikations-Fehler.

Hardware Root of Trust und Confidential Computing

Confidential Computing ist die Schlüssel-Technologie, die 2026 zwischen „regulierte Workloads“ und „vollständig souverän“ entscheidet. Intel TDX und AMD SEV-SNP verschlüsseln Memory-Inhalte mit einem CPU-internen Schlüssel, sodass selbst Root auf dem Host-System die laufenden Workloads nicht inspizieren kann.

Konkret in unserer Plattform: Jeder Workload läuft in einer Confidential VM oder Confidential Container. Beim Boot wird die Software-Konfiguration gegen das TPM attestiert — Hardware bestätigt: „Auf diesem Server läuft genau diese Software-Version, kein Tampering“. Die Workload bekommt ihre Encryption-Keys erst, wenn die Attestation erfolgreich ist.

Für LLM-Workloads mit VS-NfD-eingestuften Daten heißt das: Selbst ein Insider mit Root-Access auf dem K8s-Cluster kann die Prompt- und Response-Inhalte nicht sehen. Das ist eine strukturelle Garantie, die in Standard-Cloud-Setups nicht zu haben ist.

Compliance-Mapping: BSI, NATO, NIS2

Die Plattform ist gegen mehrere Compliance-Frameworks gleichzeitig zertifiziert oder zertifizierungsfähig.

BSI IT-Grundschutz. Vollständige Abdeckung der relevanten Bausteine (INF, NET, SYS, APP, OPS). Standard-Sicherheits-Niveau plus erhöhter Schutzbedarf für die Air-Gap-Konfiguration.

BSI C5. Cloud Computing Compliance Criteria Catalogue. Testat-fähig für die Plattform-Komponenten, was die Aufnahme in regulierte Mittelständler erleichtert.

VS-NfD. „Verschlusssache, nur für den Dienstgebrauch“. Verfahrens-Zulassung des BSI nach VSA. Damit nutzbar für Workloads von Bundesbehörden und KRITIS-Betreibern mit VS-NfD-Klassifikation. Mehr im VS-NfD-Doku-Workflow-Blog.

NATO RESTRICTED. Für NATO-relevante Workloads. Zulassung läuft über die nationalen NATO Information Assurance Authorities (in Deutschland BSI/NIASB).

NIS2 / KRITIS. EU-NIS2-Richtlinie und KRITIS-Dachgesetz-Anforderungen. Architektur und Prozesse sind auf NIS2-konforme Betreiber-Pflichten ausgerichtet.

Bei jeder Compliance-Reise begleiten wir den Kunden durch den jeweiligen Audit-Prozess — die Plattform ist die technische Grundlage, der formale Auditprozess liegt beim Kunden mit unserer technischen Unterstützung.

Hosting in Augsburg

Die Plattform wird in einem Rechenzentrum in Augsburg betrieben. Pexon hat dort Hardware-Kapazitäten für Defence- und KRITIS-Kunden, mit klarer Trennung zwischen Customer-Workloads (separate Pods, separate Hardware-Zonen, separates Netzwerk-Segmentierung pro Kunde).

Standort-Details: Tier-3-Datacenter, redundante Stromversorgung, Klimatisierung mit N+1, biometrische Zugangskontrolle, 24/7-Security-Personal, BSI-zertifiziertes Datacenter-Provider-Niveau. Hardware-Lebenszyklus von der Beschaffung bis zur sicheren Vernichtung dokumentiert.

Für Kunden, die maximale Souveränität wollen: Eigene physische Rack-Bereiche mit eigenen Sicherheits-Plomben. Hardware-Vernichtung am Lebensende dokumentiert und auditierbar.

Häufig gestellte Fragen

Wie unterscheidet sich das von einer normalen On-Prem-Installation beim Kunden?

Unterschied ist das Operations-Modell. On-Prem beim Kunden bedeutet, dass der Kunde Hardware, Patching, Monitoring, Compliance-Pflege selbst macht — oft fehlt dafür die Engineering-Kapazität. Bei der Pexon-Plattform übernehmen wir den operativen Betrieb (Updates, Hardening, Monitoring, Compliance-Pflege), der Kunde nutzt die Plattform als Service. Skalierbar für Kunden, die keinen vollen Infrastruktur-Bereich aufbauen wollen.

Können wir auch unsere eigene Hardware mitbringen?

Ja, Bring-Your-Own-Hardware ist eine Variante. Wir nutzen eure Server, betreiben darauf unsere Plattform-Software, übernehmen den Operations-Vertrag. Das ist die richtige Variante, wenn ihr ohnehin Hardware-Investitionen plant oder spezifische Server-Modelle nutzen wollt.

Wie verhält sich die Plattform mit den Hyperscaler-Modellen?

Frontier-Closed-Models (Claude, GPT, Gemini) laufen strukturell nicht auf Bare-Metal-Plattformen — sie sind Provider-only. Wir betreiben Open-Source-Modelle (Qwen 3.5, Llama 3.3, Mistral) auf der Plattform. Qualität liegt 8-15 Prozentpunkte unter Frontier-Niveau, ist für Defence-Use-Cases mit strukturierten Tasks aber typisch ausreichend. Mehr zum Self-Hosted Agent Stack.

Was kostet das laufend?

Hochabhängig von Hardware-Bedarf und Service-Level. Hausnummer für einen mittleren Defence-Setup mit 2x H100 plus 3-Node-K8s-Cluster: 18.000-32.000 EUR pro Monat Hosting plus Operations. Bei Bring-Your-Own-Hardware deutlich günstiger (Operations-Only). Konkretes Angebot nach Workshop.

Wie kommen wir an die Plattform für eine NDA-pflichtige Evaluierung?

Wir starten mit einem 90-Minuten-Vorgespräch unter NDA. Wenn der Use-Case zur Plattform passt, machen wir einen ein-Tages-Architektur-Workshop und liefern Setup-Angebot. Erste produktive Workloads laufen typisch 8-16 Wochen nach Vertragsabschluss.

Nächster Schritt

Wenn dein Unternehmen Defence-AI-Workloads, NATO-relevante Anwendungen oder die strengste KRITIS-Tier-1-Compliance braucht: Wir machen einen 60-Minuten-Erstgespräch unter NDA mit dir und idealerweise dem CISO oder Compliance-Verantwortlichen. Du beschreibst den Use-Case und die Compliance-Lage, wir skizzieren die Plattform-Architektur mit konkretem Angebot.

Verwandte Themen