.png){kind=logo}
Kubernetes, with the cluster operator outside the pods
A drop-in confidential runtime for Kubernetes: pods execute inside hardware enclaves, the control plane runs trusted, and attestation gates what starts — on the distributions your platform team already runs.
Dyneemes is the runtime beneath Confidential 5G and Garnet — the tier where enclaive's hardest workloads live.
Cloud-native, with the trust model finally matching the architecture
Kubernetes made workloads portable and operations shared — and quietly made the cluster operator omniscient: whoever runs the control plane can reach into any pod. Dyneemes inverts that. Pods execute inside hardware enclaves, isolated at the individual container and pod level, and the control plane runs trusted — scheduling decisions can't strip a workload's protection, and platform administrators hold no readable path into what they orchestrate.
It stays a drop-in runtime: your manifests, Helm charts, operators and CI/CD keep working, and clusters deploy on the enterprise distributions your organization has already standardized on — an approach validated in partnership with Red Hat OpenShift and SUSE.
The Kubernetes you operate today, with hardware answering what policy used to.
Protection is fine-grained: individual containers and pods run in their own sealed context, so multi-tenant clusters get hardware answers to tenant separation.
The control plane itself runs confidentially — the component with the most power over your workloads is no longer the component you have to trust blindly.
Pods start only when their measured state matches policy, and keys release only to attested workloads via vHSM/Vault and Nitride.
Standard images, manifests and charts deploy unchanged — confidential Kubernetes as a runtime property, not a development project.
Runs with the enterprise Kubernetes ecosystems you've standardized on — OpenShift and SUSE validation means your platform team's tooling carries over.
Dyneemes is the runtime tier beneath enclaive's 5G core deployments and the Garnet AI platform — the workloads with the least tolerance for trust assumptions.
Workload starts
Code, config and platform state measured by the CPU
Evidence produced
Hardware-rooted attestation report, signed
Policy checked
Nitride verifies the measurement against your policy
Keys released
vHSM and vault unseal — only now, only to this workload
Workload starts
Tampered image, injected container or rogue host
Evidence produced
Measurement does not match what you approved
Policy rejects
Mismatch logged with its reason, for the audit file
Nothing released
No keys, no secrets — the data stays ciphertext
What platform teams ask about Dyneemes
Is this a fork of Kubernetes?
No — Dyneemes is a confidential runtime for standard Kubernetes, not a divergent distribution. Your existing manifests, charts and operators deploy unchanged; version currency follows upstream.
How is this different from just running Kubernetes on confidential VMs?
VM-level protection seals the node; Dyneemes seals the workload — pod-level isolation plus a trusted control plane, so protection survives scheduling, multi-tenancy and the cluster operator's own access.
Does it work with our service mesh and observability stack?
Standard cloud-native tooling operates normally around sealed workloads; what changes is what infrastructure-level observers can read.
Bring a cluster. Keep your charts
A representative namespace on your distribution of choice, sealed and attested — your platform team drives, we navigate.
Running AI on it? Garnet. Network functions? Confidential 5G.
