[9주차] Ambient Mode : Ztunnel 트래픽 리디렉션

🚀 ztunnel Traffic Redirection 쉽게 이해하기

• Istio의 ambient mesh에서 ztunnel은 네트워크 트래픽을 관리하는 중요한 역할을 합니다. 

🛠️ Traffic Redirection이란?

• Ambient mesh에서 traffic redirection은 pod로 들어오거나 나가는 트래픽을 ztunnel proxy로 보내는 과정을 말합니다. ztunnel은 트래픽을 가로채 암호화하고 정책을 적용합니다. 이를 통해 보안이 강화되며, ztunnel을 우회하면 정책도 우회될 수 있으므로 이 과정은 매우 중요합니다.

Traffic redirection은
pod 트래픽을 ztunnel로 보내 암호화와 정책 적용을 처리합니다.

---

🧩 In-Pod Traffic Redirection 모델

• Ambient mesh에서는 pod 내부에서 트래픽을 가로채는 방식으로 redirection이 이루어집니다. 이 과정은 istio-cni node agent와 ztunnel proxy가 협력하여 수행됩니다. 이 모델의 장점은 기존 Kubernetes CNI 플러그인과 충돌 없이 동작한다는 점입니다.

🛠️ Pod가 Mesh에 추가되는 과정

• istio-cni가 pod 생성 이벤트를 감지하고, pod가 ambient mesh에 속하는지 확인합니다.
• istio-cni가 pod의 네트워크 namespace에 들어가 리다이렉션 규칙을 설정합니다.
• ztunnel이 pod의 네트워크 namespace에서 포트(15008, 15006, 15001)를 열고 트래픽을 처리합니다

• Istio Ambient Mesh에서 새로운 Pod가 생성되었을 때, Istio CNI와 ztunnel이 어떻게 그 Pod의 트래픽을 자동으로 처리하도록 설정하는지를 설명

https://istio.io/latest/docs/ambient/architecture/traffic-redirection/

🚀 Pod가 새로 생기면 어떤 일이 벌어질까요?

1. istio-cni가 새 Pod를 감지해요
   👉 “오! Ambient Mesh 라벨이 붙은 Pod가 생겼네?”
2. 네트워크 조정 작업 시작!
   • istio-cni가 해당 Pod의 네트워크 공간으로 들어가서:
     👉 “iptables로 트래픽을 ztunnel로 보내게 설정해줄게요!”
3. ztunnel에게 알림
   • istio-cni가 ztunnel에게 알려줘요:
     👉 “이 Pod의 트래픽을 처리할 준비 해줘!”
4. ztunnel이 준비 완료
   • ztunnel은 그 Pod 안에 들어가서 “리스닝 소켓”을 만들어요.
     👉 “이제 이 Pod의 모든 트래픽은 내가 받을 수 있어!”

istio-cni와 ztunnel이 협력하여 pod 트래픽을 리다이렉션합니다.

---

🛠️ 트래픽 흐름

• Pod 간 트래픽은 ztunnel을 거쳐 mTLS로 암호화된 HBONE 터널을 통해 전달됩니다. 이를 통해 pod는 보안 정책을 적용받으며, 애플리케이션은 이를 전혀 인지하지 않아도 됩니다.
• Istio Ambient Mesh에서 ztunnel이 트래픽을 어떻게 가로채고 처리하는지 설명

https://istio.io/latest/docs/ambient/architecture/traffic-redirection/

🟩 1. 들어오는 트래픽 (Inbound) - 예: 누군가 내 앱을 호출할 때

대상: Destination Workload Pod

1. 외부에서 Pod로 들어오는 트래픽은 먼저 15008 포트를 타고 ztunnel로 도착해요.
2. iptables가 이 트래픽을 ztunnel 내부로 보내서 "디코딩/정책 확인" 등을 하게 해요.
3. ztunnel은 트래픽을 진짜 앱이 사용하는 포트 (예: 80번 포트)로 보내요.

➡️ 요약: 들어오는 트래픽은 먼저 ztunnel을 거쳐서 앱으로 전달됨

---

🟦 2. 나가는 트래픽 (Outbound) - 예: 내 앱이 외부로 호출할 때

대상: Source Workload Pod

