Explanation of iptable rule injection within a Pod in Istio Ambient mode

/ Jimmy Song

在Previous Blog.In Istio Ambient, I outlined the iptables rules injected within the Pod network namespace in the Istio Ambient model. In this article, I’ll dive deeper into parsing these rules to explore how they enable transparent traffic interception and redirection within the Pod.

iptable rules within the Pod

Within the Pod’s network namespace, the Istio CNI Node Agent sets up a series of iptables rules to transparently intercept and redirect traffic. The following rules show what Istio injects into the mangle and nat tables to ensure that inbound and outbound traffic is handled appropriately.

# Generated by iptables-save v1.8.9 (nf_tables) on Thu Nov 14 08:43:17 2024 
*mangle 
:PREROUTING ACCEPT [99138:22880045]  # mangle 表中的 PREROUTING 链，默认策略为 ACCEPT。 
:INPUT ACCEPT [0:0]  # mangle 表中的 INPUT 链，默认策略为 ACCEPT。 
:FORWARD ACCEPT [0:0]  # mangle 表中的 FORWARD 链，默认策略为 ACCEPT。 
:OUTPUT ACCEPT [100900:34940164]  # mangle 表中的 OUTPUT 链，默认策略为 ACCEPT。 
:POSTROUTING ACCEPT [0:0]  # mangle 表中的 POSTROUTING 链，默认策略为 ACCEPT。 
:ISTIO_OUTPUT - [0:0]  # 自定义的 ISTIO_OUTPUT 链，用于处理 Istio 的出站流量。 
:ISTIO_PRERT - [0:0]  # 自定义的 ISTIO_PRERT 链，用于处理 Istio 的预路由流量。 
-A PREROUTING -j ISTIO_PRERT  # 将所有 PREROUTING 流量跳转到 ISTIO_PRERT 链。 
-A OUTPUT -j ISTIO_OUTPUT  # 将所有 OUTPUT 流量跳转到 ISTIO_OUTPUT 链。 
-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff 
# 如果连接标记为 0x111/0xfff，则恢复连接标记，用于连接追踪的一致性。 
 
-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff 
# 如果数据包标记为 0x539/0xfff，在 PREROUTING 链中将其连接标记设置为 0x111/0xfff。 
 
COMMIT  # 应用 mangle 表规则。 
# Completed on Thu Nov 14 08:43:17 2024 
 
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Nov 14 08:43:17 2024 
*nat 
:PREROUTING ACCEPT [2:120]  # nat 表中的 PREROUTING 链，默认策略为 ACCEPT。 
:INPUT ACCEPT [0:0]  # nat 表中的 INPUT 链，默认策略为 ACCEPT。 
:OUTPUT ACCEPT [119:9344]  # nat 表中的 OUTPUT 链，默认策略为 ACCEPT。 
:POSTROUTING ACCEPT [0:0]  # nat 表中的 POSTROUTING 链，默认策略为 ACCEPT。 
:ISTIO_OUTPUT - [0:0]  # 自定义的 ISTIO_OUTPUT 链，用于处理 Istio 的出站 NAT 流量。 
:ISTIO_PRERT - [0:0]  # 自定义的 ISTIO_PRERT 链，用于处理 Istio 的预路由 NAT 流量。 
-A PREROUTING -j ISTIO_PRERT  # 将所有 PREROUTING 流量跳转到 ISTIO_PRERT 链。 
-A OUTPUT -j ISTIO_OUTPUT  # 将所有 OUTPUT 流量跳转到 ISTIO_OUTPUT 链。 
-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT 
# 如果目标地址为 169.254.7.127（可能是 Istio 内部地址），允许 TCP 流量通过。 
 
-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT 
# 如果数据包标记为 0x111/0xfff，允许 TCP 流量通过。 
 
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ACCEPT 
# 允许发往本地回环接口（但不包括 127.0.0.1）的流量通过。 
 
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001 
# 将发往非 127.0.0.1 的出站 TCP 流量（且标记不是 0x539/0xfff）重定向到端口 15001（Istio 出站流量入口）。 
 
