So BPF programs are the kernel entities, as they run within the kernel space. On the other hand, Linux namespaces aka containers, provide application-level isolation, in which case they all share the host's kernel, kernel modules etc.
So I guess it doesn't make sense to load a bpf program per container, as it will become visible on the host as well?
Therefore I would guess that bpf programs would load on the host and monitor/mangle/etc. packets to/from namespaces. Given that struct sock has the information about namespace id, I think only certain types of bpf programs would be able to do that?
So I guess it doesn't make sense to load a
bpfprogram per container, as it will become visible on the host as well?
If you mean loading a BPF program from a container, then yes it would be visible on the host as well (and you would need a privileged container in order to do that).
Given that
struct sockhas the information about namespace id, I think only certain types ofbpfprograms would be able to do that?
I couldn't find any BPF program type that has direct access to struct sock. BPF programs of type sockops have access to struct bpf_sock, but it contains few actual information.
You could use BPF programs of type cgroup/skb though. Those are attached to cgroups and can act on both ingress and egress packets. They receive a struct __sk_buff object as argument, a mirror of the sk_buff for the packet received/sent. They can only use a few helpers (in addition to the common base), and don't seem to have write access to packets.
kprobe BPF programs have access to any kernel function kprobes can be attached to. So you could retrieve the namespace information by probing the appropriate function and then send it to your monitor/mangle/etc. program through a bpf map. Not the simplest option though.