|
| 1 | +# Edera Technical Overview |
| 2 | + |
| 3 | +## What is Edera? |
| 4 | + |
| 5 | +Edera is a secure-by-default, cloud-native platform built on a reimagined, memory-safe type-1 hypervisor. It unlocks hard multitenancy and strong container isolation—without the performance hit. |
| 6 | + |
| 7 | +Unlike traditional container runtimes that share a single Linux kernel across containers, Edera runs each container in a lightweight virtual machine (called a **zone**), with its own dedicated Linux kernel. This eliminates the kernel as a shared attack surface. |
| 8 | + |
| 9 | +And because Edera doesn’t rely on nested virtualization, it runs wherever containers do—across public clouds, on-prem, and edge environments. |
| 10 | + |
| 11 | +## How Edera Works |
| 12 | + |
| 13 | +At its core, Edera uses a custom hypervisor based on Xen, with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads. |
| 14 | + |
| 15 | +Each zone runs its own Linux kernel and minimal init system. The kernel and other system components are delivered via OCI images, keeping things composable, cacheable, and consistent. |
| 16 | + |
| 17 | +Zones are paravirtualized using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance. |
| 18 | + |
| 19 | +## How Edera Runs & Secures Containers |
| 20 | + |
| 21 | +Edera allows you to compose your infrastructure the same way you compose workloads: using OCI images. |
| 22 | + |
| 23 | +Each zone consumes a small number of OCI images: |
| 24 | +- A **kernel image** that provides the zone kernel. |
| 25 | +- One or more **system extension images** that provide init systems, utilities, and kernel modules. |
| 26 | +- Optionally, **driver zones**—zones that provide shared services (like networking) to other zones. |
| 27 | + |
| 28 | +Inside each zone, container workloads run via a minimal OCI runtime called **Styrolite**, written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself. |
| 29 | + |
| 30 | +### Key Benefits of This Design |
| 31 | +- No external container runtime processes |
| 32 | +- Zone init system directly manages containers |
| 33 | +- Minimal attack surface, optimized for secure execution |
| 34 | + |
| 35 | +This tightly integrated design avoids the complexity, latency, and exposure introduced by conventional container runtimes. It keeps the execution path short, verifiable, and secure-by-design. |
| 36 | + |
| 37 | +## Zones as Security Boundaries |
| 38 | + |
| 39 | +In Kubernetes, Edera runs pods inside **zones**—isolated virtual machines that eliminate risks like container escape, privilege escalation, and lateral movement. |
| 40 | + |
| 41 | +Each zone boots its own kernel, pulled via OCI, and runs a single pod by default. You can also configure zones to run a replica set, a namespace, or a set of trusted workloads together. |
| 42 | + |
| 43 | +To use Edera, apply the `RuntimeClass`: |
| 44 | + |
| 45 | +```yaml |
| 46 | +apiVersion: node.k8s.io/v1 |
| 47 | +kind: RuntimeClass |
| 48 | +metadata: |
| 49 | + name: edera |
| 50 | +handler: edera |
| 51 | +``` |
| 52 | +
|
| 53 | +Then annotate your pod: |
| 54 | +
|
| 55 | +```yaml |
| 56 | +apiVersion: v1 |
| 57 | +kind: Pod |
| 58 | +metadata: |
| 59 | + name: edera-protect-pod |
| 60 | +spec: |
| 61 | + runtimeClassName: edera |
| 62 | +``` |
| 63 | +
|
| 64 | +This causes the pod to be scheduled to a node running Edera’s hypervisor. The pod is transparently launched inside its own VM zone—no image changes, no config rewrites, and no extra work from developers. |
| 65 | +
|
| 66 | +## What Exactly Is an Edera Zone? |
| 67 | +
|
| 68 | +An Edera zone is a minimal VM built from OCI-delivered components. At launch time, the Edera daemon unpacks: |
| 69 | +
|
| 70 | +### Kernel Image |
| 71 | +Located under `/kernel` in the OCI image: |
| 72 | +- `image`: the Linux kernel (vmlinuz) |
| 73 | +- `metadata`: key-value pairs for boot parameters |
| 74 | +- `addons.squashfs`: includes kernel modules in `/modules` |
| 75 | +- `config.gz`: the kernel configuration file |
| 76 | + |
| 77 | +### Initramfs Contents |
| 78 | +Packaged in a CPIO archive, typically mounted from: |
| 79 | +`usr/lib/edera/protect/zone/initrd` |
| 80 | + |
| 81 | +The initramfs includes: |
| 82 | +- `/init`: static Rust binary that initializes the zone |
| 83 | +- `/bin/styrolite`: embedded container runtime |
| 84 | +- `/bin/zone`: control plane for managing containers and services via IDM (inter-domain messaging) |
| 85 | + |
| 86 | +This structure lets Edera launch zones rapidly, with well-defined boundaries and no dependency on the host OS kernel. Everything the workload touches is defined, versioned, and validated. |
0 commit comments