Istio Hands-on Study [1기] - 9주차 - Ambient Mesh

Istio Blog

Introducing Ambient Mesh

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

앰비언트 메시는 사용자에게 사이드카 프록시 대신 인프라에 통합된 데이터 플레인을 사용할 수 있는 옵션을 제공하며, 동시에 Istio의 핵심 기능인 제로 트러스트 보안, 원격 측정, 트래픽 관리는 그대로 유지됩니다. Ambient mesh gives users the option to forgo sidecar proxies in favor of a data plane that’s integrated into their infrastructure, all while maintaining Istio’s core features of zero-trust security, telemetry, and traffic management

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 파드를 공유하여 다른 파드들(동일 노드, 다른 노드)과 안전한 통신 환경을 제공
• Ambient mesh uses a shared, per-node ztunnel to provide a zero-trust secure overlay

 

• Layer7 통제와 정책이 필요 시, Waypoint Proxy 파드를 통하여 기능을 구현
• When additional features are needed, ambient mesh deploys waypoint proxies, which ztunnels connect through for policy enforcement

 

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

 

통신 흐름 상세 - Link

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

https://istio.io/latest/docs/setup/additional-setup/cni/cni.svg

⇒ 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 데이터 플레인을 완벽하게 분리하지는 못합니다.
• 이로 인해 다음과 같은 몇 가지 제약이 발생합니다.

 

1. 침입성(간섭) Invasiveness
   • 사이드카는 쿠버네티스 포드 사양을 수정하고 포드 내 트래픽을 리디렉션하여 애플리케이션에 "주입"해야 합니다.
   • 따라서 사이드카를 설치하거나 업그레이드하려면 애플리케이션 포드를 다시 시작해야 하며, 이는 워크로드에 지장을 줄 수 있습니다. Sidecars must be “injected” into applications by modifying their Kubernetes pod spec and redirecting traffic within the pod. As a result, installing or upgrading sidecars requires restarting the application pod, which can be disruptive for workloads
2. 리소스 활용도 저하 Underutilization of resources
   • 사이드카 프록시는 관련 워크로드에 전념하므로, 각 개별 포드의 최악의 사용 상황을 고려하여 CPU 및 메모리 리소스를 프로비저닝해야 합니다.
   • 이로 인해 대규모 예약이 발생하여 클러스터 전체의 리소스 활용도가 저하될 수 있습니다. Since the sidecar proxy is dedicated to its associated workload, the CPU and memory resources must be provisioned for worst case usage of each individual pod. This adds up to large reservations that can lead to underutilization of resources across the cluster.
3. 트래픽 차단 Traffic breaking
   • Istio의 사이드카에서 일반적으로 수행되는 트래픽 캡처 및 HTTP 처리에는 컴퓨팅 비용이 많이 들고,
   • HTTP 구현에 맞지 않는 일부 애플리케이션을 중단시킬 수 있습니다. Traffic capture and HTTP processing, as typically done by Istio’s sidecars, is computationally expensive and can break some applications with non-conformant HTTP implementations.

⇒ 사이드카가 나름의 역할을 하고 있지만(나중에 자세히 설명하겠습니다) 우리는 많은 서비스 메시 사용자에게 더 적합하고, 덜 침입적(간섭적)이고 사용하기 쉬운 옵션이 필요하다고 생각합니다. While sidecars have their place — more on that later — we think there is a need for a less invasive and easier option that will be a better fit for many service mesh users.

 

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

• 전통적으로 Istio는 기본 암호화부터 고급 L7 정책까지 모든 데이터 플레인 기능을 단일 아키텍처 구성 요소인 사이드카에 구현합니다.
• 하지만 실제로는 이러한 방식으로 사이드카는 '모두 아니면 전무 all-or-nothing proposition'의 문제가 됩니다.
• 워크로드에 간단한 전송 보안만 필요한 경우에도 관리자는 사이드카를 구축하고 유지하는 데 드는 운영 비용을 부담해야 합니다.
• 사이드카는 워크로드당 고정된 운영 비용을 가지며, 사용 사례의 복잡성에 따라 확장되지 않습니다.
• 앰비언트 데이터 플레인은 다른 접근 방식을 취합니다. Istio의 기능을 두 개의 개별 계층으로 분할합니다. The ambient data plane takes a different approach. It splits Istio’s functionality into two distinct layers.
• 가장 아래에는 라우팅과 트래픽에 대한 제로 트러스트 보안을 처리하는 보안 오버레이가 있습니다. At the base, there’s a secure overlay that handles routing and zero trust security for traffic.
• 그 위에는 필요에 따라 사용자가 L7 프로세싱을 활성화하여 모든 Istio 기능에 액세스할 수 있습니다. Above that, when needed, users can enable L7 processing to get access to the full range of Istio features.
• L7 프로세싱 모드는 보안 오버레이보다 무겁지만, 인프라의 앰비언트 구성 요소로 실행되므로 애플리케이션 파드를 수정할 필요가 없습니다. The L7 processing mode, while heavier than the secure overlay, still runs as an ambient component of the infrastructure, requiring no modifications to application pods.

Layers of the ambient mesh

• 이러한 계층적 접근 방식을 통해 사용자는 Istio를 더욱 점진적으로 도입하여 필요에 따라 네임스페이스별로 메시 없음에서 보안 오버레이, 그리고 완전한 L7 처리로 원활하게 전환할 수 있습니다.
• 또한, 서로 다른 앰비언트 계층에서 실행되거나 사이드카를 통해 실행되는 워크로드가 원활하게 상호 운용되므로 사용자는 시간이 지남에 따라 변화하는 특정 요구 사항에 따라 기능을 조합하고 조정할 수 있습니다.

 

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

• Istio의 앰비언트 데이터 플레인 모드는 쿠버네티스 클러스터의 각 노드에서 실행되는 공유 에이전트를 사용합니다. Istio’s ambient data plane mode uses a shared agent, running on each node in the Kubernetes cluster
• 이 에이전트는 **제로 트러스트 터널(또는 ztunnel )**이며, 주요 역할은 메시 내 요소를 안전하게 연결하고 인증하는 것입니다. This agent is a zero-trust tunnel (or ztunnel), and its primary responsibility is to securely connect and authenticate elements within the mesh.
• 노드의 네트워킹 스택은 로컬 ztunnel 에이전트를 통해 참여 워크로드의 모든 트래픽을 리디렉션합니다. The networking stack on the node redirects all traffic of participating workloads through the local ztunnel agent.
• 이를 통해 Istio 데이터 플레인과 애플리케이션의 문제가 완전히 분리되어 운영자가 애플리케이션을 중단하지 않고 데이터 플레인을 활성화, 비활성화, 확장 및 업그레이드할 수 있습니다. This fully separates the concerns of Istio’s data plane from those of the application, ultimately allowing operators to enable, disable, scale, and upgrade the data plane without disturbing applications.
• ztunnel은 워크로드 트래픽에 대해 L7 처리를 수행하지 않으므로 사이드카보다 훨씬 효율적입니다. The ztunnel performs no L7 processing on workload traffic, making it significantly leaner than sidecars.
• 복잡성과 관련 리소스 비용이 크게 감소하여 공유 인프라로 제공하기에 적합합니다. This large reduction in complexity and associated resource costs make it amenable to delivery as shared infrastructure.

 

• Ztunnels는 서비스 메시의 핵심 기능인 제로 트러스트를 지원합니다. Ztunnels enable the core functionality of a service mesh. zero trust
• 네임스페이스에 대해 앰비언트 모드가 활성화되면 보안 오버레이가 생성됩니다. A secure overlay is created when ambient mode is enabled for a namespace.
• HTTP를 종료하거나 파싱하지 않고도 mTLS, 원격 분석, 인증 및 L4 권한 부여를 위한 워크로드에게 제공합니다.  It provides workloads with mTLS, telemetry, authentication, and L4 authorization, without terminating or parsing HTTP.

 

• Ambient 모드가 활성화되고 보안 오버레이가 생성된 후 L7 기능을 활용하도록 네임스페이스를 구성할 수 있습니다. After ambient mode is enabled and a secure overlay is created, a namespace can be configured to utilize L7 features
• 이를 통해 네임스페이스는 Virtual Service API , L7 원격 측정 및 L7 권한 부여 정책을 포함한 Istio 전체 기능을 구현할 수 있습니다. This allows a namespace to implement the full set of Istio capabilities, including the Virtual Service API, L7 telemetry, and L7 authorization policies.
• 이 모드에서 작동하는 네임스페이스는 하나 이상의 Envoy 기반 *웨이포인트 프록시를* 사용하여 해당 네임스페이스의 워크로드에 대한 L7 처리를 처리합니다. Namespaces operating in this mode use one or more Envoy-based waypoint proxies to handle L7 processing for workloads in that namespace.
• Istio의 제어 평면은 클러스터의 ztunnel을 구성하여 L7 처리가 필요한 모든 트래픽을 웨이포인트 프록시를 통해 전달합니다. Istio’s control plane configures the ztunnels in the cluster to pass all traffic that requires L7 processing through the waypoint proxy.
• 중요한 점은 Kubernetes 관점에서 웨이포인트 프록시는 다른 Kubernetes 배포와 마찬가지로 자동 확장이 가능한 일반 포드일 뿐입니다. Importantly, from a Kubernetes perspective, waypoint proxies are just regular pods that can be auto-scaled like any other Kubernetes deployment.
• 웨이포인트 프록시는 최악의 경우 운영자가 예상하는 최대 부하가 아닌 제공하는 네임스페이스의 실시간 트래픽 수요에 맞게 자동 확장될 수 있으므로 이를 통해 사용자에게 상당한 리소스 절감 효과가 있을 것으로 예상합니다. We expect this to yield significant resource savings for users, as the waypoint proxies can be auto-scaled to fit the real time traffic demand of the namespaces they serve, not the maximum worst-case load operators expect.

 

 

• 앰비언트 메시는 mTLS 기반 HTTP CONNECT를 사용하여 보안 터널을 구현하고 경로에 웨이포인트 프록시를 삽입합니다. Ambient mesh uses HTTP CONNECT over mTLS to implement its secure tunnels and insert waypoint proxies in the path
• 이 패턴을 HBONE(HTTP 기반 오버레이 네트워크 환경) 이라고 합니다. a pattern we call HBONE (HTTP-Based Overlay Network Environment).
• HBONE은 TLS 단독 사용 시보다 트래픽을 더욱 깔끔하게 캡슐화하는 동시에 일반적인 로드 밸런서 인프라와의 상호 운용성을 지원합니다. HBONE provides for a cleaner encapsulation of traffic than TLS on its own while enabling interoperability with common load-balancer infrastructure.
• 규정 준수 요건을 충족하기 위해 FIPS 빌드가 기본적으로 사용됩니다. FIPS builds are used by default to meet compliance needs.
• HBONE, 표준 기반 접근 방식, 그리고 UDP 및 기타 비 TCP 프로토콜에 대한 계획에 대한 자세한 내용은 향후 블로그에서 제공될 예정입니다. More details on HBONE, its standards-based approach, and plans for UDP and other non-TCP protocols will be provided in a future blog.
• 단일 메시 환경에서 사이드카 모드와 앰비언트 모드를 혼합하더라도 시스템의 기능이나 보안 속성에 제한이 발생하지 않습니다. Mixing sidecar and ambient modes in a single mesh does not introduce limitations on the capabilities or security properties of the system.
• Istio 제어 평면은 선택한 배포 모델에 관계없이 정책이 적절하게 시행되도록 보장합니다. The Istio control plane ensures that policies are properly enforced regardless of the deployment model chosen.
• 앰비언트 모드는 단순히 더 나은 인체공학성과 유연성을 제공하는 옵션을 제공할 뿐입니다. Ambient mode simply introduces an option that has better ergonomics and more flexibility.

 

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

