Skip to main content
← Back

WebAssembly Kubernetes Workload Identity with SPIFFE & SPIRE

The April 9, 2025 wasmCloud community call centers on WebAssembly Kubernetes workload identity. Fresh off back-to-back wasm.io Barcelona and KubeCon London, Joonas Bergius demos the work he and Colin presented on stage: using SPIFFE and SPIRE to give WebAssembly workloads a verifiable identity, then exchanging short-lived SPIFFE JWTs for temporary AWS credentials — no static secrets in the mix. Bailey Hayes and Liam Randall co-host, walking through how this solves first- and third-party multi-tenancy and cross-cloud deployment, before a community Q&A on WASI version compatibility, Helm/NATS deployments, and the capability boundaries of the WebAssembly component model.

Key Takeaways​

  • SPIFFE is a CNCF standard for describing the identity associated with a workload, with SPIRE as its reference implementation; both were designed for the container age and assume they can observe every workload they issue identities for
  • WebAssembly breaks that assumption — you can't observe an individual Wasm workload by PID because they all run inside the host runtime — so the demo uses SPIRE's delegated identity API, brought into the wasmCloud host behind an experimental flag, exposed as a new wasmcloud:identity host interface
  • In the wasmPay demo, an API gateway component running on a wasmCloud host mints a SPIFFE JWT, then exchanges it via AWS STS AssumeRoleWithWebIdentity for temporary credentials used to call Amazon Bedrock — all with no AWS secrets stored locally
  • The minted credentials are short-lived (as low as 5–15 minutes), so a leaked token has a very narrow exploitation window; onboarding and offboarding workloads is handled through trust domains and policies, not by distributing secrets
  • Liam framed this as the OIDC "Rosetta Stone" for WebAssembly: the same component can run as different tenants in one cloud, or move across AWS, Azure, and on-prem, getting the right contextual credentials wherever it lands
  • The team is canonicalizing wasi:io into the component model ABI as part of WASI Preview 3's async work, dramatically reducing the blast radius of version churn, with forward/backward compatibility a longer-term goal
  • The recommended way to deploy wasmCloud on Kubernetes is the Helm platform chart, which pulls in the upstream NATS chart; to wire up multiple NATS clusters, create a local umbrella chart with both as sub-charts
  • Components can target the WASI CLI run interface, but cannot shell out to arbitrary binaries — preserving structured inputs/outputs, composability, and the capability-based security sandbox; arbitrary process execution belongs in a provider

Chapters​

Meeting Notes​

Demo: SPIFFE/SPIRE Workload Identity for WebAssembly​

Joonas Bergius shared the demo he and Colin presented at KubeCon, titled "SPIFFE in Practice: Universal Identity for WebAssembly Workloads." SPIFFE is a standard specification — built and implemented inside the CNCF — for describing the identity associated with a given workload, with two representations: a JWT-based SVID and an X.509 certificate-based SVID. SPIRE is its reference implementation.

The demo runs on a Kubernetes cluster, with a SPIRE server and SPIRE agent running alongside a wasmCloud host. The challenge: SPIFFE and SPIRE were designed for the container age and expect to observe every workload they issue identities for. With WebAssembly you can't directly access a PID and see the Wasm workload — they all run inside the host runtime. SPIRE solves this with a delegated identity API, which the team brought into the wasmCloud host behind an experimental flag and exposed through a new wasmcloud:identity host interface.

Demo: wasmPay — Minting JWTs and Exchanging for AWS Credentials​

The demo application, wasmPay, includes an API gateway component running on a wasmCloud host. The flow: a curl to /api/v1/token mints a SPIFFE JWT SVID; that token is then sent to /api/v1/bedrock, where the API gateway exchanges it via AWS STS AssumeRoleWithWebIdentity for temporary AWS credentials and calls Amazon Bedrock (the Nova Lite model) to write a story about workload identity. Decoding the JWT shows the subject is the specific wasmCloud component (wasmcloud.dev/spiffe-in-practice/api-gateway) and an audience identifying the intended recipient.

Crucially, no AWS secrets are stored locally. A trust relationship is established between the local SPIRE deployment and the upstream AWS account via an OIDC identity provider, and the credentials minted are short-lived — as low as 5–15 minutes. If one leaks, the exploitation window is tiny.

Q&A: Change Control, Generality, and Business Value​

Liam asked how change control works for revoking or admitting credentials. Joonas explained it's policy-based: each cluster has a unique trust domain, and you write policies in the cloud provider associating specific workloads (identified by their path — lattice and component name) with the services they're allowed to access. No trust relationship or no matching policy means no access, even with a valid SVID. Liam noted the next phase is user experience — perhaps a dashboard or reusing existing Kubernetes CRDs.

