Use netlink interface directly (distroless)

[aojea]

This removes the dependency on the nft libraries reducing size and exposure to vulnerabilities and user space changes, netlink API seems to be more stable https://docs.kernel.org/networking/netlink_spec/nftables.html and I will add more test to ensure the user space representation does not drift google/nftables#292

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [aojea]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[danwinship]

This removes the dependency on the nft libraries reducing size and exposure to vulnerabilities and user space changes

I don't think there are any arguments for porting kube-network-policies to use netlink that wouldn't also apply to kube-proxy, so if you are thinking it makes sense to switch kube-network-policies over then we should document why and then move kube-proxy over too.

[aojea]

I don't think there are any arguments for porting kube-network-policies to use netlink that wouldn't also apply to kube-proxy, so if you are thinking it makes sense to switch kube-network-policies over then we should document why and then move kube-proxy over too.

I've been playing a lot with the netlink nftables interfaces these christmas and the API seems more solid, but the ecosystem is very small and very low level and you have to go directly to the source code a lot of times and to the wire representation mdlayher/netlink#219 ...

kube-network-policies does not require much work, just 1 Sets and ~ 4 rules per ip family, and then adding and removing elements from sets, it is unlikely this project will require to add any new rules in the future

I think that we need just this to answer the question if is worthy it, that is why we put these projects in kubernetes-sigs to explore and provide feedback ... if does not work we can just revert back

[danwinship]

the API seems more solid

FWIW I've been thinking about the possibility of a v2 json API for nft to try to make it better for programmatic use...

[aojea]

FWIW I've been thinking about the possibility of a v2 json API for nft to try to make it better for programmatic use...

nftables' virtual machine (VM) is incredibly flexible, allowing for a nice number of packet processing operations. I love that I do not need to understand the skbuff struct to do "things" with the packets. However, this flexibility has a ton of complexity and I can't say how to better model it:

• the netlink interface provides low-level access to nftables, the raw bytecode it exposes is difficult to work with directly, the mix of high-level commands (like masquerade and queue) and low-level operations (like cmp and bitwise) sometime does not work when combined in certain ways. The set functionality in nftables reminds me our Service API, powerful and nice but with a lot of options that makes it challenging to manage at the netlink level.
• nft in the other side gives you a set of Lego blocks but sometimes you miss some of the lego pieces or just are really hard to reason about on how to fit them together or they just don't fit at all until a new version happen :/

I'm looking forward to your new API, IMHO for a new nftables API, the real challenge is on how to expose those powerful network operations in a programmer-friendly way, JSON is just the surface layer; the real issue to me is about the abstractions and programmability.