Skip to main content
Katakate gives every sandbox its own VM-level network namespace and applies opinionated network policies on top. This page explains the model.

​
CNI plugin: Cilium by default

By default, K3s is installed with Flannel disabled (--flannel-backend=none --disable-network-policy) and Cilium as the CNI. Cilium runs with kubeProxyReplacement=true (no kube-proxy), and its eBPF datapath attaches to the host-side veth — including for Kata VMs, whose virtio NICs are bridged to a host veth.
When the cluster is on Cilium, k7 uses CiliumNetworkPolicy for FQDN egress. On Flannel it falls back to the standard Kubernetes NetworkPolicy with CIDR-only ipBlock rules.

​
Ingress isolation (always on)

A NetworkPolicy blocks all inter-VM ingress traffic by default. Practical implications:
  • Sandbox-to-sandbox networking is denied — even within the same namespace.
  • kubectl exec and k7 shell still work — they go through the Kubernetes API, not pod networking.
  • kube-system traffic is allowed — needed for cluster services (DNS, metrics, etc.).
  • No configuration required — this is enforced for every sandbox.

​
Egress control

Egress is configured per sandbox with egress_whitelist:

​
How FQDN egress works under Cilium

When the whitelist contains FQDNs, k7 creates a CiliumNetworkPolicy like:
Wildcards (*.example.com) are supported via Cilium’s matchPattern. Bare exact names use matchName.

​
When DNS is blocked

If the whitelist is [] or contains only CIDRs, DNS resolution is denied by the policy. To work around this:
  • Pre-resolve names in before_script (which runs before the egress policy is applied).
  • Embed your dependencies into the image rather than fetching them at runtime.
  • Whitelist your own internal DNS server / egress proxy and resolve there.
Do not whitelist public DNS resolvers like 1.1.1.1 or 8.8.8.8 — that re-enables DNS-over-UDP/TCP/443 (DoH) and defeats the lockdown. Prefer a single egress proxy IP and enforce DNS / DoH policy at the proxy. Or, even simpler, just use FQDN egress on Cilium.

​
Network policies created per sandbox

For each sandbox, k7 creates:
  1. An ingress-deny NetworkPolicy (always).
  2. Either:
    • A NetworkPolicy with CIDR-only ipBlock egress rules (when only CIDRs are listed, or the cluster runs Flannel), or
    • A CiliumNetworkPolicy for FQDN+CIDR egress (when FQDNs are present and Cilium is installed).
All policies are deleted with the sandbox.

​
Administrative access

kubectl exec, k7 shell, the API’s /exec endpoint, and k7 logs all bypass network policies because they ride the Kubernetes API. Pod networking restrictions never affect operator access.

​
Multi-node considerations

  • Cilium routes pod traffic across nodes natively (no Flannel VXLAN).
  • CiliumNetworkPolicy applies cluster-wide regardless of which node the sandbox runs on.
  • Longhorn replication traffic between nodes is not affected — it goes through the host network (Cilium’s host-level rules), not the sandbox’s policy.