ci: CI lane that builds and privileged-loads the real eBPF network-policy object

[hsinatfootprintai]

Split out of #1660 (real two-org e2e coverage for the threat-detection fence-probe rules, umbrella #1645) after investigation found the actual blocker isn't a missing test — it's that this repo has no CI lane anywhere that loads real eBPF.

What exists today

• .github/workflows/incus-create.yml ("Daemon Create() against real Incus on ZFS") is the only CI lane with real Incus+ZFS, but it's scoped to the storage/encryption create path (-tags=incus -run 'TestIntegrationIncus' against ./pkg/core/box/lxc/ ./pkg/core/incus/ ./internal/server/). It never touches internal/netbpf.
• internal/netbpf/netpolicy.bpf.o is gitignored, built only via make build-bpf (needs clang + kernel UAPI headers, see Makefile:82), and only embedded into the daemon binary with -tags embed_bpf (internal/netbpf/embed_bpf.go). A normal go build/go test compiles the no-op embed_stub.go stand-in instead.
• No workflow ever invokes make build-bpf. release.yml/proxyproto-e2e.yml only reference netbpf in a Windows cross-compile guard (must stay Linux-only), not as a loading test.

Scope

Stand up a CI lane (new workflow, or a new job in an existing one) that:

1. Has a BPF toolchain available (clang + kernel UAPI headers) and successfully runs make build-bpf.
2. Builds the daemon with -tags embed_bpf (or points CONTAINARIUM_NETWORK_POLICY_BPF_OBJECT at the freshly built object).
3. Actually loads the object and attaches its TC hooks on a real veth interface — proving the load path works, not just that it compiles. This needs CAP_BPF/CAP_NET_ADMIN (or root); incus-create.yml already runs privileged for ZFS/Incus on a GitHub-hosted runner, so the same posture is likely workable here, but that's unproven and part of this issue's job to confirm.
4. Reuses incus-create.yml's existing ZFS+Incus setup as a base rather than duplicating it, if practical.

Out of scope

• The actual two-org cross-tenant-flow / deny-burst e2e test — that's the other half of the threat-detection: real two-org e2e coverage for fence-probe rules (cmd/isolation-sentry scaffolding doesn't exist) #1660 split (file as a follow-up, blocked by this issue). This issue is infra only: prove the lane can build and load the real object.
• Any change to the eBPF program itself or the network-policy enforcer's runtime behavior.

Notes

This is new privileged-CI-execution surface (a runner loading a real kernel-attached eBPF program), not a small mechanical add — may be worth /architect:design input before implementation, given the security/operational surface of granting a CI job CAP_BPF/CAP_NET_ADMIN.

Confirmed not locally reproducible

Investigated in this dev sandbox too: incus/zfs/zpool binaries are present but non-functional here (no real device/daemon access — consistent with running nested in a container), and there is no clang toolchain available at all, so make build-bpf can't even be exercised locally in this environment. Whatever lane this issue builds will need to be validated in CI directly.

[hsinatfootprintai]

Design doc: PR #1665 (docs/EBPF-CI-LOADING-LANE-DESIGN.md). Status: proposed, awaiting review.

Key finding worth flagging here: the issue's assumption of reusing incus-create.yml's Incus/ZFS setup turned out to be unnecessary — AttachVeth(ifindex) works against any real interface, so the design uses a throwaway veth pair on the bare runner instead, no Incus needed. Also, release.yml already proves make build-bpf works in CI — the actual gap is narrower than originally scoped: just the load/attach/evaluate half, not compile.

[hsinatfootprintai]

agent-1663implement-sonnet is starting processing it

[hsinatfootprintai]

Implementation: PR #1666 (.github/workflows/ebpf-load.yml + internal/netbpf/ebpf_load_test.go, -tags=ebpf_load).

CI-green, first attempt. The new "Load + attach the real eBPF network-policy object" job passed in 52s: https://github.com/FootprintAI/Containarium/actions/runs/33479438753/job/99765539247

Actual proof, from the job's own log:

--- PASS: TestLoad_RealObjectPassesVerifier (0.01s)
--- PASS: TestAttachVeth_RealInterface (0.07s)
    ebpf_load_test.go:240: seen: 0 -> 3
    ebpf_load_test.go:246: would_deny: 0 -> 3
--- PASS: TestAttachedProgram_EvaluatesRealTraffic (0.44s)
--- PASS: TestDetachVeth_RemovesLink (0.05s)

The kernel verifier accepted the compiled object, AttachTCX succeeded on ubuntu-latest's kernel (confirming the design doc's flagged ≥6.6 assumption), and — the actual point of this lane — the attached program evaluated real ICMP traffic sent across a throwaway veth pair: seen and would_deny both moved from 0 to 3. Every pre-existing test in internal/netbpf ran alongside (the workflow's go test targets the whole package) and stayed green too. All 10 PR checks pass.

#1664 (the real two-org e2e for the fence-probe rules) is unblocked now — the eBPF load/attach path this lane proves is exactly what it was waiting on.