[9주차] Ambient Mesh

엠비언트 메시 소개

앰비언트 메시는 사용자에게사이드카 프록시 대신인프라에 통합된 데이터 플레인을 사용할 수 있는 옵션을 제공하며, 동시에 Istio의핵심 기능인 제로 트러스트 보안, 원격 측정, 트래픽 관리는그대로 유지됩니다.

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

▶ 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 배치

 

https://istio.io/latest/blog/2022/introducing-ambient-mesh/

 

▶  Istio Ambient Mesh 방식

 

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

 

 

 

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

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

https://www.solo.io/blog/understanding-istio-ambient-ztunnel-and-secure-overlay/

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 통제/정책 제공

Layering of ambient mesh data plane

Each namespace/identity has its own L7 proxies; no multi-tenant proxies

 

 

▶ 통신 흐름 상세

공통 : 파드 트래픽을 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

 

• 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 기반 웨이포인트 프록시를 사용하여 해당 네임스페이스의 워크로드에 대한 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 빌드가 기본적으로 사용됩니다

 

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

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

 

 

▶  하지만 추가된 홉은 어떻게 되나요?

• 앰비언트 모드에서는 웨이포인트가 해당 워크로드와 동일한 노드에 있을 것이라고 보장할 수 없습니다.
• 언뜻 보기에는 성능 문제로 보일 수 있지만, 궁극적으로는 Istio의 현재 사이드카 구현 방식과 동일한 수준의 지연 시간을 제공할 것으로 확신합니다. 
• 자세한 내용은 성능 관련 블로그 게시물에서 다루겠지만, 우선 두 가지 요점으로 요약하겠습니다. 

1. Istio 네트워크 지연 시간의 대부분은 사실 네트워크 자체에서 발생하는 것이 아닙니다( 현대 클라우드 제공업체는 매우 빠른 네트워크를 보유하고 있습니다 ). 
   • 가장 큰 원인은 Istio가 정교한 기능 세트를 구현하는 데 필요한 집중적인 L7 처리입니다.
   • 각 연결에 대해 두 단계의 L7 처리 단계(사이드카당 하나씩)를 구현하는 사이드카와 달리, 앰비언트 모드는 이 두 단계를 하나로 통합합니다.
   • 대부분의 경우, 이렇게 감소된 처리 비용은 추가 네트워크 홉을 상쇄할 것으로 예상됩니다.
2. 사용자는 종종 첫 번째 단계로 메시를 구축하여 제로 트러스트 보안 태세를 구축한 후 필요에 따라 선택적으로 L7 기능을 활성화합니다. 
   • 앰비언트 모드를 사용하면 L7 처리 비용이 전혀 들지 않을 때 L7 처리 비용을 완전히 절감할 수 있습니다. 

 

 

▶  리소스 오버헤드

• 전반적으로 Istio의 앰비언트 모드는 대부분의 사용자에게 점점 더 예측 가능한 리소스 요구 사항이 줄어들 것으로 예상됩니다. 
• ztunnel의 제한된 책임으로 인해 노드에서 공유 리소스로 배포할 수 있습니다. 이렇게 하면 대부분의 사용자에게 필요한 워크로드당 예약을 크게 줄일 수 있습니다. 
• 또한, 웨이포인트 프록시는 일반적인 쿠버네티스 포드이므로, 제공하는 워크로드의 실시간 트래픽 수요에 따라 동적으로 배포하고 확장할 수 있습니다.
  
  
• 반면 사이드카는 각 워크로드에 대해 최악의 상황을 대비하여 메모리와 CPU를 예약해야 합니다.
• 이러한 계산은 복잡하기 때문에 실제로 관리자는 과도하게 프로비저닝하는 경향이 있습니다. 
• 이로 인해 다른 워크로드를 예약할 수 없는 과도한 예약으로 인해 노드 활용도가 낮아집니다.
• 앰비언트 모드는 노드당 고정 오버헤드가 낮고 동적으로 확장되는 웨이포인트 프록시를 사용하므로 전체적으로 훨씬 적은 리소스 예약이 필요하므로 클러스터를 더욱 효율적으로 사용할 수 있습니다.

 

 

