DEVOCEAN

사내 빅데이터 플랫폼을 Cloud Native 환경에서 개발하고 있습니다.

20PiB 규모의 데이터를 최저 network 비용을 사용해 통신할 수 있는 구조를 확보해야 합니다.

제조 빅데이터의 특징은 쿼리 수행 규모가 매우 큽니다.

하루 60만건 정도의 빅데이터 ad-hoc 쿼리를 처리할 수 있는 분산 환경을 구성해야 하는데,

현재 200G Sprine -> 40G*2(bonding) Leaf 기반의 네트워크 토폴로지에서 microburst 현상이 자주 발견되어

극단적인 K8S 네트워크 최적화에 대한 검증을 하고 있습니다.

그 일환으로 Istio Mesh를 적용하여 각 노드간의 observability를 확보할려고 했으나 빅데이터 서비스 환경에는 적합하지 않다는 결론을 내렸고,

그 다음 단계로 Istio Ambient를 사용하여 트래픽 관리 및 어플리케이션의 가시성을 확보할려고 했으나 역시 적절한 기술이 아니라는 결론을 얻었습니다.

몇 가지 테스트한 내용 중 일부를 공유합니다.

결론

• Cloud Native 기반 빅데이터 플랫폼 서비스의 아키텍처에는 적합하지 않음

• 노드에서 실행하는 수 많은 분산 컴포넌트의 통신을 ztunnel을 통해 라우팅될 경우 bottleneck이 발생하는 악성 구조 유발

• mTLS를 위해 zTunnel을 사용하는 이점만큼 병목이라는 단점이 극대화

• waypoint는 north-south 통신을 위한 gateway 역할을 기대했으나, 실제로는 ztunnel을 통해 라우팅되는 만큼 Direct Return 구조가 중요한 분산 환경에서 사용할 수 없는 구조

• 현재의 Istio와 Istio Ambient는 대규모 분산 트랜잭션과 트래픽을 위한 설계는 고려되지 않은것으로 파악됨

• Kmesh 역시 istiod를 통해 실행되는 구조이기 때문에 L3 라우팅이 bpf로 처리된다고 해도 cilium 단일 CNI로 모두 대응 가능

• 특히 Istio Ambient 모드를 실행하기 위해서 Cilium CNI의 ebp.masquerade 모드를 false로 설정해야 하기 때문에 노드간의 라우팅은 iptables에 의존해야하는 불합리가 발생

  -> true일 경우 원본 source ip가 변경될 수 있기 때문에 라우팅 오류 발생

Refernence

https://www.anyflow.net/sw-engineer/istio-ambient-mode

https://teamblog.joonggonara.co.kr/istio-sidecar-%EC%95%88%EB%85%95-ambient-%ED%99%98%EC%98%81-41b71e8671eb

https://inspirit941.tistory.com/553

https://academy.tetrate.io/courses/take/istio-fundamentals

https://istio.io/latest/blog/2024/ambient-reaches-ga/

https://istio.io/latest/blog/2023/traffic-for-ambient-and-sidecar/

https://istio.io/latest/blog/2023/ambient-ebpf-redirection/

Jimmysong Blog

https://jimmysong.io/en/blog/beyond-sidecar/*

https://jimmysong.io/en/blog/istio-ambient-l7-flow-analysis/

https://jimmysong.io/en/blog/istio-ambient-packet-lifecycle-optimization/

https://jimmysong.io/en/blog/istio-ambient-inpod-iptables/*

https://jimmysong.io/en/blog/istio-ambient-traffic-interception/

https://jimmysong.io/en/blog/istio-sidecar-vs-ambient-network-cost-performance/

https://jimmysong.io/en/blog/introducing-kmesh-kernel-native-service-mesh/

https://jimmysong.io/en/blog/service-mesh-data-plane-deployment-modes/*

https://jimmysong.io/en/blog/istio-cni-deep-dive/*

https://jimmysong.io/en/blog/cni-deep-dive/*

1. Istio Blog

Introducing Ambient Mesh

사이드카 없는 istio 데이터플레인 모드 : A new dataplane mode for Istio without sidecars - Blog

• 앰비언트 메시는 사용자에게 사이드카 프록시 대신 인프라에 통합된 데이터 플레인을 사용할 수 있는 옵션을 제공하며,

  동시에 Istio의 핵심 기능인 제로 트러스트 보안, 원격 측정, 트래픽 관리는 그대로 유지됩니다.

• Istio Sidecar Data Plane vs Ambient Mesh Data Plane 비교

  
  

  Pod 1개당 1개의 Sidecar Proxy vs. Node 1개당 1개의 ztunnel

• Sidecar (Proxy 모든 기능 담당) vs Ambient Mesh (L4 Proxy 와 L7 Proxy 기능 분리)

Istio Ambient Mesh : A new, open source contribution to the Istio project, that defines a new sidecar-less data plane

• Istio and sidecars 방식 : 파드 마다 Sidecar Proxy 배치

• Istio Ambient Mesh 방식

  • 파드들은 해당 노드에 존재하는 ztunnel 파드를 공유하여 다른 파드들(동일 노드, 다른 노드)과 안전한 통신 환경을 제공

  • Ambient mesh uses a shared, per-node ztunnel to provide a zero-trust secure overlay

  
  

Basic ztunnel L4-only datapath -> ambient 모드가 적용된 Pod는 hbone 통신(미적용된 Pod는 TCP)

• Layer7 통제와 정책이 필요 시, Waypoint Proxy 파드를 통하여 기능을 구현

  • When additional features are needed, ambient mesh deploys waypoint proxies, which ztunnels connect through for policy enforcement

    -> 이러한 구조 때문에 대규모 분산 트랜잭션 서비스에는 적합하지 않음

Ztunnel datapath via an interim waypoint

• HBONE HTTP Based Overlay Network Encapsulation는 애플리케이션 통신 트래픽을 HTTP CONNECT 메서드를 통해 표준 HTTP 터널링을 사용합니다.

  TCP 상위에 HTTP/2를 사용하며, TLS를 통해 상호 인증과 암호를 제공합니다. HBONE tunnel 은 TCP 15008 포트를 사용합니다 - HTTP CONNECT & HTTP/2

• HBONE Protocol

• Ztunnel 동작 : Istiod에서 ztunnel 에 xDS Config 구성, ztunnel 연결 구성

• Ztunnel architecture : ztunnel 파드 내부 구조와 초기 동작

  참고) https://istio.io/latest/blog/2023/rust-based-ztunnel/

• Ztunnel and Waypoint : L7 필터/통제는 목적지 파드에 매칭되는 Waypoint proxy를 통해 기능 구현

• SPIFFE : Specification for a framework to bootstrap and issue identity across heterogeneous environments

• SPIRE : Implementation of the SPIFFE spec

• L4 telemetry provided by ztunnel

• Security Deep Dive : ztunnel 을 통해 Secure Overlay 를 제공, Waypoint는 L7 통제/정책 제공 - Link

통신 흐름 상세 - Link

• 공통 : 파드 트래픽을 ztunnel 로 redirection 하기 위해서, Istio CNI DaemonSet 을 활용

⇒ sidecar proxy 를 경유하기 위해서 파드 내에서 초기화 컨테이너로 iptables 설정한 것 처럼,

ztunnel 를 경유하기 위해서 istio cni DaemonSet 이 CNI Network Plugin 으로 호스트 네트워크 네임스페이스에 iptables 과 ztunnel 파드 내부에 iptables 에 설정함.

⇒ 현재는 다른 방식을 사용 중!

1. Ambient mode sleep → sidecar mode httpbin

• foo 네임스페이스는 ambient mode 활성화 : istio.io/dataplane-mode=ambient

• bar 네임스페이스는 sidecar mode 활성화 : istio-injection: enabled

  참고) https://istio.io/latest/blog/2023/traffic-for-ambient-and-sidecar/

(1)(2)(3) sleep 파드에서 bar NS의 httpbin 목적지로 요청 ⇒ Istio CNI DaemonSet에 의해서 설정된 iptables 에 따라, 요청 트래픽이 istioout → (Geneve Tunnel) → pistoout 전달

(4)(5) pistoout 은 iptables rule 을 통해 파드 내의 eth0 인터페이스에 port 15001로 redirect

(6) ztunnel 파드는 목적지 httpbin 정보를 기반으로 전달 ⇒ 노드 B eth0

(7) 요청 트패릭은 httpbin 파드 내의 iptables rule 을 통해 port 15006로 redirect 되고 이후 목적지 httpbin 파드에 도착

2. Sidecar mode sleep → ambient mode httpbin and helloworld (waypoint proxy enabled)

• foo 네임스페이스는 sidecar mode 활성화 : istio-injection: enabled

• bar-1, bar-2 네임스페이스는 ambient mode 활성화 : istio.io/dataplane-mode=ambient

• httpbin은 waypoint proxy disabled

• helloworld는 waypoint proxy enabled

  참고) https://istio.io/latest/blog/2023/traffic-for-ambient-and-sidecar/

• Sidecar mode sleep → ambient mode httpbin (waypoint proxy disabled)

(1)(2) Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨

(3) 목적지 httpbin 파드는 waypoint proxy disabled로 목적지 파드가 있는 (오른쪽 상단) 워커 노드 B로 전달됨

(4)(5)(6) veth httpbin ↔ httpbin 파드 내 eth0 과 device pair 관계이지만, iptables rule에 의해 가로채어 istioin → pistioin device로 전달

(7)(8) ztunnel 파드 내에 iptables rule에 의해 port 15008 redirect

(9) 최종적으로 httpbin 파드로 전달

• Sidecar mode sleep → ambient mode helloworld (waypoint proxy enabled)

(1)(2) Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨

(3) 목적지 helloworld 파드는 waypoint proxy enabled로 waypoint 파드가 있는 (왼쪽 하단) 워커 노드 C(Port 15008)로 전달됨

(4) waypoint 파드는 control plane 을 통해 받은 라우팅 정보로 helloworld 파드가 있는 (오른쪽 하단) 워커 노드 D로 전달됨

(5)~(10) 위 httpbin 파드 내부 과정과 동일

Istio and sidecars 사이드카 제약

• Istio 아키텍처의 핵심적인 특징 중 하나는 애플리케이션 컨테이너와 함께 배포되는 프로그래밍 가능한 프록시인 사이드카를 사용하는 것이었습니다.

• 사이드카를 통해 운영자는 애플리케이션에 큰 수정이나 관련 비용 없이 Istio의 이점을 누릴 수 있습니다.

Istio의 기존 모델 traditional model 은 워크로드의 Pod 내에 사이드카로 Envoy 프록시를 배포합니다.

• 사이드카는 애플리케이션 리팩토링에 비해 상당한 이점을 제공하지만, 애플리케이션과 Istio 데이터 플레인을 완벽하게 분리하지는 못합니다.

• 이로 인해 다음과 같은 몇 가지 제약이 발생합니다.

1. 침입성(간섭) Invasiveness

   • 사이드카는 쿠버네티스 포드 사양을 수정하고 포드 내 트래픽을 리디렉션하여 애플리케이션에 "주입"해야 합니다.

   • 따라서 사이드카를 설치하거나 업그레이드하려면 애플리케이션 포드를 다시 시작해야 하며, 이는 워크로드에 지장을 줄 수 있습니다.

2. 리소스 활용도 저하 Underutilization of resources

   • 사이드카 프록시는 관련 워크로드에 전념하므로, 각 개별 포드의 최악의 사용 상황을 고려하여 CPU 및 메모리 리소스를 프로비저닝해야 합니다.

   • 이로 인해 대규모 예약이 발생하여 클러스터 전체의 리소스 활용도가 저하될 수 있습니다.

3. 트래픽 차단 Traffic breaking

   • Istio의 사이드카에서 일반적으로 수행되는 트래픽 캡처 및 HTTP 처리에는 컴퓨팅 비용이 많이 들고,

   • HTTP 구현에 맞지 않는 일부 애플리케이션을 중단시킬 수 있습니다.

⇒ 사이드카가 나름의 역할을 하고 있지만 우리는 많은 서비스 메시 사용자에게 더 적합하고, 덜 침입적(간섭적)이고 사용하기 쉬운 옵션이 필요하다고 생각합니다.

Slicing the layers 두 개의 레이어 분리 : L7 Processing Layer, Secure Overlay

• 전통적으로 Istio는 기본 암호화부터 고급 L7 정책까지 모든 데이터 플레인 기능을 단일 아키텍처 구성 요소인 사이드카에 구현합니다.

• 하지만 실제로는 이러한 방식으로 사이드카는 '모두 아니면 전무 all-or-nothing proposition'의 문제가 됩니다.

• 워크로드에 간단한 전송 보안만 필요한 경우에도 관리자는 사이드카를 구축하고 유지하는 데 드는 운영 비용을 부담해야 합니다.

• 사이드카는 워크로드당 고정된 운영 비용을 가지며, 사용 사례의 복잡성에 따라 확장되지 않습니다.

• 앰비언트 데이터 플레인은 다른 접근 방식을 취합니다. Istio의 기능을 두 개의 개별 계층으로 분할합니다.

• 가장 아래에는 라우팅과 트래픽에 대한 제로 트러스트 보안을 처리하는 보안 오버레이가 있습니다.

• 그 위에는 필요에 따라 사용자가 L7 프로세싱을 활성화하여 모든 Istio 기능에 액세스할 수 있습니다.

• L7 프로세싱 모드는 보안 오버레이보다 무겁지만, 인프라의 앰비언트 구성 요소로 실행되므로 애플리케이션 파드를 수정할 필요가 없습니다.

Layers of the ambient mesh

• 이러한 계층적 접근 방식을 통해 사용자는 Istio를 더욱 점진적으로 도입하여 필요에 따라 네임스페이스별로 메시 없음에서 보안 오버레이, 그리고 완전한 L7 처리로 원활하게 전환할 수 있습니다.

• 또한, 서로 다른 앰비언트 계층에서 실행되거나 사이드카를 통해 실행되는 워크로드가 원활하게 상호 운용되므로 사용자는 시간이 지남에 따라 변화하는 특정 요구 사항에 따라 기능을 조합하고 조정할 수 있습니다.

Building an ambient mesh 앰비언트 매시 동작 소개

• Istio의 앰비언트 데이터 플레인 모드는 쿠버네티스 클러스터의 각 노드에서 실행되는 공유 에이전트를 사용합니다.

• 이 에이전트는 제로 트러스트 터널(또는 ztunnel )이며, 주요 역할은 메시 내 요소를 안전하게 연결하고 인증하는 것입니다.

• 노드의 네트워킹 스택은 로컬 ztunnel 에이전트를 통해 참여 워크로드의 모든 트래픽을 리디렉션합니다.

• 이를 통해 Istio 데이터 플레인과 애플리케이션의 문제가 완전히 분리되어 운영자가 애플리케이션을 중단하지 않고 데이터 플레인을 활성화, 비활성화, 확장 및 업그레이드할 수 있습니다.

• ztunnel은 워크로드 트래픽에 대해 L7 처리를 수행하지 않으므로 사이드카보다 훨씬 효율적입니다.

• 복잡성과 관련 리소스 비용이 크게 감소하여 공유 인프라로 제공하기에 적합합니다.

• Ztunnels는 서비스 메시의 핵심 기능인 제로 트러스트를 지원합니다.

• 네임스페이스에 대해 앰비언트 모드가 활성화되면 보안 오버레이가 생성됩니다.

• HTTP를 종료하거나 파싱하지 않고도 mTLS, 원격 분석, 인증 및 L4 권한 부여를 위한 워크로드에게 제공합니다.

Ambient mesh uses a shared, per-node ztunnel to provide a zero-trust secure overlay

• Ambient 모드가 활성화되고 보안 오버레이가 생성된 후 L7 기능을 활용하도록 네임스페이스를 구성할 수 있습니다.

• 이를 통해 네임스페이스는 Virtual Service API , L7 원격 측정 및 L7 권한 부여 정책을 포함한 Istio 전체 기능을 구현할 수 있습니다.

• 이 모드에서 작동하는 네임스페이스는 하나 이상의 Envoy 기반 waypoint proxy를 사용하여 해당 네임스페이스의 워크로드에 대한 L7 처리를 처리합니다.

• Istio의 제어 평면은 클러스터의 ztunnel을 구성하여 L7 처리가 필요한 모든 트래픽을 웨이포인트 프록시를 통해 전달합니다.

• 중요한 점은 Kubernetes 관점에서 웨이포인트 프록시는 다른 Kubernetes 배포와 마찬가지로 자동 확장이 가능한 일반 포드일 뿐입니다.

• 웨이포인트 프록시는 최악의 경우 운영자가 예상하는 최대 부하가 아닌 제공하는 네임스페이스의 실시간 트래픽 수요에 맞게 자동 확장될 수 있으므로 이를 통해 사용자에게 상당한 리소스 절감 효과가 있을 것으로 예상합니다.

When additional features are needed, ambient mesh deploys waypoint proxies, which ztunnels connect through for policy enforcement

• 앰비언트 메시는 mTLS 기반 HTTP CONNECT를 사용하여 보안 터널을 구현하고 경로에 웨이포인트 프록시를 삽입합니다.

• 이 패턴을 HBONE(HTTP 기반 오버레이 네트워크 환경) 이라고 합니다.

• HBONE은 TLS 단독 사용 시보다 트래픽을 더욱 깔끔하게 캡슐화하는 동시에 일반적인 로드 밸런서 인프라와의 상호 운용성을 지원합니다.

• 규정 준수 요건을 충족하기 위해 FIPS 빌드가 기본적으로 사용됩니다.

• HBONE, 표준 기반 접근 방식, 그리고 UDP 및 기타 비 TCP 프로토콜에 대한 계획에 대한 자세한 내용은 향후 블로그에서 제공될 예정입니다.

• 단일 메시 환경에서 사이드카 모드와 앰비언트 모드를 혼합하더라도 시스템의 기능이나 보안 속성에 제한이 발생하지 않습니다.

• Istio 제어 평면은 선택한 배포 모델에 관계없이 정책이 적절하게 시행되도록 보장합니다.

• 앰비언트 모드는 단순히 더 나은 인체공학성과 유연성을 제공하는 옵션을 제공할 뿐입니다.

Why no L7 processing on the local node? 로컬 노드에서 L7 처리가 없는 이유?

• 앰비언트 모드는 노드에서 공유 ztunnel 에이전트를 사용하여 메시의 제로 트러스트 기능을 처리하는 반면, L7 처리는 별도로 예약된 포드의 웨이포인트 프록시에서 수행됩니다.

• 노드에서 공유 전체 L7 프록시를 사용하지 않고 간접 연결을 사용하는 이유는 무엇일까요? 여기에는 몇 가지 이유가 있습니다.

1. Envoy는 본질적으로 멀티 테넌트가 아닙니다.

   • 따라서 공유 인스턴스에서 제약이 없는 여러 테넌트의 L7 트래픽에 대한 복잡한 처리 규칙을 혼합하는 데 보안 문제가 있습니다.

   • L4 처리로 엄격하게 제한함으로써 취약점 노출 영역을 크게 줄였습니다.

2. ztunnel이 제공하는 mTLS 및 L4 기능은 웨이포인트 프록시에 필요한 L7 처리량에 비해 훨씬 적은 CPU 및 메모리 사용량을 필요로 합니다.

   • 웨이포인트 프록시를 공유 네임스페이스 리소스로 실행하면 해당 네임스페이스의 요구에 따라 독립적으로 확장할 수 있으며, 관련 없는 테넌트에 비용이 불공평하게 분배되지 않습니다.

3. ztunnel의 범위를 줄이면 잘 정의된 상호 운용성 계약을 충족할 수 있는 다른 보안 터널 구현으로 대체될 수 있습니다.

But what about those extra hops? 하지만 추가된 홉은 어떻게 되나요?

• 앰비언트 모드에서는 웨이포인트가 해당 워크로드와 동일한 노드에 있을 것이라고 보장할 수 없습니다.

• 언뜻 보기에는 성능 문제로 보일 수 있지만, 궁극적으로는 Istio의 현재 사이드카 구현 방식과 동일한 수준의 지연 시간을 제공할 것으로 확신합니다.

• 자세한 내용은 성능 관련 블로그 게시물에서 다루겠지만, 우선 두 가지 요점으로 요약하겠습니다.

1. Istio 네트워크 지연 시간의 대부분은 사실 네트워크 자체에서 발생하는 것이 아닙니다( 현대 클라우드 제공업체는 매우 빠른 네트워크를 보유하고 있습니다 ).

   • 가장 큰 원인은 Istio가 정교한 기능 세트를 구현하는 데 필요한 집중적인 L7 처리입니다.

   • 각 연결에 대해 두 단계의 L7 처리 단계(사이드카당 하나씩)를 구현하는 사이드카와 달리, 앰비언트 모드는 이 두 단계를 하나로 통합합니다.

   • 대부분의 경우, 이렇게 감소된 처리 비용은 추가 네트워크 홉을 상쇄할 것으로 예상됩니다.

