iptables: use ISTIO_OUTPUT chain for DNS UDP rules

[eoinfennessy]

Please provide a description of this PR:

Fixes #50532

[istio-testing]

Hi @eoinfennessy. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[eoinfennessy]

Hi @bleggett, do you think any further changes need to be made to address this issue?

[costinm]

I think it's a good change but pretty risky - can you confirm the result by getting an iptables-save on a real pod ( the golden files are pretty fake - not sure why we use uid-owner 3 and 4, not something we'll have in practice ) ?

(long term): If you are interested in iptables and capture - I would save the capture in a doc, perhaps one capture from a pod with all iptables-related annotations plus ambient capture - and evaluate the differences and if we can merge the behavior. It is not clear at all why we need 2 different iptables code paths both operating on the pod - in the past ambient was in host namespace and it made sense.

[eoinfennessy]

Thanks @costinm!

Golden files don't look right - ISTIO_OUTPUT is created 2x.

ISTIO_OUTPUT is created once in the nat table and once in the raw table (is this required because some of the rules created are added to the raw table?):

iptables -t nat -N ISTIO_OUTPUT
iptables -t raw -N ISTIO_OUTPUT
...
ip6tables -t nat -N ISTIO_OUTPUT
ip6tables -t raw -N ISTIO_OUTPUT

Also there is no jump from OUTPUT to ISTIO_OUTPUT showing up - maybe I missed it or was already there for the previous ISTIO_OUTPUT rule ? I don't remember how the jump is added - please check it doesn't have "-p tcp".

This jump is currently being created with -p tcp:

iptables -t nat -A OUTPUT -p tcp -j ISTIO_OUTPUT

Do we want to now create this without the -p tcp argument? Or create another jump with -p udp? I think I'm missing the jumps to the raw table too.

can you confirm the result by getting an iptables-save on a real pod ( the golden files are pretty fake - not sure why we use uid-owner 3 and 4, not something we'll have in practice ) - and compare it against what ambient does ?

Yes, I'll do some comparisons with between this and the current behavior for both sidecar and ambient.

[bleggett]

I think it's a good change but pretty risky - can you confirm the result by getting an iptables-save on a real pod ( the golden files are pretty fake - not sure why we use uid-owner 3 and 4, not something we'll have in practice ) ?

+1 but we are using exactly the same library we use for real pods to generate the result we directly compare against the goldens - the inputs may be different in a real pod, but the rules/tables/chains will not be - that part is deterministic.

[bleggett]

This LGTM conceptually and is a pretty straightforward rename.

We have decent testing around this, so if/when the tests pass, I am good. TY @eoinfennessy !

[bleggett]

You need to insert the jump to the istio chain, since we are no longer using the default one.

[eoinfennessy]

Thank you, @bleggett! I've added the required jumps in the latest commit. The integration tests look OK now.

[hzxuzhonghu]

with this one rule
-A OUTPUT -p udp -j ISTIO_OUTPUT

I am not sure i can get what really it fix here

[eoinfennessy]

with this one rule
-A OUTPUT -p udp -j ISTIO_OUTPUT

I am not sure i can get what really it fix here

Hi @hzxuzhonghu, this jump is required because all UDP rules have been moved from the main OUTPUT chain to the ISTIO_OUTPUT chain.

[bleggett]

LGTM! ty @eoinfennessy!

[howardjohn]

with this one rule
-A OUTPUT -p udp -j ISTIO_OUTPUT
I am not sure i can get what really it fix here

Hi @hzxuzhonghu, this jump is required because all UDP rules have been moved from the main OUTPUT chain to the ISTIO_OUTPUT chain.

Shouldn't we conditionally jump? Like only for dport 53/sport 15053?

[bleggett]

with this one rule
-A OUTPUT -p udp -j ISTIO_OUTPUT
I am not sure i can get what really it fix here

Hi @hzxuzhonghu, this jump is required because all UDP rules have been moved from the main OUTPUT chain to the ISTIO_OUTPUT chain.

Shouldn't we conditionally jump? Like only for dport 53/sport 15053?

The existing rules (now moved to the custom chain) only apply if the traffic meets those reqs (is udp/ports, etc) so it amounts to the same thing.

Putting a rule in a custom chain and jumping to it doesn't change rule evaluation over how they would work in the primary/default chain (where they were before) - if they would all have been skipped in the main chain, they are still all skipped in the secondary chain.

If we checked before the jump we would effectively be checking the same properties 2x for every relevant packet. Jumps are supposed to be pretty dumb and have virtually zero cost, they're just pointers - organizational conveniences for the user.