Wasm Plugin

Order of execution (as part of Envoy’s filter chain) is determined by phase and priority settings, allowing the configuration of complex interactions between user-supplied WasmPlugins and Istio’s internal filters.

Examples:

AuthN Filter deployed to ingress-gateway that implements an OpenID flow and populates the header with a JWT to be consumed by Istio AuthN.

This is the same as the last example, but using an OCI image.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: openid-connect
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: oci://private-registry:5000/openid-connect/openid:latest
  imagePullPolicy: IfNotPresent
  imagePullSecret: private-registry-pull-secret
  phase: AUTHN
    openid_server: authn
    openid_realm: ingress

This is the same as the last example, but using VmConfig to configure environment variables in the VM.

This is also the same as the last example, but the Wasm module is pulled via https and updated for each time when this plugin resource is changed.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: openid-connect
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: https://private-bucket/filters/openid.wasm
  imagePullPolicy: Always
  phase: AUTHN
  pluginConfig:
    openid_server: authn
    openid_realm: ingress
  vmConfig:
    env:
      valueFrom: HOST
    - name: TRUST_DOMAIN
      value: "cluster.local"

And a more complex example that deploys three WasmPlugins and orders them using phase and priority. The (hypothetical) setup is that the openid-connect filter performs an OpenID Connect flow to authenticate the user, writing a signed JWT into the Authorization header of the request, which can be verified by the Istio authn plugin. Then, the plugin kicks in, passing the JWT to a policy server, which in turn responds with a signed token that contains information about which files and functions of the system are available to the user that was previously authenticated. The acl-check filter writes this token to a header. Finally, the check-header filter verifies the token in that header and makes sure that the token’s contents (the permitted ‘function’) matches its plugin configuration.

The resulting filter chain looks like this: -> openid-connect -> istio.authn -> acl-check -> check-header -> router

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: acl-check
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: oci://private-registry:5000/acl-check/acl:latest
  imagePullPolicy: Always
  imagePullSecret: private-registry-pull-secret
  phase: AUTHZ
  priority: 1000
  pluginConfig:
    acl_server: some_server

WasmPlugins provides a mechanism to extend the functionality provided by the Istio proxy through WebAssembly filters.

VmConfig

Configuration for a Wasm VM. more details can be found here.

Field	Type	Description	Required
`env`		Specifies environment variables to be injected to this VM. Note that if a key does not exist, it will be ignored.	No

PluginPhase

The phase in the filter chain where the plugin will be injected.

Name	Description
`UNSPECIFIED_PHASE`	Control plane decides where to insert the plugin. This will generally be at the end of the filter chain, right before the Router. Do not specify `PluginPhase` if the plugin is independent of others.
`AUTHN`	Insert plugin before Istio authentication filters.
`AUTHZ`	Insert plugin before Istio authorization filters and after Istio authentication filters.
`STATS`	Insert plugin before Istio stats filters and after Istio authorization filters.

The pull behaviour to be applied when fetching a Wam module, mirroring K8s behaviour.

EnvValueSource

Name	Description
`INLINE`	Explicitly given key-value pairs to be injected to this VM
	Istio-proxy’s environment variables exposed to this VM.