▶  보안은 어떻습니까?

완전히 새로운 아키텍처는 자연스럽게 보안에 대한 의문을 제기합니다. 앰비언트 모드 보안 블로그에서 심층 분석을 제공하지만, 여기서는 간략하게 설명하겠습니다.
사이드카는 서비스하는 워크로드와 함께 배치되므로, 한쪽의 취약점이 다른 쪽을 손상시킵니다.
앰비언트 메시 모델에서는 애플리케이션이 손상되더라도ztunnel과 웨이포인트 프록시는 손상된 애플리케이션의 트래픽에 대해 엄격한 보안 정책을 적용할 수 있습니다.
더욱이, Envoy는 세계 최대 규모의 네트워크 운영업체에서 사용하는 검증된 소프트웨어라는 점을 고려할 때, 함께 실행되는 애플리케이션보다 취약성이 낮을 가능성이 높습니다.
ztunnel은 공유 리소스이지만, 현재 실행 중인 노드에 있는 워크로드의 키에만 접근할 수 있습니다.
따라서 공격 반경은 노드별 키에 기반한 암호화된 CNI보다 나쁘지 않습니다.
또한 ztunnel의 제한된 L4 전용 공격 표면 영역과 앞서 언급한 Envoy의 보안 특성을 고려할 때, 이러한 위험은 제한적이며 허용 가능하다고 생각합니다.
웨이포인트 프록시는 공유 리소스이지만 하나의 서비스 계정만 지원하도록 제한될 수 있습니다.
이는 사이드카보다 더 심각한 문제는 아닙니다.
하나의 웨이포인트 프록시가 손상되면 해당 웨이포인트와 연결된 자격 증명만 손실되고 다른 것은 아무것도 남지 않습니다.

 

 

▶  사이드카 종말?

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

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

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

 

 

 

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

▶ Istio 앰비언트 메시를 위한 노드별 프록시

• 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 원격 측정(**메트릭 및 로그)을 제공합니다.

 

▶  Envoy를 재사용하지 않는 이유?

• 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 구성을 최대한 작게 유지하기 위해, 필요한 정보만 (그 이상은 포함하지 않고) 효율적인 형식으로 정확하게 포함하는 특수 제작 구성 프로토콜을 사용하여 조사했습니다. 
• 예를 들어, 단일 포드는 다음과 같이 간결하게 표현할 수 있습니다.

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

 

• 이 정보는 xDS 전송 API를 통해 전송되지만, custom ambient-specific type 을 사용합니다.
• 구성 세부 정보에 대한 자세한 내용은 워크로드 xDS 구성 섹션 을 참조하세요.

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

 

 

• 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",
      "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",
      ...
}

 

 

워크로드 수준 권한 부여 정책을 배포한 후 정책 구성은 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"
    ],
  }
  ...
}

 

 

 

▶ 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 프록시를 간편하게

• Ambient는 Istio의 기능을 보안 오버레이 계층과 레이어 7 처리 계층이라는 두 개의 개별 계층으로 나눕니다.
• 웨이포인트 프록시는 Envoy 기반이며, 관리하는 워크로드에 대한 L7 처리를 담당하는 선택적 구성 요소입니다. 
• 2022년 최초 Ambient 출시 이후 웨이포인트 구성, 디버깅 및 확장성을 간소화하기 위해 상당한 변경 작업을 수행해 왔습니다.

 

 

▶  웨이포인트 프록시의 아키텍처

• 사이드카와 마찬가지로 웨이포인트 프록시도 Envoy 기반이며, Istio를 통해 애플리케이션 구성을 지원하도록 동적으로 구성됩니다. 
• 웨이포인트 프록시의 독특한 점은 네임스페이스별(기본값) 또는 서비스 계정별로 실행된다는 것입니다. 
• 애플리케이션 포드 외부에서 실행되므로 웨이포인트 프록시는 애플리케이션과 독립적으로 설치, 업그레이드 및 확장할 수 있을 뿐만 아니라 운영 비용도 절감할 수 있습니다.

 

 

웨이포인트 프록시는 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는 이러한 리소스를 모니터링하고 해당 경로점 배포를 자동으로 사용자에게 배포하고 관리합니다.

 

 

