# Edera zones

Edera runs Kubernetes pods inside of zones, which provide a security boundary for sensitive workloads. Running pods in an Edera zone eliminates container escape, privilege escalation, and lateral movement attacks.

You can think of a zone as a virtual machine guest environment where pods run with a dedicated zone kernel. The zone kernel is separate from the host kernel and is pulled as an OCI image and unpacked into the zone to run the workload. Edera Protect zones run a single pod by default, but can be configured to run a group of pods or a Kubernetes namespace.

## Run an Protect Zone

To run a pod inside an Edera zone, the `edera` runtime class must be installed to the Kubernetes cluster.

```bash
kubectl apply -f https://public.edera.dev/kubernetes/runtime-class.yaml
```

The Edera RuntimeClass includes a `nodeSelector` that requires nodes to be labeled with `runtime=edera`. This ensures that pods using the Edera runtime are scheduled only on nodes where Edera is installed. See the [installation guides](https://docs.edera.dev/guides/install/) for details on labeling nodes.

Pods are run inside Edera zones when a pod specification specifies the `edera` runtime class.

```yaml
apiVersion: v1
kind: Pod
metadata:
 name: edera-protect-pod
spec:
 runtimeClassName: edera
```

This podspec causes the pod to be scheduled to a node running the Edera Protect type-1 hypervisor. Instead of using containerd as the default runtime, the hypervisor creates a zone to run the Kubernetes pod in. This is completely transparent to the user, they don’t know their workload is securely isolated nor do they have to change their container image or configuration at all.

### What exactly is an Edera zone?

An Edera zone runs Kubernetes pods inside a virtual machine environment that includes a zone kernel, packaged as an OCI image that contains a directory at `/kernel` with:

- `"image"`: vmlinuz, the zone kernel core.
- `"metadata"`: env-style key-value store to specify zone metadata.
- `"addons.squashfs"`: a [squashfs](https://docs.kernel.org/filesystems/squashfs.html) image that contains a modules directory where all kernel modules for the zone are stored.
- `"config.gz"`: a gzip’d kernel config.

An [initramfs](https://wiki.debian.org/initramfs) contains the following files:

- `"/init"`: a small static Rust executable that initializes the zone. The kernel calls this first.
- ["/bin/styrolite"](https://github.com/edera-dev/styrolite): a static Rust executable used to run containers inside the zone.
- `"/bin/zone"`: a static Rust executable which communicates over IDM to provide and orchestrate containers running in styrolite, along with other RPCs.

An `initramfs` can be packaged into an image with the file `usr/lib/edera/protect/zone/initrd` being a `cpio` containing the files in the `initramfs` above.

### Life of an Edera zone

When Edera starts a zone, it:

1. Reads the “image” file from the kernel OCI image into memory, loads it as an [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) (all in safe Rust code) into hypervisor memory, and begins executing the kernel.
2. Mounts the `addons.squashfs` as the first disk.
3. `/init` is called by the Linux kernel and does basic initialization.
4. `/init` calls `/bin/zone`, which connects to IDM over a shared channel with the host and handles all RPCs.
5. When the RPCs related to workloads need to run a container, it generates a `styrolite` config and runs `/bin/styrolite` with the config.