Skip to main content
← Back

WebAssembly Workload Identity with SPIFFE/SPIRE and NATS

The February 12, 2025 wasmCloud community call is anchored by a live demo of WebAssembly workload identity. Joonas Bergius shows how wasmCloud can adopt SPIFFE — with the open-source SPIRE reference implementation — to give every host a cryptographically verifiable identity and secure its NATS connection through auth callout, without distributing any secrets. Brooks Townsend bookends the demo with a proposal to define wasmCloud's CloudEvents as auto-generated JSON Schema, a new conventional-commits pipeline for cleaner release notes, and a plan to freeze wash while its library and CLI merge into one crate.

Key Takeaways​

  • Workload identity is proposed as opt-in, not a hard requirement. wasmCloud would adopt SPIFFE as the standard and the open-source SPIRE reference implementation, while leaving existing credential-based auth in place for anyone who prefers it
  • It's a secret-less approach. Instead of shipping a NATS credentials file or TLS certificate to each host, the host requests a SPIFFE-verified identity (an SVID) from the local SPIRE agent and presents that to NATS — removing the secret-introduction problem entirely
  • NATS auth callout is where the authorization decision lives. When a host connects, NATS hands the presented SVID to a configurable auth-callout service, which asks a SPIRE agent to validate it and decides whether the host may join — Joonas plans to ship a reference implementation you can run locally and adapt
  • Each host already gets a unique identity; SPIFFE makes it verifiable. The same identity can later gate other actions — for example, writing registry policies so only hosts in a given trust domain can pull OCI images
  • CloudEvents should be defined as auto-generated JSON Schema. Rather than committing to a new IDL like WIT or protobuf, Brooks proposed deriving JSON Schema from wasmCloud's Rust structs (the same trick wadm uses for its manifest) so documentation stays in sync automatically
  • A conventional-commits pipeline now powers release notes. A GitHub Action validates each commit, auto-labels PRs by type/scope/breaking-change, and feeds GitHub's release-notes generator — excluding Dependabot noise and surfacing breaking changes for provider-SDK consumers
  • Future hardware-rooted identity is on the table. Discussion touched on TPM-based node attestation (SPIRE is extremely pluggable, with an existing TPM plugin from Bloomberg) as a path to bootstrap trust all the way from bare hardware to a secure end-to-end identity
  • wash is proposed for a short feature freeze so Ahmed can consolidate the wash library and CLI into a single crate, releasing v0.39 first and landing any urgent fixes in a feature branch

Chapters​

Meeting Notes​

Demo: SPIFFE/SPIRE Workload Identity in wasmCloud​

This demo follows Joonas's deeper dive into the theory of workload identity from the previous week — worth catching up on before this hands-on session. The proposal is for wasmCloud to adopt SPIFFE as the industry standard for workload identity, with the open-source SPIRE project as the reference implementation. Crucially, this is opt-in: a feature you enable for a deployment, not a requirement for running wasmCloud.

Joonas walked through the flow with an Excalidraw diagram before showing it live. When a host comes online it asks the local SPIRE agent for its own identity; the agent attests the workload against the platform it runs on (bare metal, Docker, or — in the demo — Kubernetes via the Kubelet API), then the SPIRE server issues a cryptographically verifiable identity document. The host presents that document to NATS, which uses auth callout to hand validation off to an external service. The result: a WebAssembly host that proves, with no shared secret, that it belongs to its NATS cluster.

