RFE: Support managed iptables

[ensc]

Here, iptables rules are managed by external tools which do effectively a iptables-restore to set the policy. Because CNI writes directly into the iptables its rules are lost and networking of containers is broken when policy is reloaded.

I see two ways (beside switching to slirp4netns or so) to solve this:

1. add an option to call a script to set CNI networking rules (instead of the iptables executable and/or writing on netlink sockets)

2. support a less intrusive and more predictable setup:

   • do not touch default chains (PREROUTING, POSTROUTING, FORWARD, ...)
   • only write into chains with fixed (or better: configurable names).
   • do not create or destroy these chains but assume they exist

   With this, I can call the chains manually and save/restore their content.

[xtreme-sameer-vohra]

This might be another alternative that provides flexibility - #461

[dcbw]

This isn't a CNI specific problem. Anything doing an iptables-restore must be careful to only change/add/remove chains that tool itself controls, otherwise it will blow away any other rules on the system. For example, kube-proxy takes great pains to make sure it only restores its own chains, and leaves other chains alone.

This really sounds like a bug in the external tool doing iptables-restore, where that tool needs to be a better citizen and not assume it has complete control over the firewall (which it doesn't).

[ensc]

I solved my problem by saving/restoring the CNI-xxx chains and I am ok when CNI would manage only these chains.

But CNI (and kube-proxy) add themselves to standard chains at top most positions. I can hack around this by creating jumps at more suitable positions by adding rules with exactly the same parameters . But these parameters (which include comments like "* CNI portfwd requiring masquerade */") are not documented and are determined by trial and errors. I have a bad feeling that they change with the time (fixing typos in comments or so) and create silently leaks in my packet filters.

There should be a switch which disables touching INPUT, FORWARD + OUTPUT chains and the other created chains should be documented and their naming must stay stable across the next years..