• 앰비언트 모드는 노드에서 공유 ztunnel 에이전트를 사용하여 메시의 제로 트러스트 기능을 처리하는 반면, L7 처리는 별도로 예약된 포드의 웨이포인트 프록시에서 수행됩니다. Ambient mode uses a shared ztunnel agent on the node, which handles the zero trust aspects of the mesh, while L7 processing happens in the waypoint proxy in separately scheduled pods.
• 노드에서 공유 전체 L7 프록시를 사용하지 않고 간접 연결을 사용하는 이유는 무엇일까요? 여기에는 몇 가지 이유가 있습니다. Why bother with the indirection, and not just use a shared full L7 proxy on the node? There are several reasons for this:

 

1. Envoy는 본질적으로 멀티 테넌트가 아닙니다. Envoy is not inherently multi-tenant.
   • 따라서 공유 인스턴스에서 제약이 없는 여러 테넌트의 L7 트래픽에 대한 복잡한 처리 규칙을 혼합하는 데 보안 문제가 있습니다. As a result, we have security concerns with commingling complex processing rules for L7 traffic from multiple unconstrained tenants in a shared instance.
   • L4 처리로 엄격하게 제한함으로써 취약점 노출 영역을 크게 줄였습니다. By strictly limiting to L4 processing, we reduce the vulnerability surface area significantly.
2. ztunnel이 제공하는 mTLS 및 L4 기능은 웨이포인트 프록시에 필요한 L7 처리량에 비해 훨씬 적은 CPU 및 메모리 사용량을 필요로 합니다. The mTLS and L4 features provided by the ztunnel need a much smaller CPU and memory footprint when compared to the L7 processing required in the waypoint proxy.
   • 웨이포인트 프록시를 공유 네임스페이스 리소스로 실행하면 해당 네임스페이스의 요구에 따라 독립적으로 확장할 수 있으며, 관련 없는 테넌트에 비용이 불공평하게 분배되지 않습니다. By running waypoint proxies as a shared namespace resource, we can scale them independently based on the needs of that namespace, and its costs are not unfairly distributed across unrelated tenants.
3. ztunnel의 범위를 줄이면 잘 정의된 상호 운용성 계약을 충족할 수 있는 다른 보안 터널 구현으로 대체될 수 있습니다. By reducing ztunnel’s scope we allow for it to be replaced by other secure tunnel implementations that can meet a well-defined interoperability contract.

 

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

• 앰비언트 모드에서는 웨이포인트가 해당 워크로드와 동일한 노드에 있을 것이라고 보장할 수 없습니다. With ambient mode, a waypoint isn’t necessarily guaranteed to be on the same node as the workloads it serves.
• 언뜻 보기에는 성능 문제로 보일 수 있지만, 궁극적으로는 Istio의 현재 사이드카 구현 방식과 동일한 수준의 지연 시간을 제공할 것으로 확신합니다. While at first glance this may appear to be a performance concern, we’re confident that latency will ultimately be in-line with Istio’s current sidecar implementation.
• 자세한 내용은 성능 관련 블로그 게시물에서 다루겠지만, 우선 두 가지 요점으로 요약하겠습니다. We’ll discuss more in a dedicated performance blog post, but for now we’ll summarize with two points:

1. Istio 네트워크 지연 시간의 대부분은 사실 네트워크 자체에서 발생하는 것이 아닙니다( 현대 클라우드 제공업체는 매우 빠른 네트워크를 보유하고 있습니다 ). The majority of Istio’s network latency does not, in fact, come from the network (modern cloud providers have extremely fast networks).
   • 가장 큰 원인은 Istio가 정교한 기능 세트를 구현하는 데 필요한 집중적인 L7 처리입니다. Instead the biggest culprit is the intensive L7 processing Istio needs to implement its sophisticated feature set.
   • 각 연결에 대해 두 단계의 L7 처리 단계(사이드카당 하나씩)를 구현하는 사이드카와 달리, 앰비언트 모드는 이 두 단계를 하나로 통합합니다. Unlike sidecars, which implement two L7 processing steps for each connection (one for each sidecar), ambient mode collapses these two steps into one.
   • 대부분의 경우, 이렇게 감소된 처리 비용은 추가 네트워크 홉을 상쇄할 것으로 예상됩니다.
2. 사용자는 종종 첫 번째 단계로 메시를 구축하여 제로 트러스트 보안 태세를 구축한 후 필요에 따라 선택적으로 L7 기능을 활성화합니다. Users often deploy a mesh to enable a zero-trust security posture as a first-step and then selectively enable L7 capabilities as needed.
   • 앰비언트 모드를 사용하면 L7 처리 비용이 전혀 들지 않을 때 L7 처리 비용을 완전히 절감할 수 있습니다. Ambient mode allows those users to bypass the cost of L7 processing entirely when it’s not needed.

 

Resource overhead 리소스 오버헤드

• 전반적으로 Istio의 앰비언트 모드는 대부분의 사용자에게 점점 더 예측 가능한 리소스 요구 사항이 줄어들 것으로 예상됩니다. Overall we expect Istio’s ambient mode to have fewer and more predictable resource requirements for most users.
• ztunnel의 제한된 책임으로 인해 노드에서 공유 리소스로 배포할 수 있습니다. 이렇게 하면 대부분의 사용자에게 필요한 워크로드당 예약을 크게 줄일 수 있습니다. The ztunnel’s limited responsibilities allows it to be deployed as a shared resource on the node. This will substantially reduce the per-workload reservations required for most users.
• 또한, 웨이포인트 프록시는 일반적인 쿠버네티스 포드이므로, 제공하는 워크로드의 실시간 트래픽 수요에 따라 동적으로 배포하고 확장할 수 있습니다. Furthermore, since the waypoint proxies are normal Kubernetes pods, they can be dynamically deployed and scaled based on the real-time traffic demands of the workloads they serve.
• 반면 사이드카는 각 워크로드에 대해 최악의 상황을 대비하여 메모리와 CPU를 예약해야 합니다. Sidecars, on the other hand, need to reserve memory and CPU for the worst case for each workload.
• 이러한 계산은 복잡하기 때문에 실제로 관리자는 과도하게 프로비저닝하는 경향이 있습니다. Making these calculations are complicated, so in practice administrators tend to over-provision.
• 이로 인해 다른 워크로드를 예약할 수 없는 과도한 예약으로 인해 노드 활용도가 낮아집니다. This leads to underutilized nodes due to high reservations that prevent other workloads from being scheduled.
• 앰비언트 모드는 노드당 고정 오버헤드가 낮고 동적으로 확장되는 웨이포인트 프록시를 사용하므로 전체적으로 훨씬 적은 리소스 예약이 필요하므로 클러스터를 더욱 효율적으로 사용할 수 있습니다. Ambient mode’s lower fixed per-node overhead and dynamically scaled waypoint proxies will require far fewer resource reservations in aggregate, leading to more efficient use of a cluster.

 

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

• 완전히 새로운 아키텍처는 자연스럽게 보안에 대한 의문을 제기합니다. 앰비언트 모드 보안 블로그에서 심층 분석을 제공하지만, 여기서는 간략하게 설명하겠습니다. With a radically new architecture naturally comes questions around security. The ambient mode security blog does a deep dive, but we’ll summarize here.
• 사이드카는 서비스하는 워크로드와 함께 배치되므로, 한쪽의 취약점이 다른 쪽을 손상시킵니다. Sidecars co-locate with the workloads they serve and as a result, a vulnerability in one compromises the other.
• 앰비언트 메시 모델에서는 애플리케이션이 손상되더라도 ztunnel과 웨이포인트 프록시는 손상된 애플리케이션의 트래픽에 대해 엄격한 보안 정책을 적용할 수 있습니다. In the ambient mesh model, even if an application is compromised, the ztunnels and waypoint proxies can still enforce strict security policy on the compromised application’s traffic.
• 더욱이, Envoy는 세계 최대 규모의 네트워크 운영업체에서 사용하는 검증된 소프트웨어라는 점을 고려할 때, 함께 실행되는 애플리케이션보다 취약성이 낮을 가능성이 높습니다. Furthermore, given that Envoy is a mature battle-tested piece of software used by the world’s largest network operators, it is likely less vulnerable than the applications it runs alongside.
• ztunnel은 공유 리소스이지만, 현재 실행 중인 노드에 있는 워크로드의 키에만 접근할 수 있습니다. While the ztunnel is a shared resource, it only has access to the keys of the workloads currently on the node it’s running.
• 따라서 공격 반경은 노드별 키에 기반한 암호화된 CNI보다 나쁘지 않습니다. Thus, its blast radius is no worse than any other encrypted CNI that relies on per-node keys for encryption.
• 또한 ztunnel의 제한된 L4 전용 공격 표면 영역과 앞서 언급한 Envoy의 보안 특성을 고려할 때, 이러한 위험은 제한적이며 허용 가능하다고 생각합니다. Also, given the ztunnel’s limited L4 only attack surface area and Envoy’s aforementioned security properties, we feel this risk is limited and acceptable.

• 마지막으로, 웨이포인트 프록시는 공유 리소스이지만 하나의 서비스 계정만 지원하도록 제한될 수 있습니다. Finally, while the waypoint proxies are a shared resource, they can be limited to serving just one service account.
• 이는 사이드카보다 더 심각한 문제는 아닙니다. This makes them no worse than sidecars are today
• 하나의 웨이포인트 프록시가 손상되면 해당 웨이포인트와 연결된 자격 증명만 손실되고 다른 것은 아무것도 남지 않습니다. if one waypoint proxy is compromised, the credential associated with that waypoint is lost, and nothing else.

 

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

• 절대 아닙니다. 앞으로 많은 메시 사용자에게 앰비언트 메시가 최선의 선택이 될 것이라고 생각하지만, 규정 준수나 성능 튜닝과 같이 전용 데이터 플레인 리소스가 필요한 사용자에게는 사이드카가 여전히 좋은 선택입니다. Definitely not. While we believe ambient mesh will be the best option for many mesh users going forward, sidecars continue to be a good choice for those that need dedicated data plane resources, such as for compliance or performance tuning.
• Istio는 사이드카를 계속 지원할 것이며, 중요한 것은 사이드카가 앰비언트 모드와 원활하게 상호 운용될 수 있도록 지원할 것입니다. Istio will continue to support sidecars, and importantly, allow them to interoperate seamlessly with ambient mode.
• 실제로 오늘 출시되는 앰비언트 모드 코드는 이미 사이드카 기반 Istio와의 상호 운용성을 지원합니다. In fact, the ambient mode code we’re releasing today already supports interoperation with sidecar-based Istio.

 

 

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

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