Running everything in a local kind cluster (using SPIRE's upstream hardened Helm charts), Joonas brought up a wasmCloud host with the experimental workload identity flag enabled. The host connected with neither a JWT nor a key configured, and the NATS connections report showed two connections per host — one for the control plane (CTL) and one for RPC — each authorized via a SPIFFE identifier in the spiffe://wasmcloud.dev/... form, scoped to the wasmCloud service account in the default namespace.

Q&A: Failure Modes, Verifiability, and Hardware Attestation​

Frank asked about failure modes and migration paths. Joonas explained the plan is configurable retries at every level — both the NATS connection and the identity request — with a fail-closed default: if a host can't obtain its identity, it shouldn't connect. SVID TTLs are configurable and typically outlive the heartbeat interval. Liam and others noted SPIFFE/SPIRE are production-grade (used at Adobe in FedRAMP clusters; Uber manages millions of identities this way).

Brooks reframed the value: each host already generates its own unique NATS identity, but SPIFFE makes that identity verifiable against an existing standard — and the same primitive can later gate OCI registry pulls via policy. Joonas added that an x.509 path could eventually secure the TLS connection itself, killing two birds with one stone. Liam tied it to long-requested TPM support: because SPIRE is extremely pluggable (there's already a TPM node-attestation plugin from Bloomberg), you could bootstrap trust from bare hardware all the way to a secure end-to-end identity.

Discussion: JSON Schema for CloudEvents and Structs​

A wasmCloud roadmap item flagged a gap: CloudEvents and protocols aren't specified in a way that's usable outside the project. They're currently defined as JSON objects in the Rust codebase, so any change risks the docs drifting out of date, and consumers in other languages must hand-write the JSON. Brooks weighed WIT and protobuf as language-agnostic IDLs but proposed the lowest-friction option: derive JSON Schema directly from the existing Rust structs — the same approach wadm uses to publish a schema for its manifest — and feed that into the documentation pipeline automatically. ossfellow noted that the CloudEvents crate now has NATS mappings, and Masood asked whether only the inner data payload schema needs publishing (yes — the CloudEvents envelope is already standardized).

Discussion: Conventional Commits for Release Notes​

Brooks demoed a near-complete pipeline that reads each PR's conventional commit message and, via a GitHub Action, auto-labels the PR by type, scope, and whether it's a breaking change. Those labels then drive GitHub's built-in release-notes generator through a release.yml config — excluding Dependabot's chore bumps and nesting breaking changes, features, and fixes under their own headings. The big win: breaking changes are surfaced automatically, which matters most for provider-SDK and library consumers. Thanks to Lachlan and Roman for the heavy lifting.

Proposal: Freeze wash to Merge the Library and CLI​

Brooks proposed a short feature freeze on wash so Ahmed — a wadm maintainer who has taken on the work — can combine the wash library and CLI into a single crate. The plan: release wash v0.39 now, hold off merging new features or larger changes to main, and land any urgent fixes in a feature branch until the migration completes (hopefully by the next community call). Joonas noted a related fix is needed so a changed credentials file is re-read rather than read only once at startup.

WebAssembly News and Updates​

This call lands squarely in the cloud-native security conversation. The headline is wasmCloud's move toward SPIFFE/SPIRE for WebAssembly workload identity — the same identity fabric used in demanding enterprise environments — applied to securing NATS connections without shared secrets. It's a strong example of WebAssembly platforms adopting established cloud-native standards rather than reinventing them, and it pairs naturally with wasmCloud's existing OCI distribution and Kubernetes story — building on the enterprise-security foundation introduced in wasmCloud 1.1's secrets support. On the project-hygiene side, the CloudEvents-as-JSON-Schema and conventional-commits work both aim to keep wasmCloud's public contracts and changelogs trustworthy as the contributor base grows. For ongoing updates, follow the wasmCloud blog and the SPIFFE project.

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 uses NATS as its message bus for both control and RPC — the same connections this call secures with SPIFFE workload identity. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: WebAssembly Workload Identity​

Workload identity answers a deceptively simple question: how does a service prove it is who it claims to be, without a human handing it a secret? In wasmCloud, every host already mints a unique NATS key pair — but on its own, that key only says "I am unique," not "I am authorized to be part of this cluster." SPIFFE closes that gap with a standardized identity document (the SVID) and a trust domain (spiffe://wasmcloud.dev/...), while SPIRE attests the workload against the platform it runs on before issuing one.

The wasmCloud bet is to treat this as a composable foundation. Securing the NATS connection is the first use case, but the same verifiable identity can authorize OCI registry pulls, establish mutual TLS via x.509 SVIDs, or — through SPIRE's pluggable attestors like the Bloomberg TPM plugin — root trust in hardware. Because it's a secret-less model, it sidesteps the secret-introduction and secret-rotation problems that plague credential files, all while keeping the WebAssembly host itself unchanged and the feature strictly opt-in.

Who Should Watch This​

This call is especially valuable for platform and security engineers evaluating zero-secret authentication for cloud-native workloads — start with Joonas's SPIFFE/SPIRE demo at 22:58 and the authorization-decision Q&A at 49:37. wasmCloud contributors and API consumers will want the CloudEvents JSON Schema discussion at 8:29 and the conventional-commits release-notes pipeline at 55:12. Maintainers tracking the wash consolidation should catch the feature-freeze proposal at 61:29.

Up Next​

The next community calls follow the workload-identity work from theory into landed code: Joonas planned to open an RFC issue describing the flow and land an initial draft PR for the host-side implementation that same day, with the auth-callout reference implementation to follow. Also watch for the conventional-commits labeler to land (and show up in the first provider-SDK release), the CloudEvents JSON Schema proposal moving out of triage, and the wash single-crate migration wrapping up after the short freeze.

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 →