CloudNet@에서 진행하는 Istio Study 9주차 Ambient Mesh 내용입니다.

Istio Blog

Introducting Ambient Mesh

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

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

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

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

Istio Ambient Mesh

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

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

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

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

• 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를 통해 기능 구현

• L4 telemetry provided by ztunnel
  

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

Ambient Mesh 동작 소개

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

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

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

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

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

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

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

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

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

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

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

• 이 모드에서 작동하는 네임스페이스는 하나 이상의 Envoy 기반 *웨이포인트 프록시를* 사용하여 해당 네임스페이스의 워크로드에 대한 L7 처리를 처리합니다.

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

• 웨이포인트 프록시는 최악의 경우 운영자가 예상하는 최대 부하가 아닌 제공하는 네임스페이스의 실시간 트래픽 수요에 맞게 자동 확장될 수 있습니다.
  

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

A purpose-built per-node proxy for Istio ambient mesh

• ztunnel(제로 트러스트 터널) 구성 요소는 Istio 앰비언트 메시를 위해 특별히 설계된 노드별 프록시입니다.
• Ambient Mesh 내에서 워크로드를 안전하게 연결하고 인증하는 역할을 합니다.
• 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 원격 측정(메트릭 및 로그)을 제공합니다.

Configuration protocol

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

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

  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

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

Runtime implementation & A Rust-based ztunnel

• ztunnel은 HTTPS 터널을 사용하여 사용자 요청을 전달합니다.
• Envoy는 이 터널링을 지원하지만, 구성 모델이 저희의 요구 사항에는 제한적이라는 것을 알게 되었습니다.
• 터널 자체와 사용자 요청이라는 여러 계층의 요청이 있고, 로드 밸런싱 후 포드별 정책을 적용해야 하는 저희의 요구 사항을 고려했을 때, 이전 Envoy 기반 ztunnel을 구현할 때 연결당 이러한 필터를 4번씩 반복해야 했습니다.

A Rust-based ztunnel

• ztunnel을 빠르고 안전하며 가볍게 만들겠다는 목표에 따라 Rust를 선택합니다.
• Rust는 고성능, 저리소스 애플리케이션, 특히 네트워크 애플리케이션(서비스 메시 포함)에서 탄탄한 성공 사례를 보유하고 있습니다.
• 저희는 생태계의 사실상 표준으로 자리 잡은 두 가지 라이브러리인 Tokio 와 Hyper 라이브러리를 기반으로 개발하기로 했습니다.

L4 telemetry provided by ztunnel

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

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

Istio Ambient Waypoint Proxy Made Simple

Introducing the new destination oriented waypoint proxy for simplicity and scalability

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

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

• 여러 측면에서 웨이포인트는 네임스페이스(기본 범위) 또는 서비스 계정으로의 게이트웨이 역할을 합니다.
• Istio는 네임스페이스로 들어오는 모든 트래픽이 웨이포인트를 통과하도록 하고, 웨이포인트는 해당 네임스페이스에 대한 모든 정책을 적용합니다.
• 따라서 각 웨이포인트는 자체 네임스페이스의 구성만 알면 됩니다.

시각화를 통해 변경된 사항을 확인하겠습니다.

• 네임스페이스 2개가 있고 각 네임스페이스에 2개의 (색상 구분) deployment가 있는 간단한 배포를 생각합니다.
• 사이드카 프로그래밍에 필요한 Envoy(XDS) 구성은 원으로 표시되어 있습니다.

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

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

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

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

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

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

Ambient Mode Security Deep Dive

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

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

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는 강력한 CVE 프로세스를 통해 취약점을 식별하고 신속하게 수정하여 광범위한 영향을 미치기 전에 고객에게 배포합니다.
• Envoy 프록시의 가장 복잡한 부분은 L7 처리에 있으며, 실제로 Envoy의 취약점 대부분은 역사적으로 L7 처리 스택에 있었습니다.

  L4 및 L7 메시 기능을 분리하는 것이 중요합니다.