Bailey asked whether this was specific to Bedrock and AWS. Joonas confirmed nothing is Bedrock-specific: it's standard OIDC, applicable to any cloud provider with the same primitives (Colin had already wired up Kafka authentication the same way). Liam summarized the two big business wins: first- and third-party multi-tenancy within a single cloud, and running one component across multiple clouds — the OIDC "Rosetta Stone" for WebAssembly. As Joonas added, this is exactly how third-party OIDC was meant to be used; it's not a hack.

Conference Roundup​

Coming off wasm.io Barcelona and KubeCon London — seven talks across the team plus two booths — the maintainers flagged must-watch sessions: Luke Wagner's deep-dive (with the "shared everything functions and tables" work targeting the next release candidate), and the Oracle engineers' talk on adding Java-to-Wasm compilation support to GraalVM. Liam's KubeCon talk told the platform engineering story for WebAssembly components via live demos; Colin's wasm.io talk covered building a real component with the C2PA content-authenticity SDK and the rough edges still in WIT (like callbacks).

Q&A: WASI Compatibility, Kubernetes Deployment, and CLI Calls​

  • WASI version mismatches (Masood): Bailey explained the team is canonicalizing wasi:io into the component model ABI as part of WASI Preview 3's effort to asyncify everything — dramatically reducing the blast radius of version changes — and treating WASI as modular after 1.0. Forward/backward compatibility (already present in Wasmtime, not yet in a shared crate) is the longer-term goal.
  • Deploying on Kubernetes (Jorge): The recommended path is the Helm platform chart, which pulls in the upstream NATS chart. To communicate across multiple NATS clusters, Masood recommended creating a local umbrella chart with both as sub-charts so variables can be exchanged between them.
  • CLI calls from components (Masood): There's no process-exec API in the WASI spec, but you can compile a component to the WASI CLI interface and invoke its run function. Arbitrary shell-out belongs in a provider — Liam emphasized keeping structured inputs/outputs to preserve composability and the security sandbox.

WebAssembly News and Updates​

This call landed the week after two major WebAssembly conferences — wasm.io in Barcelona and KubeCon + CloudNativeCon EU in London — where the wasmCloud maintainers delivered seven talks across two booths. The headline themes: the Bytecode Alliance's "shared everything functions and tables" work landing in time for the upcoming release candidate, Oracle's GraalVM gaining Java-to-Wasm compilation, and growing real-world adoption of WASI Preview 2. On the identity front, SPIFFE and SPIRE entering the WebAssembly story marks a milestone for zero-trust, secretless workload identity. For ongoing updates, follow the wasmCloud blog and the Bytecode Alliance.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime and connects hosts over NATS, distributing workloads as OCI artifacts. With built-in OpenTelemetry observability and a Kubernetes operator, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure — including emerging primitives like SPIFFE/SPIRE workload identity.

Topic Deep Dive: WebAssembly Kubernetes Workload Identity​

Workload identity answers a deceptively hard question: when a piece of code calls a cloud service, how does that service know it's really talking to the workload it claims to be — without a shared secret? In the container age, SPIFFE and SPIRE answered this by observing every workload and minting it a verifiable identity. WebAssembly complicates the picture: many Wasm workloads run inside a single host runtime, invisible to a PID-based agent. wasmCloud's approach wires SPIRE's delegated identity API into the host and surfaces it through a wasmcloud:identity interface, so a component can request a short-lived SPIFFE JWT and exchange it — via standard OIDC — for cloud credentials scoped exactly to what it needs.

The payoff is twofold. For WebAssembly on Kubernetes, it means secretless, deny-by-default access that travels with the workload across namespaces and tenants. For multi-cloud, the same portable component can land on AWS, Azure, or on-prem and assume the right identity in each environment. This is the natural complement to wasmCloud's capability-based security model: components already start with zero ambient authority, and workload identity extends that principle out to the cloud services they call. For the security model in depth, see the workload security docs and network access and socket isolation.

Who Should Watch This​

This call is especially valuable for platform and security engineers designing zero-trust workload identity for WebAssembly on Kubernetes (start with Joonas's SPIFFE/SPIRE demo at 6:43), multi-cloud architects who want one component to assume the right credentials across AWS, Azure, and on-prem (Liam's "Rosetta Stone" framing at 25:59), and Kubernetes operators evaluating how to deploy wasmCloud with Helm and multiple NATS clusters (Jorge's deployment Q&A at 41:48).

Up Next​

Future community calls will track the experimental wasmcloud:identity interface maturing beyond its flag, the user-experience layer for managing trust relationships and policies (a dashboard or Kubernetes CRDs), and the WASI Preview 3 work canonicalizing wasi:io into the component model ABI. Expect recordings from wasm.io and KubeCon — including Luke Wagner's talk and the Oracle GraalVM Java session — to be linked out in the wasmCloud Slack as they're published.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →