Extensibility

    WebAssembly sandbox goals:

    • Efficiency - An extension adds low latency, CPU, and memory overhead.
    • Function - An extension can enforce policy, collect telemetry, and perform payload mutations.
    • Configuration - The plugins are configured using an API that is consistent with other Istio APIs. An extension can be configured dynamically.
    • Operator - An extension can be canaried and deployed as log-only, fail-open or fail-close.
    • Extension developer - The plugin can be written in several programming languages.

    This video talk is an introduction about architecture of WebAssembly integration.

    Istio extensions (Proxy-Wasm plugins) have several components:

    • Filter Service Provider Interface (SPI) for building Proxy-Wasm plugins for filters.
    • Sandbox V8 Wasm Runtime embedded in Envoy.
    • Host APIs for headers, trailers and metadata.
    • Stats and Logging APIs for metrics and monitoring.

    An example C++ Proxy-Wasm plugin for a filter can be found here. You can follow to implement a Wasm extension with C++.

    Istio and Envoy WebAssembly Extensibility, One Year On

    An update on Envoy and Istio’s WebAssembly-based extensibility effort.

    Declarative WebAssembly deployment for Istio

    Configuring Wasm extensions for Envoy and Istio declaratively.

    The future of Istio extensibility using WASM.