Add transparent network policy support for HBONE connections

[electricjesus]

Description

Introduces TRANSPARENT_NETWORK_POLICIES config flag to preserve original destination ports for HBONE protocol connections. When enabled, outbound HBONE traffic uses the original destination port instead of routing all traffic through the standard HBONE port. This allows network policies to operate transparently based on the actual service port, enabling port-level policy enforcement without application awareness.

Defaults to false to maintain backward compatibility.

Requires this change also for the rest of the traffic control

How does it work?

With our modifications:

sequenceDiagram
    participant PodA as Pod A<br/>(Client)
    participant ZTA as ZTunnel<br>(listening socket in Pod A netns)
    participant IFPodA as Iface Pod A
    participant Plc as Network Policies<br>(Allow port 8080 for Pod A)
    participant IFPodB as Iface Pod B
    participant ZTB as ZTunnel<br>(listening socket in Pod B netns)
    participant PodB as Pod B<br/>(Server:8080)

    Note over PodA,PodB: Mesh Communication - with microsegmentation
    PodA->>ZTA: Istio redirects all TCP traffic,<br>leaving the pod, to ZTunnel
    ZTA->>IFPodA: Proxing over<br>HBONE protocol<br>(original dst port)
    Note over ZTA,IFPodA: Modified ZTunnel<br>that proxies with<br>original dst port
    IFPodA->>Plc: Flow to Pod B (port 8080)
    Plc->>IFPodB: Traffic Allowed
    Note over IFPodB: Felix makes magic<br>DSCP mark (0x17)<br>(host netns)
    Note over IFPodB: Modified Istio CNI<br>iptables rules<br>redirects to ZTunnel<br>(pod netns)

    IFPodB->>ZTB: ZTunnel receives<br>the connection :15008
    ZTB->>PodB: Ztunnel proxying<br>finishes

Loading

The key concept is that Felix (part of calico-node) maintains an ipset of pods that have the istio ambient mode label. For traffic that matches tha ipset it's marked with a DSCP rule that drives traffic back to ztunnel inbound

[istio-policy-bot]

😊 Welcome @electricjesus! This is either your first contribution to the Istio ztunnel repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[linux-foundation-easycla]

• ❌ - login: @radixo / name: Walter Neto . The commit (5e6988c) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[istio-testing]

Hi @electricjesus. 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.

[electricjesus]

Hi all! this is still a draft. We're still working on a few things related to this here over at ProjectCalico.

[MikeZappa87]

Introduces TRANSPARENT_NETWORK_POLICIES config flag to preserve original destination ports for HBONE protocol connections. When enabled, outbound HBONE traffic uses the original destination port instead of routing all traffic through the standard HBONE port. This allows network policies to operate transparently based on the actual service port, enabling port-level policy enforcement without application awareness.

Defaults to false to maintain backward compatibility.

We had started a conversation with some of the istio maintainers a couple weeks ago regarding the desire to make the dst port rewrite optional as it conflicted with L4 Network Policy enforcement. If I remember correctly they were ok with this as long as its disabled by default which you have satisfied the requirement here.

How do you envision to handle the destination proxy behavior? Since the listening socket is on 0.0.0.0:15008 in the pod network namespace and you no longer have the dstport:15008 and maintaining the original dst port? Are you using bpf, netfilter to redirect to the correct socket? It probably makes sense to get this ironed out? Unless I am completely missunderstanding the code :-)

[electricjesus]

hi @MikeZappa87, thanks for your comment here! My mistake, I completely forgot to reference the companion change to Istio CNI. However, all of these are pretty much prototyping code. These two are all still missing some further enhancement details like the same behaviour when it comes to waypoint proxy.

We had started a conversation with some of the istio maintainers a couple weeks ago

Will you point me to where this discussion is happening, we're hoping to participate

[keithmattix]

Looking at the CNI change, it looks like you're using dscp marking in the IP header to match inbound traffic and send it to ztunnel port 15008. I assume something in ztunnel would need to set that mark?

[MikeZappa87]

Looking at the CNI change, it looks like you're using dscp marking in the IP header to match inbound traffic and send it to ztunnel port 15008. I assume something in ztunnel would need to set that mark?

I was curious of what was setting the mark here. Is Calico providing this with ebpf? I am assuming if it is ebpf you are checking if a pkt matches a netpol you apply this mark?

[MikeZappa87]

hi @MikeZappa87, thanks for your comment here! My mistake, I completely forgot to reference the companion change to Istio CNI. However, all of these are pretty much prototyping code. These two are all still missing some further enhancement details like the same behaviour when it comes to waypoint proxy.

We had started a conversation with some of the istio maintainers a couple weeks ago

Will you point me to where this discussion is happening, we're hoping to participate

Want to message me on the K8s slack? We probably all can think about this.