TSB configuration

This document will describe how the WASM extensions are defined in TSB and how are they assigned to the components on the hierarchy.

WASM in TSB

In order to control the extensions allowed in the mesh, avoid security leakages and ease the process of extension upgrades, TSB has a WASM extension catalog, where an administrator will register all the extensions that will be available to be used in the different components. This catalog will contain the description, image and execution properties for each extension. When a new version of the extension is available, changing the content of the WASM extension catalog record will propagate the update to all the assignments for that extension.

These extensions are packaged as OCI images, containing the WASM file, and deployed in a container images registry from where Istio will pull and extract the contents. The benefit of using OCI images in order to deliver the WASM extensions is that the security is already implemented and standardized with the same approach as with the rest of workloads images.

Extensions can be allowed to be used globally or restricted in a set of Tenants, and this will affect where the extension can be attached.

After having the extensions created in the catalog they become enabled and available to be used in the attachments for the TSB components in the same organization hierarchy. And their properties will become the configuration for the attachments. Components that can be configured with WASM extensions are : Organization, Tenant, Workspace, SecurityGroup, Gateway, IngressGateway, EgressGateway and Tier1Gateway.

Using WASM extensions in the TSB resources

WASM extensions can be specified in the defaultSecuritySettings property of OrganizationSetting, TenantSetting, WorkspaceSetting , and in the spec of SecuritySettings, and it will affect all the workloads belonging to those resources in the hierarchy. Also, these attachments can be specified in the IngressGateway, EgressGateway and Tier1Gateway extension property, and only the workloads linked to these gateways will be affected by the WASM extension. TSB will use workload selectors to specify the workloads.

  extension:
    - fqn: "organizations/tetrate/extensions/wasm-add-header"
      config:
        header: x-wasm-header
        value: igw-tsb

Another way of using WASM extensions in TSB is using the Istio direct mode, creating an IstioInternalGroup and a WasmPlugin with references to that group. For example:

apiVersion: istiointernal.tsb.tetrate.io/v2
kind: Group
metadata:
  organization: tetrate
  tenant: mytenant
  workspace: myworkspace
  name: internal-group
spec:
  namespaceSelector:
    names:
      - "*/httpbin"

And then creating directly the Istio WasmPlugin:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: demo-wasm-add-header
  namespace: app-namespace
  annotations:
    tsb.tetrate.io/organization: tetrate
    tsb.tetrate.io/tenant: mytenant
    tsb.tetrate.io/workspace: myworkspace
    tsb.tetrate.io/istioInternalGroup: internal-group
spec:
  selector:
    matchLabels:
      app: httpbin
  url: oci://docker.io/tetrate/xcp-wasm-e2e:0.3
  imagePullPolicy: IfNotPresent
  pluginConfig:
    header: x-wasm-header
    value: xcp