▶ 소스 프록시 구성을 대상 프록시로 전환

• 기존 사이드카 아키텍처에서 대부분의 트래픽 셰이핑(예: 요청 라우팅 , 트래픽 이동 또는 오류 주입 ) 정책은 소스(클라이언트) 프록시에 의해 구현되는 반면, 대부분의 보안 정책은 목적지(서버) 프록시에 의해 구현됩니다. 이로 인해 다음과 같은 여러 가지 문제가 발생합니다.  
  • Scaling 스케일링
    • 각 소스 사이드카는 메시 내 다른 모든 목적지에 대한 정보를 알아야 합니다. 이는 다항식 스케일링 문제입니다. 
    • 더 심각한 것은 목적지 구성이 변경되면 모든 사이드카에 동시에 알려야 한다는 것입니다.
  • Debugging 디버깅
    • 정책 시행이 클라이언트와 서버 사이드카로 분리되어 있기 때문에 문제를 해결할 때 시스템의 동작을 이해하기 어려울 수 있습니다. 
  • Mixed environments 혼합 환경
    • 모든 클라이언트가 메시에 속하지 않는 시스템에서는 동작이 일관되지 않습니다. 
    • 예를 들어, 메시가 아닌 클라이언트는 카나리아 롤아웃 정책을 준수하지 않아 예상치 못한 트래픽 분산이 발생할 수 있습니다. 
  • Ownership and attribution 소유권 및 귀속
    • 이상적으로는 하나의 네임스페이스에 작성된 정책은 동일한 네임스페이스에서 실행되는 프록시가 수행하는 작업에만 영향을 미쳐야 합니다. 
    • 그러나 이 모델에서는 정책이 각 사이드카에 의해 분산되고 적용됩니다.
    • Istio는 이러한 제약 조건을 고려하여 보안을 강화하도록 설계되었지만, 여전히 최적의 방법은 아닙니다. 
• 앰비언트에서는 모든 정책이 목적지 웨이포인트에 의해 적용됩니다. 
• 여러 측면에서 웨이포인트는 **네임스페이스(**기본 범위) 또는 서비스 계정으로의 게이트웨이 역할을 합니다.
• Istio는 네임스페이스로 들어오는 모든 트래픽이 웨이포인트를 통과하도록 하고, 웨이포인트는 해당 네임스페이스에 대한 모든 정책을 적용합니다. 
• 따라서 각 웨이포인트는 자체 네임스페이스의 구성만 알면 됩니다. 
• 특히 확장성 문제는 대규모 클러스터를 사용하는 사용자에게 골칫거리입니다. 
• 이를 시각화해 보면 새로운 아키텍처가 얼마나 큰 개선을 이루었는지 알 수 있습니다. 
• 네임스페이스 2개가 있고 각 네임스페이스에 2개의 (색상 구분) deployment가 있는 간단한 배포를 생각해 보겠습니다. 
• 사이드카 프로그래밍에 필요한 Envoy(XDS) 구성은 원으로 표시되어 있습니다. 

• 사이드카 모델에는 4개의 워크로드가 있으며, 각 워크로드에는 4개의 구성 세트가 있습니다. 
• 이러한 구성 중 하나라도 변경되면 모든 구성을 업데이트해야 합니다. 총 16개의 구성이 배포됩니다.

 

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

• 여기서는 매우 다른 상황을 볼 수 있습니다.
• 각 프록시가 전체 네임스페이스를 지원할 수 있고, 각 프록시는 자체 네임스페이스에 대한 구성만 필요하기 때문에 웨이포인트 프록시는 두 개뿐입니다.
• 간단한 예시일지라도 **전송되는 구성의 총량은 전체의 25%**입니다.

 

• 각 네임스페이스를 각각 10개의 포드로 구성된 25개 배포까지 확장하고, 고가용성을 위해 각 웨이포인트 배포를 2개의 포드로 구성하면 숫자는 훨씬 더 인상적입니다.
• 아래 표에서 볼 수 있듯이 웨이포인트 구성 배포에는 사이드카 구성 배포의 0.8%만 필요합니다!
  

  구성베포	네임스페이스1	네임스페이스2	총
  사이드카	25가지 구성 * 250개 사이드카	25가지 구성 * 250개 사이드카	12500
  웨이포인트	25가지 구성 * 2개의 웨이포인트	25가지 구성 * 2개의 웨이포인트	100
  웨이포인트/사이드카	0.8%	0.8%	0.8%

 

