Skip to content

Commit 699c2e0

Browse files
authored
added a technical overview and added a link in the readme (#474)
1 parent 53052b2 commit 699c2e0

2 files changed

Lines changed: 88 additions & 0 deletions

File tree

README.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ krata is an implementation of a Xen control-plane in Rust.
1111
- [Frequently Asked Questions](FAQ.md)
1212
- [Code of Conduct](CODE_OF_CONDUCT.md)
1313
- [Security Policy](SECURITY.md)
14+
- [Edera Technical Overview](technical-overview.md)
1415

1516
## Introduction
1617

@@ -23,3 +24,4 @@ It provides the base layer upon which Edera Protect zones are built on: a secure
2324
|--------------|------------------|-------------------------|
2425
| x86_64 | 100% Completed | None, Intel VT-x, AMD-V |
2526
| aarch64 | 10% Completed | AArch64 virtualization |
27+

technical-overview.md

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
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

Comments
 (0)