WASM Workloads on Kubernetes: runwasi, Spin, and the Threat Model Shift from OCI Containers

Problem

WebAssembly workloads now run on Kubernetes the same way containers do: a Pod manifest, an OCI image, scheduling by the kubelet. The mechanism underneath is different — runwasi (a containerd shim that hosts a WASM runtime instead of runc), or kwasm-operator for nodes that need WASM runtime injection — but from the user-API perspective the workload looks like any other Pod with a special RuntimeClass.

The threat model is not the same. WASM workloads share the kubelet, the cluster network, the secret store, and the image-distribution pipeline with regular containers, but they bring different escape surfaces, different isolation guarantees, and different supply-chain shape:

• No Linux namespaces. A WASM module is not a container; it is a sandboxed binary running inside the shim’s host process. Pod-level controls that depend on Linux namespaces (PID, IPC, mount, hostNetwork toggles) do not apply or apply differently.
• No seccomp / AppArmor surface. Pod securityContext fields that enforce kernel-level filters are no-ops for WASM modules — there are no syscalls to filter, only host-call imports.
• WASI capability handover happens at runtime mount. Filesystem access for a WASM workload is not via Pod volume mounts but via the WASI preopened_dir mechanism the shim configures.
• Resource limits use a different accounting layer. Pod resources.limits.cpu translates to runtime fuel/epoch budget, not cgroup CPU quotas.
• Image format is the same OCI registry but content is application/vnd.wasm.config.v0+json. Admission controllers that check image labels miss WASM-specific identifiers unless they look for the alternate media type.

Mainstream by 2026: Spin (Fermyon), wasmCloud, and the containerd-shim-spin are stable, included in many CNCF distributions, and run real production workloads. The hardening story has caught up but is not the same as the container hardening story.

This article covers RuntimeClass setup, Pod-level configuration that does and does not apply to WASM, NetworkPolicy at the Pod boundary, image attestation for WASM, and the operational gaps to monitor.

Target systems: Kubernetes 1.28+, containerd 1.7+ with runwasi shim (containerd-shim-spin-v2, containerd-shim-wasmtime-v1, containerd-shim-wasmedge-v1), or kwasm-operator for node-level WASM runtime installation. Compatible with Spin 2.0+, wasmCloud 1.0+, and standalone Wasmtime/WasmEdge runtimes.

Threat Model

• Adversary 1 — Untrusted WASM module: an attacker uploads a .wasm artifact and convinces the platform to schedule it. They want to escape the WASM sandbox to access the kubelet, host filesystem, or other tenants.
• Adversary 2 — Compromised WASM build pipeline: a previously-trusted module containing malicious imports introduced through dependency or supply-chain compromise.
• Adversary 3 — Cross-runtime lateral movement: an attacker has compromised a container Pod and uses its position on the cluster network to attack co-resident WASM Pods (or vice versa).
• Adversary 4 — Misconfigured RBAC granting WASM Pods cluster-API access: a WASM workload with a default ServiceAccount has the same kubernetes-api access as any other Pod and can call pods.get, list secrets in its namespace, etc.
• Access level: Adversary 1 has module-upload permission. Adversary 2 has prior trust. Adversary 3 has Pod-level execution somewhere. Adversary 4 has ServiceAccount token access from inside the WASM Pod.
• Objective: Escape the WASM sandbox to host or kubelet; pivot through the cluster network; abuse over-permissioned ServiceAccount tokens to pivot to other namespaces.
• Blast radius: Without hardening: WASM Pods inherit the cluster’s default ServiceAccount and unrestricted egress; a sandbox-escape exploit means kubelet-level access. With hardening: NetworkPolicy bounds egress, ServiceAccount tokens are disabled, runtime resource limits enforce fairness, and image attestation blocks unsigned modules at admission time.

Configuration

Step 1: Install the WASM Runtime via RuntimeClass

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime
handler: wasmtime
scheduling:
  nodeSelector:
    workload-type: wasm

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: spin
handler: spin
scheduling:
  nodeSelector:
    workload-type: wasm

The handler corresponds to the containerd shim (containerd-shim-wasmtime-v1, containerd-shim-spin-v2). Each node hosting WASM workloads needs the shim installed. Use kwasm-operator to automate:

# Deploy kwasm-operator and label nodes for WASM.
kubectl label node worker-1 kwasm.sh/kwasm-node=true
kubectl label node worker-2 kwasm.sh/kwasm-node=true

Restrict WASM nodes to known workloads using taints + tolerations so a misconfigured Pod cannot accidentally schedule on a WASM node:

# Taint the wasm-pool nodes.
kubectl taint nodes worker-1 worker-2 \
  workload-type=wasm:NoSchedule

Step 2: Pod Spec for a WASM Workload

apiVersion: v1
kind: Pod
metadata:
  name: wasm-app
  namespace: wasm-tenant-payments
  labels:
    app: payments-api
    runtime: wasm
spec:
  runtimeClassName: wasmtime
  serviceAccountName: wasm-app
  automountServiceAccountToken: false   # WASM Pods rarely need API access
  tolerations:
    - key: workload-type
      operator: Equal
      value: wasm
      effect: NoSchedule
  containers:
    - name: app
      image: ghcr.io/myorg/payments@sha256:abc123...   # OCI artifact with .wasm payload
      command: ["/payments.wasm"]
      env:
        - name: TENANT_ID
          value: payments
      ports:
        - containerPort: 8080
          name: http
      resources:
        # CPU and memory limits translate to runtime fuel and memory caps.
        # The shim consults these when configuring Wasmtime/WasmEdge.
        requests:
          cpu: 100m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 256Mi
      # Most securityContext fields are no-ops for WASM. These are the ones
      # that still apply at the shim/container level.
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: workdir
          mountPath: /work
        - name: assets
          mountPath: /assets
          readOnly: true
  volumes:
    - name: workdir
      emptyDir:
        sizeLimit: 64Mi
    - name: assets
      configMap:
        name: payments-assets