• 위에서 단순화를 설명하기 위해 네임스페이스 범위의 웨이포인트 프록시를 사용했지만, 이를 서비스 계정 웨이포인트 프록시에 적용하면 단순화는 유사합니다.  
• 이렇게 축소된 구성은 제어 플레인과 데이터 플레인 모두의 리소스 사용량(CPU, RAM, 네트워크 대역폭)을 줄인다는 것을 의미합니다.
• 현재 사용자는 exportToIstio 네트워킹 리소스나 Sidecar API를 신중하게 사용하면 유사한 개선 효과를 볼 수 있지만, 앰비언트 모드에서는 이러한 작업이 더 이상 필요하지 않으므로 확장이 훨씬 수월해집니다.

 

▶ 목적지에 웨이포인트 프록시가 없는 경우는 어떻게 되나요?

 

• 앰비언트 모드는 대부분의 구성이 서비스 소비자가 아닌 서비스 생산자에 의해 가장 잘 구현된다는 가정을 중심으로 설계되었습니다.
• 하지만 항상 그런 것은 아닙니다. 때로는 제어할 수 없는 대상에 대한 트래픽 관리를 구성해야 할 수도 있습니다.
• 이러한 일반적인 예로는 간헐적인 연결 문제를 처리하기 위해 향상된 복원력을 갖춘 외부 서비스에 연결하는 것입니다(예: 호출에 시간 초과를 추가하는 경우 example.com).

이 영역은 커뮤니티에서 활발하게 개발 중인 영역으로, 트래픽이 이그레스 게이트웨이로 라우팅되는 방식과 원하는 정책으로 이그레스 게이트웨이를 구성하는 방법을 설계합니다. 이 영역에 대한 향후 블로그 게시물도 기대해 주세요!

 

※ 웨이포인트 구성에 대한 심층 분석

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

$ 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 프록시를 보려면 엔드포인트를 확인하세요. Check out the endpoints for reviews waypoint proxy.

$ 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

• 최근 Istio의 새로운 앰비언트 모드를 발표했습니다. 이는 Istio를 위한 사이드카 없는 데이터 플레인이자 앰비언트 메시 패턴의 참조 구현입니다.
• 발표 블로그에서 언급했듯이 , 앰비언트 메시를 통해 해결하고자 하는 주요 과제는 운영 간소화, 더 광범위한 애플리케이션 호환성, 인프라 비용 절감, 그리고 성능 향상입니다.
• 앰비언트 데이터 플레인을 설계할 때, 보안이나 기능을 희생하지 않으면서도 운영, 비용, 그리고 성능에 대한 우려 사항들을 신중하게 균형 있게 고려하고자 했습니다.
• 앰비언트 메시의 구성 요소가 애플리케이션 포드 외부에서 실행됨에 따라 보안 경계가 변경되었으며, 이는 더 나은 방향으로 변화했다고 생각합니다. 
• 이 블로그에서는 이러한 변경 사항과 사이드카 배포와의 차이점을 자세히 설명합니다.

 

 

• 요약하자면, Istio의 앰비언트 모드는 전송 보안 및 라우팅을 담당하는 보안 오버레이를 갖춘 계층화된 메시 데이터 플레인을 도입하며, 필요한 네임스페이스에 L7 기능을 추가할 수 있는 옵션을 제공합니다.
• 보안 오버레이는 노드 공유 구성 요소인 ztunnel로 구성되며, ztunnel은 L4 원격 측정 및 DaemonSet으로 배포되는 mTLS를 담당합니다.
• 메시의 L7 계층은 웨이포인트 프록시, 즉 ID/워크로드 유형별로 배포되는 전체 L7 Envoy 프록시에 의해 제공됩니다.
• 이 설계의 핵심적인 의미는 다음과 같습니다.
  • 데이터 플레인에서 애플리케이션 분리 
  • 보안 오버레이 계층의 구성 요소는 CNI의 구성 요소와 유사합니다. 
  • 보안을 위해서는 운영의 단순성이 더 좋습니다. 
  • 다중 테넌트 L7 프록시 피하기 
  • 사이드카는 여전히 일류 지원 배포입니다. 

 

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

