Using Extensions

WebAssembly Extension support is in Tech Preview in Maistra 2.0, therefore any API or specs mentioned here are not final and might change before it is Generally Available

Enabling WebAssembly Extension support

Support for WebAssembly Extensions to Maistra is currently in Tech Preview, so it needs to be explicitly enabled for your control plane. This can be done by setting spec.techPreview.wasmExtensions.enabled in your SMCPv2 to true. Here’s an example:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: openid-connect
  namespace: istio-system
spec:
  techPreview:
    wasmExtensions:
      enabled: true

Deploying Extensions

Maistra Extensions can be enabled using the ServiceMeshExtension resource. You can see an example resource below.

apiVersion: maistra.io/v1alpha1
kind: ServiceMeshExtension
metadata:
  name: header-append
  # Deploy to the Control Plane Namespace to enable globally, or to another Namespace to only enable locally
  namespace: istio-system
spec:
  # specify a set of labels to match specific workloads, or leave empty to match all workloads
  workloadSelector:
    labels:
      app: httpbin
  # the configuration to be passed to the extension. In this case, the value of the header that
  # is added to the requests
  config: test
  # the container image containing the extension
  image: quay.io/maistra-dev/header-append-filter:latest
  # where in the filter chain this extension should be injected
  # one of: PreAuthN, PostAuthN, PreAuthZ, PostAuthZ, PreStats, PostStats
  phase: PostAuthZ
  # priority is used for ordering of extensions within the same phase. higher priority means
  # earlier execution
  priority: 100

Field Reference

metadata.namespace

The metadata.namespace of a ServiceMeshExtension source has a special semantic: if it equals the Control Plane Namespace, the Extension will be applied to all workloads in the Service Mesh that match its workloadSelector. When deployed to any other Mesh Namespace, it will only be applied to workloads in that same Namespace.

spec.workloadSelector

The spec.workloadSelector field has the same semantic as the spec.selector field of the Istio Gateway resource. It will match a workload based on its Pod labels. If no workloadSelector is specified, the Extension will be applied to all workloads in the namespace.

spec.config

This is a pass-through string field that will be handed over to the Extension, so syntax and semantics are dependant on the Extension you’re deploying.

spec.phase

This field defaults to the value set in the manifest.yaml of the Extension, but can be overwritten by the user.

spec.image

A container image URI pointing to the image that holds the Extension.

spec.phase

The phase determines where in the filter chain the Extension is injected, in relation to existing Istio functionality like Authentication, Authorization and metrics generation.

Valid values are: PreAuthN, PostAuthN, PreAuthZ, PostAuthZ, PreStats, PostStats

This field defaults to the value set in the manifest.yaml of the Extension, but can be overwritten by the user.

spec.priority

If multiple Extensions with the same spec.phase are applied to the same workload instance, the spec.priority determines the ordering of execution. Extensions with higher priority will be executed first. This allows for inter-dependant Extensions.

This field defaults to the value set in the manifest.yaml of the Extension, but can be overwritten by the user.