A daevix enclave is a set of regular Kubernetes workloads. It runs anywhere that
Kubernetes runs, but it depends on a few platform features that a stock cluster
does not ship. This page lists them, so you can check your cluster before you
deploy. The dev cluster (`daevix-dev`, a kind cluster under rootful podman) runs
a compliant configuration, and every requirement below traces to a manifest in
`deploy/` or to that cluster.

## Kubernetes and CNI

The enclave requires Kubernetes 1.35-era APIs (the dev cluster runs v1.35.0 with
containerd 2.2.0) and **Cilium** as the CNI. Cilium is not optional: the
egress-redirect model needs Cilium's Envoy integration. A
`CiliumNetworkPolicy` redirects agent TCP egress into Cilium's embedded Envoy,
and Envoy forwards each connection to the node-local `dvx-gateway` over a Unix
socket with a PROXY-protocol v2 header. The agent participates in none of this;
the agent has no gateway address. Install Cilium with Envoy config enabled:

{{< terminal title="dvx" prompt="$" >}}
$ cilium install --wait --set envoyConfig.enabled=true
{{< /terminal >}}

If your cluster already runs Cilium, the equivalent is
`cilium config set enable-envoy-config true`. Without it, the redirect policies
that force agent traffic through the gateway do not take effect, and agents
egress unmediated. The dev kind config disables the default CNI at creation so
Cilium is the only CNI (`deploy/kind/kind.yaml`: `disableDefaultCNI: true`,
pod subnet `10.244.0.0/16`, service subnet `10.96.0.0/16`).

## Kata containers for agent pods

Agent pods run as virtual machines under [Kata Containers](https://kata-containers.io/),
which is what makes the IMDS delivery model work: a hostPath Unix socket cannot
cross into a guest VM, so the node-local imds serves agent VMs over vsock
instead. An agent pod sets `runtimeClassName: kata-clh`.

Install Kata with the vendored kata-deploy manifest (`make deploy-kata`):

- It runs a privileged DaemonSet in `kube-system` that installs the Kata
  binaries onto each node, rewrites the node's containerd config, and labels
  the node `katacontainers.io/kata-runtime=true`. The install restarts
  containerd, so running pods restart once per node.
- It creates a single RuntimeClass, `kata-clh` (cloud-hypervisor), which
  schedules onto nodes carrying that label. Only the `clh` shim is enabled:
  `kata-qemu` faults on host kernel 6.12 (`kvm run failed: Bad address`), so
  the cloud-hypervisor shim is the pinned choice. The pin is kata-containers
  **3.32.0** (`quay.io/kata-containers/kata-deploy:3.32.0`).

Kata needs the node to expose `/dev/kvm`, `/dev/vhost-vsock`, and
`/dev/vhost-net`. The vsock devices matter twice: the in-guest shim proxies the
IMDS socket to the host imds over vsock, and the imds DaemonSet reads Kata's
runtime state from `/run/vc` on the node to find each sandbox's vsock socket.

## Node requirements

The enclave DaemonSets (`dvx-imds`, `dvx-gateway`, `dvx-forensics`) run on every
enclave node with elevated privileges and node-local mounts:

| Path on the node | Mounted by | Used for |
|---|---|---|
| `/run/dvx/<enclave-prefix>` | imds, gateway, forensics | Per-agent IMDS sockets, audit WALs, per-enclave state |
| `/run/vc` | imds, forensics | Kata runtime state: per-sandbox vsock sockets, VM control sockets |
| `/var/run/cilium/envoy/sockets` | gateway | The Unix socket Cilium's Envoy dials the gateway through |
| `/proc` (read-only) | forensics | Resolving the VMM's RAM memfd file descriptors |

All three DaemonSets run as root (`runAsUser: 0`), because the Cilium Envoy
socket directory is root-owned and the imds creates per-agent sockets on the
node filesystem. The `/run/dvx` hostPath is templated at apply time to a
per-enclave subtree (the first 12 hex characters of the enclave id), so a
co-scheduled enclave cannot read another enclave's sockets, SVIDs (SPIFFE
Verifiable Identity Documents), or audit
spool. Plan node capacity for the VM overhead: each Kata pod is scheduled with a fixed overhead of 130 MiB memory and 250m
CPU (the RuntimeClass `overhead.podFixed` fields) on top of the guest's load.

## Storage

The enclave's databases and audit stores need persistent volumes:

- **enclave-postgres**: the enclave's own database, physically separate from
  the controlplane's.
- **ClickHouse** (`enclave-clickhouse`): the enclave's audit store. The daemon
  manifests point `DVX_AUDIT_DSN` at it, and the imds and gateway each spool
  audit rows to a node-local WAL under `/run/dvx` when ClickHouse is
  unreachable. Size the WAL volumes for your audit retention, since the spool
  survives pod restarts by design.

Any standard storage class that supports `ReadWriteOnce` volumes works; the dev
cluster uses its default class with 10Gi PVCs for each ClickHouse.

## Images and certificates

Stage these images where your cluster can pull them:

- `localhost/dvx:dev` in dev (your registry in production): the single daevix
  image. Every enclave component runs it with `imagePullPolicy: IfNotPresent`.
  Build and load it with `make image` and `make kind-load`.
- `quay.io/kata-containers/kata-deploy:3.32.0`: the Kata installer DaemonSet.

The enclave needs TLS material before it boots. In dev, `make dev-certs`
generates a local mkcert CA plus serving certs whose SANs include the
in-cluster service names that the components dial (`dvx-controlplane.dvx-system.svc.cluster.local`,
`dvx-broker.dvx-enclave.svc.cluster.local`, `dvx-relay.dvx-enclave.svc.cluster.local`,
`dvx-fake-upstream.dvx-enclave.svc.cluster.local`). `make gateway-ca` generates
the MITM CA that terminates agent egress TLS. `make deploy-enclave` generates
the llmproxy self-signed cert and the tunnel-ticket keypair itself if they are
absent. In production, replace the dev certs with your own CA and serving
certs; the manifests mount them as Secrets.

## Ordering the first deploy

The enclave deployment depends on a reachable controlplane: the broker registers
with it, and the gateway's policy sidecar pulls policy from the controlplane
through the broker. There is no
baseline policy ConfigMap. A first deploy runs, in order:

{{< terminal title="dvx" prompt="$" >}}
$ make kind-up cilium-install dev-certs gateway-ca kind-load
$ make deploy-iam iam-migrate
$ make deploy-enclave
$ make deploy-kata
{{< /terminal >}}

In dev, `deploy-enclave` also runs `register-broker-dev`, which mints the
enclave's identity and key. Run it once per enclave: re-running it mints a new
enclave id and orphans the agents already registered against the old one.