• 앰비언트 메시의 주요 목표는 서비스 메시 운영을 단순화하는 것이지만, 보안 강화에도 기여합니다.
• 복잡성은 취약성을 야기하며, 엔터프라이즈 애플리케이션(및 그 전이적 종속성, 라이브러리, 프레임워크)은 매우 복잡하고 취약성에 취약합니다.
• 복잡한 비즈니스 로직 처리부터 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 기능 영역에서 발견될 가능성이 더 높습니다.

 

• 각 네임스페이스/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

• 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 구현 방식과 관계없이 플랫폼에서 사이드카 없는 앰비언트 메시의 이점을 누릴 수 있게 되었습니다.

▶ ztunnel이 포드 네트워크 네임스페이스 내부에서 리디렉션 소켓을 시작하면서 포드 외부에서 실행**

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 노드 에이전트는 포드의 네트워크 네임스페이스에 들어가 포드 네트워크 네임스페이스 내부에 네트워크 리디렉션 규칙을 설정하여 포드에 들어오고 나가는 패킷을 가로채서 잘 알려진 포트(15008, 15006, 15001)에서 노드 로컬 ztunnel 프록시 인스턴스로 투명하게 리디렉션합니다. 그런 다음 istio-cni 노드 에이전트는 유닉스 도메인 소켓을 통해 노드 ztunnel에 포드의 네트워크 네임스페이스(15008, 15006, 15001) 내부에 로컬 프록시 리스닝 포트를 설정해야 한다고 알리고, ztunnel에 포드의 네트워크 네임스페이스를 나타내는 저수준 리눅스 파일 설명자를 제공합니다. 
  
  
• 일반적으로 소켓은 리눅스 네트워크 네임스페이스 내에서 실제로 실행되는 프로세스에 의해 생성되지만, 생성 시점에 대상 네트워크 네임스페이스가 알려져 있다고 가정하면 리눅스의 저수준 소켓 API를 활용하여 한 네트워크 네임스페이스에서 실행되는 프로세스가 다른 네트워크 네임스페이스에서 리스닝 소켓을 생성할 수 있도록 하는 것이 완벽하게 가능합니다. 
  
  
• node-local ztunne은 내부적으로 새로운 프록시 인스턴스와 리스닝 포트 세트를 스핀업하여 새로 추가된 포드 전용으로 만듭니다.
  
  
• 인팟 리디렉션 규칙이 적용되고 ztunnel이 청취 포트를 설정하면 이전과 마찬가지로 네트워크에 포드가 추가되고 노드-로컬 ztunnel을 통해 트래픽이 흐르기 시작합니다.
  
  
• 다음은 주변 메시에 추가되는 애플리케이션 포드의 흐름을 보여주는 기본 다이어그램입니다:
  

  

• 포드가 앰비언트 메시에 성공적으로 추가되면, 메시의 포드 간 트래픽은 Istio와 마찬가지로 기본적으로 mTLS로 완전히 암호화됩니다. 
• 이제 트래픽은 암호화된 트래픽으로 포드 네트워크 네임스페이스에 들어오고 나갈 것입니다. 이는 주변 메시의 모든 포드가 메쉬 정책을 적용하고 트래픽을 안전하게 암호화할 수 있는 기능을 가지고 있는 것처럼 보일 것입니다. 하지만 포드에서 실행 중인 사용자 애플리케이션은 이러한 기능을 인식하지 못합니다. 
• 다음은 새 모델에서 주변 메시의 포드 간 암호화된 트래픽이 어떻게 흐르는지 설명하는 다이어그램입니다:
  

  

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

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

 

 

 

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

• 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를 지원합니다.
  • 제어된 메시 출력을 위한 웨이포인트 사용 Using waypoints for controlled mesh egress
  • 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