1. 앱에서 외부로 나가는 트래픽이 생기면, iptables가 그걸 15001 ztunnel 포트로 리다이렉션해요.
2. ztunnel은 그 트래픽에 암호화(encap) 처리 등을 하고,
3. 외부(예: 5151 포트로 통신하는 서비스)로 안전하게 보냅니다.

➡️ 요약: 나가는 트래픽도 ztunnel을 거쳐야 외부로 나갈 수 있음

트래픽은 ztunnel을 통해 mTLS로 암호화되어 안전하게 전달됩니다.

---

🕵️‍♂️ Traffic Redirection 디버깅 방법

• Traffic redirection이 제대로 작동하지 않을 경우, 아래 방법으로 문제를 확인할 수 있습니다.

ztunnel 로그 확인

• ztunnel 로그를 확인하면 pod가 mesh에 추가되었는지, 리다이렉션이 활성화되었는지 알 수 있습니다.

kubectl logs ds/ztunnel -n istio-system  | grep inpod
Found 3 pods, using pod/ztunnel-hl94n
inpod_enabled: true
inpod_uds: /var/run/ztunnel/ztunnel.sock
inpod_port_reuse: true
inpod_mark: 1337
2024-02-21T22:01:49.916037Z  INFO ztunnel::inpod::workloadmanager: handling new stream
2024-02-21T22:01:49.919944Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy
2024-02-21T22:01:49.925997Z  INFO ztunnel::inpod::statemanager: pod received snapshot sent
2024-02-21T22:03:49.074281Z  INFO ztunnel::inpod::statemanager: pod delete request, draining proxy
2024-02-21T22:04:58.446444Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy

• 로그에서 inpod_enabled: true와 같은 메시지가 보이면 리다이렉션이 활성화된 것입니다.

ztunnel 로그로 리다이렉션 상태를 확인할 수 있습니다.

소켓 상태 확인

• 포트 15001, 15006, 15008이 열려 있는지 확인합니다.

kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it -n ambient-demo  --image nicolaka/netshoot  -- ss -ntlp
Defaulting debug container name to debugger-nhd4d.
State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
LISTEN 0      128        127.0.0.1:15080      0.0.0.0:*
LISTEN 0      128                *:15006            *:*
LISTEN 0      128                *:15001            *:*
LISTEN 0      128                *:15008            *:*

• 출력에서 해당 포트가 LISTEN 상태인지 확인하세요.

소켓 상태를 확인해 ztunnel 포트가 열려 있는지 점검합니다.

iptables 규칙 확인

• Pod 내부의 iptables 규칙을 확인해 트래픽 리다이렉션 설정을 점검합니다.

$ kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
Defaulting debug container name to debugger-m44qc.
# Generated by iptables-save
*mangle
:PREROUTING ACCEPT [320:53261]
:INPUT ACCEPT [23753:267657744]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23352:134432712]
:POSTROUTING ACCEPT [23352:134432712]
:ISTIO_OUTPUT - [0:0]
:ISTIO_PRERT - [0:0]
-A PREROUTING -j ISTIO_PRERT
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff
-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
-A ISTIO_PRERT ! -d 127.0.0.1/32 -i lo -p tcp -j ACCEPT
-A ISTIO_PRERT -p tcp -m tcp --dport 15008 -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15008 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
-A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
COMMIT
# Completed
# Generated by iptables-save
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [175:13694]
:POSTROUTING ACCEPT [205:15494]
:ISTIO_OUTPUT - [0:0]
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ACCEPT
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001
COMMIT

• 출력에서 트래픽이 포트 15008(HBONE), 15006(plaintext), 15001(egress)로 리다이렉션되는지 확인할 수 있습니다.

iptables 규칙으로 트래픽 리다이렉션 설정을 확인합니다.

---

📌 핵심 요약

• Traffic redirection은 pod 트래픽을 ztunnel로 보내 암호화와 정책을 적용합니다.
• istio-cni와 ztunnel이 협력하여 pod의 네트워크 namespace에서 리다이렉션을 설정합니다.
• 트래픽은 ztunnel을 거쳐 mTLS로 암호화된 HBONE 터널로 전달됩니다.
• 디버깅은 ztunnel 로그, 소켓 상태, iptables 규칙 확인으로 진행합니다.