Cluster prerequisites

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:

$ cilium install --wait --set envoyConfig.enabled=true

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, 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:

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:

$ make kind-up cilium-install dev-certs gateway-ca kind-load$ make deploy-iam iam-migrate$ make deploy-enclave$ make deploy-kata

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.