• 사이드카 배포에서는 기능의 일부만 사용하더라도 모든 프록시를 채택하는 반면, 앰비언트 모드에서는 안전한 오버레이를 제공하고 필요에 따라 L7 레이어만 추가하여 노출을 제한할 수 있습니다.
• 또한, L7 구성 요소는 애플리케이션과 완전히 분리되어 실행되므로 공격 경로를 제공하지 않습니다.

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

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

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

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

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

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

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

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

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

Maturing Istio Ambient: Compatibility Across Various Kubernetes Providers and CNIs

How did we get here?

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).

그러나, 근본적인 문제가 있습니다. 많은 CNI 구현이 있으며, Linux에서는 패킷이 한 네트워크 네임스페이스에서 다른 네트워크 네임스페이스로 이동하는 방식을 구성할 수 있는 근본적으로 다양하고 호환되지 않는 방법이 많습니다. 터널을 사용하거나, 네트워크를 오버레이하거나, 호스트 네트워크 네임스페이스를 통과하거나, 우회할 수 있습니다. Linux 사용자 공간 네트워킹 스택을 통과하거나, 이를 건너뛰고 커널 공간 스택에서 패킷을 왕복할 수 있습니다.

즉, 이전 리다이렉션 접근 방식에서는 앰비언트가 작동하지 않는 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에 포드의 네트워크 네임스페이스를 나타내는 저수준 리눅스 파일 설명자를 제공합니다.
• node-local ztunne은 내부적으로 새로운 프록시 인스턴스와 리스닝 포트 세트를 스핀업하여 새로 추가된 포드 전용으로 만듭니다.

• 메시에 추가되는 애플리케이션 포드의 흐름을 보여주는 기본 다이어그램
  
• 포드가 앰비언트 메시에 성공적으로 추가되면, 메시의 포드 간 트래픽은 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

• 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?

• ambient mesh의 핵심 혁신은 레이어 4(L4)와 레이어 7(L7) 처리를 두 개의 서로 다른 레이어로 분할하는 것입니다. Istio의 앰비언트 모드는 가볍고 공유된 L4 노드 프록시와 선택적인 L7 프록시로 구동되므로 데이터 플레인에서 기존 사이드카 프록시가 필요하지 않습니다. 이 레이어드 접근 방식을 통해 Istio를 점진적으로 채택하여 메시 없음에서 보안 오버레이(L4)로, 필요에 따라 이름 공간 단위로 전체 L7 처리로 원활하게 전환할 수 있습니다.
• 앰비언트 메시를 활용하여 사용자들은 사이드카 모델의 이전에 제한적이었던 요소들을 우회합니다. 이제 서버 전송 우선 프로토콜이 작동하며, 대부분의 예약된 포트를 사용할 수 있게 되었으며, 컨테이너가 악의적이든 아니든 사이드카를 우회할 수 있는 기능이 제거되었습니다.
• 경량 공유 L4 노드 프록시를 ztunnel(제로 트러스트 터널)이라고 합니다. ztunnel은 예상 부하를 처리하기 위해 클러스터 내에서 메모리와 CPU를 과도하게 프로비저닝할 필요를 제거하여 메시 실행의 오버헤드를 크게 줄여줍니다. 일부 사용 사례에서는 암호화 신원, 간단한 L4 인증 정책 및 원격 측정 기능을 갖춘 상호 TLS를 사용하여 제로 트러스트 보안을 제공하면서도 90% 이상의 비용을 절감할 수 있습니다.
• L7 프록시를 웨이포인트라고 합니다. 웨이포인트는 트래픽 라우팅, 풍부한 권한 부여 정책 시행, 엔터프라이즈급 복원력과 같은 L7 기능을 처리합니다. 웨이포인트는 애플리케이션 배포 외부에서 실행되며 전체 네임스페이스 또는 네임스페이스 내의 여러 서비스에 대한 필요에 따라 독립적으로 확장할 수 있습니다. 사이드카와 비교할 때 애플리케이션 포드당 하나의 웨이포인트가 필요하지 않으며, 그 범위에 따라 웨이포인트를 효과적으로 확장할 수 있어 대부분의 경우 상당한 양의 CPU와 메모리를 절약할 수 있습니다.