.png){kind=logo}
Kubernetes, bei dem der Cluster-Admin draußen bleibt
Eine einfach integrierbare Confidential Runtime für Kubernetes: Pods laufen in hardwaregeschützten Enklaven, die Control Plane wird in einer vertrauenswürdigen Umgebung ausgeführt und die Attestierung entscheidet, welche Workloads überhaupt starten dürfen – auf den Kubernetes-Distributionen, die Ihr Plattform-Team bereits einsetzt.
Dyneemes bildet die Runtime-Basis für Confidential 5G und Garnet – die Plattformebene, auf der Enclaive seine anspruchsvollsten Workloads betreibt.
Cloud-native – mit einem Trust Model, das perfekt zur Architektur passt
Kubernetes hat Workloads portabel gemacht und den Betrieb auf viele Schultern verteilt – dabei aber dem Cluster-Betreiber weitreichende Zugriffsrechte eingeräumt: Wer die Control Plane betreibt, kann grundsätzlich auch auf die Pods zugreifen. Dyneemes kehrt dieses Prinzip um. Pods laufen in hardwaregeschützten Enklaven und sind bis auf Container- und Pod-Ebene isoliert. Gleichzeitig wird die Control Plane in einer vertrauenswürdigen Umgebung ausgeführt. Scheduling-Entscheidungen können den Schutz eines Workloads damit nicht aushebeln, und Plattform-Administratoren haben keine Möglichkeit, die von ihnen orchestrierten Daten im Klartext einzusehen.
Dabei bleibt Dyneemes eine einfach integrierbare Runtime-Umgebung: Ihre Manifests, Helm Charts, Operators und CI/CD-Prozesse funktionieren unverändert weiter. Die Cluster lassen sich auf allen gängigen Enterprise-Distributionen bereitstellen, die in Ihrem Unternehmen als Standard etabliert sind – ein Ansatz, der gemeinsam mit Red Hat OpenShift und SUSE validiert wurde.
Ihre vertraute Kubernetes-Umgebung – mit hardwarebasiertem Schutz dort, wo bisher Policies und Vertrauen genügen mussten.
Der Schutz ist granular: Einzelne Container und Pods laufen in eigenen geschützten Umgebungen. So wird die Tenant-Isolation in Multi-Tenant-Clustern direkt durch die Hardware abgesichert.
Auch die Control Plane selbst – die Komponente mit den weitreichendsten Zugriffsrechten auf Ihre Workloads – läuft geschützt. Sie müssen ihr also nicht mehr blind vertrauen.
Pods starten nur, wenn ihr Status nachweislich den definierten Policies entspricht. Keys werden über vHSM/Vault und Nitride ausschließlich für erfolgreich attestierte Workloads freigegeben.
Standard-Images, Manifests und Charts lassen sich unverändert weiternutzen. Confidential Kubernetes wird damit zur Eigenschaft der Runtime – und nicht zum Entwicklungsprojekt.
Dyneemes läuft in den Enterprise-Kubernetes-Umgebungen, die Sie bereits als Standard etabliert haben. Die Validierung mit OpenShift und SUSE stellt sicher, dass Ihr Plattform-Team seine bestehenden Tools und Prozesse weiter nutzen kann.
Dyneemes bildet die Runtime-Basis für Enclaives 5G-Core-Deployments und die Garnet AI Platform – Workloads, bei denen möglichst wenig Vertrauen in die zugrunde liegende Infrastruktur vorausgesetzt werden soll.
Workload startet
CPU prüft Code, Konfiguration und Plattformstatus
Nachweis erstellt
Hardwarebasierter Attestierungsnachweis, signiert
Policy geprüft
Nitride gleicht den Nachweis mit Ihrer Policy ab
Keys freigegeben
vHSM und Vault entsiegeln – erst jetzt, nur für diesen Workload
Workload startet
Manipuliertes Image, eingeschleuster Container oder UNBEKANNTER HOST
Nachweis erstellt
Messwert stimmt nicht mit der freigegebenen Konfiguration überein
Policy lehnt ab
Abweichung und Ursache werden im Audit Log erfasst
Keine Freigabe
Keine Keys, keine Secrets – die Daten bleiben verschlüsselt
Was Plattform-Teams über Dyneemes wissen möchten
Ist Dyneemes ein Kubernetes-Fork?
Nein. Dyneemes ist eine Confidential Runtime für Standard-Kubernetes und keine eigenständige Distribution. Ihre bestehenden Manifests, Charts und Operators lassen sich unverändert bereitstellen; die Versionierung folgt dem jeweiligen Upstream.
Was unterscheidet Dyneemes von Kubernetes auf Confidential VMs?
Der Schutz auf VM-Ebene sichert den Node ab; Dyneemes schützt den einzelnen Workload. Die Isolation auf Pod-Ebene und eine vertrauenswürdige Control Plane sorgen dafür, dass der Schutz auch bei Scheduling und Multi-Tenancy erhalten bleibt und Cluster-Betreiber nicht auf die geschützten Workloads zugreifen können.
Funktioniert Dyneemes mit unserem Service Mesh und unserem Observability Stack?
Standardmäßige Cloud-Native Tools funktionieren auch mit geschützten Workloads wie gewohnt. Der Unterschied liegt darin, welche Daten für Beobachter auf Infrastrukturebene einsehbar sind.
Bringen Sie Ihren Cluster mit.
Ihre Charts können Sie behalten
Wählen Sie einen repräsentativen Namespace auf der Distribution Ihrer Wahl. Wir zeigen Ihnen, wie Dyneemes ihn schützt und attestiert – Ihr Plattform-Team sitzt am Steuer, wir navigieren.
Sie betreiben darauf AI Workloads? Dafür gibt es Garnet. Network Functions? Confidential 5G.
