Deploy Wasm Filters to Alibaba Cloud Service Mesh with ORAS and Envoy

Overview

This guide shows how to push a WebAssembly (Wasm) module to an OCI‑compatible registry using the ORAS client, enable Wasm support in Alibaba Cloud Service Mesh (ASM), and declaratively deploy the module as an Envoy filter via the custom resource ASMFilterDeployment. The ASM controller pulls the Wasm image, mounts it on the node, and generates an IstioEnvoyFilter that inserts the Wasm filter into the Envoy proxy.

Envoy filter basics

Envoy implements a filter‑chain architecture. Filters are categorized as:

Listener Filter – operates on L4 connection metadata.

Network Filter – processes raw L4 data.

HTTP Filter – handles L7 HTTP requests and responses.

In the Istio Bookinfo productpage example, the listener on port 9080 applies a chain that includes:

envoy.filters.network.metadata_exchange

envoy.http_connection_manager

with sub‑filters such as envoy.filters.http.wasm/envoy.wasm.metadata_exchange, Istio_authn, envoy.filters.http.cors, envoy.filters.http.fault, and custom Wasm filters.

Configuration can be inspected with:

kubectl exec -it <productpage-pod> -c istio-proxy -- curl localhost:15000/config_dump

Extending Envoy with Wasm

Two approaches exist:

Static pre‑compilation – integrate the filter into Envoy source and rebuild a custom Envoy binary (requires C++ development and maintenance of a custom Envoy version).

Dynamic runtime loading – load filters at runtime via Wasm, providing portability, isolation, and hot‑update capability.

Pros of Wasm filters

Agility – can be loaded into a running Envoy process without restart.

Maintainability – no need to modify Envoy source.

Language diversity – filters can be written in C/C++, Rust, etc., and compiled to Wasm.

Reliability & isolation – runs in a sandboxed VM, preventing crashes from affecting Envoy.

Security – limited API surface restricts what a filter can modify.

Cons of Wasm filters

Performance is roughly 70 % of native C++ filters.

Additional memory overhead for the Wasm VM.

The Wasm ecosystem is still maturing.

Wasm runtime mechanism

Envoy‑Wasm loads and executes a Wasm filter through the following steps:

Load the Wasm binary from a local file or a remote xDS source.

Validate the module against the Proxy‑Wasm specification (https://github.com/proxy-wasm/spec).

Insert the Wasm filter into the appropriate filter chain.

Execute the filter via the Proxy‑Wasm extension controller.

Supported runtimes include WAVM (~20 MB) and V8 (~10 MB).

Managing Wasm artifacts with ORAS

ORAS (OCI Registry As Storage) stores arbitrary artifacts in OCI registries. Example commands (replace placeholders as needed):

oras login --username=<username> acree-1-registry.cn-hangzhou.cr.aliyuncs.com

oras push acree-1-registry.cn-hangzhou.cr.aliyuncs.com/<repo>/asm-test:v0.1 \
  --manifest-config runtime-config.json:application/vnd.module.wasm.config.v1+json \
  example-filter.wasm:application/vnd.module.wasm.content.layer.v1+wasm

The --manifest-config argument follows the Wasm Artifact image specification.

Alibaba Cloud Service Mesh (ASM) architecture

ASM is a fully managed, Istio‑compatible service mesh. The control plane runs as a managed service in Alibaba Cloud, while the data plane (Envoy proxies) runs in user Kubernetes clusters. ASM supports multi‑cluster, multi‑cloud deployments and provides built‑in capabilities such as OPA security, SPIFFE/SPIRE, and EnvoyFilter extensions.

Enable Wasm in ASM

aliyun servicemesh UpdateMeshFeature \
  --ServiceMeshId=<mesh-id> \
  --WebAssemblyFilterEnabled=true

Enabling this feature deploys the asmwasm-controller DaemonSet, which watches a ConfigMap containing Wasm image references, pulls the images via ORAS, and mounts them on the node using a HostPath volume.

Deploy a Wasm filter with ASMFilterDeployment

Create a custom resource that references the Wasm image and specifies the target workload:

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMFilterDeployment
metadata:
  name: details-v1-wasmfiltersample
spec:
  workload:
    kind: Deployment
    labels:
      app: details
      version: v1
  filter:
    parameters: '{"name":"hello","value":"hello details"}'
    image: 'acree-1-registry.cn-hangzhou.cr.aliyuncs.com/asm/asm-test:v0.1'
    imagePullOptions:
      pullSecret: 'asmwasm-cache'
    rootID: 'my_root_id'
    id: 'details-v1-wasmfiltersample.default'

The controller generates an IstioEnvoyFilter that inserts the Wasm filter before envoy.router using an INSERT_BEFORE patch.

Update the workload deployment to expose a host‑path volume for the Wasm files:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  ...
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/userVolume: '[{"name":"wasmfilters-dir","hostPath":{"path":"/var/local/lib/wasm-filters"}}]'
        sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/lib/wasm-filters","name":"wasmfilters-dir"}]'

Verification

Send a request from the productpage pod and check the response headers for the filter’s addition:

kubectl exec -ti deploy/productpage-v1 -c istio-proxy -- curl -v http://details:9080/details/123

The response should contain a header such as resp-header-demo: added by our filter.

Development and deployment workflow

Development phase: Build a Wasm binary with the appropriate SDK (e.g., Rust or C++), then push it to an OCI registry using ORAS.

Deployment phase: Enable Wasm support in ASM, create an ASMFilterDeployment resource, let the controller pull the image, mount the Wasm file on the node, and verify that the Envoy proxy loads the filter.