• ztunnel(제로 트러스트 터널) 구성 요소는 Istio 앰비언트 메시를 위해 특별히 설계된 노드별 프록시입니다. The ztunnel (zero trust tunnel) component is a purpose-built per-node proxy for Istio ambient mesh.
• 앰비언트 메시 내에서 워크로드를 안전하게 연결하고 인증하는 역할을 합니다. It is responsible for securely connecting and authenticating workloads within ambient mesh.
• Ztunnel은 워크로드 HTTP 트래픽을 종료하거나 워크로드 HTTP 헤더를 파싱하지 않고도 mTLS, 인증, L4 권한 부여, 원격 측정과 같은 앰비언트 메시 내 워크로드를 위한 소수의 기능에 집중하도록 설계되었습니다. Ztunnel is designed to focus on a small set of features for your workloads in ambient mesh such as mTLS, authentication, L4 authorization and telemetry, without terminating workload HTTP traffic or parsing workload HTTP headers.
• ztunnel은 HTTP 원격 측정 및 부하 분산과 같은 Istio의 모든 기능이 구현된 웨이포인트 프록시로 트래픽이 효율적이고 안전하게 전송되도록 보장합니다. The ztunnel ensures traffic is efficiently and securely transported to the waypoint proxies, where the full suite of Istio’s functionality, such as HTTP telemetry and load balancing, is implemented.
• ztunnel은 모든 쿠버네티스 워커 노드에서 실행되도록 설계되었으므로 리소스 사용량을 작게 유지하는 것이 중요합니다. Because ztunnel is designed to run on all of your Kubernetes worker nodes, it is critical to keep its resource footprint small.
• Ztunnel은 워크로드에 미치는 영향을 최소화하면서 서비스 메시의 보이지 않는(또는 "주변") 부분으로 설계되었습니다. Ztunnel is designed to be an invisible (or “ambient”) part of your service mesh with minimal impact on your workloads.

 

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

사이드카와 유사하게 ztunnel은 xDS 클라이언트 및 CA 클라이언트 역할도 수행: ****Similar to sidecars, ztunnel also serves as an xDS client and CA client:

1. 시작 시 서비스 계정 토큰을 사용하여 Istiod 제어 평면에 안전하게 연결합니다. During startup, it securely connects to the Istiod control plane using its service account token.
   • ztunnel에서 Istiod로의 연결이 TLS를 사용하여 안전하게 설정되면 xDS 클라이언트로서 xDS 구성을 가져오기 시작합니다. Once the connection from ztunnel to Istiod is established securely using TLS, it starts to fetch xDS configuration as an xDS client.
   • 이는 사이드카, 게이트웨이 또는 웨이포인트 프록시와 유사하게 작동하지만, Istiod가 ztunnel의 요청을 인식하고 ztunnel용으로 특별히 제작된 xDS 구성을 전송한다는 점이 다릅니다. 이 구성에 대해서는 곧 자세히 알아보겠습니다. This works similarly to sidecars or gateways or waypoint proxies, except that Istiod recognizes the request from ztunnel and sends the purpose-built xDS configuration for ztunnel, which you will learn more about soon.
2. 또한 관리하는 모든 공동 작업 부하를 대신하여 mTLS 인증서를 관리하고 제공하는 CA 클라이언트 역할도 수행합니다. It also serves as a CA client to manage and provision mTLS certificates on behalf of all co-located workloads it manages.
3. 트래픽이 들어오고 나갈 때, 관리하는 모든 공동 배치 워크로드에 대한 인바운드 및 아웃바운드 트래픽(메시 외부 일반 텍스트 또는 메시 내부 HBONE)을 처리하는 핵심 프록시 역할을 합니다. As traffic comes in or goes out, it serves as a core proxy that handles the inbound and outbound traffic (either out-of-mesh plain text or in-mesh HBONE) for all co-located workloads it manages.
4. 필요한 경우 ztunnel을 디버깅하는 데 도움이 되는 디버깅 정보가 포함된 관리 서버와 함께 **L4 원격 측정(**메트릭 및 로그)을 제공합니다. It provides L4 telemetry (metrics and logs) along with an admin server with debugging information to help you debug ztunnel if needed.

 

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

• 2022년 9월 7일 Istio 앰비언트 서비스 메시가 발표되었을 때 ztunnel은 Envoy 프록시를 사용하여 구현되었습니다. When Istio ambient service mesh was announced on Sept 7, 2022, the ztunnel was implemented using an Envoy proxy.
• 사이드카, 게이트웨이, 웨이포인트 프록시 등 Istio의 나머지 부분에도 Envoy를 사용하고 있다는 점을 고려하면, Envoy를 사용하여 ztunnel을 구현하는 것은 당연한 일이었습니다. Given that we use Envoy for the rest of Istio - sidecars, gateways, and waypoint proxies - it was natural for us to start implementing ztunnel using Envoy.
• 하지만 Envoy가 다른 사용 사례에는 매우 적합했지만, Envoy에서 ztunnel을 구현하는 것은 쉽지 않았습니다. 사이드카 프록시나 인그레스 게이트웨이와는 장단점, 요구 사항, 사용 사례가 크게 다르기 때문입니다. However, we found that while Envoy was a great fit for other use cases, it was challenging to implement ztunnel in Envoy, as many of the tradeoffs, requirements, and use cases are dramatically different than that of a sidecar proxy or ingress gateway.
• 게다가 Envoy를 다른 사용 사례에 매우 적합하게 만드는 풍부한 L7 기능 세트와 확장성 같은 요소들이 ztunnel에서는 쓸모없게 되었습니다. ztunnel에는 이러한 기능이 필요하지 않았기 때문입니다. In addition, most of the things that make Envoy such a great fit for those other use cases, such as its rich L7 feature set and extensibility, went to waste in ztunnel which didn’t need those features.

 

A purpose-built ztunnel

• Envoy를 저희의 필요에 맞게 변형하는 데 어려움을 겪은 후, 저희는 ztunnel을 특수 목적에 맞게 구현하는 방법을 모색하기 시작했습니다. After having trouble bending Envoy to our needs, we started investigating making a purpose-built implementation of the ztunnel.
• 처음부터 단일 사용 사례에 집중하여 설계하면, 범용 프로젝트를 저희의 맞춤형 사용 사례에 맞춰 만드는 것보다 더 간단하고 성능이 뛰어난 솔루션을 개발할 수 있을 것이라는 가설이 있었습니다. Our hypothesis was that by designing with a single focused use case in mind from the beginning, we could develop a solution that was simpler and more performant than molding a general purpose project to our bespoke use cases.
• ztunnel을 단순하게 만들기로 한 명확한 결정이 이 가설의 핵심이었습니다. The explicit decision to make ztunnel simple was key to this hypothesis;
• 예를 들어, 지원되는 기능과 통합 기능이 매우 많은 게이트웨이를 다시 작성하는 경우에는 이러한 논리가 적용되지 않을 것입니다. similar logic wouldn’t hold up to rewriting the gateway, for example, which has a huge list of supported features and integrations.
• 이 특수 목적의 터널에는 두 가지 주요 영역이 포함됩니다. This purpose-built ztunnel involved two key areas
  • ztunnel과 Istiod 간의 구성 프로토콜 The configuration protocol between ztunnel and its Istiod
  • ztunnel의 런타임 구현 The runtime implementation of ztunnel

 

Configuration protocol 설정 프로토콜

• Envoy 프록시는 구성에 xDS 프로토콜을 사용합니다. Envoy proxies use the xDS Protocol for configuration.
• 이는 Istio가 원활하게 작동하도록 하는 핵심 요소이며, 풍부하고 동적인 구성 업데이트를 제공합니다. This is a key part of what makes Istio work well, offering rich and dynamic configuration updates.
• 하지만 기존 방식을 벗어나면서 구성은 점점 더 맞춤형으로 바뀌어 훨씬 더 크고 생성 비용도 더 많이 듭니다. However, as we tread off the beaten path, the config becomes more and more bespoke, which means it’s much larger and more expensive to generate.
• 사이드카에서 1개의 포드를 가진 단일 서비스는 약 350줄의 xDS(YAML 형식)를 생성하는데, 이는 이미 확장이 어려운 문제였습니다. In a sidecar, a single Service with 1 pod, generates roughly ~350 lines of xDS (in YAML), which already has been challenging to scale.
• Envoy 기반 ztunnel은 훨씬 더 나빴고, 일부 영역에서는 N^2개의 확장 속성을 사용했습니다. The Envoy-based ztunnel was far worse, and in some areas had N^2 scaling attributes.
• ztunnel 구성을 최대한 작게 유지하기 위해, 필요한 정보만 (그 이상은 포함하지 않고) 효율적인 형식으로 정확하게 포함하는 특수 제작 구성 프로토콜을 사용하여 조사했습니다. To keep the ztunnel configuration as small as possible, we investigated using a purpose built configuration protocol, that contains precisely the information we need (and nothing more), in an efficient format.
• 예를 들어, 단일 포드는 다음과 같이 간결하게 표현할 수 있습니다. For example, a single pod could be represented concisely:

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 을 사용합니다. 사용자 지정 주변 환경별 유형 This information is transported over the xDS transport API, but uses a custom ambient-specific type.
• 구성 세부 정보에 대한 자세한 내용은 워크로드 xDS 구성 섹션 을 참조하세요. Refer to the workload xDS configuration section to learn more about the configuration details.

 

• a purpose built API 전용 API를 사용하면 Envoy 구성 대신 프록시에 로직을 푸시할 수 있습니다. By having a purpose built API, we can push logic into the proxy instead of in Envoy configuration.
• 예를 들어 Envoy에서 mTLS를 구성하려면 각 서비스의 TLS 설정을 정밀하게 조정하는 동일한 대규모 구성 세트를 추가해야 합니다. For example, to configure mTLS in Envoy, we need to add an identical large set of configuration tuning the precise TLS settings for each service;
• ztunnel에서는 mTLS 사용 여부를 선언하는 열거형 하나만 있으면 됩니다. 나머지 복잡한 로직은 ztunnel 코드에 직접 내장됩니다. with ztunnel, we need only a single enum to declare whether mTLS should be used or not. The rest of the complex logic is embedded directly into ztunnel code.
• Istiod와 ztunnel 간의 효율적인 API를 통해 10만 개의 포드가 있는 메시와 같은 대규모 메시에 대한 정보로 ztunnel을 구성할 수 있었고, 구성이 엄청나게 줄어 CPU, 메모리, 네트워크 비용이 절감되었습니다. With this efficient API between Istiod and ztunnel, we found we could configure ztunnels with information about large meshes (such as those with 100,000 pods) with orders of magnitude less configuration, which means less CPU, memory, and network costs.

 

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