-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT 
# 如果源地址为 169.254.7.127，允许 TCP 流量通过 PREROUTING 链。 
 
-A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m tcp ! --dport 15008 -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15006 
# 将非 127.0.0.1 且目标端口不是 15008 的入站 TCP 流量（标记不是 0x539/0xfff）重定向到端口 15006（Istio 入站流量入口）。 
 
COMMIT  # 应用 nat 表规则。 
# Completed on Thu Nov 14 08:43:17 2024

The Role of Port Numbers

These iptables rules differentiate and handle different types of traffic by specific port numbers:

  • 15008 (HBONE Socket): Used for transparently proxying HTTP-based traffic and supports transparent transport of the HBONE protocol.
  • 15006 (Plaintext Socket): Used to handle unencrypted intra-grid traffic for inter-Pod traffic management.
  • 15001 (Outbound Socket): Used to manage outbound traffic and enable policy control of access to external services.

These ports enable Istio to transparently manage and control inbound, outbound, and internal traffic for fine-grained security policies and traffic control. For more information on the use of port numbers please refer toIstio Application Requirements。

marking0x539role of

0x539is a flag used to identify traffic sent by the Istio proxy. This flag is set when the traffic enters the iptables rule, and is used to distinguish packets that have been processed by a proxy (such as ztunnel), preventing them from being re-proxied or mishandled. In this way, the0x539The markers efficiently identify the traffic in which the agent is involved and ensure that the packets flow according to the expected path.0x539in hexadecimal corresponds to the decimal equivalent of1337but (not)0xfffis a mask to match specific bits.

marking0x111role of

0x111Used for connection-level tagging management to identify the entire connection in the Istio grid that has been processed by the proxy. This is accomplished through the iptablesCONNMARKModule.0x111Marking can scale from a single packet to the entire lifecycle of a connection, thereby accelerating the matching of subsequent packets and avoiding duplicate proxy and routing logic. This significantly improves traffic processing performance and reduces system overhead.

iptables rule visualization

The following figure shows the execution path of traffic through the iptables rule to help understand the process of matching and redirecting traffic:

imageIstio ambient pod 内 iptables 可视化

To learn more about how Istio CNI handles iptables, please refer to the codeistio/cni/pkg/iptables/iptables.go at master – istio/istio – GitHub。

Routing visualization for different types of traffic

The following figure shows the encrypted and plaintext traffic paths for same node and cross node respectively.

Encrypted traffic paths across nodes:

imageEncrypted traffic paths across nodes

Explicit traffic paths across nodes:

imageCross-node explicit traffic paths

encrypted traffic paths of the same node:

imageEncrypted traffic paths on the same node

plaintext traffic path of the same node:

imagePlaintext traffic paths on the same node

  1. The application sends a request: Traffic is sent from the application process into the Pod’s network namespace.
  2. iptables rule matching：
    • outbound traffic在OUTPUTare matched in the chain and eligible traffic is redirected to theISTIO_OUTPUTChain.
    • 在ISTIO_OUTPUTIn the chain, traffic is labeled and accepted.
  3. REDIRECT Redirect: Traffic is captured by iptables and redirected to the ztunnel listening port (15006 for plaintext traffic and 15008 for encrypted traffic).
  4. ztunnel handles traffic: ztunnel receives the traffic and performs operations such as policy checking and encryption.
  5. Traffic forwarding to target services: ztunnel sends the processed traffic to the target service.
  6. Return path: The response from the target service is returned over the network to ztunnel, which decrypts and policy-checks the response and returns it to the application.

summarize

By parsing the iptables rules in Istio Ambient mode, we can see that Istio has set up a series of transparent traffic interception rules within the Pod via the CNI plugin. These rules ensure that traffic is handled as expected by the ztunnel agent as it moves in and out of the Pod, enabling more granular traffic management and security policy application. Stay tuned as we continue to explore more details about the network in Istio Ambient mode.