2. 사용자는 종종 첫 번째 단계로 메시를 구축하여 제로 트러스트 보안 태세를 구축한 후 필요에 따라 선택적으로 L7 기능을 활성화합니다.

   • 앰비언트 모드를 사용하면 L7 처리 비용이 전혀 들지 않을 때 L7 처리 비용을 완전히 절감할 수 있습니다.

* 이 설명은 Cilium 기반으로 L4 영역까지 zero trust 환경을 구축하고 모든 패킷의 통신을 eBFP로 처리할 수 있게할 경우 동일한 수준 달성 가능

Resource overhead 리소스 오버헤드

• 전반적으로 Istio의 앰비언트 모드는 대부분의 사용자에게 점점 더 예측 가능한 리소스 요구 사항이 줄어들 것으로 예상됩니다.

• ztunnel의 제한된 책임으로 인해 노드에서 공유 리소스로 배포할 수 있습니다. 이렇게 하면 대부분의 사용자에게 필요한 워크로드당 예약을 크게 줄일 수 있습니다.

• 또한, 웨이포인트 프록시는 일반적인 쿠버네티스 포드이므로, 제공하는 워크로드의 실시간 트래픽 수요에 따라 동적으로 배포하고 확장할 수 있습니다.

• 반면 사이드카는 각 워크로드에 대해 최악의 상황을 대비하여 메모리와 CPU를 예약해야 합니다.

• 이러한 계산은 복잡하기 때문에 실제로 관리자는 과도하게 프로비저닝하는 경향이 있습니다.

• 이로 인해 다른 워크로드를 예약할 수 없는 과도한 예약으로 인해 노드 활용도가 낮아집니다.

• 앰비언트 모드는 노드당 고정 오버헤드가 낮고 동적으로 확장되는 웨이포인트 프록시를 사용하므로 전체적으로 훨씬 적은 리소스 예약이 필요하므로 클러스터를 더욱 효율적으로 사용할 수 있습니다.

What about security? 보안은 어떻습니까?

• 완전히 새로운 아키텍처는 자연스럽게 보안에 대한 의문을 제기합니다. 앰비언트 모드 보안 블로그에서 심층 분석을 제공하지만, 여기서는 간략하게 설명하겠습니다.

• 사이드카는 서비스하는 워크로드와 함께 배치되므로, 한쪽의 취약점이 다른 쪽을 손상시킵니다.

• 앰비언트 메시 모델에서는 애플리케이션이 손상되더라도 ztunnel과 웨이포인트 프록시는 손상된 애플리케이션의 트래픽에 대해 엄격한 보안 정책을 적용할 수 있습니다.

• 더욱이, Envoy는 세계 최대 규모의 네트워크 운영업체에서 사용하는 검증된 소프트웨어라는 점을 고려할 때, 함께 실행되는 애플리케이션보다 취약성이 낮을 가능성이 높습니다.

• ztunnel은 공유 리소스이지만, 현재 실행 중인 노드에 있는 워크로드의 키에만 접근할 수 있습니다.

• 따라서 공격 반경은 노드별 키에 기반한 암호화된 CNI보다 나쁘지 않습니다.

• 또한 ztunnel의 제한된 L4 전용 공격 표면 영역과 앞서 언급한 Envoy의 보안 특성을 고려할 때, 이러한 위험은 제한적이며 허용 가능하다고 생각합니다.

• 마지막으로, 웨이포인트 프록시는 공유 리소스이지만 하나의 서비스 계정만 지원하도록 제한될 수 있습니다.

• 이는 사이드카보다 더 심각한 문제는 아닙니다.

• 하나의 웨이포인트 프록시가 손상되면 해당 웨이포인트와 연결된 자격 증명만 손실되고 다른 것은 아무것도 남지 않습니다.

Is this the end of the road for the sidecar? 사이드카 종말?

• 절대 아닙니다. 앞으로 많은 메시 사용자에게 앰비언트 메시가 최선의 선택이 될 것이라고 생각하지만, 규정 준수나 성능 튜닝과 같이 전용 데이터 플레인 리소스가 필요한 사용자에게는 사이드카가 여전히 좋은 선택입니다.

• Istio는 사이드카를 계속 지원할 것이며, 중요한 것은 사이드카가 앰비언트 모드와 원활하게 상호 운용될 수 있도록 지원할 것입니다.

• 실제로 오늘 출시되는 앰비언트 모드 코드는 이미 사이드카 기반 Istio와의 상호 운용성을 지원합니다.

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

Istio 앰비언트 메시를 위한 노드별 프록시 : A purpose-built per-node proxy for Istio ambient mesh - Blog

• ztunnel(제로 트러스트 터널) 구성 요소는 Istio 앰비언트 메시를 위해 특별히 설계된 노드별 프록시입니다.

• 앰비언트 메시 내에서 워크로드를 안전하게 연결하고 인증하는 역할을 합니다.

• Ztunnel은 워크로드 HTTP 트래픽을 종료하거나 워크로드 HTTP 헤더를 파싱하지 않고도 mTLS, 인증, L4 권한 부여, 원격 측정과 같은 앰비언트 메시 내 워크로드를 위한 소수의 기능에 집중하도록 설계되었습니다.

• ztunnel은 HTTP 원격 측정 및 부하 분산과 같은 Istio의 모든 기능이 구현된 웨이포인트 프록시로 트래픽이 효율적이고 안전하게 전송되도록 보장합니다.

• ztunnel은 모든 쿠버네티스 워커 노드에서 실행되도록 설계되었으므로 리소스 사용량을 작게 유지하는 것이 중요합니다.

• Ztunnel은 워크로드에 미치는 영향을 최소화하면서 서비스 메시의 보이지 않는(또는 "주변") 부분으로 설계되었습니다.

Ztunnel architecture : xDS Client, CA Client, L4 Policy enforcement, L4 Telemetry

Ztunnel architecture - 사이드카와 유사하게 ztunnel 은 xDS 클라이언트 및 CA 클라이언트 역할도 수행:

1. 시작 시 서비스 계정 토큰을 사용하여 Istiod 제어 평면에 안전하게 연결합니다.

   • ztunnel에서 Istiod로의 연결이 TLS를 사용하여 안전하게 설정되면 xDS 클라이언트로서 xDS 구성을 가져오기 시작합니다.

   • 이는 사이드카, 게이트웨이 또는 웨이포인트 프록시와 유사하게 작동하지만, Istiod가 ztunnel의 요청을 인식하고 ztunnel용으로 특별히 제작된 xDS 구성을 전송한다는 점이 다릅니다.

2. 또한 관리하는 모든 공동 작업 부하를 대신하여 mTLS 인증서를 관리하고 제공하는 CA 클라이언트 역할도 수행합니다.

3. 트래픽이 들어오고 나갈 때, 관리하는 모든 공동 배치 워크로드에 대한 인바운드 및 아웃바운드 트래픽(메시 외부 일반 텍스트 또는 메시 내부 HBONE)을 처리하는 핵심 프록시 역할을 합니다.

4. 필요한 경우 ztunnel을 디버깅하는 데 도움이 되는 디버깅 정보가 포함된 관리 서버와 함께 L4 원격 측정(메트릭 및 로그)을 제공합니다.

Why not reuse Envoy? Envoy를 재사용하지 않는 이유? ⇒ ztunnel 은 L7 기능 불필요

• 2022년 9월 7일 Istio 앰비언트 서비스 메시가 발표되었을 때 ztunnel은 Envoy 프록시를 사용하여 구현되었습니다.

• 사이드카, 게이트웨이, 웨이포인트 프록시 등 Istio의 나머지 부분에도 Envoy를 사용하고 있다는 점을 고려하면, Envoy를 사용하여 ztunnel을 구현하는 것은 당연한 일이었습니다.

• 하지만 Envoy가 다른 사용 사례에는 매우 적합했지만, Envoy에서 ztunnel을 구현하는 것은 쉽지 않았습니다. 사이드카 프록시나 인그레스 게이트웨이와는 장단점, 요구 사항, 사용 사례가 크게 다르기 때문입니다.

• 게다가 Envoy를 다른 사용 사례에 매우 적합하게 만드는 풍부한 L7 기능 세트와 확장성 같은 요소들이 ztunnel에서는 쓸모없게 되었습니다. ztunnel에는 이러한 기능이 필요하지 않았기 때문입니다.

A purpose-built ztunnel

• Envoy를 저희의 필요에 맞게 변형하는 데 어려움을 겪은 후, 저희는 ztunnel을 특수 목적에 맞게 구현하는 방법을 모색하기 시작했습니다.

• 처음부터 단일 사용 사례에 집중하여 설계하면, 범용 프로젝트를 저희의 맞춤형 사용 사례에 맞춰 만드는 것보다 더 간단하고 성능이 뛰어난 솔루션을 개발할 수 있을 것이라는 가설이 있었습니다.

• ztunnel을 단순하게 만들기로 한 명확한 결정이 이 가설의 핵심이었습니다.

• 예를 들어, 지원되는 기능과 통합 기능이 매우 많은 게이트웨이를 다시 작성하는 경우에는 이러한 논리가 적용되지 않을 것입니다.

• 이 특수 목적의 터널에는 두 가지 주요 영역이 포함됩니다.

  • ztunnel과 Istiod 간의 구성 프로토콜

  • ztunnel의 런타임 구현

Configuration protocol 설정 프로토콜

• Envoy 프록시는 구성에 xDS 프로토콜을 사용합니다.

• 이는 Istio가 원활하게 작동하도록 하는 핵심 요소이며, 풍부하고 동적인 구성 업데이트를 제공합니다.

• 하지만 기존 방식을 벗어나면서 구성은 점점 더 맞춤형으로 바뀌어 훨씬 더 크고 생성 비용도 더 많이 듭니다.

• 사이드카에서 1개의 포드를 가진 단일 서비스는 약 350줄의 xDS(YAML 형식)를 생성하는데, 이는 이미 확장이 어려운 문제였습니다.

• Envoy 기반 ztunnel은 훨씬 더 나빴고, 일부 영역에서는 N^2개의 확장 속성을 사용했습니다.

• ztunnel 구성을 최대한 작게 유지하기 위해, 필요한 정보만 (그 이상은 포함하지 않고) 효율적인 형식으로 정확하게 포함하는 특수 제작 구성 프로토콜을 사용하여 조사했습니다.

• 예를 들어, 단일 포드는 다음과 같이 간결하게 표현할 수 있습니다.

  • 이 정보는 xDS 전송 API를 통해 전송되지만, custom ambient-specific type 을 사용합니다. 사용자 지정 주변 환경별 유형

  • 구성 세부 정보에 대한 자세한 내용은 워크로드 xDS 구성 섹션 을 참조하세요.

name: helloworld-v1-55446d46d8-ntdbk
namespace: default
serviceAccount: helloworld
node: ambient-worker2
protocol: TCP
status: Healthy
waypointAddresses: []
workloadIp: 10.244.2.8
canonicalName: helloworld
canonicalRevision: v1
workloadName: helloworld-v1
workloadType: deployment

• a purpose built API 전용 API를 사용하면 Envoy 구성 대신 프록시에 로직을 푸시할 수 있습니다.

• 예를 들어 Envoy에서 mTLS를 구성하려면 각 서비스의 TLS 설정을 정밀하게 조정하는 동일한 대규모 구성 세트를 추가해야 합니다.

• ztunnel에서는 mTLS 사용 여부를 선언하는 열거형 하나만 있으면 됩니다. 나머지 복잡한 로직은 ztunnel 코드에 직접 내장됩니다.

• Istiod와 ztunnel 간의 효율적인 API를 통해 10만 개의 포드가 있는 메시와 같은 대규모 메시에 대한 정보로 ztunnel을 구성할 수 있었고, 구성이 엄청나게 줄어 CPU, 메모리, 네트워크 비용이 절감되었습니다.

Runtime implementation 런타임 구현 & A Rust-based ztunnel

• 이름에서 알 수 있듯이 ztunnel은 HTTPS 터널을 사용하여 사용자 요청을 전달합니다.

• Envoy는 이 터널링을 지원하지만, 구성 모델이 저희의 요구 사항에는 제한적이라는 것을 알게 되었습니다.

• Envoy는 요청을 수락하는 것부터 시작하여 요청을 전송하는 것까지 일련의 "필터"를 통해 요청을 전송하는 방식으로 작동합니다.

• 터널 자체와 사용자 요청이라는 여러 계층의 요청이 있고, 로드 밸런싱 후 포드별 정책을 적용해야 하는 저희의 요구 사항을 고려했을 때, 이전 Envoy 기반 ztunnel을 구현할 때 연결당 이러한 필터를 4번씩 반복해야 했습니다.

• Envoy는 메모리에서 "자기 자신에게 요청을 전송"하는 데 있어 몇 가지 최적화를 제공했지만 , 여전히 매우 복잡하고 비용이 많이 들었습니다.

• 자체 구현을 구축함으로써 이러한 제약 조건을 처음부터 고려하여 설계할 수 있었습니다.

• 또한, 설계의 모든 측면에서 더 큰 유연성을 확보할 수 있었습니다.

• 예를 들어, 여러 스레드 간에 연결을 공유하거나 서비스 계정 간 격리를 중심으로 더욱 맞춤형 요구 사항을 구현할 수 있었습니다.

• 특수 목적 프록시가 실행 가능하다는 것을 확인한 후, 구현 세부 사항을 선택하기 시작했습니다.

A Rust-based ztunnel

• ztunnel을 빠르고 안전하며 가볍게 만들겠다는 목표에 따라 Rust는 당연한 선택이었습니다. 하지만 Rust가 저희의 첫 번째 선택은 아니었습니다.

• Istio가 현재 Go를 광범위하게 사용하고 있다는 점을 고려했을 때, 저희는 Go 기반 구현으로 이러한 목표를 달성할 수 있기를 바랐습니다.

• 초기 프로토타입에서는 Go 기반 구현과 Rust 기반 구현의 간단한 버전을 모두 구축했습니다.

• 테스트 결과, Go 기반 버전은 성능 및 설치 공간 요구 사항을 충족하지 못했습니다.

• 더 최적화할 수 있었을 가능성도 있지만, Rust 기반 프록시가 장기적으로 최적의 구현을 제공할 것이라고 생각했습니다.

• Envoy의 일부를 재사용하는 C++ 구현도 고려되었습니다.

• 그러나 메모리 안전성 부족, 개발자 경험 문제, 그리고 Rust를 선호하는 업계 전반의 추세로 인해 이 옵션은 추진되지 않았습니다.

• 이러한 제거 과정을 거쳐 Rust가 탄생했고, Rust는 우리에게 딱 맞는 선택이었습니다.

• Rust는 고성능, 저리소스 애플리케이션, 특히 네트워크 애플리케이션(서비스 메시 포함)에서 탄탄한 성공 사례를 보유하고 있습니다.

• 저희는 생태계의 사실상 표준으로 자리 잡은 두 가지 라이브러리인 Tokio 와 Hyper 라이브러리를 기반으로 개발하기로 했습니다.

• 이 라이브러리들은 광범위한 실전 테스트를 거쳤으며, 고성능 비동기 코드를 쉽게 작성할 수 있습니다.

A quick tour of the Rust-based ztunnel

Workload xDS configuration 워크로드 xDS 구성

• localhost:15000/config_dump 워크로드 xDS 구성은 이해하고 디버깅하기가 매우 쉽습니다.

• ztunnel 포드 중 하나에서 요청을 보내거나 편리한 명령을 사용하여 확인할 수 있습니다 istioctl pc workload.

• 워크로드 xDS 구성에는 워크로드와 정책이라는 두 가지 주요 구성이 있습니다.

• 워크로드가 앰비언트 메시에 포함되기 전에는 ztunnel의 구성 덤프에서 해당 워크로드를 확인할 수 있습니다. ztunnel은 앰비언트 활성화 여부와 관계없이 모든 워크로드를 인식하기 때문입니다.

• 예를 들어, 아래는 새로 배포된 helloworld v1 포드의 샘플 워크로드 구성입니다. 이 포드는 메시 외부(out-of-mesh)로 표시되어 있습니다 protocol: TCP.

{
  "workloads": {
    "10.244.2.8": {
      "workloadIp": "10.244.2.8",
      "protocol": "TCP", # mesh 내부 통신을 하지 않음
      "name": "helloworld-v1-cross-node-55446d46d8-ntdbk",
      "namespace": "default",
      "serviceAccount": "helloworld",
      "workloadName": "helloworld-v1-cross-node",
      "workloadType": "deployment",
      "canonicalName": "helloworld",
      "canonicalRevision": "v1",
      "node": "ambient-worker2",
      "authorizationPolicies": [],
      "status": "Healthy"
    }
  }
}

• 포드가 ambient에 포함된 후(네임스페이스 default를 로 레이블 지정 istio.io/dataplane-mode=ambient) 해당 protocol값은 로 바뀌어 HBONEztunnel이 helloworld-v1 포드에서 들어오고 나가는 모든 통신을 HBONE으로 업그레이드하도록 지시합니다.