• 이름에서 알 수 있듯이 ztunnel은 HTTPS 터널을 사용하여 사용자 요청을 전달합니다. As the name suggests, ztunnel uses an HTTPS tunnel to carry users requests.
• Envoy는 이 터널링을 지원하지만, 구성 모델이 저희의 요구 사항에는 제한적이라는 것을 알게 되었습니다. While Envoy supports this tunneling, we found the configuration model limiting for our needs.
• Envoy는 요청을 수락하는 것부터 시작하여 요청을 전송하는 것까지 일련의 "필터"를 통해 요청을 전송하는 방식으로 작동합니다. Roughly speaking, Envoy operates by sending requests through a series of “filters”, starting with accepting a request and ending with sending a request.
• 터널 자체와 사용자 요청이라는 여러 계층의 요청이 있고, 로드 밸런싱 후 포드별 정책을 적용해야 하는 저희의 요구 사항을 고려했을 때, 이전 Envoy 기반 ztunnel을 구현할 때 연결당 이러한 필터를 4번씩 반복해야 했습니다. With our requirements, which have multiple layers of requests (the tunnel itself and the users’ requests), as well as a need to apply per-pod policy after load balancing, we found we would need to loop through these filters 4 times per connection when implementing our prior Envoy-based ztunnel.
• Envoy는 메모리에서 "자기 자신에게 요청을 전송"하는 데 있어 몇 가지 최적화를 제공했지만 , 여전히 매우 복잡하고 비용이 많이 들었습니다. While Envoy has some optimizations for essentially “sending a request to itself” in memory, this was still very complex and expensive.
• 자체 구현을 구축함으로써 이러한 제약 조건을 처음부터 고려하여 설계할 수 있었습니다. By building out our own implementation, we could design around these constraints from the ground up.
• 또한, 설계의 모든 측면에서 더 큰 유연성을 확보할 수 있었습니다. In addition, we have more flexibility in all aspects of the design.
• 예를 들어, 여러 스레드 간에 연결을 공유하거나 서비스 계정 간 격리를 중심으로 더욱 맞춤형 요구 사항을 구현할 수 있었습니다. For example, we could choose to share connections across threads or implement more bespoke requirements around isolation between service accounts.
• 특수 목적 프록시가 실행 가능하다는 것을 확인한 후, 구현 세부 사항을 선택하기 시작했습니다. After establishing that a purpose built proxy was viable, we set out to choose the implementation details.

 

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 구성은 이해하고 디버깅하기가 매우 쉽습니다. The workload xDS configurations are very easy to understand and debug.
• ztunnel 포드 중 하나에서 요청을 보내거나 편리한 명령을 사용하여 확인할 수 있습니다 istioctl pc workload.
• 워크로드 xDS 구성에는 워크로드와 정책이라는 두 가지 주요 구성이 있습니다. There are two key workload xDS configurations: workloads and policies.
• 워크로드가 앰비언트 메시에 포함되기 전에는 ztunnel의 구성 덤프에서 해당 워크로드를 확인할 수 있습니다. ztunnel은 앰비언트 활성화 여부와 관계없이 모든 워크로드를 인식하기 때문입니다. Before your workloads are included in your ambient mesh, you will still be able to see them in ztunnel’s config dump, as ztunnel is aware of all of the workloads regardless of whether they are ambient enabled or not.
• 예를 들어, 아래는 새로 배포된 helloworld v1 포드의 샘플 워크로드 구성입니다. 이 포드는 메시 외부(out-of-mesh)로 표시되어 있습니다 protocol: TCP.
• For example, below contains a sample workload configuration for a newly deployed helloworld v1 pod which is out-of-mesh indicated by 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으로 업그레이드하도록 지시합니다. After the pod is included in ambient (by labeling the namespace default with istio.io/dataplane-mode=ambient), the protocol value is replaced with HBONE, instructing ztunnel to upgrade all incoming and outgoing communications from the helloworld-v1 pod to be HBONE.