Notes that matter for security:

• automountServiceAccountToken: false is critical. WASM workloads usually do not need Kubernetes API access; defaulting to mounting a token grants whatever the namespace’s default ServiceAccount permissions allow.
• securityContext.privileged, capabilities, seccompProfile, procMount — all no-ops for WASM. Setting them does no harm but provides no protection.
• Volume mounts are translated by the shim into WASI preopened_dir calls. The path inside the volume is the path the WASM module sees.
• command points to the WASM module’s entrypoint. args are passed as WASI command-line arguments.

Step 3: NetworkPolicy at the Pod Boundary

WASM workloads sit on the same Pod network as containers. NetworkPolicy applies the same way:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: wasm-payments-egress
  namespace: wasm-tenant-payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
      runtime: wasm
  policyTypes:
    - Egress
  egress:
    # Allow outbound to the database service only.
    - to:
        - namespaceSelector:
            matchLabels:
              name: data
          podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    # Allow DNS.
    - to:
        - namespaceSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Combined with WASI socket allowlists at the runtime layer (Wasmtime / WasmEdge configuration), NetworkPolicy provides defense in depth. The runtime layer rejects connections the WASM module attempts to make to disallowed destinations; NetworkPolicy rejects them again at the Pod boundary.

Step 4: Admission Control for WASM Image Verification

WASM modules in OCI registries use a media type distinct from container images: application/vnd.wasm.config.v0+json. Admission policies that gate container images by signature need a parallel rule for WASM artifacts.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: wasm-image-must-be-signed
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: >
        !has(object.spec.runtimeClassName) ||
        !(object.spec.runtimeClassName in ["wasmtime", "spin", "wasmcloud", "wasmedge"]) ||
        object.spec.containers.all(c,
          c.image.startsWith("ghcr.io/myorg/wasm/") ||
          c.image.startsWith("registry.example.com/wasm/"))
      message: "WASM workloads must use images from the approved WASM registry namespace"

Pair with cosign-based verification via the cosigned admission controller or Kyverno’s verifyImages rule, configured with a type: oci for WASM artifacts:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-wasm-signatures
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: verify-wasm
      match:
        resources:
          kinds: [Pod]
      preconditions:
        all:
          - key: "{{request.object.spec.runtimeClassName || ''}}"
            operator: AnyIn
            value: ["wasmtime", "spin", "wasmcloud"]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/wasm/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

Step 5: Observability for WASM Workloads

Standard Kubernetes metrics (CPU, memory) reflect the shim host process, not the WASM module’s own resource use. Wire the runtime’s telemetry into Prometheus:

# Spin includes OTel telemetry for module execution.
apiVersion: spinkube.dev/v1alpha1
kind: SpinApp
metadata:
  name: payments-api
spec:
  runtime: wasmtime
  observability:
    otel:
      endpoint: http://otel-collector.observability:4317
      attributes:
        - tenant: payments
        - app: payments-api

Track:

wasm_module_invocations_total{tenant, module}    counter
wasm_module_duration_seconds                      histogram
wasm_module_traps_total{kind}                     counter
wasm_module_memory_pages                          gauge
wasm_module_fuel_consumed                         histogram

Alert on wasm_module_traps_total{kind=~"epoch_deadline|fuel_exhausted|memory_grow"} spikes — these are the abuse signals.

Step 6: Cross-Runtime Network Boundaries

A cluster running both containers and WASM Pods needs explicit policy at the boundary. A compromised container reaching a WASM Pod (or vice versa) on the same node should not be possible by default.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-runtime
  namespace: wasm-tenant-payments
spec:
  podSelector:
    matchLabels:
      runtime: wasm
  policyTypes:
    - Ingress
  ingress:
    # Only allow ingress from other WASM Pods or known gateways.
    - from:
        - podSelector:
            matchLabels:
              runtime: wasm
        - namespaceSelector:
            matchLabels:
              name: gateway-system

For node-level isolation, schedule WASM workloads on a dedicated node pool (the workload-type=wasm taint above) and apply node-level firewall rules at the host:

# On worker nodes hosting WASM workloads.
nft add rule inet filter input \
  iifname "cni0" oifname "cni0" \
  ip daddr <wasm-pod-cidr> ip saddr != <wasm-pod-cidr> drop

Expected Behaviour

Verify a WASM Pod is correctly using the WASM runtime:

kubectl exec -n wasm-tenant-payments wasm-app -- ps -ef
# Output is from the shim host process, not a Linux container init.

# On the node, check the shim:
crictl ps --label "io.kubernetes.pod.name=wasm-app" -v
# RUNTIME: io.containerd.spin.v2

# Confirm no SA token is mounted.
kubectl exec -n wasm-tenant-payments wasm-app -- ls /var/run/secrets/kubernetes.io
# (no such file or directory)

Trade-offs

Failure Modes

When to Consider a Managed Alternative

Self-hosted WASM-on-Kubernetes requires shim distribution, RuntimeClass management, image admission, and cross-runtime policy maintenance (4-10 hours/month for a multi-tenant cluster).

• Fermyon Cloud: managed Spin platform with built-in tenant isolation and image attestation.
• Cosmonic: managed wasmCloud with capability-based tenancy.

Related Articles

• Wasmtime Production Hardening
• WASI Preview 2 Capability-Based Security
• OCI WASM Module Signing and Verification
• Network Policies for Zero-Trust Kubernetes Networking
• ValidatingAdmissionPolicy with CEL