{
  "workloads": {
    "10.244.2.8": {
      "workloadIp": "10.244.2.8",
      "protocol": "HBONE", # mesh 내부 통신을 하는 것을 확인
      ...
}

• 워크로드 수준 권한 부여 정책을 배포한 후 정책 구성은 Istiod에서 ztunnel로 xDS 구성으로 푸시되고 아래에 표시됩니다 policies.

{
  "policies": {
    "default/hw-viewer": {
      "name": "hw-viewer",
      "namespace": "default",
      "scope": "WorkloadSelector",
      "action": "Allow",
      "groups": [[[{
        "principals": [{"Exact": "cluster.local/ns/default/sa/sleep"}]
      }]]]
    }
  }
  ...
}

• 또한 승인 정책을 참조하여 워크로드의 구성이 업데이트된 것을 확인할 수 있습니다.

{
  "workloads": {
    "10.244.2.8": {
    "workloadIp": "10.244.2.8",
    ...
    "authorizationPolicies": [
        "default/hw-viewer"
    ],
  }
  ...
}

L4 telemetry provided by ztunnel ztunnel에서 제공하는 L4 원격 측정

• ztunnel 로그가 이해하기 쉽다는 사실에 놀라실지도 모릅니다.

• 예를 들어, 목적지 ztunnel에서 소스 포드 IP( peer_ip)와 목적지 포드 IP를 나타내는 HTTP Connect 요청이 표시됩니다.

2023-02-15T20:40:48.628251Z  INFO inbound{id=4399fa68cf25b8ebccd472d320ba733f **peer_ip**=10.244.2.5 peer_id=spiffe://cluster.local/ns/default/sa/sleep}: ztunnel::proxy::inbound: got **CONNECT** request to 10.244.2.8:5000

• localhost:15020/metrics사이드카에서 노출하는 것과 동일한 레이블을 사용하여 전체 TCP 표준 메트릭 세트를 제공하는 API 에 액세스하여 워크로드의 L4 메트릭을 볼 수 있습니다.

istio_tcp_connections_opened_total{
  reporter="source",
  source_workload="sleep",
  source_workload_namespace="default",
  source_principal="spiffe://cluster.local/ns/default/sa/sleep",
  destination_workload="helloworld-v1",
  destination_workload_namespace="default",
  destination_principal="spiffe://cluster.local/ns/default/sa/helloworld",
  request_protocol="tcp",
  connection_security_policy="mutual_tls"
  ...
} 1

• Prometheus와 Kiali를 설치하면 Kiali UI에서 이러한 지표를 쉽게 볼 수 있습니다.

Istio Ambient Waypoint Proxy Made Simple

Istio Ambient Waypoint 프록시를 간편하게 : Introducing the new destination oriented waypoint proxy for simplicity and scalability - Blog

• Ambient는 Istio의 기능을 보안 오버레이 계층과 레이어 7 처리 계층이라는 두 개의 개별 계층으로 나눕니다.

• 웨이포인트 프록시는 Envoy 기반이며, 관리하는 워크로드에 대한 L7 처리를 담당하는 선택적 구성 요소입니다.

• 2022년 최초 Ambient 출시 이후 웨이포인트 구성, 디버깅 및 확장성을 간소화하기 위해 상당한 변경 작업을 수행해 왔습니다.

Architecture of waypoint proxies 웨이포인트 프록시의 아키텍처

• 사이드카와 마찬가지로 웨이포인트 프록시도 Envoy 기반이며, Istio를 통해 애플리케이션 구성을 지원하도록 동적으로 구성됩니다.

• 웨이포인트 프록시의 독특한 점은 네임스페이스별(기본값) 또는 서비스 계정별로 실행된다는 것입니다.

• 애플리케이션 포드 외부에서 실행되므로 웨이포인트 프록시는 애플리케이션과 독립적으로 설치, 업그레이드 및 확장할 수 있을 뿐만 아니라 운영 비용도 절감할 수 있습니다.

Waypoint architecture

• 웨이포인트 프록시는 Kubernetes Gateway 리소스나 유용한 istioctl명령을 사용하여 선언적으로 배포됩니다.

$ istioctl experimental waypoint generate
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: namespace
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

• Istiod는 이러한 리소스를 모니터링하고 해당 경로점 배포를 자동으로 사용자에게 배포하고 관리합니다.

Shift source proxy configuration to destination proxy 소스 프록시 구성을 대상 프록시로 전환*

• 기존 사이드카 아키텍처에서 대부분의 트래픽 셰이핑(예: 요청 라우팅 , 트래픽 이동 또는 오류 주입 ) 정책은 소스(클라이언트) 프록시에 의해 구현되는 반면, 대부분의 보안 정책은 목적지(서버) 프록시에 의해 구현됩니다. 이로 인해 다음과 같은 여러 가지 문제가 발생합니다.

  • Scaling 스케일링

    • 각 소스 사이드카는 메시 내 다른 모든 목적지에 대한 정보를 알아야 합니다. 이는 다항식 스케일링 문제입니다.

    • 더 심각한 것은 목적지 구성이 변경되면 모든 사이드카에 동시에 알려야 한다는 것입니다.

  • Debugging 디버깅

    • 정책 시행이 클라이언트와 서버 사이드카로 분리되어 있기 때문에 문제를 해결할 때 시스템의 동작을 이해하기 어려울 수 있습니다.

  • Mixed environments 혼합 환경

    • 모든 클라이언트가 메시에 속하지 않는 시스템에서는 동작이 일관되지 않습니다.

    • 예를 들어, 메시가 아닌 클라이언트는 카나리아 롤아웃 정책을 준수하지 않아 예상치 못한 트래픽 분산이 발생할 수 있습니다.

  • Ownership and attribution 소유권 및 귀속

    • 이상적으로는 하나의 네임스페이스에 작성된 정책은 동일한 네임스페이스에서 실행되는 프록시가 수행하는 작업에만 영향을 미쳐야 합니다.

    • 그러나 이 모델에서는 정책이 각 사이드카에 의해 분산되고 적용됩니다.

    • Istio는 이러한 제약 조건을 고려하여 보안을 강화하도록 설계되었지만, 여전히 최적의 방법은 아닙니다.

• 앰비언트에서는 모든 정책이 목적지 웨이포인트에 의해 적용됩니다.

• 여러 측면에서 웨이포인트는 **네임스페이스(**기본 범위) 또는 서비스 계정으로의 게이트웨이 역할을 합니다.

• Istio는 네임스페이스로 들어오는 모든 트래픽이 웨이포인트를 통과하도록 하고, 웨이포인트는 해당 네임스페이스에 대한 모든 정책을 적용합니다.

• 따라서 각 웨이포인트는 자체 네임스페이스의 구성만 알면 됩니다.

• 특히 확장성 문제는 대규모 클러스터를 사용하는 사용자에게 골칫거리입니다.

• 이를 시각화해 보면 새로운 아키텍처가 얼마나 큰 개선을 이루었는지 알 수 있습니다.

• 네임스페이스 2개가 있고 각 네임스페이스에 2개의 (색상 구분) deployment가 있는 간단한 배포를 생각해 보겠습니다.

• 사이드카 프로그래밍에 필요한 Envoy(XDS) 구성은 원으로 표시되어 있습니다.

• 사이드카 모델에는 4개의 워크로드가 있으며, 각 워크로드에는 4개의 구성 세트가 있습니다.

• 이러한 구성 중 하나라도 변경되면 모든 구성을 업데이트해야 합니다. 총 16개의 구성이 배포됩니다.

• 그러나 웨이포인트 아키텍처에서는 구성이 극적으로 단순화되었습니다.

Each waypoint only has configuration for its own namespace

• 여기서는 매우 다른 상황을 볼 수 있습니다.

• 각 프록시가 전체 네임스페이스를 지원할 수 있고, 각 프록시는 자체 네임스페이스에 대한 구성만 필요하기 때문에 웨이포인트 프록시는 두 개뿐입니다.

• 간단한 예시일지라도 전송되는 구성의 총량은 전체의 25%입니다.

• 각 네임스페이스를 각각 10개의 포드로 구성된 25개 배포까지 확장하고, 고가용성을 위해 각 웨이포인트 배포를 2개의 포드로 구성하면 숫자는 훨씬 더 인상적입니다.

• 아래 표에서 볼 수 있듯이 웨이포인트 구성 배포에는 사이드카 구성 배포의 0.8%만 필요합니다!

  구성 배포	Namespace 1	Namespace 2	총
  사이드카	25가지 구성 * 250개 사이드카	25가지 구성 * 250개 사이드카	12500
  웨이포인트	25가지 구성 * 2개의 웨이포인트	25가지 구성 * 2개의 웨이포인트	100
  웨이포인트/사이드카	0.8%	0.8%	0.8%

• 위에서 단순화를 설명하기 위해 네임스페이스 범위의 웨이포인트 프록시를 사용했지만, 이를 서비스 계정 웨이포인트 프록시에 적용하면 단순화는 유사합니다.

• 이렇게 축소된 구성은 제어 플레인과 데이터 플레인 모두의 리소스 사용량(CPU, RAM, 네트워크 대역폭)을 줄인다는 것을 의미합니다.

• 현재 사용자는 exportToIstio 네트워킹 리소스나 Sidecar API를 신중하게 사용하면 유사한 개선 효과를 볼 수 있지만, 앰비언트 모드에서는 이러한 작업이 더 이상 필요하지 않으므로 확장이 훨씬 수월해집니다.

What if my destination doesn’t have a waypoint proxy? 목적지에 웨이포인트 프록시가 없는 경우는 어떻게 되나요?

• 앰비언트 모드는 대부분의 구성이 서비스 소비자가 아닌 서비스 생산자에 의해 가장 잘 구현된다는 가정을 중심으로 설계되었습니다.

• 하지만 항상 그런 것은 아닙니다. 때로는 제어할 수 없는 대상에 대한 트래픽 관리를 구성해야 할 수도 있습니다.

• 이러한 일반적인 예로는 간헐적인 연결 문제를 처리하기 위해 향상된 복원력을 갖춘 외부 서비스에 연결하는 것입니다(예: 호출에 시간 초과를 추가하는 경우 example.com)

• 이 영역은 커뮤니티에서 활발하게 개발 중인 영역으로, 트래픽이 이그레스 게이트웨이로 라우팅되는 방식과 원하는 정책으로 이그레스 게이트웨이를 구성하는 방법을 설계합니다.

A deep-dive of waypoint configuration 웨이포인트 구성에 대한 심층 분석

• 환경 시작 가이드 와 제어 트래픽 섹션을 따랐다고 가정하면 bookinfo-reviews 서비스 계정에 대한 웨이포인트 프록시를 배포하여 90%의 트래픽을 리뷰 v1로, 10%의 트래픽을 리뷰 v2로 유도했습니다.

• istioctl웨이포인트 프록시 에 대한 리스너를 검색하는 데 사용합니다.

$ istioctl proxy-config listener deploy/bookinfo-reviews-istio-waypoint --waypoint
LISTENER              CHAIN                                                    MATCH                                         DESTINATION
envoy://connect_originate                                                      ALL                                           Cluster: connect_originate
envoy://main_internal inbound-vip|9080||reviews.default.svc.cluster.local-http ip=10.96.104.108 -> port=9080                 Inline Route: /*
envoy://main_internal direct-tcp                                               ip=10.244.2.14 -> ANY                         Cluster: encap
envoy://main_internal direct-tcp                                               ip=10.244.1.6 -> ANY                          Cluster: encap
envoy://main_internal direct-tcp                                               ip=10.244.2.11 -> ANY                         Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.2.11 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.2.11 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.2.14 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.2.14 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.1.6 -> application-protocol='h2c'   Cluster: encap
envoy://main_internal direct-http                                              ip=10.244.1.6 -> application-protocol='http/1.1'  Cluster: encap
envoy://connect_terminate default                                              ALL                                           Inline Route:

• 기본적으로 Istio의 인바운드 HBONE port인 포트 15008에 도착하는 요청의 경우, 웨이포인트 프록시가 HBONE 연결을 종료하고 main_internal listener에게 요청을 전달하여 AuthorizationPolicy와 같은 워크로드 정책을 적용합니다.

• 내부 리스너 에 대해 잘 모르시는 분들을 위해 설명드리자면 , 내부 리스너는 시스템 네트워크 API를 사용하지 않고 사용자 공간 연결을 허용하는 Envoy 리스너입니다.

• 위의 istioctl proxy-config 명령에 추가된 --waypoint 플래그는 main_internal listener, filter chains, chain matches 및 destinations의 세부 정보를 표시하도록 지시합니다.

• 10.96.104.108은 리뷰의 서비스 VIP이며, 10.244.x.x는 리뷰의 v1/v2/v3 포드 IP로, kubectl get svc,pod -o wide 명령을 사용하여 클러스터를 확인할 수 있습니다.

• 일반 텍스트 또는 HBONE 종료 인바운드 트래픽의 경우, 검토를 위해 서비스 VIP 및 포트 9080에서 일치시키거나 팟 IP 주소 및 애플리케이션 프로토콜(ANY, h2c 또는 http/1.1)로 일치시킵니다.

• reviews 웨이포인트 프록시 클러스터를 확인하면 main_internal 클러스터와 몇 개의 인바운드 클러스터가 표시됩니다.

• 인프라용 클러스터를 제외하고, 생성된 유일한 Envoy 클러스터는 동일한 서비스 계정에서 실행되는 서비스와 포드를 위한 것입니다.

• 다른 곳에서 실행되는 서비스나 포드를 위한 클러스터는 생성되지 않습니다.

$ istioctl proxy-config clusters deploy/bookinfo-reviews-istio-waypoint
SERVICE FQDN                         PORT SUBSET  DIRECTION   TYPE         DESTINATION RULE
agent                                -    -       -           STATIC
connect_originate                    -    -       -           ORIGINAL_DST
encap                                -    -       -           STATIC
kubernetes.default.svc.cluster.local 443  tcp     inbound-vip EDS
main_internal                        -    -       -           STATIC
prometheus_stats                     -    -       -           STATIC
reviews.default.svc.cluster.local    9080 http    inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v1 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v2 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v3 inbound-vip EDS
sds-grpc                             -    -       -           STATIC
xds-grpc                             -    -       -           STATIC
zipkin                               -    -       -           STRICT_DNS

• 목록에 아웃바운드 클러스터가 없다는 것은 istioctl proxy-config cluster deploy/bookinfo-reviews-istio-waypoint --direction outbound!를 사용하여 확인할 수 있습니다!

• 좋은 점은 다른 북인포 서비스(예: 제품 페이지 또는 평점 서비스)에서 exportTo를 구성할 필요가 없다는 것입니다.

• 다시 말해, reviews waypoint는 불필요한 클러스터에 대해 추가적인 수동 설정 없이는 인식되지 않습니다.

• reviews waypoint 프록시의 경로 목록을 표시합니다.

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint
NAME                                                    DOMAINS MATCH              VIRTUAL SERVICE
encap                                                   *       /*
inbound-vip|9080|http|reviews.default.svc.cluster.local *       /*                 reviews.default
default

• Istio 네트워킹 리소스에 사이드카 리소스나 exportTo 구성을 구성하지 않았다는 점을 기억하세요.

• 그러나 productpage로 라우팅하기 위한 ingress gateway를 구성하기 위해 bookinfo-productpage 경로를 배포했지만 reviews waypoint는 이러한 관련 없는 경로에 대해 인지하지 못했습니다.

• inbound-vip|9080|http|reviews.default.svc.cluster.local 경로에 대한 자세한 정보를 표시하면 가중치 기반 라우팅 구성이 트래픽의 90%를 v1 리뷰로, 10%를 v2 리뷰로 유도하는 것을 볼 수 있으며, Istio의 기본 재시도 및 타임아웃 구성도 포함됩니다.

• 이는 앞서 논의한 바와 같이 트래픽 및 복원력 정책이 원본 경유지에서 목적지 지향 경유지로 전환되었음을 확인시켜줍니다.

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint --name "inbound-vip|9080|http|reviews.default.svc.cluster.local" -o yaml
- name: inbound-vip|9080|http|reviews.default.svc.cluster.local
 validateClusters: false
 virtualHosts:
 - domains:
   - '*'
   name: inbound|http|9080
   routes:
   - decorator:
       operation: reviews:9080/*
     match:
       prefix: /
     metadata:
       filterMetadata:
         istio:
           config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
     route:
       maxGrpcTimeout: 0s
       retryPolicy:
         hostSelectionRetryMaxAttempts: "5"
         numRetries: 2
         retriableStatusCodes:
         - 503
         retryHostPredicate:
         - name: envoy.retry_host_predicates.previous_hosts
           typedConfig:
             '@type': type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
         retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
       timeout: 0s
       weightedClusters:
         clusters:
         - name: inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
           weight: 90
         - name: inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
           weight: 10

• reviews waypoint 프록시를 보려면 엔드포인트를 확인하세요.

$ istioctl proxy-config endpoints deploy/bookinfo-reviews-istio-waypoint
ENDPOINT                                            STATUS  OUTLIER CHECK CLUSTER
127.0.0.1:15000                                     HEALTHY OK            prometheus_stats
127.0.0.1:15020                                     HEALTHY OK            agent
envoy://connect_originate/                          HEALTHY OK            encap
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http/v3|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://main_internal/                              HEALTHY OK            main_internal
unix://./etc/istio/proxy/XDS                        HEALTHY OK            xds-grpc
unix://./var/run/secrets/workload-spiffe-uds/socket HEALTHY OK            sds-grpc

• 기본 및 istio-system 네임스페이스에 몇 가지 다른 서비스가 있음에도 불구하고 리뷰 외에는 다른 서비스와 관련된 엔드포인트를 얻을 수 없습니다.

Ambient Mode Security Deep Dive

Digging into the security implications of the recently announced Istio ambient mode, a sidecar-less data plane for Istio - Blog

• 최근 Istio의 새로운 앰비언트 모드를 발표했습니다. 이는 Istio를 위한 사이드카 없는 데이터 플레인이자 앰비언트 메시 패턴의 참조 구현입니다.

• 발표 블로그에서 언급했듯이 , 앰비언트 메시를 통해 해결하고자 하는 주요 과제는 운영 간소화, 더 광범위한 애플리케이션 호환성, 인프라 비용 절감, 그리고 성능 향상입니다.

• 앰비언트 데이터 플레인을 설계할 때, 보안이나 기능을 희생하지 않으면서도 운영, 비용, 그리고 성능에 대한 우려 사항들을 신중하게 균형 있게 고려하고자 했습니다.

• 앰비언트 메시의 구성 요소가 애플리케이션 포드 외부에서 실행됨에 따라 보안 경계가 변경되었으며, 이는 더 나은 방향으로 변화했다고 생각합니다.

• 이 블로그에서는 이러한 변경 사항과 사이드카 배포와의 차이점을 자세히 설명합니다.

Layering of ambient mesh data plane

• 요약하자면, Istio의 앰비언트 모드는 전송 보안 및 라우팅을 담당하는 보안 오버레이를 갖춘 계층화된 메시 데이터 플레인을 도입하며, 필요한 네임스페이스에 L7 기능을 추가할 수 있는 옵션을 제공합니다. 자세한 내용은 공지 블로그 와 시작하기 블로그를 참조하세요.

• 보안 오버레이는 노드 공유 구성 요소인 ztunnel로 구성되며, ztunnel은 L4 원격 측정 및 DaemonSet으로 배포되는 mTLS를 담당합니다.

• 메시의 L7 계층은 웨이포인트 프록시, 즉 ID/워크로드 유형별로 배포되는 전체 L7 Envoy 프록시에 의해 제공됩니다.

• 이 설계의 핵심적인 의미는 다음과 같습니다.

  • 데이터 플레인에서 애플리케이션 분리

  • 보안 오버레이 계층의 구성 요소는 CNI의 구성 요소와 유사합니다.

  • 보안을 위해서는 운영의 단순성이 더 좋습니다.

  • 다중 테넌트 L7 프록시 피하기

  • 사이드카는 여전히 일류 지원 배포입니다.

데이터 플레인에서 애플리케이션 분리 Separation of application from data plane

• 앰비언트 메시의 주요 목표는 서비스 메시 운영을 단순화하는 것이지만, 보안 강화에도 기여합니다.

• 복잡성은 취약성을 야기하며, 엔터프라이즈 애플리케이션(및 그 전이적 종속성, 라이브러리, 프레임워크)은 매우 복잡하고 취약성에 취약합니다.

• 복잡한 비즈니스 로직 처리부터 OSS 라이브러리 또는 버그가 있는 내부 공유 라이브러리 활용에 이르기까지, 사용자의 애플리케이션 코드는 내부 또는 외부 공격자의 주요 공격 대상입니다.

• 애플리케이션이 침해되면 메모리에 마운트되거나 저장된 자격 증명, 비밀, 키가 공격자에게 노출됩니다.

• 사이드카 모델을 살펴보면, 애플리케이션 침해에는 사이드카 및 관련 ID/키 자료의 점유가 포함됩니다.

• Istio의 앰비언트 모드에서는 애플리케이션과 동일한 포드(pod)에서 실행되는 데이터 플레인 구성 요소가 없으므로 애플리케이션 침해가 비밀 접근으로 이어지지 않습니다.

• Envoy 프록시가 잠재적인 취약점 공격 대상이 될 가능성은 어떨까요?

• Envoy는 엄격한 보안 검사를 거치는 매우 강화된 인프라로, 중요 환경 (예: Google 네트워크의 운영 환경 ) 에서 대규모로 운영됩니다.

• 하지만 Envoy는 소프트웨어이기 때문에 취약점으로부터 완전히 자유롭지는 않습니다.

• 취약점이 발생할 경우, Envoy는 강력한 CVE 프로세스를 통해 취약점을 식별하고 신속하게 수정하여 광범위한 영향을 미치기 전에 고객에게 배포합니다.

• "복잡성은 취약점을 낳는다"라는 이전 댓글로 돌아가서, Envoy 프록시의 가장 복잡한 부분은 L7 처리에 있으며, 실제로 Envoy의 취약점 대부분은 역사적으로 L7 처리 스택에 있었습니다.

• 하지만 mTLS에 Istio만 사용한다면 어떨까요? CVE 위험이 더 높은 완전한 L7 프록시를 배포하는 위험을 감수할 이유가 있을까요?

• 해당 기능을 사용하지 않는데 말이죠. 여기서 L4 및 L7 메시 기능을 분리하는 것이 중요합니다.

• 사이드카 배포에서는 기능의 일부만 사용하더라도 모든 프록시를 채택하는 반면, 앰비언트 모드에서는 안전한 오버레이를 제공하고 필요에 따라 L7 레이어만 추가하여 노출을 제한할 수 있습니다.

• 또한, L7 구성 요소는 애플리케이션과 완전히 분리되어 실행되므로 공격 경로를 제공하지 않습니다.

Pushing L4 down into the CNI : 보안 오버레이 계층의 구성 요소는 CNI의 구성 요소와 유사

• 앰비언트 모드 데이터 플레인의 L4 구성 요소는 DaemonSet 또는 노드당 하나씩 실행됩니다.

• 즉, 특정 노드에서 실행 중인 모든 파드에 대한 공유 인프라입니다.

• 이 구성 요소는 특히 민감하므로 CNI 에이전트, kube-proxy, kubelet 또는 Linux 커널과 같은 노드의 다른 공유 구성 요소와 동일한 수준에서 처리해야 합니다.

• 워크로드에서 발생하는 트래픽은 ztunnel로 리디렉션되고, ztunnel은 워크로드를 식별하고 mTLS 연결에서 해당 워크로드를 나타내는 올바른 인증서를 선택합니다.

• ztunnel은 각 포드에 대해 고유한 자격 증명을 사용하며, 이 자격 증명은 포드가 현재 노드에서 실행 중인 경우에만 발급됩니다.

• 이를 통해 손상된 ztunnel의 공격 범위가 해당 노드에 현재 예약된 포드의 자격 증명만 유출될 수 있도록 보장합니다.

• 이는 다른 보안 CNI 구현을 포함하여 잘 구현된 다른 공유 노드 인프라와 유사한 특성입니다.

• ztunnel은 클러스터 전체 또는 노드별 자격 증명을 사용하지 않습니다. 이러한 자격 증명은 유출될 경우 복잡한 보조 권한 부여 메커니즘을 구현하지 않는 한 클러스터의 모든 애플리케이션 트래픽을 즉시 침해할 수 있습니다.

• 사이드카 모델과 비교해 보면, ztunnel은 공유되며, 침해 시 노드에서 실행 중인 애플리케이션의 ID가 유출될 수 있음을 알 수 있습니다.

• 그러나 이 구성 요소에서 CVE가 발생할 가능성은 Istio 사이드카보다 낮습니다. 공격 표면이 크게 줄어들기 때문입니다(L4 처리만 가능).

• ztunnel은 L7 처리를 전혀 하지 않습니다. 또한, L7로 인해 공격 표면이 더 넓은 사이드카에서 발생하는 CVE는 침해된 특정 워크로드에만 국한되지 않습니다.

• 사이드카에서 발생하는 심각한 CVE는 메시의 모든 워크로드에도 반복될 가능성이 높습니다.

Simplicity of operations is better for security : 운영의 단순성 - 업그레이드 용이

• 궁극적으로 Istio는 유지 관리가 필수인 핵심 인프라입니다.

• Istio는 애플리케이션을 대신하여 제로 트러스트 네트워크 보안의 핵심 원칙 중 일부를 구현하는 데 있어 신뢰받고 있으며, 일정에 따라 또는 필요에 따라 패치를 배포하는 것이 매우 중요합니다.

• 플랫폼 팀은 애플리케이션과는 상당히 다른 예측 가능한 패치 또는 유지 관리 주기를 갖는 경우가 많습니다.

• 애플리케이션은 새로운 기능이 필요할 때, 그리고 일반적으로 프로젝트의 일부로 업데이트될 가능성이 높습니다.

• 애플리케이션 변경, 업그레이드, 프레임워크 및 라이브러리 패치에 대한 이러한 접근 방식은 예측이 매우 어렵고, 시간이 많이 소요되며, 안전한 보안 관행에 적합하지 않습니다.

• 따라서 이러한 보안 기능을 플랫폼의 일부로 유지하고 애플리케이션과 분리하는 것이 더 나은 보안 태세를 구축하는 데 도움이 될 것입니다.

• 공지 블로그에서 확인했듯이, 사이드카 운영은 사이드카의 침습적 특성(사이드카 주입/배포 설명자 변경, 애플리케이션 재시작, 컨테이너 간 경합 조건 등)으로 인해 더욱 복잡해질 수 있습니다.

• 사이드카를 사용하는 워크로드를 업그레이드하려면 애플리케이션이 다운되지 않도록 조정해야 할 수 있는 롤링 재시작과 계획 수립이 조금 더 필요합니다.

• 앰비언트 모드에서는 ztunnel 업그레이드를 일반적인 노드 패치 또는 업그레이드와 동시에 진행할 수 있으며, 웨이포인트 프록시는 네트워크의 일부이므로 필요에 따라 애플리케이션에 완전히 투명하게 업그레이드할 수 있습니다.

Avoiding multi-tenant L7 proxies 다중 테넌트 L7 프록시 피하기

• HTTP 1/2/3, gRPC, 헤더 구문 분석, 재시도 구현, 데이터 플레인에서 Wasm 및/또는 Lua를 사용한 커스터마이징과 같은 L7 프로토콜을 지원하는 것은 L4를 지원하는 것보다 훨씬 더 복잡합니다.

• 이러한 동작을 구현하기 위한 코드(루아나 와즘과 같은 사용자 지정 코드 포함)가 훨씬 더 많으며, 이러한 복잡성은 취약점의 잠재력으로 이어질 수 있습니다.

• 이로 인해 CVE는 이러한 L7 기능 영역에서 발견될 가능성이 더 높습니다.

Each namespace/identity has its own L7 proxies; no multi-tenant proxies - 각 네임스페이스/ID에는 자체 L7 프록시가 있습니다. 다중 테넌트 프록시는 없습니다.

• 앰비언트 모드에서는 여러 ID에 걸쳐 프록시에서 L7 처리를 공유하지 않습니다.

• 각 신원(쿠버네티스의 서비스 계정)은 사이드카에서 사용하는 모델과 **매우 유사한 전용 L7 프록시(웨이포인트 프록시)**를 가지고 있습니다.

• 여러 신원과 그들의 독특한 복잡한 정책 및 맞춤화를 동시에 찾으려는 시도는 공유 자원에 많은 변동성을 추가하여 기껏해야 불공정한 비용 귀속을 초래하고 최악의 경우 완전한 대리 타협을 초래합니다.

Sidecars are still a first-class supported deployment 사이드카는 여전히 일류 지원 배포입니다.

• 일부 사람들은 사이드카 모델과 알려진 보안 경계에 익숙하며 그 모델을 유지하기를 원한다는 것을 이해합니다.

• Istio를 사용하면 사이드카는 메시의 일류 시민이며 플랫폼 소유자는 사이드카를 계속 사용할 수 있습니다.

• 플랫폼 소유자가 사이드카 모드와 앰비언트 모드를 모두 지원하고자 하는 경우, 지원할 수 있습니다.

• 주변 데이터 플레인이 있는 워크로드는 사이드카가 배치된 워크로드와 기본적으로 통신할 수 있습니다.

• 사람들이 앰비언트 모드의 보안 자세를 더 잘 이해하기 때문에, 특정 최적화를 위해 사이드카가 사용되는 Istio의 선호되는 데이터 플레인 모드가 될 것이라고 확신합니다.

Maturing Istio Ambient: Compatibility Across Various Kubernetes Providers and CNIs

An innovative traffic redirection mechanism between workload pods and ztunnel - Blog

• Istio 프로젝트는 2022년에 새로운 사이드카 없는 데이터 평면 모드인 앰비언트 메시를 발표하고 2023년 초에 알파 구현을 출시했습니다.

• 알파 버전은 제한된 구성과 환경에서 앰비언트 데이터 플레인 모드의 가치를 입증하는 데 중점을 두었습니다. 그러나 조건은 매우 제한적이었습니다.

• 앰비언트 모드는 워크로드 포드와 ztunnel 간의 트래픽을 투명하게 리디렉션하는 데 의존하며, 이를 위해 사용한 초기 메커니즘은 여러 범주의 타사 컨테이너 네트워킹 인터페이스(CNI) 구현과 충돌했습니다.

• GitHub 이슈와 Slack 토론을 통해 사용자들이 Cilium 및 Calico 와 같은 CNI 구현과 OpenShift 및 Amazon EKS 와 같은 사내 CNI 구현을 제공하는 서비스와 함께 minikube 및 Docker Desktop 에서 앰비언트 모드를 사용할 수 있기 를 원한다는 것을 알게 되었습니다.

• 어디에서든 Kubernetes에 대한 광범위한 지원을 받는 것이 베타 버전으로 전환하는 앰비언트 메시의 가장 중요한 요구 사항이 되었습니다.

• 사람들은 Istio가 모든 Kubernetes 플랫폼과 모든 CNI 구현에서 작동하기를 기대하게 되었습니다.

• 어디에 있지 않으면 앰비언트가 앰비언트가 아닐 것입니다!

• Solo에서는 Gloo Mesh 제품에 앰비언트 모드를 통합해 왔으며, 이 문제에 대한 혁신적인 해결책을 제시했습니다.

• 앰비언트 모드가 베타 버전에 더 빨리 출시될 수 있도록 2023년 말에 변경 사항을 업스트림하기 로 결정했습니다.

• 이를 통해 더 많은 사용자가 Istio 1.21 이상에서 앰비언트를 사용하고, 기존 또는 선호하는 CNI 구현 방식과 관계없이 플랫폼에서 사이드카 없는 앰비언트 메시의 이점을 누릴 수 있게 되었습니다.

How did we get here? 우리는 어떻게 여기까지 왔을까? ztunnel이 포드 네트워크 네임스페이스 내부에서 리디렉션 소켓을 시작하면서 포드 외부에서 실행** -> 현재의 Ambient 라우팅 구조

Service meshes and CNIs: it’s complicated. 복잡하다!

• Istio는 서비스 메시이며, 엄격한 정의에 따르면 모든 서비스 메시는 CNI 구현이 아닙니다. 서비스 메시는 모든 Kubernetes 클러스터에 사양을 준수하는 기본 CNI 구현이 있어야 하며, 그 위에 있어야 합니다.

• 이 기본 CNI 구현은 클라우드 제공업체(AKS, GKE, EKS 모두 자체 배송) 또는 Calico 및 Cilium과 같은 타사 CNI 구현에 의해 제공될 수 있습니다. 일부 서비스 메시는 자체 기본 CNI 구현과 함께 번들로 배송될 수 있으며, 이를 위해 명시적으로 필요합니다.

• 기본적으로 mTLS를 사용하여 안전한 포드 트래픽과 같은 작업을 수행하고 서비스 메시 계층에서 고급 인증 및 권한 부여 정책을 적용하기 전에, 기능적 CNI 구현이 가능한 Kubernetes 클러스터가 있어야 하며, 기본 네트워킹 경로가 설정되어 패킷이 클러스터 내에서 한 포드에서 다른 포드(그리고 한 노드에서 다른 노드로)로 이동할 수 있도록 해야 합니다.

• 일부 서비스 메시는 자체적으로 기본 CNI 구현을 배송하고 필요로 할 수도 있지만, 때로는 동일한 클러스터 내에서 두 개의 기본 CNI 구현을 병렬로 실행할 수도 있습니다(예: 클라우드 제공업체에서 배송하는 구현과 타사 구현). 실제로는 각 CNI 구현이 내부적으로 사용할 수 있는 매우 다양한 메커니즘으로 인해 호환성 문제, 이상한 동작, 축소된 특징 세트 및 일부 비호환성 문제가 발생합니다.

• 이를 방지하기 위해 Istio 프로젝트는 배송을 하지 않거나 자체 기본 CNI 구현을 요구하지 않거나, 심지어 "선호되는" CNI 구현을 요구하지 않기로 결정했습니다. 대신 가능한 한 가장 넓은 CNI 구현 생태계와의 CNI 체인을 지원하고, 관리형 오퍼링과의 최대 호환성, 공급업체 간 지원, 더 넓은 CNCF 생태계와의 구성 가능성을 보장하기로 했습니다.

Traffic redirection in ambient alpha : 앰비언트 알파에서의 트래픽 리디렉션

• istio-cni 구성 요소는 사이드카 데이터 플레인 모드에서 선택적인 구성 요소로, 일반적으로 포드를 메시에 배포하는 사용자에게 NET_ADMIN 및 NET_RAW 기능의 요구 사항을 제거하는 데 사용됩니다. istio-cni는 앰비언트 데이터 플레인 모드에서 필수 구성 요소입니다. istio-cni 구성 요소는 기본 CNI 구현이 아니며, 클러스터에 이미 존재하는 기본 CNI 구현을 확장하는 노드 에이전트입니다.

• 포드가 앰비언트 메시에 추가될 때마다 istio-CNI 구성 요소는 노드 수준의 네트워크 네임스페이스를 통해 포드 노드에서 실행되는 ztunnel과 포드 간의 모든 들어오고 나가는 트래픽에 대한 트래픽 리디렉션을 구성합니다. 사이드카 메커니즘과 앰비언트 알파 메커니즘의 주요 차이점은 후자의 경우 포드 트래픽이 포드 네트워크 네임스페이스에서 벗어나 공동 위치한 ztunnel 포드 네트워크 네임스페이스로 리디렉션되었다는 점입니다. 이는 이를 달성하기 위한 대부분의 트래픽 리디렉션 규칙이 구현된 곳입니다.

• 여러 실제 쿠버네티스 환경에서 자체 기본 CNI를 사용하여 더 광범위하게 테스트한 결과, 알파 개발 당시와 마찬가지로 호스트 네트워크 네임스페이스에서 포드 트래픽을 캡처하고 리디렉션하는 것이 우리의 요구 사항을 충족하지 못한다는 것이 분명해졌습니다. 이러한 다양한 환경에서 일반적인 방식으로 목표를 달성하는 것은 이 접근 방식으로는 불가능했습니다.

• 호스트 네트워크 네임스페이스에서 트래픽 리디렉션의 근본적인 문제는 클러스터의 기본 CNI 구현이 트래픽 라우팅/네트워킹 규칙을 구성해야 하는 바로 그 지점에 있다는 것입니다. 이로 인해 가장 중요한 것은 피할 수 없는 충돌이 발생했다는 점입니다.

  • 기본 CNI 구현의 기본 호스트 수준 네트워킹 구성은 Istio의 CNI 확장에서 호스트 수준의 주변 네트워킹 구성을 방해하여 트래픽 중단 및 기타 충돌을 일으킬 수 있습니다.

  • 사용자가 기본 CNI 구현에 의해 네트워크 정책을 시행하도록 배포한 경우, Istio CNI 확장이 배포될 때 네트워크 정책이 시행되지 않을 수 있습니다(기본 CNI 구현이 네트워크 정책을 시행하는 방식에 따라 달라질 수 있습니다)

• 일부 주요 CNI 구현을 위해 사례별로 이 문제를 설계할 수는 있지만, 보편적인 CNI 지원에 지속 가능하게 접근할 수는 없습니다. 우리는 eBPF를 고려했지만, 현재로서는 임의의 eBPF 프로그램을 안전하게 체인/확장할 수 있는 표준화된 방법이 없기 때문에 eBPF 구현이 동일한 기본 문제를 가질 수 있다는 것을 깨달았습니다. 그리고 이 접근 방식으로는 여전히 비 eBPF CNI를 지원하는 데 어려움을 겪을 가능성이 있습니다.

Addressing the challenges 과제 해결!

• 새로운 해결책이 필요했습니다. 노드의 네트워크 네임스페이스에서 임의의 종류의 리디렉션을 수행하면 호환성 요구 사항을 위반하지 않는 한 피할 수 없는 충돌이 발생할 수 있었습니다.

• 사이드카 모드에서는 사이드카와 애플리케이션 포드 간의 트래픽 리디렉션을 구성하는 것이 간단합니다. 이 둘은 모두 포드의 네트워크 네임스페이스 내에서 작동하기 때문입니다. 이로 인해 사이드카를 모방하고 애플리케이션 포드의 네트워크 네임스페이스에서 리디렉션을 구성하는 것은 어떨까요?

• "단순한" 생각처럼 들리지만, 이것이 어떻게 가능할까요? 환경의 중요한 요구 사항 중 하나는 ztunnel이 Istio 시스템 네임스페이스에서 애플리케이션 포드 외부에서 실행되어야 한다는 것입니다. 몇 가지 연구 끝에, 우리는 하나의 네트워크 네임스페이스에서 실행되는 Linux 프로세스가 다른 네트워크 네임스페이스 내에서 리스닝 소켓을 생성하고 소유할 수 있다는 것을 발견했습니다. 이것이 Linux 소켓 API의 기본 기능입니다. 그러나 이를 작동시키고 모든 포드 라이프사이클 시나리오를 다루기 위해서는 ztunnel과 Istio-CNI 노드 에이전트에 아키텍처를 변경해야 했습니다.

• 프로토타입을 제작하고 이 새로운 접근 방식이 우리가 접근할 수 있는 모든 Kubernetes 플랫폼에서 작동하는지 충분히 검증한 후, 우리는 이 작업에 대한 신뢰를 쌓고 모든 주요 클라우드 제공업체 및 CNI와 호환되도록 처음부터 구축된 워크로드 포드와 ztunnel 노드 프록시 구성 요소 간의 인팟 트래픽 리디렉션 메커니즘인 이 새로운 트래픽 리디렉션 모델의 업스트림에 기여하기로 결정했습니다.

• 핵심 혁신은 포드의 네트워크 네임스페이스를 공동 위치한 ztunnel에 제공하여 ztunnel이 포드 네트워크 네임스페이스 내부에서 리디렉션 소켓을 시작하면서 포드 외부에서 실행할 수 있도록 하는 것입니다. 이 접근 방식을 통해 ztunnel과 애플리케이션 포드 간의 트래픽 리디렉션은 오늘날 사이드카 및 애플리케이션 포드와 매우 유사한 방식으로 이루어지며, 노드 네트워크 네임스페이스에서 작동하는 모든 Kubernetes 기본 CNI에서는 엄격히 보이지 않습니다. 네트워크 정책은 CNI가 eBPF를 사용하든 iptables를 사용하든 충돌 없이 모든 Kubernetes 기본 CNI에 의해 계속 시행되고 관리될 수 있습니다.

Technical deep dive of in-Pod traffic redirection* : 파드 내 트래픽 리디렉션에 대한 분석, 흐름 확인

Why did we drop the previous model? 왜 이전 모델을 폐기했나요?

• Istio 앰비언트 메시에서는 모든 노드가 Kubernetes DaemonSets로 실행되는 최소 두 개의 컨테이너를 가지고 있습니다:

  • 메시 트래픽 프록시 작업과 L4 정책 집행을 처리하는 효율적인 ztunnel.

  • 새로운 포드와 기존 포드를 앰비언트 메시에 추가하는 작업을 처리하는 istio-CNI 노드 에이전트입니다.

• 이전 앰비언트 메시 구현에서는 애플리케이션 포드가 앰비언트 메시에 이렇게 추가되었습니다:

  • istio-CNI 노드 에이전트는 네임스페이스에 istio.io/dataplane-mode=ambient, 라벨이 붙은 기존 또는 새로 started Kubernetes 포드를 감지하여 앰비언트 메시에 포함되어야 함을 나타냅니다.

  • istio-cni 노드 에이전트는 호스트 네트워크 네임스페이스에 네트워크 리디렉션 규칙을 설정하여 애플리케이션 포드에 들어오거나 나가는 패킷을 가로채 해당 노드의 ztunnel로 리디렉션합니다(15008, 15006 또는 15001).

• 즉, 앰비언트 메시에서 포드가 생성한 패킷의 경우 해당 패킷이 소스 포드를 떠나 노드의 호스트 네트워크 네임스페이스에 들어간 다음, 이상적으로 인터셉트되어 해당 노드의 ztunnel(자체 네트워크 네임스페이스에서 실행됨)로 리디렉션되어 목적지 포드로 프록시됩니다. 반환 경로는 비슷합니다.

• 이 모델은 초기 앰비언트 메시 알파 구현을 위한 자리 표시자로서 충분히 잘 작동했지만, 앞서 언급했듯이 근본적인 문제가 있습니다. 많은 CNI 구현이 있으며, Linux에서는 패킷이 한 네트워크 네임스페이스에서 다른 네트워크 네임스페이스로 이동하는 방식을 구성할 수 있는 근본적으로 다양하고 호환되지 않는 방법이 많습니다. 터널을 사용하거나, 네트워크를 오버레이하거나, 호스트 네트워크 네임스페이스를 통과하거나, 우회할 수 있습니다. Linux 사용자 공간 네트워킹 스택을 통과하거나, 이를 건너뛰고 커널 공간 스택에서 패킷을 왕복할 수 있습니다. 모든 가능한 접근 방식에 대해 CNI 구현이 있을 가능성이 높습니다.

• 즉, 이전 리다이렉션 접근 방식에서는 앰비언트가 작동하지 않는 CNI 구현이 많았습니다. 호스트 네트워크 네임스페이스 패킷 리다이렉션에 의존하기 때문에, 패킷을 호스트 네트워크 네임스페이스를 통해 라우팅하지 않는 CNI는 다른 리다이렉션 구현이 필요합니다. 그리고 이를 수행하는 CNI조차도 호스트 수준의 규칙이 상충되는 경우 피할 수 없고 잠재적으로 해결할 수 없는 문제가 발생할 수 있습니다. CNI를 가로채는 것이 먼저인가요, 아니면 나중에 가로채는 것인가요? 어떤 CNI는 하나, 아니면 다른 CNI를 수행하면 깨질까요? 네트워크 정책은 호스트 네트워크 네임스페이스에서 시행되어야 하므로 어디서 언제 시행되나요? 모든 인기 있는 CNI를 특수하게 구분하기 위해 많은 코드가 필요한가요?

Istio ambient traffic redirection: the new model 새로운 모델!

새로운 앰비언트 모델에서는 애플리케이션 포드가 앰비언트 메시에 이렇게 추가됩니다:

• istio-CNI 노드 에이전트는 네임스페이스에 istio.io/dataplane-mode=ambient, 라벨이 붙은 Kubernetes 포드(기존 또는 새로 생성된 started)를 감지하여 앰비언트 메시에 포함되어야 함을 나타냅니다.

  • 앰비언트 메시에 추가해야 하는 새로운 포드가 시작되면, CRI에 의해 CNI 플러그인(istio-cni 에이전트에 의해 설치 및 관리됨)이 트리거됩니다. 이 플러그인은 노드의 istio-cni 에이전트에 새로운 포드 이벤트를 푸시하고 에이전트가 리다이렉션을 성공적으로 구성할 때까지 포드 시작을 차단하는 데 사용됩니다. CRI는 Kubernetes 포드 생성 과정에서 CNI 플러그인을 가능한 한 빨리 호출하기 때문에, 이를 통해 초기 컨테이너와 같은 것에 의존하지 않고 시작 중에 트래픽이 빠져나가지 않도록 충분히 일찍 트래픽 리다이렉션을 설정할 수 있습니다.

  • 이미 실행 중인 포드가 앰비언트 메시에 추가되면 새로운 포드 이벤트가 트리거됩니다. istio-CNI 노드 에이전트의 Kubernetes API 감시기가 이를 감지하면 리디렉션도 동일한 방식으로 구성됩니다.

• istio-cni 노드 에이전트는 포드의 네트워크 네임스페이스에 들어가 포드 네트워크 네임스페이스 내부에 네트워크 리디렉션 규칙을 설정하여 포드에 들어오고 나가는 패킷을 가로채서 잘 알려진 포트(15008, 15006, 15001)에서 노드 로컬 ztunnel 프록시 인스턴스로 투명하게 리디렉션합니다. 그런 다음 istio-cni 노드 에이전트는 유닉스 도메인 소켓을 통해 노드 ztunnel에 포드의 네트워크 네임스페이스(15008, 15006, 15001) 내부에 로컬 프록시 리스닝 포트를 설정해야 한다고 알리고, ztunnel에 포드의 네트워크 네임스페이스를 나타내는 저수준 리눅스 파일 설명자를 제공합니다.

• 일반적으로 소켓은 리눅스 네트워크 네임스페이스 내에서 실제로 실행되는 프로세스에 의해 생성되지만, 생성 시점에 대상 네트워크 네임스페이스가 알려져 있다고 가정하면 리눅스의 저수준 소켓 API를 활용하여 한 네트워크 네임스페이스에서 실행되는 프로세스가 다른 네트워크 네임스페이스에서 리스닝 소켓을 생성할 수 있도록 하는 것이 완벽하게 가능합니다.

• node-local ztunne은 내부적으로 새로운 프록시 인스턴스와 리스닝 포트 세트를 스핀업하여 새로 추가된 포드 전용으로 만듭니다.

• 인팟 리디렉션 규칙이 적용되고 ztunnel이 청취 포트를 설정하면 이전과 마찬가지로 네트워크에 포드가 추가되고 노드-로컬 ztunnel을 통해 트래픽이 흐르기 시작합니다.

• 다음은 주변 메시에 추가되는 애플리케이션 포드의 흐름을 보여주는 기본 다이어그램입니다:

• 포드가 앰비언트 메시에 성공적으로 추가되면, 메시의 포드 간 트래픽은 Istio와 마찬가지로 기본적으로 mTLS로 완전히 암호화됩니다.

• 이제 트래픽은 암호화된 트래픽으로 포드 네트워크 네임스페이스에 들어오고 나갈 것입니다. 이는 주변 메시의 모든 포드가 메쉬 정책을 적용하고 트래픽을 안전하게 암호화할 수 있는 기능을 가지고 있는 것처럼 보일 것입니다. 하지만 포드에서 실행 중인 사용자 애플리케이션은 이러한 기능을 인식하지 못합니다.

• 다음은 새 모델에서 주변 메시의 포드 간 암호화된 트래픽이 어떻게 흐르는지 설명하는 다이어그램입니다:

• 그리고 이전과 마찬가지로 메쉬 외부에서 암호화되지 않은 평문 트래픽은 필요한 경우에도 처리하고 정책을 시행할 수 있습니다:

The new ambient traffic redirection: what this gets us

• 새로운 앰비언트 캡처 모델의 최종 결과는 모든 트래픽 캡처와 리디렉션이 포드의 네트워크 네임스페이스 내부에서 발생한다는 것입니다. 노드, CNI 및 기타 모든 것에 대해 포드 내부에 사이드카 프록시가 있는 것처럼 보입니다. 비록 포드에서 사이드카 프록시가 전혀 실행되지 않더라도 말입니다. CNI 구현의 임무는 패킷을 포드로 주고 받는 것임을 기억하세요. 설계상으로나 CNI 사양에 따라 그 이후에는 패킷이 어떻게 될지 신경 쓰지 않습니다.

• 이 접근 방식은 다양한 CNI 및 네트워크 정책 구현과의 충돌을 자동으로 제거하고, 모든 주요 CNI에서 모든 주요 관리 쿠버네티스 제품과의 Istio 앰비언트 메시 호환성을 크게 향상시킵니다.

Fast, Secure, and Simple: Istio’s Ambient Mode Reaches General Availability in v1.24

Our latest release signals ambient mode – service mesh without sidecars – is ready for everyone - Blog

• Istio의 앰비언트 데이터 플레인 모드가 General Availability(GA)에 도달했음을 자랑스럽게 발표하며, Istio TOC에 의해 ztunnel, 웨이포인트 및 API가 Stable로 표시되었습니다. 이는 Istio의 기능 단계 진행의 마지막 단계로, 앰비언트 모드가 광범위한 프로덕션 사용을 위해 완전히 준비되었음을 알리는 신호입니다.

• 앰비언트 메시(Ambient Mesh)와 Istio의 앰비언트 모드에 대한 참조 구현은 2022년 9월에 발표되었습니다. 그 이후로 우리 커뮤니티는 26개월간의 노력과 협력을 기울였으며, Solo.io , Google, Microsoft, Intel, Aviatrix, Huawei, IBM, Red Hat 등 많은 사람들의 기여를 받았습니다. 1.24의 안정적인 상태는 앰비언트 모드의 기능이 이제 광범위한 프로덕션 워크로드에 완전히 대비되었음을 나타냅니다. 이는 Istio에게 큰 이정표로, 사이드카 없이도 Istio를 프로덕션 준비 상태로 전환하고 사용자에게 선택권을 제공합니다.

How does ambient mode make adoption easier?

• 앰비언트 메시의 핵심 혁신은 레이어 4(L4)와 레이어 7(L7) 처리를 두 개의 서로 다른 레이어로 분할하는 것입니다. Istio의 앰비언트 모드는 가볍고 공유된 L4 노드 프록시와 선택적인 L7 프록시로 구동되므로 데이터 플레인에서 기존 사이드카 프록시가 필요하지 않습니다. 이 레이어드 접근 방식을 통해 Istio를 점진적으로 채택하여 메시 없음에서 보안 오버레이(L4)로, 필요에 따라 이름 공간 단위로 전체 L7 처리로 원활하게 전환할 수 있습니다.

• 앰비언트 메시를 활용하여 사용자들은 사이드카 모델의 이전에 제한적이었던 요소들을 우회합니다. 이제 서버 전송 우선 프로토콜이 작동하며, 대부분의 예약된 포트를 사용할 수 있게 되었으며, 컨테이너가 악의적이든 아니든 사이드카를 우회할 수 있는 기능이 제거되었습니다.

• 경량 공유 L4 노드 프록시를 ztunnel(제로 트러스트 터널)이라고 합니다. ztunnel은 예상 부하를 처리하기 위해 클러스터 내에서 메모리와 CPU를 과도하게 프로비저닝할 필요를 제거하여 메시 실행의 오버헤드를 크게 줄여줍니다. 일부 사용 사례에서는 암호화 신원, 간단한 L4 인증 정책 및 원격 측정 기능을 갖춘 상호 TLS를 사용하여 제로 트러스트 보안을 제공하면서도 90% 이상의 비용을 절감할 수 있습니다.

• L7 프록시를 웨이포인트라고 합니다. 웨이포인트는 트래픽 라우팅, 풍부한 권한 부여 정책 시행, 엔터프라이즈급 복원력과 같은 L7 기능을 처리합니다. 웨이포인트는 애플리케이션 배포 외부에서 실행되며 전체 네임스페이스 또는 네임스페이스 내의 여러 서비스에 대한 필요에 따라 독립적으로 확장할 수 있습니다. 사이드카와 비교할 때 애플리케이션 포드당 하나의 웨이포인트가 필요하지 않으며, 그 범위에 따라 웨이포인트를 효과적으로 확장할 수 있어 대부분의 경우 상당한 양의 CPU와 메모리를 절약할 수 있습니다.

• L4 보안 오버레이 레이어와 L7 처리 레이어 사이의 분리는 이전의 바이너리 "올인" 사이드카 주입과 달리 앰비언트 모드 데이터 평면을 점진적으로 채택할 수 있게 합니다. 사용자는 보안 L4 오버레이로 시작할 수 있으며, 이 오버레이는 사람들이 Istio를 배포하는 대부분의 기능(mTLS, 인증 정책, 원격 측정)을 제공합니다. 그런 다음 재시도, 트래픽 분할, 로드 밸런싱, 관찰 가능성 수집과 같은 복잡한 L7 처리를 사례별로 활성화할 수 있습니다.

What is in scope? 개발 기능(현재 미지원 기능) : Multi-cluster installations , Multi-network support , VM support

• 앰비언트 모드의 일반적인 가용성은 이제 다음과 같은 것들이 안정적인 것으로 간주된다는 것을 의미합니다:

  • 환경 모드를 지원하는 Helm 또는 istioctl을 사용하여 Istio를 설치합니다 - Docs

  • 워크로드를 메시에 추가하여 암호화 신원, L4 인증 정책 및 원격 측정을 통해 상호 TLS를 얻습니다.

  • 트래픽 전환, 요청 라우팅, 풍부한 권한 부여 정책 시행과 같은 L7 기능을 사용하도록 웨이포인트를 구성합니다.

  • Istio 입력 게이트웨이를 앰비언트 모드의 워크로드에 연결하여 Kubernetes 게이트웨이 API와 모든 기존 Istio API를 지원합니다.

  • 제어된 메시 출력을 위한 웨이포인트 사용

  • istioctl을 사용하여 웨이포인트를 운영하고 ztunnel 및 웨이포인트를 문제 해결합니다.

• Refer to the feature status page for more information.

Roadmap : 개발 기능(현재 미지원 기능)

• Full support for sidecar and ambient mode interoperability

• Multi-cluster installations

• Multi-network support

• VM support

[Istio Docs] Architecture

Ambient and the Istio control plane - https://istio.io/latest/docs/ambient/architecture/control-plane/

The figure shows an overview of the control plane related components and flows between ztunnel proxy and the istiod control plane.

Ambient data plane - ****https://istio.io/latest/docs/ambient/architecture/data-plane/

Dataplane example for Layer 4 traffic

The following figure shows the datapath between ztunnel and a waypoint

HBONE : composes(HTTP/2, HTTP CONNECT, mTLS) https://istio.io/latest/docs/ambient/architecture/hbone/

HBONE L3 packet format

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

Istio’s in-pod traffic redirection model

This diagram illustrates how encrypted traffic flows between pods in the ambient mesh in the new model:

Jimmy Song Blog Review

Istio CNI Unveiled: Streamlining Service Mesh Connectivity

서비스 메시 연결 간소화 - Blog

• Init 컨테이너의 보안 위험과 이를 해결하는 방법 Security risks of Init containers and their solutions.

• Istio CNI의 작동 원리와 장점. Working principles and advantages of Istio CNI.

• Ambient Mode의 구현 메커니즘과 CNI와의 통합. Implementation mechanism of Ambient Mode and its integration with CNI.

Istio 네트워크 요구 사항 및 솔루션 개요

Istio 서비스 메시는 사이드카 모드를 통해 애플리케이션 트래픽을 가로채고 관리합니다. 이 모드는 사이드카 프록시와 init 컨테이너를 애플리케이션 파드에 주입하고 iptables 규칙을 사용하여 네트워크 트래픽을 관리합니다. 자세한 배포 및 운영 프로세스는 Istio의 사이드카 주입, 투명 트래픽 하이재킹 및 트래픽 라우팅 이해 를 참조하십시오 . 이 방법은 대부분의 쿠버네티스 플랫폼에서 효과적이지만, 권한에 대한 높은 의존성으로 인해 멀티 테넌트 환경에서는 보안 문제가 발생할 수 있습니다.

Istio-init의 한계 Limitations

• Istio는 초기 네트워크 구성 과정에서 istio-init트래픽 차단 규칙을 초기화하기 위해 컨테이너를 채택했으며, IPTables 규칙과 같은 네트워크 구성을 수정하려면 컨테이너에 고급 권한이 필요했습니다. 이 방법은 트래픽을 효과적으로 관리하지만, 권한 요구 사항과 보안 위험을 크게 증가시킵니다. Istio 문서 에 따르면 , istio-init컨테이너는 기본적으로 Istio 메시 내의 포드에 주입되어 Istio의 사이드카 프록시로 네트워크 트래픽을 하이재킹합니다. 이 프로세스는 포드를 배포하는 서비스 계정에 NET_ADMIN컨테이너 권한을 부여해야 하며 , 이는 일부 조직의 보안 정책과 상충될 수 있습니다.

Istio CNI 플러그인

• 이러한 과제에 대응하여 Istio 커뮤니티는 Istio CNI 플러그인을 도입했습니다 . 이 플러그인은 init 컨테이너의 필요성을 없애고 Kubernetes 네트워크 계층에서 직접 조작을 허용하여 권한 요구 사항을 줄이고 배포 프로세스를 간소화하지만 CNI 호환성 문제가 있습니다.

앰비언트 모드 소개

• Istio의 Ambient Mode는 Geneve 터널 이나 Istio CNI를 사용 하여 네트워크 유연성과 보안을 강화하는 혁신적인 사이드카 없는 솔루션입니다 .

• Istio 커뮤니티는 최근에야 모든 CNI와 호환되는 범용 솔루션을 도입했습니다 . 이 모드는 모든 CNI와의 호환성 문제를 해결하여 Istio가 기존 네트워크 정책에 영향을 미치지 않고 서비스 간 트래픽을 더욱 효과적으로 관리할 수 있도록 지원합니다.

NET_ADMIN 권한에 대한 보안 고려 사항

• 쿠버네티스 및 도커와 같은 컨테이너 환경에서는 NET_ADMIN권한을 통해 컨테이너 내 프로세스가 iptables 규칙 수정, 네트워크 인터페이스 구성 변경, IP 라우팅 테이블 관리, 네트워킹 관련 커널 매개변수 제어 등 광범위한 네트워크 관련 작업을 수행할 수 있습니다. 그러나 이러한 권한을 사용하면 보안 문제가 발생하며, 특히 과도한 권한 부여 및 잠재적인 공격 영역과 관련된 문제가 발생할 수 있습니다.

모범 사례는 다음과 같습니다

• 사용 범위 제한NET_ADMIN : 필요한 경우에만 권한을 부여하고 Kubernetes 네트워크 정책을 통해 이를 제한합니다.

• 지속적인 모니터링 및 감사NET_ADMIN : 권한을 사용하여 컨테이너에 대한 엄격한 로깅 및 모니터링을 시행합니다

Istio CNI 플러그인의 작동 원리

Istio CNI 플러그인은 각 노드의 파일 시스템에 에이전트로 설치되는 바이너리 파일입니다. 다음 흐름도는 Istio CNI 노드 에이전트의 작동 원리를 보여줍니다.

Working Principles of Istio CNI Plugin

• Istio CNI 노드 에이전트는 각 노드에 설치된 에이전트 역할을 합니다.

• Istio CNI 플러그인을 설치하고 노드의 CNI 구성을 업데이트합니다.

• 에이전트는 CNI 플러그인과 구성 경로의 변경 사항을 모니터링합니다.

• 사이드카 모드 에서는 포드에 대한 iptables를 사용하여 사이드카 네트워킹 설정을 처리합니다.

• 앰비언트 모드 에서는 포드 이벤트를 앰비언트 감시 서버와 동기화한 다음, 해당 서버가 포드 내에서 iptables를 구성합니다.

• 노드에는 두 가지 모드에서 작동하기 위해 CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW 와 같은 상승된 권한이 필요합니다

Istio Ambient Mode와 Kubernetes CNI 간 충돌 해결

Istio의 앰비언트 모드는 모든 CNI에 적응하도록 설계되었으며, 기존 CNI 구성에 영향을 주지 않고 ztunnel을 사용하여 포드 내 트래픽 리디렉션을 투명하게 처리합니다. 이 모드에서 앰비언트 모드는 ztunnel을 통해 Istio 서비스 메시를 통과하는 트래픽을 관리하는 반면, 표준 CNI는 포드에 표준화된 네트워크 액세스를 제공하는 데 중점을 둡니다.

• CNI의 주요 역할은 IP 주소 할당 및 패킷 전달 등 쿠버네티스 파드 간의 네트워크 연결 문제를 해결하는 것입니다. 반면, 앰비언트 모드는 ztunnel로 트래픽을 가져와야 하는데, 이는 CNI의 네트워크 구성과 호환되지 않을 수 있습니다. 주요 문제는 다음과 같습니다.

  • 주요 CNI 네트워크 구성은 Istio의 CNI 확장과 충돌하여 트래픽 처리가 중단될 수 있습니다.

  • 배포된 네트워크 정책이 CNI에 따라 달라지는 경우 Istio CNI를 사용하면 이러한 정책의 실행에 영향을 미칠 수 있습니다.

• 이러한 문제를 해결하기 위해, 포드와 동일한 사용자 공간에서 ztunnel을 실행하여 트래픽 리디렉션을 관리함으로써 CNI에 의해 수정된 커널 공간과의 충돌을 방지합니다. 따라서 포드는 CNI의 영향을 받지 않고 ztunnel에 직접 연결할 수 있습니다.

• 다음 시퀀스 다이어그램은 Ambient 모드에서의 프로세스를 설명합니다.

• Ambient CNI 에이전트는 포드 생성을 알리는 UDS 이벤트를 수신하여 상호작용을 시작합니다.

• Ambient Watch Server는 필요에 따라 포드 내의 iptables를 수정하여 트래픽을 ztunnel로 리디렉션합니다.

• ztunnel은 Kubernetes 클러스터 내에서 연결을 설정하고 네트워크 트래픽 리디렉션을 처리합니다.

• 이러한 충돌을 완화하기 위해 Istio의 Ambient Mode는 CNI에서 수정된 커널 공간에 대한 종속성을 피합니다.

  • 사용자 공간에서 ztunnel 실행 : ztunnel이 포드와 동일한 사용자 공간에서 실행되어 CNI와의 직접적인 충돌을 피할 수 있습니다.

  • CNI 호환성 보장 : Istio CNI 구성은 기존 CNI 플러그인 구성에 영향을 미치지 않고 수행되어야 하며, 포드 간의 정상적인 통신과 트래픽 관리를 보장해야 합니다.

• 이러한 조치는 Istio의 Ambient Mode가 기존 CNI 플러그인을 방해하지 않고 서비스 간 트래픽을 효과적으로 관리하는 데 도움이 됩니다.

Istio Ambient Mode를 통한 최적화된 트래픽 관리

Istio의 앰비언트 모드는 노드 로컬 Ztunnel을 통한 고급 트래픽 전달 메커니즘을 사용하여 Pod의 네트워크 네임스페이스 내에 수신 소켓을 설정할 수 있도록 합니다.

이 설정은 서비스 메시에서 발생하는 암호화된(mTLS) 트래픽과 일반 텍스트 트래픽의 효과적인 리디렉션을 용이하게 합니다.

이러한 접근 방식은 트래픽 관리의 유연성을 향상시킬 뿐만 아니라 기존 CNI 플러그인과의 잠재적 충돌을 방지합니다.

• 이 모드의 자세한 구현 흐름은 다음과 같습니다.

1. 태그 감지istio.io/dataplane-mode=ambient: Istio CNI 노드 에이전트는 태그가 지정된 Pod를 감지합니다.

2. CNI 플러그인 트리거 : Pod 이벤트(새로운 시작 또는 기존 Pod가 메시에 가입)를 기반으로 CNI 플러그인이 트리거되어 Istio CNI 노드 에이전트가 트래픽 리디렉션을 구성합니다.

3. 리디렉션 규칙 구성 : 네트워크 리디렉션 규칙은 Pod의 네트워크 네임스페이스 내에 설정되어 트래픽을 가로채서 노드 로컬 ztunnel 프록시로 리디렉션합니다.

4. 수신 소켓 설정 : 노드 로컬 ztunnel은 트래픽 리디렉션을 활성화하기 위해 Pod의 네트워크 네임스페이스 내에 수신 소켓을 생성합니다.

5. 트래픽 처리: 노드 로컬 ztunnel은 메시 내에서 암호화된(mTLS) 트래픽과 일반 텍스트 트래픽을 처리하여 안전하고 효율적인 데이터 전송을 보장합니다.

Detailed Explanation of Transparent Traffic Interception in Istio Ambient Mode

Istio Ambient Mode에서 투명 트래픽 차단에 대한 자세한 설명 - Blog

• 이 글은 Istio 앰비언트 모드 시리즈의 첫 번째 글입니다. 다음 글에서는 ztunnel이 트래픽을 웨이포인트 프록시로 전달하는 방식, 웨이포인트 프록시가 트래픽을 처리하는 방식, 그리고 Bookinfo 예제를 사용하여 트래픽 경로를 종합적으로 분석하는 등 주요 구성 요소와 작동 원리를 자세히 살펴보겠습니다. 트래픽 인터셉션은 서비스 메시 기능의 기반이므로, 이 글에서는 트래픽 인터셉션부터 시작하여 전체적인 이해를 도모하고자 합니다.

• Istio 앰비언트 모드는 각 포드에 사이드카를 주입할 필요성을 없애는 서비스 메시 구현 방식입니다. 포드의 네트워크 네임스페이스 내에서 투명한 트래픽 차단 및 리디렉션을 구성함으로써 애플리케이션은 수정 없이 서비스 메시 기능을 활용할 수 있습니다. 다음 내용은 Istio CNI 노드 에이전트 , ztunnel , 네트워크 네임스페이스 , iptables 규칙 등의 구성 요소를 포괄하는 투명한 트래픽 차단 프로세스에 대한 자세한 설명을 제공하며, 흐름도와 다이어그램을 통해 설명됩니다.

배경 지식 : NET NS, Istio CNI Node Agent, ztunnel, HBONE

Linux 네트워크 네임스페이스

• 네트워크 네임스페이스 는 여러 프로세스의 네트워크 환경을 격리하는 데 사용되는 Linux 커널 기능입니다. 각 네트워크 네임스페이스는 고유한 네트워크 장치, IP 주소, 라우팅 테이블 및 iptables 규칙을 갖습니다. 컨테이너 기술(예: Docker, Kubernetes)은 네트워크 네임스페이스를 사용하여 각 컨테이너(또는 Pod)에 격리된 네트워크 스택을 제공합니다.

Istio CNI 노드 에이전트

• Istio CNI 노드 에이전트는 쿠버네티스 노드에서 작동하는 앰비언트 모드의 핵심 구성 요소로, 앰비언트 메시에 참여하는 파드를 감지하고 해당 파드에 대한 트래픽 리디렉션 규칙을 구성합니다. 이는 기존 Istio CNI 플러그인이 아닌 Istio CNI 노드 에이전트를 사용합니다. 노드 에이전트는 ztunnel과 함께 작동하는 데몬 역할을 하지만 네트워크 플러그인 작업을 직접 수행하지는 않습니다.

ztunnel

• ztunnel 은 각 노드에서 DaemonSet으로 실행되는 앰비언트 모드의 핵심 구성 요소입니다. ztunnel의 역할은 다음과 같습니다.

  • 리디렉션된 트래픽을 수신하고 처리합니다.

  • mTLS 암호화 및 액세스 제어와 같은 L4 정책을 시행합니다.

  • 제어 평면과 통신하여 구성 및 인증서를 얻습니다.

HBONE (HTTP-Based Overlay Network Encapsulation)

• HBONE(HTTP 기반 오버레이 네트워크 캡슐화) 은 Istio에서 ztunnel과 웨이포인트 프록시 간의 임의의 TCP 트래픽 전송을 위해 도입한 프로토콜입니다.

• HBONE은 HTTP/2 및 HTTP/3 다중화 및 암호화 기능을 활용하여 통신 효율성과 보안을 향상시킵니다.

Detailed Traffic Interception Process

앰비언트 모드에서는 애플리케이션 포드에 코드 변경이나 사이드카 주입이 필요하지 않습니다. 트래픽 가로채기 및 리디렉션은 포드의 네트워크 네임스페이스 내에서만 이루어지므로 기본 CNI와의 충돌을 방지합니다.

• 관련 단계는 다음과 같습니다.

Traffic Interception Process in Istio Ambient Mode

1. Pod 초기화 및 네트워크 구성 Pod Initialization and Network Configuration

   • 쿠버네티스가 포드를 생성할 때 컨테이너 런타임 인터페이스(CRI)를 통해 기본 CNI 플러그인(예: Calico, Cilium)을 호출하여 포드의 네트워크를 구성합니다.

   • 이 단계에서는 포드의 네트워크 네임스페이스(netns)가 설정됩니다.

2. Istio CNI 노드 에이전트가 트래픽 리디렉션을 구성 Istio CNI Node Agent Configures Traffic Redirection

   • Istio CNI 노드 에이전트는 새로운 포드가 주변 모드로 표시되었음을 감지합니다(레이블을 통해 istio.io/dataplane-mode=ambient).

   • 포드의 네트워크 네임스페이스에 들어가 트래픽 가로채기를 위한 iptables 규칙을 설정합니다.

   • 네트워크 네임스페이스의 파일 설명자(FD)가 ztunnel에 전달됩니다. The network namespace’s file descriptor (FD) is passed to ztunnel.

3. Ztunnel이 Pod 네트워크 네임스페이스에서 소켓 수신을 시작 Ztunnel Starts Listening Sockets in Pod Network Namespace

   • ztunnel은 네임스페이스 FD를 수신하고 리디렉션된 트래픽을 처리하기 위해 해당 네임스페이스 내의 소켓을 수신하기 시작합니다. ztunnel receives the namespace FD and starts listening sockets within it to handle redirected traffic.

4. 투명한 트래픽 차단 및 처리 Transparent Traffic Interception and Processing

   • 애플리케이션에서 발생한 트래픽은 Pod의 iptables 규칙에 의해 가로채여 투명하게 ztunnel로 리디렉션됩니다.

   • ztunnel은 트래픽을 대상 서비스로 전달하기 전에 정책 검사, 암호화 및 기타 처리를 수행합니다.

   • 응답은 ztunnel에 의해 해독되어 애플리케이션으로 반환됩니다.

ztunnel Log Analysis 로그 분석

• 다음 명령을 사용하여 ztunnel의 트래픽 차단과 관련된 모든 로그를 검사할 수 있습니다.

kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"

• 로그는 아래 예와 비슷하게 표시되며, 여기서 inbound및 outbound는 ztunnel을 기준으로 합니다.

• 인바운드 트래픽 예

2024-11-16T10:33:01.410751Z	info	access	connection complete	src.addr=10.28.2.19:58000 src.workload="bookinfo-gateway-istio-64fc6d75d6-s442s" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/bookinfo-gateway-istio" dst.addr=10.28.2.18:15008 dst.hbone_addr=10.28.2.18:9080 dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-57ffb6658c-tgbjs" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="inbound" bytes_sent=9603 bytes_recv=2052 duration="2110ms"

이 로그는 HBONE 터널을 사용하여 ztunnel을 통해 경유지 포드(포트 15008)로 라우팅된 제품 페이지 포드에서 세부 서비스로 나가는 아웃바운드 트래픽을 보여줍니다.

결론 : Istio 앰비언트 모드는 Istio CNI 노드 에이전트와 ztunnel의 협업을 통해 사이드카 없이 투명한 트래픽 차단을 구현

• 높은 호환성 : 기본 CNI와의 충돌을 방지합니다.

• 간소화된 작업 : 애플리케이션 코드를 변경할 필요가 없어 리소스 오버헤드가 줄어듭니다.

• 강화된 보안 : HBONE을 통해 종단 간 암호화된 전송이 가능합니다.

In-Pod IPtables Rule Injection in Istio Ambient Mode Explained

A deep dive into how iptables rules in Istio ambient mode enable transparent traffic interception and control within Pods.

iptables Rules Inside the Pod : Pod 내부의 iptables 규칙

• 포드의 네트워크 네임스페이스에서 Istio CNI 노드 에이전트는 투명한 트래픽 차단 및 리디렉션을 가능하게 하는 일련의 iptables 규칙을 설정합니다.

• 다음 규칙들은 mangle과 nat 테이블에 삽입되어 Istio가 인바운드 및 아웃바운드 트래픽을 처리하는 방법을 보여줍니다.

# Generated by iptables-save v1.8.9 (nf_tables) on Thu Nov 14 08:43:17 2024
*mangle
:PREROUTING ACCEPT [99138:22880045]  # Default ACCEPT policy for the PREROUTING chain in the mangle table.
:INPUT ACCEPT [0:0]                  # Default ACCEPT policy for the INPUT chain in the mangle table.
:FORWARD ACCEPT [0:0]                # Default ACCEPT policy for the FORWARD chain in the mangle table.
:OUTPUT ACCEPT [100900:34940164]     # Default ACCEPT policy for the OUTPUT chain in the mangle table.
:POSTROUTING ACCEPT [0:0]            # Default ACCEPT policy for the POSTROUTING chain in the mangle table.
:ISTIO_OUTPUT - [0:0]                # Custom ISTIO_OUTPUT chain for handling outbound traffic.
:ISTIO_PRERT - [0:0]                 # Custom ISTIO_PRERT chain for handling prerouting traffic.
-A PREROUTING -j ISTIO_PRERT         # Direct all PREROUTING traffic to the ISTIO_PRERT chain.
-A OUTPUT -j ISTIO_OUTPUT            # Direct all OUTPUT traffic to the ISTIO_OUTPUT chain.
-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
# Restore connection mark 0x111/0xfff for consistent connection tracking.

-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff
# Set connection mark to 0x111/0xfff for packets marked 0x539/0xfff in PREROUTING.

COMMIT  # Apply mangle table rules.
# 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]           # Default ACCEPT policy for the PREROUTING chain in the nat table.
:INPUT ACCEPT [0:0]                  # Default ACCEPT policy for the INPUT chain in the nat table.
:OUTPUT ACCEPT [119:9344]            # Default ACCEPT policy for the OUTPUT chain in the nat table.
:POSTROUTING ACCEPT [0:0]            # Default ACCEPT policy for the POSTROUTING chain in the nat table.
:ISTIO_OUTPUT - [0:0]                # Custom ISTIO_OUTPUT chain for handling outbound NAT traffic.
:ISTIO_PRERT - [0:0]                 # Custom ISTIO_PRERT chain for handling prerouting NAT traffic.
-A PREROUTING -j ISTIO_PRERT         # Direct all PREROUTING traffic to the ISTIO_PRERT chain.
-A OUTPUT -j ISTIO_OUTPUT            # Direct all OUTPUT traffic to the ISTIO_OUTPUT chain.
-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
# Allow TCP traffic destined for 169.254.7.127 (likely an internal Istio address).

-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT
# Allow TCP traffic marked as 0x111/0xfff.

-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ACCEPT
# Allow traffic to the loopback interface excluding 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
# Redirect outbound TCP traffic (not marked 0x539/0xfff) destined outside 127.0.0.1 to port 15001 (outbound socket).

-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
# Allow TCP traffic originating from 169.254.7.127 in the PREROUTING chain.

-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
# Redirect inbound TCP traffic (not marked 0x539/0xfff) to port 15006 (inbound socket) if its destination port is not 15008.

COMMIT  # Apply nat table rules.
# Completed on Thu Nov 14 08:43:17 2024

Role of Specific Ports : 특정 포트의 역할

• 15008(HBONE 소켓) : HBONE 프로토콜을 사용하여 HTTP 기반 트래픽을 투명하게 처리합니다.

• 15006(일반 텍스트 소켓) : 포드 간 통신을 위해 메시 내의 암호화되지 않은 트래픽을 관리합니다.

• 15001(아웃바운드 소켓) : 아웃바운드 트래픽을 제어하고 외부 서비스 액세스에 대한 정책을 시행합니다.

• Istio는 이러한 포트를 활용하여 인바운드, 아웃바운드 및 내부 트래픽을 투명하게 관리하고 제어하며, 세분화된 보안 정책과 트래픽 제어를 적용합니다. 자세한 내용은 Istio 애플리케이션 요구 사항을 참조하세요 .

Significance of 0x539 Mark!

• 0x539 마크는 Istio 프록시(예: ztunnel)에서 발생하는 트래픽을 식별합니다. 이 마크는 프록시에서 처리된 패킷을 구별하여 재처리되거나 잘못된 경로로 지정되지 않도록 합니다.

Significance of 0x111 Mark!

• 0x111 마크는 Istio 메시 내의 연결 수준 표시에 사용되며, 이는 프록시에 의해 연결이 처리되었음을 나타냅니다.

• iptables의 CONNMARK 모듈은 이 마크를 전체 연결로 확장하여 후속 패킷 매칭 속도를 높입니다.

Visualizing iptables Rules : 규칙 시각화 - Code

Traffic Routing Visualization : 트래픽 라우팅 시각화

노드 간 암호화된 L4 트래픽 의 경로

Cross-node encrypted traffic (L4)

1. 애플리케이션이 요청을 보냅니다

   • 트래픽은 애플리케이션 프로세스에 의해 시작되어 Pod의 네트워크 네임스페이스에 들어갑니다.

2. iptables 규칙 매칭:

   • 아웃바운드 트래픽은 OUTPUT 체인에서 일치하며, 권한 있는 트래픽 eligible traffic은 ISTIO_OUTPUT 체인으로 리디렉션됩니다.

   • ISTIO_OUTPUT 체인에서는 트래픽이 표시 marked 되고 수락 accepted됩니다.

3. REDIRECT 동작

   • 트래픽은 iptables에 의해 캡처되어 ztunnel의 수신 포트(일반 텍스트 트래픽의 경우 15006, 암호화된 트래픽의 경우 15008)로 리디렉션됩니다.

4. ztunnel은 트래픽을 처리합니다

   • ztunnel은 트래픽을 수신하고 정책 검사, 암호화 및 기타 작업을 수행합니다.

5. 트래픽이 대상 서비스로 전달됩니다

   • ztunnel은 처리된 트래픽을 HBONE 터널을 통해 대상 노드의 ztunnel로 전송합니다. 이후 ztunnel은 트래픽을 복호화하여 대상 서비스로 전달합니다.

Packet Lifecycle and Traffic Optimization in Istio Ambient Mode

Istio Ambient Mode에서의 패킷 수명 주기 및 트래픽 최적화 - Blog

Overview of Packet Lifecycle: From Kernel Space to User Space - 패킷 수명 주기 개요: 커널 공간에서 사용자 공간으로

• 앰비언트 모드에서 패킷 처리는 Pod의 커널 공간 네트워크 스택에서 시작됩니다.

• 여기서 패킷은 iptables 규칙에 의해 가로채인 후 사용자 공간의 zTunnel에 의해 처리됩니다.

• zTunnel은 투명 프록싱, 정책 적용, 암호화된 터널 생성 등의 작업을 처리합니다.

• 그런 다음 패킷은 대상 서비스 또는 다른 zTunnel로 전달되기 위해 커널 공간 네트워크로 다시 전송됩니다.

• 핵심 아이디어는 첫 번째 패킷을 세부적으로 분석하고 태그를 지정하여 후속 패킷의 경로를 확보함으로써 중복 오버헤드를 줄이는 것입니다.

• 아래 다이어그램은 Istio Ambient Mode에서 Pod에서 zTunnel로 가는 패킷 수명 주기를 보여줍니다.

Packet Lifecycle in Istio Ambient Mode from a Pod to ztunnel

First Packet Path: From Interception to Destination Resolution - 첫 번째 패킷 경로: 가로채기에서 목적지 확인까지 → 후속 패킷 최적화를 위해 기록

• 초기 패킷 방출

  • Pod 내의 애플리케이션이 패킷(예: HTTP 요청)을 방출하면 해당 패킷은 먼저 Pod의 네트워크 네임스페이스와 커널 공간 네트워크 스택에서 처리됩니다.

• Iptables를 통한 투명한 차단

  • iptables 규칙은 아웃바운드 트래픽을 필터링합니다. 대상 주소가 non-local이고 패킷에 특정 태그가 없는 경우 zTunnel의 투명 프록시 포트(예: 15006 또는 15008)로 리디렉션됩니다.

  • IP_Transparent 및 SO_ORIGINAL_DST 옵션을 사용하여 zTunnel은 사용자 공간에서 패킷의 원래 목적지 주소를 추출할 수 있습니다. ⇒ 소스IP 보존!

  • 이렇게 하면 동일한 노드, 여러 노드 또는 메시 외부에 위치한 서비스에 대해 투명한 프록시 처리가 가능합니다.

• zTunnel 사용자 공간에서의 정책 검증 및 처리 :

  • zTunnel에 들어가면 첫 번째 패킷은 RBAC 검증 및 mTLS 암호화 결정과 같은 정책 및 보안 검사를 거칩니다.

  • 메쉬 내 트래픽의 경우, 암호화된 노드 간 통신을 위해 HTTP/2 CONNECT 터널(HBONE)이 설정됩니다. 메쉬 외 트래픽의 경우, 직접 TCP 전송이 사용됩니다.

• 패킷 송신 및 연결 설정 :

  • 처리 후, zTunnel은 패킷의 구문 분석된 세부 정보를 기반으로 아웃바운드 소켓(예: HTTP/2 터널 또는 평문 TCP 연결)을 설정하고, 이를 커널 공간으로 다시 보내 대상 서비스 또는 zTunnel로 라우팅합니다.

  • 이 시점에서 첫 번째 패킷은 커널 공간에서 사용자 공간으로 갔다가 돌아오는 전체 여정을 완료했습니다.

  • 연결 상태, 정책 및 터널 정보는 후속 패킷을 최적화하기 위해 기록됩니다.

Subsequent Packet Path: Fast Forwarding with Conntrack and Tunnel Reuse - 후속 패킷 경로: Conntrack 및 터널 재사용을 통한 빠른 전달

• 첫 번째 패킷이 대상 해결 및 정책 검증을 완료하면, 리눅스 커널의 연결 추적(conntrack)은 연결 상태를 기록하고 태그를 지정합니다.

• 동일한 연결에 속하는 후속 패킷은 복잡한 iptables 리디렉션 및 대상 해상도를 우회하여 zTunnel의 인바운드 소켓에 직접 도달합니다.

Conntrack의 역할

• conntrack은 기존 연결을 추적하여 후속 패킷을 위한 빠른 경로를 제공합니다.

• 이를 통해 iptables 규칙을 반복적으로 트리거하거나 정책 검사를 거치지 않고 패킷을 zTunnel로 직접 전송할 수 있습니다.

인바운드 소켓 및 사용자 공간 처리 Inbound Socket and User Space Processing

• zTunnel의 인바운드 소켓에 들어오는 후속 패킷은 연결 태그에 의해 직접 식별되며, 복잡한 RBAC 검증 또는 암호화 결정을 건너뛰게 됩니다.

• 첫 번째 패킷에 대해 암호화된 터널(HBONE)이 설정된 경우, 후속 패킷들은 이 터널을 재사용합니다.

• 평문 트래픽의 경우, 기존 TCP 연결이 직접 전송에 사용됩니다.

터널 및 일반 텍스트 경로 최적화 Optimization for Tunnel and Plaintext Paths

• HBONE 터널 : 메쉬 내 암호화된 트래픽의 경우 HTTP/2 터널을 통해 멀티플렉싱이 가능해져 반복적인 연결 오버헤드가 줄어듭니다.

• Plaintext Socket : 로컬 또는 외부 비암호화 트래픽의 경우, 후속 패킷은 기존 평문 연결을 사용하여 추가 캡슐화를 방지합니다.

이러한 메커니즘은 후속 패킷의 처리 경로를 크게 간소화하여 성능과 처리량을 향상시킵니다.

Key Technical Points and Optimization Strategies 핵심 기술 포인트 및 최적화 전략

1. Transparent Proxying

   • IP_Transparent와 SO_ORIGINAL_DST를 사용하여 zTunnel은 non-local 트래픽을 원활하게 캡처하고 파싱하여 진정한 투명 프록시를 달성합니다.

2. Efficient Kernel-User Space Switching 효율적인 커널-사용자 공간 전환

   • 사용자 공간에서 첫 번째 패킷에 대한 상세한 구문 분석과 정책 검증을 완료하고, 후속 패킷에 대한 연결 트랙 및 인바운드 소켓 메커니즘을 활용함으로써 불필요한 컨텍스트 전환을 최소화할 수 있습니다.

3. Multiplexed Tunnels 다중화 터널

   • HTTP/2 CONNECT 터널(HBONE)은 암호화, 로드 밸런싱 및 다중화를 지원하여 후속 패킷 전송의 효율성을 향상시킵니다.

Understanding L7 Traffic Management in Istio Ambient Mode: From Ztunnel to Waypoint Proxy

Istio Ambient Mode에서 L7 트래픽 관리 이해하기: Ztunnel에서 Waypoint Proxy까지 - Blog

• Istio의 앰비언트 모드에서 ztunnel은 서비스 간 L4 트래픽 가로채기 및 암호화를 담당하는 노드 수준 보안 프록시 역할을 합니다.

• 그러나 ztunnel은 HTTP 기반 라우팅이나 정책 적용과 같은 L7 작업은 처리하지 않습니다.

• L7 트래픽 관리를 위해 Envoy 기반 웨이포인트 프록시가 HTTP 요청을 처리하고 L7 정책을 적용합니다.

• ztunnel은 L7 처리가 필요한 트래픽을 감지하면 HBONE 프로토콜을 사용하여 해당 트래픽을 웨이포인트 프록시로 전달합니다.

• 프록시는 정책을 적용하고, 원격 측정 데이터를 로깅하고, ztunnel을 통해 대상 Pod로 요청을 전달합니다.

• 이 게시물에서는 트래픽 전달 경로를 자세히 설명하고, L7 트래픽이 ztunnel 에서 웨이포인트 프록시로, 그리고 최종적으로 대상 Pod로 흐르는 방식을 분석합니다

Roles and Responsibilities in Ambient Mode 앰비언트 모드에서의 역할 및 책임

• L4(TCP) 수준에서 트래픽을 가로챕니다.

• mTLS 암호화를 사용하여 트래픽을 보호하고 서비스 ID를 인증합니다.

웨이포인트 프록시(L7 트래픽 관리자)

• HTTP 라우팅, 인증, 권한 부여, 원격 측정과 같은 L7 트래픽 정책을 관리합니다.

• 애플리케이션 인식 프록시 역할을 하여 비즈니스별 정책을 적용하고 관찰 스택에 메트릭을 전송합니다.

요청에 L7 처리(예: productpage서비스 호출 reviews-v1) 가 필요한 경우 ztunnel은 HBONE을 사용하여 트래픽을 웨이포인트 프록시로 전달하여 투명한 정책 적용 및 원격 측정 수집을 가능하게 합니다.

• ztunnel(L4 트래픽 관리자)

L7 Traffic Path in Ambient Mode*

The following diagram illustrates the L7 traffic path in Istio ambient mode:

L7 Traffic Path in Ambient Mode

다음 두 그림은 각각 동일 노드와 크로스 노드 시나리오에서 소스 Pod와 대상 Pod의 L7 트래픽 처리 경로를 보여줍니다

동일 노드에 있는 소스 포드와 목적지 포드의 L7 트래픽 경로

다른 노드에 있는 소스 파드와 대상 파드의 L7 트래픽 경로

Traffic Path Breakdown 분석

1. Application Request Sent : 요청 전송

   • productpage 서비스는 reviews.default.svc.cluster.local:9080에서 reviews-v1 서비스에 대한 HTTP 요청을 시작합니다.

2. ztunnel L4 Traffic Interception

   • 소스 노드의 Ztunnel은 Kubernetes의 iptables 규칙을 사용하여 제품 페이지에서 아웃바운드 요청을 intercepts합니다.

   • Istio의 제어 평면 구성을 검사하고 L7 정책이 적용되어야 한다고 판단합니다.

3. Forwarding Traffic Using HBONE Protocol : HBONE 프로토콜을 사용한 트래픽 전달

   • Ztunnel은 네이티브 Envoy XDS 또는 TCP+mTLS 터널링 대신 HBONE 프로토콜을 사용합니다.

   • HBONE(HTTP 기반 오버레이 네트워크 환경)은 HTTP/2에서 트래픽을 캡슐화하여 L7 처리를 위한 투명한 트래픽 전달을 가능하게 합니다.

   • ztunnel은 가로챈 트래픽을 HBONE 터널로 감싸 웨이포인트 프록시로 전달합니다.

4. L7 Processing and Policy Enforcement by Waypoint Proxy : Waypoint 프록시를 통한 L7 처리 및 정책 시행

   • 웨이포인트 프록시는 Envoy을 기반으로 구축되었으며, 인증을 위해 SPIFF ID와 컨텍스트 메타데이터를 사용하여 다운스트림 클라이언트의 mTLS 자격 증명을 검증합니다. 그런 다음 다음 다음 정책을 적용합니다

   • HTTP 라우팅 및 부하 분산 : 호스트/경로 헤더를 기반으로 요청을 라우팅합니다.

   • 승인 정책 : 헤더와 토큰을 통해 액세스를 검증합니다.

   • 트래픽 셰이핑 : 오류 주입, 요청 속도 제한, 재시도 구현.

   • 원격 측정 수집 : 메트릭, 로그, 추적 및 요청 기간을 추적합니다.

   • 웨이포인트 프록시는 처리된 트래픽을 HBONE을 통해 대상 노드의 ztunnel로 전달합니다.

5. Delivering Traffic to Target Pod : 타겟 포드에 트래픽 전달

   • 타겟 노드의 ztunnel은 HBONE을 통해 웨이포인트 프록시로부터 트래픽을 수신하고, 요청을 캡슐화 해제한 후 애플리케이션 포트의 타겟 포드(reviews-v1)로 전달합니다.

Insights and Key Takeaways

1. Transparent Routing via Waypoint Proxy :  Waypoint 프록시를 통한 투명한 라우팅

   • 웨이포인트 프록시는 대상 Pod의 IP 주소와 재작성된 포트 15008만 알고 있습니다.

   • ztunnel은 Kubernetes iptables를 사용하여 트래픽 리디렉션을 관리합니다.

2. End-to-End Security : 종단간 보안

   • SPIFF ID 검증을 통한 상호 TLS(mTLS)는 안전한 트래픽 전송을 보장합니다.

   • 트래픽은 ztunnel을 우회하여 제로 트러스트 아키텍처를 적용할 수 없습니다.

3. Transparent Policy Enforcement : 투명한 정책 시행

   • 개발자는 애플리케이션 코드를 변경할 필요가 없습니다.

   • 교통 관제, 보안, 원격 측정은 데이터 플레인 수준에서 완전히 자동화됩니다.

How to Debug Ambient Mode?

• Use istioctl ztunnel to inspect ztunnel configurations and states.

Waypoint Proxy Debugging

• Use Envoy-specific commands such as istioctl pc and istioctl ps to inspect Envoy proxy configurations.

• Use istioctl waypoint for streamlined configuration inspection.

Conclusion 결론

• Istio 앰비언트 모드는 투명 인터셉션, mTLS 암호화, 포워딩을 포함한 L4 트래픽 처리를 위해 ztunnel을 사용합니다.

• HTTP 기반 라우팅, 정책 시행, 원격 측정 수집과 같은 L7 작업은 웨이포인트 프록시에 의해 관리되며, ztunnel과 웨이포인트 프록시 간의 통신은 HBONE 프로토콜에 의해 촉진됩니다.

• 이 혁신적인 디자인은 사이드카를 제거하여 작동을 단순화하면서도 고성능, 보안, 관찰 가능성을 유지합니다.

Beyond Sidecar: A Deep Dive Into Istio Ambient Mode Traffic Mechanism and Cost Efficiency 

Istio의 배경, 핵심 구성 요소, 트래픽 흐름 메커니즘, Ambient Mode와 기존 Sidecar 모델 간의 비교를 소개 - Blog , Slide

Why Care About Ambient Mode? 앰비언트 모드가 중요한 이유는?

Challenges with Service Mesh

• 사이드카 프록시로 인해 발생하는 리소스 오버헤드 및 운영 복잡성

• Envoy를 업그레이드하거나시작하려면 다시 모든 Pod를 다시 시작해야 하는 경우가 많습니다.

• 고성능과 낮은 비용 에 대한 수요 증가

일반적인 서비스 메시 배포 모델

Proxy Locations

서비스 메시 아키텍처는 오랫동안 다음과 같은 다양한 프록시 배포 전략을 모색해 왔습니다.

• Sidecar : 각 Pod 내부에서 Envoy 프록시를 실행합니다.

• Ambient : 프록시를 Pod에서 노드 수준으로 이동합니다(이 게시물에서는 이에 대해 중점적으로 다룹니다)

• Cilium Mesh : L4의 커널 공간에서 eBPF를 사용하고 L7 기능을 위해 Envoy와 결합합니다.

• gRPC : 메시 기능을 애플리케이션 SDK에 직접 내장합니다.

이러한 각 모델은 기능, 보안, 성능 및 운영 복잡성 측면에서 장단점을 가지고 있습니다.

Istio Ambient Mode는 Sidecar 모델의 오버헤드와 운영 부담을 해결하기 위한 새로운 시도입니다.

앰비언트 모드의 탄생

• ztunnel + Waypoint Proxy를 사용하여 데이터 플레인을 단순화하고 Sidecar를 제거하는 차세대 Istio 아키텍처

• 자원을 절약하고 운영 복잡성을 줄입니다.

• Waypoint Proxy가 선택적으로 L7 기능을 제공 하면서 mTLS정책 시행을 및 계속 지원합니다 .

Deployment Model Quadrants

Istio Ambient Mode의 핵심 개념*Key Components of Ambient Mode

1. ztunnel(L4)

   • 노드 수준 프록시로 실행됩니다.

   • 투명한 트래픽 차단 및 mTLS 암호화를 담당합니다 .

   • L4 전달만 필요한 대부분의 트래픽을 처리합니다.

2. 웨이포인트 프록시(L7)

   • 선택적으로 배포됨(네임스페이스, 서비스 또는 포드 세분성으로 구성 가능)

   • HTTP/gRPC 인증, 라우팅, 관찰성과 같은 고급 기능을 처리합니다.

3. 이스티오 CNI

   • 컨테이너를 교체 istio-init 하고 트래픽 리디렉션을 처리합니다.

   • Supports both Sidecar and Ambient modes

   • 보안 강화를 위해 권한이 없는 모드 에서 트래픽 리디렉션을 활성화합니다.

Overview of Ambient Mode Architecture

Ambient Mode에서는 Istio 데이터 평면이 두 개의 계층으로 분할

1. Security Layer (ztunnel): A lightweight L4 proxy is deployed on each node

2. Optional L7 Layer (Waypoint Proxy): Deployed only when HTTP/gRPC proxying is needed

• 제어 평면은 여전히 Istiod 에서 관리하며 , Istiod는 구성과 인증서를 ztunnel과 Waypoint 프록시 모두에 배포합니다.

Deployment Strategies for Waypoint Proxy

• Namespace-level (default): Applies to all workloads in the namespace 네임스페이스의 모든 작업에 적용됩니다.

• Service-level: For services that require L7 processing only L7 처리만 필요한 서비스의 경우

• Pod-level: Offers fine-grained control 세부적인 제어 제공

• Cross-namespace: Enables sharing via Gateway resources 게이트웨이 리소스를 통한 공유를 활성화합니다.

Istio CNI

• Traffic Interception: Replaces the istio-init container, simplifying the installation process 초기화 대처로 설치 간소화

• Dual-mode Support: Compatible with both Sidecar and Ambient modes 모두 호환

• Unprivileged Mode Compatibility: Enables traffic redirection for Pods running without elevated privileges

• CNI Chaining: Adds Istio CNI as an additional plugin in the existing CNI configuration 기존 CNI 추가 플러그인

• In-Pod Traffic Redirection (Ambient Mode):

  • Uses iptables REDIRECT rules inside the Pod’s network namespace Pod의 네트워크 네임스페이스 내부에서 규칙을 사용

  • Creates a local socket within the Pod to intercept and proxy traffic Pod 내에 로컬 소켓을 생성하여 트래픽을 가로채고 프록시

다음 다이어그램은 Istio CNI가 Calico 또는 Cilium과 같은 쿠버네티스 네트워크 플러그인과 통합되는 방식을 보여줍니다.

Istio CNI는 CNI 체인에 자신을 추가하여 노드의 CNI 구성을 수정합니다.

쿠버네티스가 Pod IP를 할당하면 Istio CNI는 인터셉션 로직을 실행하고 트래픽 리디렉션 규칙을 Pod의 네트워크 네임스페이스에 삽입합니다.

Pod가 Sidecar 모드 또는 Ambient 모드에서 실행되는지에 따라 다른 규칙을 적용하여 iptables기존 네트워크 정책과 충돌하지 않고 보완하는 체인형 CNI 워크플로를 형성합니다.

How Istio CNI Works

How the Istio CNI Plugin Works

Pod가 시작될 때 Istio CNI가 수행하는 작업

1. Pod의 네트워크 네임스페이스에 들어가서 ztunnel이 수신 중인 소켓으로 트래픽을 리디렉션하기 위한 iptables 규칙 세트를 생성합니다.

2. 더 이상 각 Pod에 init 컨테이너를 주입할 필요가 없으며, 권한 상승도 필요하지 않습니다. 따라서 배포가 더욱 깔끔하고 안전해집니다.

3. ztunnel은 각 Pod의 네트워크 네임스페이스 내부에 소켓을 생성하고, 노드의 모든 Pod에 대해 이를 수행합니다.

Traffic Flow and Core Mechanisms

앰비언트 모드의 핵심 인 트래픽 경로 에 대해 자세히 알아보겠습니다.

zTunnel과 Waypoint는 어떻게 트래픽을 가로채고 전달하는 걸까요?

투명한 트래픽 가로채기와 HBONE 프로토콜을 통해 이 부분을 살펴보겠습니다.

Transparent Traffic Interception

• 앰비언트 모드에서 Istio CNI는 각 Pod의 네트워크 네임스페이스에 iptables 규칙을 주입하여 아웃바운드 트래픽을 투명하게 가로채고 노드의 로컬 ztunnel 프로세스로 리디렉션합니다. 그런 다음 zTunnel은 트래픽을 L4에서 전달할지 아니면 L7 처리를 위해 Waypoint Proxy 로 보낼지 결정합니다 .

• 다이어그램에서 볼 수 있듯이 Kubelet이 노드에서 Pod를 시작하면 Istio CNI 에이전트가 이 이벤트를 감지합니다. 에이전트는 Pod의 네트워크 네임스페이스에 진입하여 트래픽을 로컬 소켓으로 리디렉션하는 iptables 규칙을 설정하고, Pod의 파일 디스크립터(FD)를 zTunnel에 전달합니다. zTunnel은 FD를 수신하면 Pod의 네임스페이스 내에 소켓을 생성합니다.

• Pod가 트래픽을 전송할 때 일반적으로 대상 주소로 직접 전송됩니다. 하지만 iptables 규칙 때문에 트래픽이 가로채여 로컬 zTunnel 프로세스로 리디렉션됩니다. zTunnel은 Waypoint를 통해 트래픽에 L7 처리가 필요한지 여부를 판단합니다.

  • 그렇지 않은 경우, 트래픽을 암호화하여 L4 에서 대상 Pod로 직접 전달합니다.

  • L7Waypoint Proxy 기능이 필요한 경우 (예: 인증) 트래픽을 로 터널링합니다 .

Transparent Traffic Interception

Packet Lifecycle Overview

1. Pod → ztunnel : Pod의 트래픽은 CNI에 의해 가로채여 동일한 노드의 로컬 ztunnel로 리디렉션됩니다.

2. ztunnel : 대상 주소를 확인하고 mTLS 암호화를 적용합니다.

3. (L7 정책이 필요한 경우) ztunnel → Waypoint Proxy : HTTP 인증, 라우팅 등을 처리합니다.

4. 웨이포인트 프록시 : L7 처리 후 트래픽은 ztunnel로 다시 전송됩니다.

5. ztunnel : 트래픽을 대상 노드의 ztunnel로 캡슐화를 해제하거나 전달합니다.

6. 대상 Pod로 : 목적지 ztunnel은 최종적으로 대상 Pod로 트래픽을 전달합니다.

The HBONE Protocol

앰비언트 모드에서 ztunnel과 Waypoint Proxy는 HBONE(HTTP/2 + CONNECT) 프로토콜을 사용하여 보안 터널을 구축합니다.

이를 통해 mTLS 암호화 및 다중화가 가능해져 연결 오버헤드가 줄어들고 프록시 전달 로직이 간소화됩니다.

HBONE Protocol

다음은 HBONE CONNECT 요청의 단순화된 예입니다.

HBONE CONNECT 요청은 x-envoy-original-dst-host 및 x-istio-auth-userinfo와 같은 헤더를 사용하여 라우팅 및 인증 컨텍스트를 전달합니다.

:method: CONNECT
:scheme: https
:authority: Pod_B_IP:9080
:path: /api/v1/users?id=123
x-envoy-original-dst-host: Pod_B_IP:9080
x-forwarded-proto: hbone
x-istio-attributes: ...
...

• 이 예에서는 ztunnel A가 노드 B로 트래픽을 전송하고 있다고 가정합니다. 외부 TCP 연결은 실제로 ztunnel_A_IP:52368에서 Node_B_IP:15008까지이며, 여기서 포트 15008은 대상 노드의 HBONE 청취자입니다.

• HTTP/2 계층에서 CONNECT 요청이 시작됩니다. 권한 필드는 Pod_B_IP:9080을 나타내며, 이는 Pod B의 실제 목적지 포트를 나타냅니다. x-envoy-original-dst-host 헤더는 동일한 대상을 전달합니다.

• 또한 수신 ztunnel 또는 다운스트림 프록시에 대한 라우팅 컨텍스트 및 보안 메타데이터를 전달하는 x-forwarded-proto 및 x-istio-attributes과 같은 사용자 지정 헤더도 확인할 수 있습니다.

• HTTP/2 CONNECT 위에 구축된 "inner 터널"이라고 생각하면 됩니다: 애플리케이션 계층 요청(예: /api/v1/users?id=123)은 내부에 캡슐화된 후 ztunnel B에 의해 언팩되어 Pod B로 전달됩니다.

• 이 전체 프로세스는 애플리케이션에 투명하게 적용됩니다. 그러나 CONNECT 헤더를 검사함으로써, 우리는 앰비언트 모드가 HTTP/2 계층에서 트래픽 라우팅과 신원 확인을 수행하는 방식에 대한 통찰력을 얻을 수 있습니다. 이러한 유연성 덕분에 HBONE은 전통적인 사이드카 간 통신, 특히 mTLS와 L7 확장을 구현하는 데 있어 더욱 적응력 있는 대안이 될 수 있습니다.

Encrypted Traffic on the Same Node : 동일한 노드의 암호화된 트래픽

• 소스 Pod와 대상 Pod가 동일한 노드에 있는 경우 트래픽은 ztunnel의 L4 암호화 경로를 통해 전송됩니다.

• 여기에서 볼 수 있듯이 ztunnel은 각 노드에 DaemonSet으로 배포되고 호스트 네트워크에서 실행되며 호스트의 네트워크 네임스페이스를 공유합니다.

• Istio CNI는 Pod의 아웃바운드 트래픽을 가로채 ztunnel의 포트 15001로 리디렉션합니다.

• 소스 Pod와 대상 Pod가 모두 같은 노드에 있는 경우, ztunnel은 내부적으로 암호화 및 복호화를 수행하고 트래픽을 대상 Pod로 직접 전달합니다.

• L7 트래픽 처리가 필요한 경우(예: 인증), ztunnel은 Waypoint 프록시와 HBONE 터널을 설정하고 트래픽은 대상 Pod에 도달하기 전에 Waypoint를 통해 라우팅됩니다.Encrypted Traffic on the Same Node

Encrypted Traffic Across Nodes (L4) : 노드 간 암호화된 트래픽(L4)

• 이것은 교차 노드 시나리오이며, 가장 일반적인 경우이기도 합니다:

• 소스 노드의 ztunnel은 HBONE 터널을 통해 트래픽을 암호화하여 목적지 노드의 ztunnel로 보냅니다.

• 목적지 ztunnel은 트래픽을 압축 해제하고 이를 일반 텍스트로 목적지 Pod로 전달합니다.

• 트래픽이 순수하게 L4로 유지되고 L7 기능이 필요하지 않은 한, Waypoint 프록시를 통한 추가 홉을 피하여 프록시 체인을 줄이고 효율성을 향상시킵니다.Encrypted Traffic Across Nodes (L4)

Encrypted Traffic Across Nodes (L7) : 노드 간 암호화된 트래픽(L7)

• L7 처리가 필요한 경우 트래픽은 다음 흐름에 따라 추가 웨이포인트 프록시를 통과합니다:

• source ztunnel은 트래픽을 웨이포인트 프록시로 터널링합니다.

• 웨이포인트는 인증 및 라우팅과 같은 L7 로직을 처리합니다.

• 웨이포인트는 HBONE을 사용하여 트래픽을 destination ztunnel로 재터널링합니다.

• destination ztunnel은 트래픽을 압축 해제하여 목적지 포드까지 전달합니다.

Encrypted Traffic Across Nodes (L7) -> 이 프로세스는 L4 전용 트래픽에 비해 하나의 프록시 홉을 추가하지만, 이점은 L7 처리가 필요한 트래픽만 이 추가 단계를 거쳐 불필요한 오버헤드가 줄어든다는 것입니다

Catch-All Traffic (Preventing Traffic Escape) : 이탈 방지

• IP와 포트를 통해 직접 Pod에 액세스하려는 Istio 메시 외부에서 발생하는 트래픽의 경우, Istio는 이러한 트래픽이 메시를 우회하지 않도록 ztunnel에서 가로채고 관리해야 합니다.

• 트래픽이 애플리케이션 포트를 대상으로 하는 경우 ztunnel은 패킷에 0x539 마크가 포함되어 있는지 확인합니다. 그렇지 않은 경우 ztunnel이 모니터링하는 일반 텍스트 포트인 포트 15006으로 트래픽을 리디렉션합니다. 처리 후 ztunnel은 0x539 마크를 추가하여 애플리케이션 포트로 전달합니다.

• 대상 포트가 15008인 경우 패킷은 HBONE 트래픽으로 처리되며 ztunnel에서 직접 처리합니다.

Non-Mesh Traffic Routed into the Mesh

L4와 L7 트래픽의 차이점

• TCP 계층에서 암호화 및 전달만 필요한 대부분의 트래픽에서 앰비언트 모드는 ztunnel에만 의존합니다.

• HTTP 계층 정책이 필요할 때만 트래픽이 웨이포인트 프록시를 통해 라우팅됩니다.

Ambient Mode vs. Sidecar Mode

• 앰비언트 모드와 사이드카 모드를 혼합할 때, 개별 포드에 세분화된 프록시 구성(예: EnvoyFilter)을 적용하는 것은 어렵습니다.

• 다중 클러스터, 다중 네트워크 및 VM 워크로드에 대한 지원은 아직 성숙하지 않았으며, 운영 환경에서 주의가 필요합니다.

• WASM 플러그인과 같은 일부 고급 사용자 지정은 앰비언트 모드에서 팟 단위로 직접 적용할 수 없습니다.

Recommendations

• 이미 사이드카 모델을 사용 중이고 성숙한 기능에 크게 의존하고 있다면, 지금은 사이드카를 계속 사용할 수 있습니다.

• 자원 절약과 운영 간소화가 우선이고 트래픽의 대부분이 L4인 경우 앰비언트 모드를 사용해 보세요.

• 하이브리드 요구 사항의 경우 혼합 배포를 고려하되, 사이드카 대 앰비언트 워크로드에 대한 경계와 정책을 명확하게 계획해야 합니다.

Key Takeaways 주요 내용

• 앰비언트 모드는 사이드카를 제거하여 팟당 프록시 오버헤드를 줄여 리소스 및 운영 비용을 크게 낮춥니다.

• ztunnel + Waypoint 아키텍처: L7 기능은 필요할 때만 활성화되며, 다른 모든 트래픽은 L4에서 효율적으로 전달됩니다.

• 앰비언트 모드가 GA에 도달했지만, 멀티 클러스터 / VM / 멀티 네트워크 지원과 같은 기능들은 여전히 추가적인 테스트와 검증이 필요합니다.

• 추천 대상: 대규모 클러스터, 주로 L4 트래픽, 자원 효율성과 중앙 집중식 관리에 대한 수요가 높은 팀.

Ambient Quick Start

Ambient Mode

kind : k8s(1.32.2) 배포 , control-plane, worker-node x 2대

kind docker network 에 테스트용 PC(실제로는 컨테이너) 배포

# kind 설치 시 kind 이름의 도커 브리지가 생성된다 : 172.18.0.0/16 대역

# '테스트용 PC(mypc)' 컨테이너 기동 : kind 도커 브리지를 사용하고, 컨테이너 IP를 지정 혹은 지정 없이 배포

# kind network 중 컨테이너(노드) IP(대역) 확인

MetalLB 배포 - Github

# MetalLB 배포

# IPAddressPool, L2Advertisement 설정

istio 1.26.0 설치 : Ambient profile - GettingStarted , install

# istioctl 설치

# ambient 프로파일 컨트롤 플레인 배포

# ambient 프로파일 컨트롤 플레인 배포 & 보조도구 설치

# 설치 확인 : istiod, istio-ingressgateway, crd 등

# iptables 규칙 확인

for node in control-plane worker worker2; do echo "node : myk8s-$node" ; docker exec -it myk8s-$node sh -c 'iptables-save'; echo; done

# NodePort 변경 및 nodeport 30001~30003으로 변경 : prometheus(30001), grafana(30002), kiali(30003), tracing(30004)

istio-cni-node 와 ztunnel 데몬셋 파드 정보 확인

istio-cni-node

# 노드에서 기본 정보 확인

# istio-cni-node 데몬셋 파드 로그 확인

ztunnel

# ztunnel 파드 확인 : 파드 이름 변수 지정

worker 노드에서도 pexec 확인

kubectl pexec $ZPOD2NAME -it -T -n istio-system -- bash
kubectl pexec $ZPOD3NAME -it -T -n istio-system -- bash

Deploy the sample application - Docs

# Deploy the Bookinfo sample application

# 통신 확인 : ratings 에서 productpage 페이지

# 요청 테스트용 파드 생성 : netshoot

# 요청 확인

# 반복 요청

while true; do kubectl exec -it netshoot -- curl -sS productpage:9080/productpage | grep -i title ; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done

Open the application to outside traffic

docker exec -it myk8s-control-plane cat istio-1.26.0/samples/bookinfo/gateway-api/bookinfo-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo
spec:
  parentRefs:
  - name: bookinfo-gateway
  rules:
  - matches:
    - path:
        type: Exact
        value: /productpage
    - path:
        type: PathPrefix
        value: /static
    - path:
        type: Exact
        value: /login
    - path:
        type: Exact
        value: /logout
    - path:
        type: PathPrefix
        value: /api/v1/products
    backendRefs:
    - name: productpage
      port: 9080

# 반복 요청 : 아래 mypc 컨테이너에서 반복 요청 계속 해두기!
GWLB=$(kubectl get svc bookinfo-gateway-istio -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
while true; do docker exec -it mypc curl $GWLB/productpage | grep -i title ; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done

로컬 PC에서 접속

Adding your application to ambient- Docs

• The namespace or pod has the label: istio.io/dataplane-mode=ambient

• The pod does not have the opt-out label: istio.io/dataplane-mode=none

자물쇠 모양 확인(mTLS 통신), L4 텔레메트리 수집(TCP Trafiic min/max 정보 확인)

# 디폴트 네임스페이서 모든 파드들에 ambient mesh 통신 적용 설정
# You can enable all pods in a given namespace to be part of the ambient mesh by simply labeling the namespace:
kubectl label namespace default istio.io/dataplane-mode=ambient

# 파드 정보 확인 : 사이트카가 없다! , 파드 수명 주기에 영향도 없다! -> mTLS 암호 통신 제공, L4 텔레메트리(메트릭) 제공

HBONE 통신 확인

# 노드에서 ipset 확인 : 파드들의 ip를 멤버로 관리 확인

# istio-cni-node 로그 확인

# ztunnel 파드 로그 모니터링 : IN/OUT 트래픽 정보

# 메트릭 정보 확인

# Viewing Istiod state for ztunnel xDS resources
curl -s http://localhost:15000/config_dump

# netshoot 파드만 ambient mode 에서 제외

그라파나 Ztunnel 대시보드 확인

프로메테우스 L4 메트릭 확인 : istio_tcp_sent_bytes_total

상세 정보 분석

istio-proxy 정보 확인

docker exec -it myk8s-control-plane istioctl proxy-status
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/bookinfo-gateway-istio
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/bookinfo-gateway-istio --waypoint
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/bookinfo-gateway-istio --port 80
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/bookinfo-gateway-istio --port 80 -o json

docker exec -it myk8s-control-plane istioctl proxy-config route deploy/bookinfo-gateway-istio
docker exec -it myk8s-control-plane istioctl proxy-config route deploy/bookinfo-gateway-istio --name http.80
docker exec -it myk8s-control-plane istioctl proxy-config route deploy/bookinfo-gateway-istio --name http.80 -o json

docker exec -it myk8s-control-plane istioctl proxy-config cluster deploy/bookinfo-gateway-istio
docker exec -it myk8s-control-plane istioctl proxy-config cluster deploy/bookinfo-gateway-istio --fqdn productpage.default.svc.cluster.local -o json

docker exec -it myk8s-control-plane istioctl proxy-config endpoint deploy/bookinfo-gateway-istio --status healthy
docker exec -it myk8s-control-plane istioctl proxy-config endpoint deploy/bookinfo-gateway-istio --cluster 'outbound|9080||productpage.default.svc.cluster.local' -o json

docker exec -it myk8s-control-plane istioctl proxy-config secret deploy/bookinfo-gateway-istio
docker exec -it myk8s-control-plane istioctl proxy-config secret deploy/bookinfo-gateway-istio -o json

docker exec -it myk8s-control-plane istioctl proxy-config bootstrap deploy/bookinfo-gateway-istio

ztunnel-config

docker exec -it myk8s-control-plane istioctl ztunnel-config

docker exec -it myk8s-control-plane istioctl ztunnel-config service --service-namespace default --node myk8s-worker
docker exec -it myk8s-control-plane istioctl ztunnel-config service --service-namespace default --node myk8s-worker2
docker exec -it myk8s-control-plane istioctl ztunnel-config service --service-namespace default --node myk8s-worker2 -o json
...
    {
        "name": "productpage",
        "namespace": "default",
        "hostname": "productpage.default.svc.cluster.local",
        "vips": [
            "/10.200.1.207"
        ],
        "ports": {
            "9080": 9080
        },
        "endpoints": {
            "Kubernetes//Pod/default/productpage-v1-54bb874995-xkq54": {
                "workloadUid": "Kubernetes//Pod/default/productpage-v1-54bb874995-xkq54",
                "service": "",
                "port": {
                    "9080": 9080
                }
            }
        },
        "ipFamilies": "IPv4"
    },
...

docker exec -it myk8s-control-plane istioctl ztunnel-config workload
docker exec -it myk8s-control-plane istioctl ztunnel-config workload --workload-namespace default
docker exec -it myk8s-control-plane istioctl ztunnel-config workload --workload-namespace default --node myk8s-worker2
docker exec -it myk8s-control-plane istioctl ztunnel-config workload --workload-namespace default --node myk8s-worker -o json
...
    {
        "uid": "Kubernetes//Pod/default/productpage-v1-54bb874995-xkq54",
        "workloadIps": [
            "10.10.2.20"
        ],
        "protocol": "HBONE",
        "name": "productpage-v1-54bb874995-xkq54",
        "namespace": "default",
        "serviceAccount": "bookinfo-productpage",
        "workloadName": "productpage-v1",
        "workloadType": "pod",
        "canonicalName": "productpage",
        "canonicalRevision": "v1",
        "clusterId": "Kubernetes",
        "trustDomain": "cluster.local",
        "locality": {},
        "node": "myk8s-worker",
        "status": "Healthy",
        "hostname": "",
        "capacity": 1,
        "applicationTunnel": {
            "protocol": ""
        }
    },
...

docker exec -it myk8s-control-plane istioctl ztunnel-config certificate --node myk8s-worker -o json

도식화

암호 통신 시

평문 통신 시

Role of Specific Ports

• 15008(HBONE 소켓) : HBONE 프로토콜을 사용하여 HTTP 기반 트래픽을 투명하게 처리합니다.

• 15006(일반 텍스트 소켓) : 포드 간 통신을 위해 메시 내의 암호화되지 않은 트래픽을 관리합니다.

• 15001(아웃바운드 소켓) : 아웃바운드 트래픽을 제어하고 외부 서비스 액세스에 대한 정책을 시행합니다.

• 0x539 마크는 Istio 프록시(예: ztunnel)에서 발생하는 트래픽을 식별합니다.

  • 이 마크는 프록시에서 처리된 패킷을 구별하여 재처리되거나 잘못된 경로로 지정되지 않도록 합니다.

• 0x111 마크는 Istio 메시 내의 연결 수준 표시에 사용되며, 이는 프록시에 의해 연결이 처리되었음을 나타냅니다.

  • iptables의 CONNMARK 모듈은 이 마크를 전체 연결로 확장하여 후속 패킷 매칭 속도를 높입니다.

새로운 앰비언트 캡처 모델의 최종 결과는 모든 트래픽 캡처와 리디렉션이 포드의 네트워크 네임스페이스 내부에서 발생한다는 것입니다.

노드, CNI 및 기타 모든 것에 대해 포드 내부에 사이드카 프록시가 있는 것처럼 보입니다.

비록 포드에서 사이드카 프록시가 전혀 실행되지 않더라도 말입니다.

productpage 확인

트래픽 리디렉션 확인 - 15001, 15006, 15008

# DNS 트래픽에 대해 연결 추적을 설정, 이후 마크 기반으로 리디렉션 여부를 제어
iptables -t raw -S
...
-A PREROUTING -j ISTIO_PRERT
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -p udp -m mark --mark 0x539/0xfff -m udp --dport 53 -j CT --zone 1
-A ISTIO_PRERT -p udp -m mark ! --mark 0x539/0xfff -m udp --sport 53 -j CT --zone 1


# 특정 마크가 붙은 트래픽을 식별해서 추후 NAT에서 건너뛰게 함
iptables -t mangle -S
...
## 들어오는 패킷을 ISTIO_PRERT 체인으로 전달
-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


# 트래픽 리디렉션 실행
iptables -t nat -S
...
## 특정 IP 예외 처리 (프록시 자체나 메타데이터 주소 등)
-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT

## DNS 요청(udp/53) 을 15053 포트로 리디렉션
-A ISTIO_OUTPUT ! -o lo -p udp -m mark ! --mark 0x539/0xfff -m udp --dport 53 -j REDIRECT --to-ports 15053

## TCP 기반 DNS 요청 도 15053으로 리디렉션
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m tcp --dport 53 -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15053

## 특정 마크가 붙은 트래픽은 리디렉션에서 제외
-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

## 나머지 TCP 트래픽은 15001 로 리디렉션
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001

## 특정 메타데이터 IP에서 온 트래픽은 리디렉션 예외
-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT

## 들어오는 외부 TCP 트래픽을 inbound 포트(15006) 로 리디렉션
-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

# 요약
## DNS 트래픽 → 15053 포트로 리디렉션 (Envoy가 DNS를 프록시)
## TCP 트래픽 (출발지/도착지에 따라) → 15001 또는 15006 포트로 리디렉션
## 특정 마크 (0x539, 0x111)나 주소는 리디렉션 제외
## conntrack 및 mark 시스템으로 트래픽 상태 관리 및 리디렉션 조건 제어

# 암호화 확인

#
ngrep -tW byline -d eth0 '' 'tcp port 15001'
ngrep -tW byline -d eth0 '' 'tcp port 15006'

# 
ls -l /var/run/ztunnel

Verify mutual TLS is enabled - Docs

Validate mTLS using workload’s ztunnel configurations

# PROTOCOL HBONE 확인

Validate mTLS from metrics

istio_tcp_connections_opened_total{
  app="ztunnel",
  connection_security_policy="mutual_tls",
  destination_principal="spiffe://cluster.local/ns/default/sa/bookinfo-details",
  destination_service="details.default.svc.cluster.local",
  reporter="source",
  request_protocol="tcp",
  response_flags="-",
  source_app="curl",
  source_principal="spiffe://cluster.local/ns/default/sa/curl",source_workload_namespace="default",
  ...}

Validate mTLS from logs - mTLS가 활성화되었는지 확인하기 위해 소스 또는 대상 ztunnel 로그를 피어 ID와 함께 확인

Validate with Kiali dashboard

Validate with tcpdump

• If you have access to your Kubernetes worker nodes, you can run the tcpdump command to capture all traffic on the network interface, with optional focusing the application ports and HBONE port.

• In this example, port 9080 is the details service port and 15008 is the HBONE port:

Secure Application Access : L4 Authorization Policy - Docs

• Istio의 보안 정책의 레이어 4(L4) 기능은 ztunnel에서 지원되며 앰비언트 모드로 사용할 수 있습니다. 또한 클러스터에 이를 지원하는 CNI 플러그인이 있는 경우에도 Kubernetes 네트워크 정책은 계속 작동하며 심층적인 방어 기능을 제공하는 데 사용할 수 있습니다.

• ztunnel 및 웨이포인트 프록시의 계층화를 통해 주어진 워크로드에 대해 레이어 7(L7) 처리를 활성화할지 여부를 선택할 수 있습니다. L7 정책과 Istio의 트래픽 라우팅 기능을 사용하려면 워크로드에 웨이포인트를 배포할 수 있습니다. 이제 정책을 두 곳에서 시행할 수 있기 때문에 이해해야 할 사항이 있습니다.

# netshoot 파드만 ambient mode 다시 참여

# L4 Authorization Policy 신규 생성 # Explicitly allow the netshoot and gateway service accounts to call the productpage service:

# ztunnel 파드 로그 모니터링

# L4 Authorization Policy 동작 확인
## 차단 확인!
GWLB=$(kubectl get svc bookinfo-gateway-istio -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
while true; do docker exec -it mypc curl $GWLB/productpage | grep -i title ; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done

## 허용 확인!
kubectl exec -it netshoot -- curl -sS productpage:9080/productpage | grep -i title
while true; do kubectl exec -it netshoot -- curl -sS productpage:9080/productpage | grep -i title ; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done

# L4 Authorization Policy 업데이트

# 허용 확인!
GWLB=$(kubectl get svc bookinfo-gateway-istio -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
while true; do docker exec -it mypc curl $GWLB/productpage | grep -i title ; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done

Configure waypoint proxies - Docs

• 웨이포인트 프록시는 정의된 워크로드 집합에 레이어 7(L7) 처리를 추가하기 위해 Envoy 기반 프록시를 선택적으로 배포하는 것입니다.

• 웨이포인트 프록시는 애플리케이션과 독립적으로 설치, 업그레이드 및 확장되며, 애플리케이션 소유자는 이러한 프록시의 존재를 인식하지 않아야 합니다. 각 워크로드와 함께 에너포 프록시 인스턴스를 실행하는 사이드카 데이터 플레인 모드에 비해 필요한 프록시 수를 크게 줄일 수 있습니다.

• 웨이포인트 또는 웨이포인트 세트는 보안 경계가 비슷한 애플리케이션 간에 공유할 수 있습니다. 이는 특정 워크로드의 모든 인스턴스 또는 네임스페이스의 모든 워크로드일 수 있습니다.

• 사이드카 모드와는 달리, 앰비언트 모드에서는 정책이 목적지 경유지에 의해 시행됩니다. 여러 면에서 경유지는 자원(이름 공간, 서비스 또는 포드)으로 가는 관문 역할을 합니다. Istio는 자원으로 들어오는 모든 트래픽이 경유지를 통과하도록 강제하며, 이는 그 자원에 대한 모든 정책을 강제합니다.

Do you need a waypoint proxy?

• 앰비언트의 레이어드 접근 방식을 통해 사용자는 no mesh에서 보안 L4 오버레이, 전체 L7 처리로 원활하게 전환하면서 Istio를 보다 점진적인 방식으로 채택할 수 있습니다.

• 앰비언트 모드의 대부분의 기능은 ztunnel 노드 프록시에 의해 제공됩니다. ztunnel은 계층 4(L4)에서만 트래픽을 처리하도록 설계되어 공유 구성 요소로 안전하게 작동할 수 있습니다.

• 웨이포인트로 리디렉션을 구성하면 트래픽이 ztunnel을 통해 해당 웨이포인트로 전달됩니다. 애플리케이션에 다음 L7 메쉬 기능이 필요한 경우 웨이포인트 프록시를 사용해야 합니다:

  • Traffic management: HTTP routing & load balancing, circuit breaking, rate limiting, fault injection, retries, timeouts

  • Security: Rich authorization policies based on L7 primitives such as request type or HTTP header

  • Observability: HTTP metrics, access logging, tracing

Deploy a waypoint proxy

# istioctl can generate a Kubernetes Gateway resource for a waypoint proxy.

# For example, to generate a waypoint proxy named waypoint for the default namespace that can process traffic for services in the namespace:

Kiali 의 Ambient Mesh 지원 내용 - https://kiali.io/docs/features/ambient/

* 전반적으로 미완성 상태