{
  "workloads": {
    "10.244.2.8": {
      "workloadIp": "10.244.2.8",
      "protocol": "HBONE",
      ...
}

워크로드 수준 권한 부여 정책을 배포한 후 정책 구성은 Istiod에서 ztunnel로 xDS 구성으로 푸시되고 아래에 표시됩니다 policies. After you deploy any workload level authorization policy, the policy configuration will be pushed as xDS configuration from Istiod to ztunnel and shown under policies

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

또한 승인 정책을 참조하여 워크로드의 구성이 업데이트된 것을 확인할 수 있습니다. You’ll also notice the workload’s configuration is updated with reference to the authorization policy.

{
  "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 처리 계층이라는 두 개의 개별 계층으로 나눕니다. Ambient splits Istio’s functionality into two distinct layers, a secure overlay layer and a Layer 7 processing layer.
• 웨이포인트 프록시는 Envoy 기반이며, 관리하는 워크로드에 대한 L7 처리를 담당하는 선택적 구성 요소입니다. The waypoint proxy is an optional component that is Envoy-based and handles L7 processing for workloads it manages.
• 2022년 최초 Ambient 출시 이후 웨이포인트 구성, 디버깅 및 확장성을 간소화하기 위해 상당한 변경 작업을 수행해 왔습니다. Since the initial ambient launch in 2022, we have made significant changes to simplify waypoint configuration, debuggability and scalability.

 

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

• 사이드카와 마찬가지로 웨이포인트 프록시도 Envoy 기반이며, Istio를 통해 애플리케이션 구성을 지원하도록 동적으로 구성됩니다. Similar to sidecar, the waypoint proxy is also Envoy-based and is dynamically configured by Istio to serve your applications configuration.
• 웨이포인트 프록시의 독특한 점은 네임스페이스별(기본값) 또는 서비스 계정별로 실행된다는 것입니다. What is unique about the waypoint proxy is that it runs either per-namespace (default) or per-service account.
• 애플리케이션 포드 외부에서 실행되므로 웨이포인트 프록시는 애플리케이션과 독립적으로 설치, 업그레이드 및 확장할 수 있을 뿐만 아니라 운영 비용도 절감할 수 있습니다. By running outside of the application pod, a waypoint proxy can install, upgrade, and scale independently from the application, as well as reduce operational costs.

웨이포인트 프록시는 Kubernetes Gateway 리소스나 유용한 istioctl명령을 사용하여 선언적으로 배포됩니다. Waypoint proxies are deployed declaratively using Kubernetes Gateway resources or the helpful istioctl command

$ 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는 이러한 리소스를 모니터링하고 해당 경로점 배포를 자동으로 사용자에게 배포하고 관리합니다. Istiod will monitor these resources and deploy and manage the corresponding waypoint deployment for users automatically.

 

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

기존 사이드카 아키텍처에서 대부분의 트래픽 셰이핑(예: 요청 라우팅 , 트래픽 이동 또는 오류 주입 ) 정책은 소스(클라이언트) 프록시에 의해 구현되는 반면, 대부분의 보안 정책은 목적지(서버) 프록시에 의해 구현됩니다. 이로 인해 다음과 같은 여러 가지 문제가 발생합니다. In the existing sidecar architecture, most traffic-shaping (for example request routing or traffic shifting or fault injection) policies are implemented by the source (client) proxy while most security policies are implemented by the destination (server) proxy. This leads to a number of concerns:

• Scaling 스케일링
  • 각 소스 사이드카는 메시 내 다른 모든 목적지에 대한 정보를 알아야 합니다. 이는 다항식 스케일링 문제입니다. each source sidecar needs to know information about every other destination in the mesh. This is a polynomial scaling problem.
  • 더 심각한 것은 목적지 구성이 변경되면 모든 사이드카에 동시에 알려야 한다는 것입니다. Worse, if any destination configuration changes, we need to notify all sidecars at once.
• Debugging 디버깅
  • 정책 시행이 클라이언트와 서버 사이드카로 분리되어 있기 때문에 문제를 해결할 때 시스템의 동작을 이해하기 어려울 수 있습니다. because policy enforcement is split between the client and server sidecars, it can be hard to understand the behavior of the system when troubleshooting.
• Mixed environments 혼합 환경
  • 모든 클라이언트가 메시에 속하지 않는 시스템에서는 동작이 일관되지 않습니다. if we have systems where not all clients are part of the mesh, we get inconsistent behavior.
  • 예를 들어, 메시가 아닌 클라이언트는 카나리아 롤아웃 정책을 준수하지 않아 예상치 못한 트래픽 분산이 발생할 수 있습니다. For example, a non-mesh client wouldn’t respect a canary rollout policy, leading to unexpected traffic distribution.
• Ownership and attribution 소유권 및 귀속
  • 이상적으로는 하나의 네임스페이스에 작성된 정책은 동일한 네임스페이스에서 실행되는 프록시가 수행하는 작업에만 영향을 미쳐야 합니다.  ideally a policy written in one namespace should only affect work done by proxies running in the same namespace
  • 그러나 이 모델에서는 정책이 각 사이드카에 의해 분산되고 적용됩니다. However, in this model, it is distributed and enforced by each sidecar.
  • Istio는 이러한 제약 조건을 고려하여 보안을 강화하도록 설계되었지만, 여전히 최적의 방법은 아닙니다. While Istio has designed around this constraint to make this secure, it is still not optimal.

 

• 앰비언트에서는 모든 정책이 목적지 웨이포인트에 의해 적용됩니다. In ambient, all policies are enforced by the destination waypoint
• 여러 측면에서 웨이포인트는 **네임스페이스(**기본 범위) 또는 서비스 계정으로의 게이트웨이 역할을 합니다. In many ways, the waypoint acts as a gateway into the namespace (default scope) or service account.
• Istio는 네임스페이스로 들어오는 모든 트래픽이 웨이포인트를 통과하도록 하고, 웨이포인트는 해당 네임스페이스에 대한 모든 정책을 적용합니다. Istio enforces that all traffic coming into the namespace goes through the waypoint, which then enforces all policies for that namespace.
• 따라서 각 웨이포인트는 자체 네임스페이스의 구성만 알면 됩니다. Because of this, each waypoint only needs to know about configuration for its own namespace.
• 특히 확장성 문제는 대규모 클러스터를 사용하는 사용자에게 골칫거리입니다. The scalability problem, in particular, is a nuisance for users running in large clusters.
• 이를 시각화해 보면 새로운 아키텍처가 얼마나 큰 개선을 이루었는지 알 수 있습니다. If we visualize it, we can see just how big an improvement the new architecture is.
• 네임스페이스 2개가 있고 각 네임스페이스에 2개의 (색상 구분) deployment가 있는 간단한 배포를 생각해 보겠습니다. Consider a simple deployment, where we have 2 namespaces, each with 2 (color coded) deployments.

 

사이드카 프로그래밍에 필요한 Envoy(XDS) 구성은 원으로 표시되어 있습니다. The Envoy (XDS) configuration required to program the sidecars is shown as circles:

• 사이드카 모델에는 4개의 워크로드가 있으며, 각 워크로드에는 4개의 구성 세트가 있습니다. In the sidecar model, we have 4 workloads, each with 4 sets of configuration.
• 이러한 구성 중 하나라도 변경되면 모든 구성을 업데이트해야 합니다. 총 16개의 구성이 배포됩니다. If any of those configurations changed, all of them would need to be updated. In total there are 16 configurations distributed.

 

그러나 웨이포인트 아키텍처에서는 구성이 극적으로 단순화되었습니다. In the waypoint architecture, however, the configuration is dramatically simplified

• 여기서는 매우 다른 상황을 볼 수 있습니다.
• 각 프록시가 전체 네임스페이스를 지원할 수 있고, 각 프록시는 자체 네임스페이스에 대한 구성만 필요하기 때문에 웨이포인트 프록시는 두 개뿐입니다.
• 간단한 예시일지라도 **전송되는 구성의 총량은 전체의 25%**입니다. Here, we see a very different story. We have only 2 waypoint proxies, as each one is able to serve the entire namespace, and each one only needs configuration for its own namespace. In total we have 25% of the amount of configuration sent, even for a simple example.

 

• 각 네임스페이스를 각각 10개의 포드로 구성된 25개 배포까지 확장하고, 고가용성을 위해 각 웨이포인트 배포를 2개의 포드로 구성하면 숫자는 훨씬 더 인상적입니다.
• 아래 표에서 볼 수 있듯이 웨이포인트 구성 배포에는 사이드카 구성 배포의 0.8%만 필요합니다! If we scale each namespace up to 25 deployments with 10 pods each and each waypoint deployment with 2 pods for high availability, the numbers are even more impressive - the waypoint config distribution requires just 0.8% of the configuration distribution of the sidecar, as the table below illustrates!

 

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

 

• 위에서 단순화를 설명하기 위해 네임스페이스 범위의 웨이포인트 프록시를 사용했지만, 이를 서비스 계정 웨이포인트 프록시에 적용하면 단순화는 유사합니다. While we use namespace scoped waypoint proxies to illustrate the simplification above, the simplification is similar when you apply it to service account waypoint proxies.
• 이렇게 축소된 구성은 제어 플레인과 데이터 플레인 모두의 리소스 사용량(CPU, RAM, 네트워크 대역폭)을 줄인다는 것을 의미합니다.
• 현재 사용자는 exportToIstio 네트워킹 리소스나 Sidecar API를 신중하게 사용하면 유사한 개선 효과를 볼 수 있지만, 앰비언트 모드에서는 이러한 작업이 더 이상 필요하지 않으므로 확장이 훨씬 수월해집니다. This reduced configuration means lower resource usage (CPU, RAM, and network bandwidth) for both the control plane and data plane. While users today can see similar improvements with careful usage of exportTo in their Istio networking resources or of the Sidecar API, in ambient mode this is no longer required, making scaling a breeze.

 

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

• 앰비언트 모드는 대부분의 구성이 서비스 소비자가 아닌 서비스 생산자에 의해 가장 잘 구현된다는 가정을 중심으로 설계되었습니다.
• 하지만 항상 그런 것은 아닙니다. 때로는 제어할 수 없는 대상에 대한 트래픽 관리를 구성해야 할 수도 있습니다.
• 이러한 일반적인 예로는 간헐적인 연결 문제를 처리하기 위해 향상된 복원력을 갖춘 외부 서비스에 연결하는 것입니다(예: 호출에 시간 초과를 추가하는 경우 example.com). The design of ambient mode centers around the assumption that most configuration is best implemented by the service producer, rather than the service consumer. However, this isn’t always the case - sometimes we need to configure traffic management for destinations we don’t control. A common example of this would be connecting to an external service with improved resilience to handle occasional connection issues (e.g., to add a timeout for calls to example.com).
• 이 영역은 커뮤니티에서 활발하게 개발 중인 영역으로, 트래픽이 이그레스 게이트웨이로 라우팅되는 방식과 원하는 정책으로 이그레스 게이트웨이를 구성하는 방법을 설계합니다. 이 영역에 대한 향후 블로그 게시물도 기대해 주세요! This is an area under active development in the community, where we design how traffic can be routed to your egress gateway and how you can configure the egress gateway with your desired policies. Look out for future blog posts in this area!

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

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

$ 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와 같은 워크로드 정책을 적용합니다. For requests arriving on port 15008, which by default is Istio’s inbound HBONE port, the waypoint proxy terminates the HBONE connection and forwards the request to the main_internal listener to enforce any workload policies such as AuthorizationPolicy.
• 내부 리스너 에 대해 잘 모르시는 분들을 위해 설명드리자면 , 내부 리스너는 시스템 네트워크 API를 사용하지 않고 사용자 공간 연결을 허용하는 Envoy 리스너입니다. If you are not familiar with internal listeners, they are Envoy listeners that accepts user space connections without using the system network API.
• 위의 istioctl proxy-config 명령에 추가된 --waypoint 플래그는 main_internal listener, filter chains, chain matches 및 destinations의 세부 정보를 표시하도록 지시합니다. The --waypoint flag added to the istioctl proxy-config command, above, instructs it to show the details of the main_internal listener, its filter chains, chain matches, and destinations.
• 10.96.104.108은 리뷰의 서비스 VIP이며, 10.244.x.x는 리뷰의 v1/v2/v3 포드 IP로, kubectl get svc,pod -o wide 명령을 사용하여 클러스터를 확인할 수 있습니다. 10.96.104.108 is the reviews’ service VIP and 10.244.x.x are the reviews’ v1/v2/v3 pod IPs, which you can view for your cluster using the kubectl get svc,pod -o wide command.
• 일반 텍스트 또는 HBONE 종료 인바운드 트래픽의 경우, 검토를 위해 서비스 VIP 및 포트 9080에서 일치시키거나 팟 IP 주소 및 애플리케이션 프로토콜(ANY, h2c 또는 http/1.1)로 일치시킵니다. For plain text or HBONE terminated inbound traffic, it will be matched on the service VIP and port 9080 for reviews or by pod IP address and application protocol (either ANY, h2c, or http/1.1).

• reviews 웨이포인트 프록시 클러스터를 확인하면 main_internal 클러스터와 몇 개의 인바운드 클러스터가 표시됩니다. Checking out the clusters for the reviews waypoint proxy, you get the main_internal cluster along with a few inbound clusters.
• 인프라용 클러스터를 제외하고, 생성된 유일한 Envoy 클러스터는 동일한 서비스 계정에서 실행되는 서비스와 포드를 위한 것입니다. Other than the clusters for infrastructure, the only Envoy clusters created are for services and pods running in the same service account.

다른 곳에서 실행되는 서비스나 포드를 위한 클러스터는 생성되지 않습니다. No clusters are created for services or pods running elsewhere.

$ 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!를 사용하여 확인할 수 있습니다! that there are no outbound clusters in the list, which you can confirm using istioctl proxy-config cluster deploy/bookinfo-reviews-istio-waypoint --direction outbound!
• 좋은 점은 다른 북인포 서비스(예: 제품 페이지 또는 평점 서비스)에서 exportTo를 구성할 필요가 없다는 것입니다. What’s nice is that you didn’t need to configure exportTo on any other bookinfo services (for example, the productpage or ratings services).
• 다시 말해, reviews waypoint는 불필요한 클러스터에 대해 추가적인 수동 설정 없이는 인식되지 않습니다. In other words, the reviews waypoint is not made aware of any unnecessary clusters, without any extra manual configuration from you.
• reviews waypoint 프록시의 경로 목록을 표시합니다. Display the list of routes for the reviews waypoint proxy

$ 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 구성을 구성하지 않았다는 점을 기억하세요. Recall that you didn’t configure any Sidecar resources or exportTo configuration on your Istio networking resources.
• 그러나 productpage로 라우팅하기 위한 ingress gateway를 구성하기 위해 bookinfo-productpage 경로를 배포했지만 reviews waypoint는 이러한 관련 없는 경로에 대해 인지하지 못했습니다. You did, however, deploy the bookinfo-productpage route to configure an ingress gateway to route to productpage but the reviews waypoint has not been made aware of any such irrelevant routes.
• inbound-vip|9080|http|reviews.default.svc.cluster.local 경로에 대한 자세한 정보를 표시하면 가중치 기반 라우팅 구성이 트래픽의 90%를 v1 리뷰로, 10%를 v2 리뷰로 유도하는 것을 볼 수 있으며, Istio의 기본 재시도 및 타임아웃 구성도 포함됩니다. Displaying the detailed information for the inbound-vip|9080|http|reviews.default.svc.cluster.local route, you’ll see the weight-based routing configuration directing 90% of the traffic to reviews v1 and 10% of the traffic to reviews v2, along with some of Istio’s default retry and timeout configurations.
• 이는 앞서 논의한 바와 같이 트래픽 및 복원력 정책이 원본 경유지에서 목적지 지향 경유지로 전환되었음을 확인시켜줍니다. This confirms the traffic and resiliency policies are shifted from the source to destination oriented waypoint as discussed earlier.

$ 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 네임스페이스에 몇 가지 다른 서비스가 있음에도 불구하고 리뷰 외에는 다른 서비스와 관련된 엔드포인트를 얻을 수 없습니다. that you don’t get any endpoints related to any services other than reviews, even though you have a few other services in the default and istio-system namespace.

 

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를 위한 사이드카 없는 데이터 플레인이자 앰비언트 메시 패턴의 참조 구현입니다.
• 발표 블로그에서 언급했듯이 , 앰비언트 메시를 통해 해결하고자 하는 주요 과제는 운영 간소화, 더 광범위한 애플리케이션 호환성, 인프라 비용 절감, 그리고 성능 향상입니다.
• 앰비언트 데이터 플레인을 설계할 때, 보안이나 기능을 희생하지 않으면서도 운영, 비용, 그리고 성능에 대한 우려 사항들을 신중하게 균형 있게 고려하고자 했습니다.
• 앰비언트 메시의 구성 요소가 애플리케이션 포드 외부에서 실행됨에 따라 보안 경계가 변경되었으며, 이는 더 나은 방향으로 변화했다고 생각합니다. As the components of ambient mesh run outside of the application pods, the security boundaries have changed – we believe for the better

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

• 요약하자면, Istio의 앰비언트 모드는 전송 보안 및 라우팅을 담당하는 보안 오버레이를 갖춘 계층화된 메시 데이터 플레인을 도입하며, 필요한 네임스페이스에 L7 기능을 추가할 수 있는 옵션을 제공합니다. 자세한 내용은 공지 블로그 와 시작하기 블로그를 참조하세요. To recap, Istio’s ambient mode introduces a layered mesh data plane with a secure overlay responsible for transport security and routing, that has the option to add L7 capabilities for namespaces that need them.
• 보안 오버레이는 노드 공유 구성 요소인 ztunnel로 구성되며, ztunnel은 L4 원격 측정 및 DaemonSet으로 배포되는 mTLS를 담당합니다.
• 메시의 L7 계층은 웨이포인트 프록시, 즉 ID/워크로드 유형별로 배포되는 전체 L7 Envoy 프록시에 의해 제공됩니다.
• 이 설계의 핵심적인 의미는 다음과 같습니다.
  • 데이터 플레인에서 애플리케이션 분리 Separation of application from data plane
  • 보안 오버레이 계층의 구성 요소는 CNI의 구성 요소와 유사합니다. Components of the secure overlay layer resemble that of a CNI
  • 보안을 위해서는 운영의 단순성이 더 좋습니다. Simplicity of operations is better for security
  • 다중 테넌트 L7 프록시 피하기 Avoiding multi-tenant L7 proxies
  • 사이드카는 여전히 일류 지원 배포입니다. Sidecars are still a first-class supported deployment

 

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

• 앰비언트 메시의 주요 목표는 서비스 메시 운영을 단순화하는 것이지만, 보안 강화에도 기여합니다.
• 복잡성은 취약성을 야기하며, 엔터프라이즈 애플리케이션(및 그 전이적 종속성, 라이브러리, 프레임워크)은 매우 복잡하고 취약성에 취약합니다.
• 복잡한 비즈니스 로직 처리부터 OSS 라이브러리 또는 버그가 있는 내부 공유 라이브러리 활용에 이르기까지, 사용자의 애플리케이션 코드는 내부 또는 외부 공격자의 주요 공격 대상입니다.
• 애플리케이션이 침해되면 메모리에 마운트되거나 저장된 자격 증명, 비밀, 키가 공격자에게 노출됩니다. If an application is compromised, credentials, secrets, and keys are exposed to an attacker including those mounted or stored in memory.
• 사이드카 모델을 살펴보면, 애플리케이션 침해에는 사이드카 및 관련 ID/키 자료의 점유가 포함됩니다. When looking at the sidecar model, an application compromise includes takeover of the sidecar and any associated identity/key material.
• Istio의 앰비언트 모드에서는 애플리케이션과 동일한 포드(pod)에서 실행되는 데이터 플레인 구성 요소가 없으므로 애플리케이션 침해가 비밀 접근으로 이어지지 않습니다. In Istio’s ambient mode, no data plane components run in the same pod as the application and therefore an application compromise does not lead to the access of secrets.

• Envoy 프록시가 잠재적인 취약점 공격 대상이 될 가능성은 어떨까요?
• Envoy는 엄격한 보안 검사를 거치는 매우 강화된 인프라로, 중요 환경 (예: Google 네트워크의 운영 환경 ) 에서 대규모로 운영됩니다. Envoy is an extremely hardened piece of infrastructure under intense scrutiny and run at scale in critical environments (e.g., used in production to front Google’s network).
• 하지만 Envoy는 소프트웨어이기 때문에 취약점으로부터 완전히 자유롭지는 않습니다. However, since Envoy is software, it is not immune to vulnerabilities.
• 취약점이 발생할 경우, Envoy는 강력한 CVE 프로세스를 통해 취약점을 식별하고 신속하게 수정하여 광범위한 영향을 미치기 전에 고객에게 배포합니다. When those vulnerabilities do arise, Envoy has a robust CVE process for identifying them, fixing them quickly, and rolling them out to customers before they have the chance for wide impact.

• "복잡성은 취약점을 낳는다"라는 이전 댓글로 돌아가서, Envoy 프록시의 가장 복잡한 부분은 L7 처리에 있으며, 실제로 Envoy의 취약점 대부분은 역사적으로 L7 처리 스택에 있었습니다. Circling back to the earlier comment that “complexity breeds vulnerabilities”, the most complex parts of Envoy Proxy is in its L7 processing, and indeed historically the majority of Envoy’s vulnerabilities have been in its L7 processing stack.
• 하지만 mTLS에 Istio만 사용한다면 어떨까요? CVE 위험이 더 높은 완전한 L7 프록시를 배포하는 위험을 감수할 이유가 있을까요? But what if you just use Istio for mTLS? Why take the risk of deploying a full-blown L7 proxy which has a higher chance of CVE when you don’t use that functionality?
• 해당 기능을 사용하지 않는데 말이죠. 여기서 L4 및 L7 메시 기능을 분리하는 것이 중요합니다. Separating L4 and L7 mesh capabilities comes into play here.
• 사이드카 배포에서는 기능의 일부만 사용하더라도 모든 프록시를 채택하는 반면, 앰비언트 모드에서는 안전한 오버레이를 제공하고 필요에 따라 L7 레이어만 추가하여 노출을 제한할 수 있습니다. While in sidecar deployments you adopt all of the proxy, even if you use only a fraction of the functionality, in ambient mode we can limit the exposure by providing a secure overlay and only layering in L7 as needed.
• 또한, L7 구성 요소는 애플리케이션과 완전히 분리되어 실행되므로 공격 경로를 제공하지 않습니다. Additionally, the L7 components run completely separate from the applications and do not give an attack avenue.

 

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

• 앰비언트 모드 데이터 플레인의 L4 구성 요소는 DaemonSet 또는 노드당 하나씩 실행됩니다. The L4 components of the ambient mode data plane run as a DaemonSet, or one per node.
• 즉, 특정 노드에서 실행 중인 모든 파드에 대한 공유 인프라입니다. This means it is shared infrastructure for any of the pods running on a particular node.
• 이 구성 요소는 특히 민감하므로 CNI 에이전트, kube-proxy, kubelet 또는 Linux 커널과 같은 노드의 다른 공유 구성 요소와 동일한 수준에서 처리해야 합니다. This component is particularly sensitive and should be treated at the same level as any other shared component on the node such as any CNI agents, kube-proxy, kubelet, or even the Linux kernel.
• 워크로드에서 발생하는 트래픽은 ztunnel로 리디렉션되고, ztunnel은 워크로드를 식별하고 mTLS 연결에서 해당 워크로드를 나타내는 올바른 인증서를 선택합니다. Traffic from workloads is redirected to the ztunnel which then identifies the workload and selects the right certificates to represent that workload in a mTLS connection.

• ztunnel은 각 포드에 대해 고유한 자격 증명을 사용하며, 이 자격 증명은 포드가 현재 노드에서 실행 중인 경우에만 발급됩니다. The ztunnel uses a distinct credential for every pod which is only issued if the pod is currently running on the node.
• 이를 통해 손상된 ztunnel의 공격 범위가 해당 노드에 현재 예약된 포드의 자격 증명만 유출될 수 있도록 보장합니다. This ensures that the blast radius for a compromised ztunnel is that only credentials for pods currently scheduled on that node could be stolen.
• 이는 다른 보안 CNI 구현을 포함하여 잘 구현된 다른 공유 노드 인프라와 유사한 특성입니다. This is a similar property to other well implemented shared node infrastructure including other secure CNI implementations.
• ztunnel은 클러스터 전체 또는 노드별 자격 증명을 사용하지 않습니다. 이러한 자격 증명은 유출될 경우 복잡한 보조 권한 부여 메커니즘을 구현하지 않는 한 클러스터의 모든 애플리케이션 트래픽을 즉시 침해할 수 있습니다. The ztunnel does not use cluster-wide or per-node credentials which, if stolen, could immediately compromise all application traffic in the cluster unless a complex secondary authorization mechanism is also implemented.
• 사이드카 모델과 비교해 보면, ztunnel은 공유되며, 침해 시 노드에서 실행 중인 애플리케이션의 ID가 유출될 수 있음을 알 수 있습니다. If we compare this to the sidecar model, we notice that the ztunnel is shared and compromise could result in exfiltration of the identities of the applications running on the node.
• 그러나 이 구성 요소에서 CVE가 발생할 가능성은 Istio 사이드카보다 낮습니다. 공격 표면이 크게 줄어들기 때문입니다(L4 처리만 가능). However, the likelihood of a CVE in this component is lower than that of an Istio sidecar since the attack surface is greatly reduced (only L4 handling);
• ztunnel은 L7 처리를 전혀 하지 않습니다. 또한, L7로 인해 공격 표면이 더 넓은 사이드카에서 발생하는 CVE는 침해된 특정 워크로드에만 국한되지 않습니다. the ztunnel does not do any L7 processing. In addition, a CVE in a sidecar (with a larger attack surface with L7) is not truly contained to only that particular workload which is compromised.
• 사이드카에서 발생하는 심각한 CVE는 메시의 모든 워크로드에도 반복될 가능성이 높습니다. Any serious CVE in a sidecar is likely repeatable to any of the workloads in the mesh as well.

 

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

• 궁극적으로 Istio는 유지 관리가 필수인 핵심 인프라입니다. Ultimately, Istio is a critical piece of infrastructure that must be maintained.
• Istio는 애플리케이션을 대신하여 제로 트러스트 네트워크 보안의 핵심 원칙 중 일부를 구현하는 데 있어 신뢰받고 있으며, 일정에 따라 또는 필요에 따라 패치를 배포하는 것이 매우 중요합니다. Istio is trusted to implement some of the tenets of zero-trust network security on behalf of applications and rolling out patches on a schedule or on demand is paramount.
• 플랫폼 팀은 애플리케이션과는 상당히 다른 예측 가능한 패치 또는 유지 관리 주기를 갖는 경우가 많습니다. Platform teams often have predictable patching or maintenance cycles which is quite different from that of applications.
• 애플리케이션은 새로운 기능이 필요할 때, 그리고 일반적으로 프로젝트의 일부로 업데이트될 가능성이 높습니다. Applications likely get updated when new capabilities and functionality are required and usually part of a project.
• 애플리케이션 변경, 업그레이드, 프레임워크 및 라이브러리 패치에 대한 이러한 접근 방식은 예측이 매우 어렵고, 시간이 많이 소요되며, 안전한 보안 관행에 적합하지 않습니다. This approach to application changes, upgrades, framework and library patches, is highly unpredictable, allows a lot of time to pass, and does not lend itself to safe security practices.
• 따라서 이러한 보안 기능을 플랫폼의 일부로 유지하고 애플리케이션과 분리하는 것이 더 나은 보안 태세를 구축하는 데 도움이 될 것입니다. Therefore, keeping these security features part of the platform and separate from the applications is likely to lead to a better security posture.
• 공지 블로그에서 확인했듯이, 사이드카 운영은 사이드카의 침습적 특성(사이드카 주입/배포 설명자 변경, 애플리케이션 재시작, 컨테이너 간 경합 조건 등)으로 인해 더욱 복잡해질 수 있습니다. As we’ve identified in the announcement blog, operating sidecars can be more complex because of the invasive nature of them (injecting the sidecar/changing the deployment descriptors, restarting the applications, race conditions between containers, etc).
• 사이드카를 사용하는 워크로드를 업그레이드하려면 애플리케이션이 다운되지 않도록 조정해야 할 수 있는 롤링 재시작과 계획 수립이 조금 더 필요합니다. Upgrades to workloads with sidecars require a bit more planning and rolling restarts that may need to be coordinated to not bring down the application.
• 앰비언트 모드에서는 ztunnel 업그레이드를 일반적인 노드 패치 또는 업그레이드와 동시에 진행할 수 있으며, 웨이포인트 프록시는 네트워크의 일부이므로 필요에 따라 애플리케이션에 완전히 투명하게 업그레이드할 수 있습니다. With ambient mode, upgrades to the ztunnel can coincide with any normal node patching or upgrades, while the waypoint proxies are part of the network and can be upgraded completely transparently to the applications as needed.

 

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

• HTTP 1/2/3, gRPC, 헤더 구문 분석, 재시도 구현, 데이터 플레인에서 Wasm 및/또는 Lua를 사용한 커스터마이징과 같은 L7 프로토콜을 지원하는 것은 L4를 지원하는 것보다 훨씬 더 복잡합니다. Supporting L7 protocols such as HTTP 1/2/3, gRPC, parsing headers, implementing retries, customizations with Wasm and/or Lua in the data plane is significantly more complex than supporting L4.
• 이러한 동작을 구현하기 위한 코드(루아나 와즘과 같은 사용자 지정 코드 포함)가 훨씬 더 많으며, 이러한 복잡성은 취약점의 잠재력으로 이어질 수 있습니다. There is a lot more code to implement these behaviors (including user-custom code for things like Lua and Wasm) and this complexity can lead to the potential for vulnerabilities.
• 이로 인해 CVE는 이러한 L7 기능 영역에서 발견될 가능성이 더 높습니다.
  Because of this, CVEs have a higher chance of being discovered in these areas of L7 functionality

각 네임스페이스/ID에는 자체 L7 프록시가 있습니다. 다중 테넌트 프록시는 없습니다.

• 앰비언트 모드에서는 여러 ID에 걸쳐 프록시에서 L7 처리를 공유하지 않습니다. In ambient mode, we do not share L7 processing in a proxy across multiple identities.
• 각 신원(쿠버네티스의 서비스 계정)은 사이드카에서 사용하는 모델과 **매우 유사한 전용 L7 프록시(웨이포인트 프록시)**를 가지고 있습니다. Each identity (service account in Kubernetes) has its own dedicated L7 proxy (waypoint proxy) which is very similar to the model we use with sidecars.
• 여러 신원과 그들의 독특한 복잡한 정책 및 맞춤화를 동시에 찾으려는 시도는 공유 자원에 많은 변동성을 추가하여 기껏해야 불공정한 비용 귀속을 초래하고 최악의 경우 완전한 대리 타협을 초래합니다. Trying to co-locate multiple identities and their distinct complex policies and customizations adds a lot of variability to a shared resource which leads to unfair cost attribution at best and total proxy compromise at worst.

 

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

• 일부 사람들은 사이드카 모델과 알려진 보안 경계에 익숙하며 그 모델을 유지하기를 원한다는 것을 이해합니다. We understand that some folks are comfortable with the sidecar model and their known security boundaries and wish to stay on that model.
• Istio를 사용하면 사이드카는 메시의 일류 시민이며 플랫폼 소유자는 사이드카를 계속 사용할 수 있습니다. With Istio, sidecars are a first-class citizen to the mesh and platform owners have the choice to continue using them.
• 플랫폼 소유자가 사이드카 모드와 앰비언트 모드를 모두 지원하고자 하는 경우, 지원할 수 있습니다. If a platform owner wants to support both sidecar and ambient modes, they can.
• 주변 데이터 플레인이 있는 워크로드는 사이드카가 배치된 워크로드와 기본적으로 통신할 수 있습니다. A workload with the ambient data plane can natively communicate with workloads that have a sidecar deployed.
• 사람들이 앰비언트 모드의 보안 자세를 더 잘 이해하기 때문에, 특정 최적화를 위해 사이드카가 사용되는 Istio의 선호되는 데이터 플레인 모드가 될 것이라고 확신합니다. As folks better understand the security posture of ambient mode, we are confident that it will be the preferred data plane mode of Istio, with sidecars used for specific optimizations.

 

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이 포드 네트워크 네임스페이스 내부에서 리디렉션 소켓을 시작하면서 포드 외부에서 실행**

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

• Istio는 서비스 메시이며, 엄격한 정의에 따르면 모든 서비스 메시는 CNI 구현이 아닙니다. 서비스 메시는 모든 Kubernetes 클러스터에 사양을 준수하는 기본 CNI 구현이 있어야 하며, 그 위에 있어야 합니다. Istio is a service mesh, and all service meshes by strict definition are not CNI implementations - service meshes require a spec-compliant, primary CNI implementation to be present in every Kubernetes cluster, and rest on top of that.
• 이 기본 CNI 구현은 클라우드 제공업체(AKS, GKE, EKS 모두 자체 배송) 또는 Calico 및 Cilium과 같은 타사 CNI 구현에 의해 제공될 수 있습니다. 일부 서비스 메시는 자체 기본 CNI 구현과 함께 번들로 배송될 수 있으며, 이를 위해 명시적으로 필요합니다.
• 기본적으로 mTLS를 사용하여 안전한 포드 트래픽과 같은 작업을 수행하고 서비스 메시 계층에서 고급 인증 및 권한 부여 정책을 적용하기 전에, 기능적 CNI 구현이 가능한 Kubernetes 클러스터가 있어야 하며, 기본 네트워킹 경로가 설정되어 패킷이 클러스터 내에서 한 포드에서 다른 포드(그리고 한 노드에서 다른 노드로)로 이동할 수 있도록 해야 합니다.
• 일부 서비스 메시는 자체적으로 기본 CNI 구현을 배송하고 필요로 할 수도 있지만, 때로는 동일한 클러스터 내에서 두 개의 기본 CNI 구현을 병렬로 실행할 수도 있습니다(예: 클라우드 제공업체에서 배송하는 구현과 타사 구현). 실제로는 각 CNI 구현이 내부적으로 사용할 수 있는 매우 다양한 메커니즘으로 인해 호환성 문제, 이상한 동작, 축소된 특징 세트 및 일부 비호환성 문제가 발생합니다.
• 이를 방지하기 위해 Istio 프로젝트는 배송을 하지 않거나 자체 기본 CNI 구현을 요구하지 않거나, 심지어 "선호되는" CNI 구현을 요구하지 않기로 결정했습니다. 대신 가능한 한 가장 넓은 CNI 구현 생태계와의 CNI 체인을 지원하고, 관리형 오퍼링과의 최대 호환성, 공급업체 간 지원, 더 넓은 CNCF 생태계와의 구성 가능성을 보장하기로 했습니다. To avoid this, the Istio project has chosen not to ship or require our own primary CNI implementation, or even require a “preferred” CNI implementation - instead choosing to support CNI chaining with the widest possible ecosystem of CNI implementations, and ensuring maximum compatibility with managed offerings, cross-vendor support, and composability with the broader CNCF ecosystem.

 

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

• istio-cni 구성 요소는 사이드카 데이터 플레인 모드에서 선택적인 구성 요소로, 일반적으로 포드를 메시에 배포하는 사용자에게 NET_ADMIN 및 NET_RAW 기능의 요구 사항을 제거하는 데 사용됩니다. istio-cni는 앰비언트 데이터 플레인 모드에서 필수 구성 요소입니다. istio-cni 구성 요소는 기본 CNI 구현이 아니며, 클러스터에 이미 존재하는 기본 CNI 구현을 확장하는 노드 에이전트입니다. The istio-cni component is an optional component in the sidecar data plane mode, commonly used to remove the requirement for the NET_ADMIN and NET_RAW capabilities for users deploying pods into the mesh. istio-cni is a required component in the ambient data plane mode. The istio-cni component is not a primary CNI implementation, it is a node agent that extends whatever primary CNI implementation is already present in the cluster.
• 포드가 앰비언트 메시에 추가될 때마다 istio-CNI 구성 요소는 노드 수준의 네트워크 네임스페이스를 통해 포드 노드에서 실행되는 ztunnel과 포드 간의 모든 들어오고 나가는 트래픽에 대한 트래픽 리디렉션을 구성합니다. 사이드카 메커니즘과 앰비언트 알파 메커니즘의 주요 차이점은 후자의 경우 포드 트래픽이 포드 네트워크 네임스페이스에서 벗어나 공동 위치한 ztunnel 포드 네트워크 네임스페이스로 리디렉션되었다는 점입니다. 이는 이를 달성하기 위한 대부분의 트래픽 리디렉션 규칙이 구현된 곳입니다. Whenever pods are added to an ambient mesh, the istio-cni component configures traffic redirection for all incoming and outgoing traffic between the pods and the ztunnel running on the pod’s node, via the node-level network namespace. The key difference between the sidecar mechanism and the ambient alpha mechanism is that in the latter, pod traffic was redirected out of the pod network namespace, and into the co-located ztunnel pod network namespace - necessarily passing through the host network namespace on the way, which is where the bulk of the traffic redirection rules to achieve this were implemented.
• 여러 실제 쿠버네티스 환경에서 자체 기본 CNI를 사용하여 더 광범위하게 테스트한 결과, 알파 개발 당시와 마찬가지로 호스트 네트워크 네임스페이스에서 포드 트래픽을 캡처하고 리디렉션하는 것이 우리의 요구 사항을 충족하지 못한다는 것이 분명해졌습니다. 이러한 다양한 환경에서 일반적인 방식으로 목표를 달성하는 것은 이 접근 방식으로는 불가능했습니다. As we tested more broadly in multiple real-world Kubernetes environments, which have their own default CNI, it became clear that capturing and redirecting pod traffic in the host network namespace, as we were during alpha development, was not going to meet our requirements. Achieving our goals in a generic manner across these diverse environments was simply not feasible with this approach.
• 호스트 네트워크 네임스페이스에서 트래픽 리디렉션의 근본적인 문제는 클러스터의 기본 CNI 구현이 트래픽 라우팅/네트워킹 규칙을 구성해야 하는 바로 그 지점에 있다는 것입니다. 이로 인해 가장 중요한 것은 피할 수 없는 충돌이 발생했다는 점입니다: The fundamental problem with redirecting traffic in the host network namespace is that this is precisely the same spot where the cluster’s primary CNI implementation must configure traffic routing/networking rules. This created inevitable conflicts, most critically:
  • 기본 CNI 구현의 기본 호스트 수준 네트워킹 구성은 Istio의 CNI 확장에서 호스트 수준의 주변 네트워킹 구성을 방해하여 트래픽 중단 및 기타 충돌을 일으킬 수 있습니다. The primary CNI implementation’s basic host-level networking configuration could interfere with the host-level ambient networking configuration from Istio’s CNI extension, causing traffic disruption and other conflicts.
  • 사용자가 기본 CNI 구현에 의해 네트워크 정책을 시행하도록 배포한 경우, Istio CNI 확장이 배포될 때 네트워크 정책이 시행되지 않을 수 있습니다(기본 CNI 구현이 네트워크 정책을 시행하는 방식에 따라 달라질 수 있습니다) If users deployed a network policy to be enforced by the primary CNI implementation, the network policy might not be enforced when the Istio CNI extension is deployed (depending on how the primary CNI implementation enforces NetworkPolicy)
• 일부 주요 CNI 구현을 위해 사례별로 이 문제를 설계할 수는 있지만, 보편적인 CNI 지원에 지속 가능하게 접근할 수는 없습니다. 우리는 eBPF를 고려했지만, 현재로서는 임의의 eBPF 프로그램을 안전하게 체인/확장할 수 있는 표준화된 방법이 없기 때문에 eBPF 구현이 동일한 기본 문제를 가질 수 있다는 것을 깨달았습니다. 그리고 이 접근 방식으로는 여전히 비 eBPF CNI를 지원하는 데 어려움을 겪을 가능성이 있습니다. While we could design around this on a case-by-case basis for some primary CNI implementations, we could not sustainably approach universal CNI support. We considered eBPF, but realized any eBPF implementation would have the same basic problem, as there is no standardized way to safely chain/extend arbitrary eBPF programs at this time, and we would still potentially have a hard time supporting non-eBPF CNIs with this approach.

 

Addressing the challenges 과제 해결!

• 새로운 해결책이 필요했습니다. 노드의 네트워크 네임스페이스에서 임의의 종류의 리디렉션을 수행하면 호환성 요구 사항을 위반하지 않는 한 피할 수 없는 충돌이 발생할 수 있었습니다. A new solution was necessary - doing redirection of any sort in the node’s network namespace would create unavoidable conflicts, unless we compromised our compatibility requirements.
• 사이드카 모드에서는 사이드카와 애플리케이션 포드 간의 트래픽 리디렉션을 구성하는 것이 간단합니다. 이 둘은 모두 포드의 네트워크 네임스페이스 내에서 작동하기 때문입니다. 이로 인해 사이드카를 모방하고 애플리케이션 포드의 네트워크 네임스페이스에서 리디렉션을 구성하는 것은 어떨까요? In sidecar mode, it is trivial to configure traffic redirection between the sidecar and application pod, as both operate within the pod’s network namespace. This led to a light-bulb moment: why not mimic sidecars, and configure the redirection in the application pod’s network namespace?
• "단순한" 생각처럼 들리지만, 이것이 어떻게 가능할까요? 환경의 중요한 요구 사항 중 하나는 ztunnel이 Istio 시스템 네임스페이스에서 애플리케이션 포드 외부에서 실행되어야 한다는 것입니다. 몇 가지 연구 끝에, 우리는 하나의 네트워크 네임스페이스에서 실행되는 Linux 프로세스가 다른 네트워크 네임스페이스 내에서 리스닝 소켓을 생성하고 소유할 수 있다는 것을 발견했습니다. 이것이 Linux 소켓 API의 기본 기능입니다. 그러나 이를 작동시키고 모든 포드 라이프사이클 시나리오를 다루기 위해서는 ztunnel과 Istio-CNI 노드 에이전트에 아키텍처를 변경해야 했습니다. While this sounds like a “simple” thought, how would this even be possible? A critical requirement of ambient is that ztunnel must run outside application pods, in the Istio system namespace. After some research, we discovered a Linux process running in one network namespace could create and own listening sockets within another network namespace. This is a basic capability of the Linux socket API. However, to make this work operationally and cover all pod lifecycle scenarios, we had to make architectural changes to the ztunnel as well as to the istio-cni node agent.
• 프로토타입을 제작하고 이 새로운 접근 방식이 우리가 접근할 수 있는 모든 Kubernetes 플랫폼에서 작동하는지 충분히 검증한 후, 우리는 이 작업에 대한 신뢰를 쌓고 모든 주요 클라우드 제공업체 및 CNI와 호환되도록 처음부터 구축된 워크로드 포드와 ztunnel 노드 프록시 구성 요소 간의 인팟 트래픽 리디렉션 메커니즘인 이 새로운 트래픽 리디렉션 모델의 업스트림에 기여하기로 결정했습니다. After prototyping and sufficiently validating that this novel approach does work for all the Kubernetes platforms we have access to, we built confidence in the work and decided to contribute to upstream this new traffic redirection model, an in-Pod traffic redirection mechanism between workload pods and the ztunnel node proxy component that has been built from the ground up to be highly compatible with all major cloud providers and CNIs.
• 핵심 혁신은 포드의 네트워크 네임스페이스를 공동 위치한 ztunnel에 제공하여 ztunnel이 포드 네트워크 네임스페이스 내부에서 리디렉션 소켓을 시작하면서 포드 외부에서 실행할 수 있도록 하는 것입니다. 이 접근 방식을 통해 ztunnel과 애플리케이션 포드 간의 트래픽 리디렉션은 오늘날 사이드카 및 애플리케이션 포드와 매우 유사한 방식으로 이루어지며, 노드 네트워크 네임스페이스에서 작동하는 모든 Kubernetes 기본 CNI에서는 엄격히 보이지 않습니다. 네트워크 정책은 CNI가 eBPF를 사용하든 iptables를 사용하든 충돌 없이 모든 Kubernetes 기본 CNI에 의해 계속 시행되고 관리될 수 있습니다. The key innovation is to deliver the pod’s network namespace to the co-located ztunnel so that ztunnel can start its redirection sockets inside the pod’s network namespace, while still running outside the pod. With this approach, the traffic redirection between ztunnel and application pods happens in a way that’s very similar to sidecars and application pods today and is strictly invisible to any Kubernetes primary CNI operating in the node network namespace. Network policy can continue to be enforced and managed by any Kubernetes primary CNI, regardless of whether the CNI uses eBPF or iptables, without any conflict.

 

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 플러그인을 가능한 한 빨리 호출하기 때문에, 이를 통해 초기 컨테이너와 같은 것에 의존하지 않고 시작 중에 트래픽이 빠져나가지 않도록 충분히 일찍 트래픽 리다이렉션을 설정할 수 있습니다. If a new pod is started that should be added to the ambient mesh, a CNI plugin (as installed and managed by the istio-cni agent) is triggered by the CRI. This plugin is used to push a new pod event to the node’s istio-cni agent, and block pod startup until the agent successfully configures redirection. Since CNI plugins are invoked by the CRI as early as possible in the Kubernetes pod creation process, this ensures that we can establish traffic redirection early enough to prevent traffic escaping during startup, without relying on things like init containers.
  • 이미 실행 중인 포드가 앰비언트 메시에 추가되면 새로운 포드 이벤트가 트리거됩니다. istio-CNI 노드 에이전트의 Kubernetes API 감시기가 이를 감지하면 리디렉션도 동일한 방식으로 구성됩니다. If an already-running pod becomes added to the ambient mesh, a new pod event is triggered. The istio-cni node agent’s Kubernetes API watcher detects this, and redirection is configured in the same manner.
• istio-cni 노드 에이전트는 포드의 네트워크 네임스페이스에 들어가 포드 네트워크 네임스페이스 내부에 네트워크 리디렉션 규칙을 설정하여 포드에 들어오고 나가는 패킷을 가로채서 잘 알려진 포트(15008, 15006, 15001)에서 노드 로컬 ztunnel 프록시 인스턴스로 투명하게 리디렉션합니다. 그런 다음 istio-cni 노드 에이전트는 유닉스 도메인 소켓을 통해 노드 ztunnel에 포드의 네트워크 네임스페이스(15008, 15006, 15001) 내부에 로컬 프록시 리스닝 포트를 설정해야 한다고 알리고, ztunnel에 포드의 네트워크 네임스페이스를 나타내는 저수준 리눅스 파일 설명자를 제공합니다. The istio-cni node agent then informs the node ztunnel over a Unix domain socket that it should establish local proxy listening ports inside the pod’s network namespace, (on 15008, 15006, and 15001), and provides ztunnel with a low-level Linux file descriptor representing the pod’s network namespace.
• 일반적으로 소켓은 리눅스 네트워크 네임스페이스 내에서 실제로 실행되는 프로세스에 의해 생성되지만, 생성 시점에 대상 네트워크 네임스페이스가 알려져 있다고 가정하면 리눅스의 저수준 소켓 API를 활용하여 한 네트워크 네임스페이스에서 실행되는 프로세스가 다른 네트워크 네임스페이스에서 리스닝 소켓을 생성할 수 있도록 하는 것이 완벽하게 가능합니다. While typically sockets are created within a Linux network namespace by the process actually running inside that network namespace, it is perfectly possible to leverage Linux’s low-level socket API to allow a process running in one network namespace to create listening sockets in another network namespace, assuming the target network namespace is known at creation time.
• node-local ztunne은 내부적으로 새로운 프록시 인스턴스와 리스닝 포트 세트를 스핀업하여 새로 추가된 포드 전용으로 만듭니다. The node-local ztunnel internally spins up a new proxy instance and listen port set, dedicated to the newly-added pod.
• 인팟 리디렉션 규칙이 적용되고 ztunnel이 청취 포트를 설정하면 이전과 마찬가지로 네트워크에 포드가 추가되고 노드-로컬 ztunnel을 통해 트래픽이 흐르기 시작합니다. Once the in-Pod redirect rules are in place and the ztunnel has established the listen ports, the pod is added in the mesh and traffic begins flowing thru the node-local ztunnel, as before.

 

다음은 주변 메시에 추가되는 애플리케이션 포드의 흐름을 보여주는 기본 다이어그램입니다: Here’s a basic diagram showing the flow of application pod being added to the ambient mesh

• 포드가 앰비언트 메시에 성공적으로 추가되면, 메시의 포드 간 트래픽은 Istio와 마찬가지로 기본적으로 mTLS로 완전히 암호화됩니다. Once the pod is successfully added to the ambient mesh, traffic to and from pods in the mesh will be fully encrypted with mTLS by default, as always with Istio.
• 이제 트래픽은 암호화된 트래픽으로 포드 네트워크 네임스페이스에 들어오고 나갈 것입니다. 이는 주변 메시의 모든 포드가 메쉬 정책을 적용하고 트래픽을 안전하게 암호화할 수 있는 기능을 가지고 있는 것처럼 보일 것입니다. 하지만 포드에서 실행 중인 사용자 애플리케이션은 이러한 기능을 인식하지 못합니다. Traffic will now enter and leave the pod network namespace as encrypted traffic - it will look like every pod in the ambient mesh has the ability to enforce mesh policy and securely encrypt traffic, even though the user application running in the pod has no awareness of either.
• 다음은 새 모델에서 주변 메시의 포드 간 암호화된 트래픽이 어떻게 흐르는지 설명하는 다이어그램입니다: Here’s a diagram to illustrate how encrypted traffic flows between pods in the ambient mesh in the new model:

그리고 이전과 마찬가지로 메쉬 외부에서 암호화되지 않은 평문 트래픽은 필요한 경우에도 처리하고 정책을 시행할 수 있습니다: And, as before, unencrypted plaintext traffic from outside the mesh can still be handled and policy enforced, for use cases where that is necessary:

 

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

 

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