Tests

ebfw is exercised by unit tests, controller envtest, and two end-to-end suites that run the real datapath against real traffic.

# Unit tests (no eBPF, runs anywhere); operator controllers under envtest.
make test            # everything except internal/controller (which needs envtest)
make test-operator   # api + controller envtest (downloads envtest binaries)

# Host e2e: runs the binary on a Linux host, generates real curl traffic, and
# asserts captures — DNS / TLS SNI / HTTP+HTTPS paths / headers / filter / enforce.
docker build --target bin --output type=local,dest=out .   # -> out/ebfw
sudo ./test/e2e.sh out/ebfw

# Kubernetes e2e: installs the chart on a throwaway k3d cluster and asserts the
# full CRD-driven path end to end.
./test/crd.sh

Host e2e — test/e2e.sh

Linux host, eBPF, root. Covers visibility — DNS, TLS SNI, HTTP/1.x + HTTP/2 request paths, headers — plus internal-traffic filtering, IPv4 + IPv6 packet decoding, JSON output, and enforcement: a CIDR deny drops the connection, a domain deny blocks via DNS→IP learning, and log mode annotates the verdict without dropping.

Kubernetes e2e — test/crd.sh

k3d + Helm. Installs the CRDs, operator, and agent (enforce mode, EBFW_POLICY_SOURCE=crd) on a throwaway cluster and asserts the full CRD-driven path:

CI

.github/workflows/e2e.yml runs the unit tests, make test-operator (envtest), test/e2e.sh, and test/crd.sh on ubuntu-24.04 for every push and pull request.