Landlock policy generation via eBPF tracing -- potential upstream fit for LandlockProfile?

[idriss-eliguene]

Hi Flavio,

I've been building landlock-genprof — it traces a running pod via eBPF
(Inspektor Gadget gadgets: filesystem, network, syscalls, capabilities)
and generates least-privilege security profiles from what was actually
observed, rather than hand-authored rules.

Repo: https://github.com/idriss-eliguene/landlock-genprof

PodLock is the closest existing project to what this feeds into — you
have the LandlockProfile CRD and the enforcement side (NRI plugin,
seal/execve) solved well, but the profiles themselves are still
hand-written today. That's the gap landlock-genprof targets: it already
emits a podlock.kubewarden.io/v1alpha1 LandlockProfile directly (see
examples/nginx-generated-profile.yaml), with each rule
confidence-annotated based on how consistently it was observed across
training runs (--history).

Current status: observe → synthesize → export pipeline confirmed
end-to-end on a live cluster, tagged v0.1.0. Filesystem is the most
mature path; network/seccomp/capabilities are generated from the same
trace in parallel formats (NetworkPolicy, SPO SeccompProfile,
securityContext).

A few things I'd value your take on, since you know PodLock's
LandlockProfile schema better than anyone:

• Is generating directly into your CRD format the right integration
  point, or would you rather see this stay a separate tool that just
  happens to emit compatible YAML?
• Any schema evolution planned for LandlockProfile that I should track,
  so the generator doesn't drift from what PodLock actually consumes?
• Open to a PR adding a short mention in PodLock's docs pointing at
  generation tooling, once this is further along — or is that premature
  at v0.1.0?

Not trying to reinvent enforcement — happy to stay strictly upstream of
it.