Skip to main content
← Back

Workload Identity (SPIFFE) and wash Plugins as Wasm Components

The February 5, 2025 wasmCloud community call pairs two forward-looking RFCs. Joonas Bergius walks through a workload identity proposal built on SPIFFE — an infrastructure-agnostic, cryptographically verifiable identity for hosts, providers, and components that can secure NATS connectivity, enable secret-less OCI pulls, and establish mutual TLS across clusters. Then the team makes the case for turning the wash CLI into a Wasm component-based plugin system — the dog-food argument that the Wasm component model should be "the last plugin system you'll ever need." Brooks Townsend closes with a Q1 roadmap check-in.

Key Takeaways​

  • Workload identity for wasmCloud aims to be infrastructure-agnostic, standards-based, cryptographically verifiable, and — to the extent possible — fully automated, so a workload only has to request an identity for it to be available
  • The proposal adopts SPIFFE as the standard and leans on the SPIRE ecosystem to bootstrap, with the option to swap in lighter-weight or managed back-ends because the implementation targets the SPIFFE spec rather than SPIRE specifically
  • Immediate use cases include securing NATS connectivity, secret-less dynamic OCI artifact pulls, secret-less access to third-party resources (e.g. a blobstore provider talking to S3), mutual TLS between hosts and providers, and cross-cluster trust
  • Workload identity will be optional and additive (non-breaking); the team cited OWASP's new Non-Human Identity Top 10 as motivation, noting workload identity addresses over half of those risks
  • The wash plugin RFC (issue #4059) proposes plugin-ifying large parts of the wash CLI into Wasm components, renaming the subcommand interface to plugin, and delegating all argument parsing to plugins for maximum flexibility (including multi-tier subcommands)
  • A new auth interface abstracts login flows behind a single authenticate method, returning NATS credentials (seed + JWT) and an optional bearer token, with wasmCloud handling the OIDC callback server so plugins don't have to
  • Plugins request capabilities (env vars, paths) via an access-request prompt — an OS-style "this app would like access" experience — backed by a new wash config file for sandboxing; default builds embed core plugins so nothing extra is installed
  • New subcommands should land as plugins, enabling out-of-band, SemVer-compatible updates via OCI and far fewer full wash CLI releases; wash drain and wash keys are the first proof-of-concept plugins

Chapters​

Meeting Notes​

Workload Identity: A SPIFFE-Based RFC​

Joonas Bergius opened with an educational walkthrough of workload identity — the concept of a platform issuing identity to the services running on it, increasingly known as non-human identity to contrast it with human users. Cloud providers and orchestrators like Kubernetes and Nomad already offer this; the proposal is for wasmCloud to provide its own form. Because wasmCloud runs everywhere from edge to cloud to on-prem to IoT, the identity has to be infrastructure-agnostic (not tied to AWS/GCP/Azure primitives), standards-based and interoperable across platforms, cryptographically verifiable, and — to the extent possible — fully automated.

The immediate use cases: securing NATS connectivity for hosts and providers, enabling secret-less dynamic OCI artifact pulls (so the host presents its identity rather than storing registry credentials), secret-less access to third-party resources (a blobstore provider authenticating to S3 with no stored secrets), mutual TLS between hosts and providers, and establishing trust between clusters deployed across different environments.

Adopting SPIFFE and SPIRE​

The proposal adopts SPIFFE — the CNCF-graduated standard for workload identity — and uses the SPIRE reference-implementation ecosystem to bootstrap. Joonas outlined a three-step rollout: the host first (so it can obtain identity for itself and its workloads), then providers (where ready-to-go use cases exist), then components. As extra motivation he pointed to OWASP's newly published Non-Human Identity Top 10, noting that workload identity can address over half of those risks. Next steps: an RFC/proposal in the wasmCloud issue tracker, a proof-of-concept showing host-side NATS connectivity over workload identity, and a tracking issue — with a preview teased for the team's upcoming KubeCon talk.

Optional, Additive, and Enterprise-Focused​

Florian Fürstenberg asked whether workload identity would be mandatory and whether the RFC would cover best practices for operating SPIRE. Joonas confirmed it will be optional and additive — a sizable footprint you opt into, not a hard dependency — and that wasmCloud will provide getting-started guidance while deferring deep operational knowledge to the SPIRE community (and recommending managed back-ends where available). Liam Randall framed this as an enterprise problem — the kind Istio solved with SPIFFE — and argued that baking it in could make wasmCloud "the last service-token problem you ever have." Because the implementation targets SPIFFE rather than SPIRE specifically, lighter-weight or development-friendly back-ends remain possible, and the SPIRE agent could eventually be folded directly into the host.

Plugin-ifying wash with Wasm Components​

Picking up the wash plugin RFC (#4059) — originally authored as the text-based plugin demo — the team proposed turning large chunks of the wash CLI into Wasm components that can be updated independently. The motivation is twofold: dog-food components (the project's own tooling proving out the model) and serve the growing number of teams productionizing wasmCloud who need auth plugins and custom extensions. The RFC renames the subcommand interface to plugin, supporting both standard subcommand plugins and auth plugins; crucially, all argument parsing is now delegated to plugins, unlocking multi-tier subcommands and full CLI-like flexibility.

The new auth interface abstracts login flows behind a single authenticate method and returns a NATS credential (seed + JWT) plus an optional token for future HTTP/bearer flows. Because many plugins need an OIDC flow, wasmCloud provides the callback machinery — spinning up a localhost listener and inserting the response — so plugins don't reimplement it. A new wash config file enables sandboxing: plugins declare access requests (env vars, file paths) and users approve them through an OS-style permission prompt, interactive by default. To keep the experience seamless, the default wash build embeds core plugins, with a future light build letting you assemble your own. wash drain and wash keys are the first proof-of-concept plugins; wash context, an auth plugin, and wash pull/push follow.

Q1 Roadmap Check-In​

Brooks Townsend closed with the roadmap, noting strong progress moving issues from triage into ready for work. Highlights: Aditya's cron job provider, Masood/ossfellow's built-in HTTP client provider and SBOM/build-provenance work, Ahmed's draft to consolidate wash CLI and wash lib (functionally done, with workspace pains remaining), and Roman's wasmCloud crate features work that — combined with Nix flake outputs and Nix-on-CI — lets CI build only the specific binaries it needs, making builds faster and greener.

WebAssembly News and Updates​

Both headline items reflect where the broader WebAssembly ecosystem was heading in early 2025: security primitives and the Wasm component model as a universal extension mechanism. Workload identity brings the SPIFFE/SPIRE standard — battle-tested in the Istio/Envoy world — into a Wasm-native platform, addressing OWASP's Non-Human Identity Top 10 risks. The wash plugin RFC is a bet on the component model as the substrate for extensible tooling, echoing the longer story told in Introducing wash: a Wasm-powered plugin system. 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 host is built on Wasmtime, connects its control plane over NATS, and distributes workloads as OCI artifacts. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model as a Plugin System​

The wash RFC is, at heart, an argument about the Wasm component model. The thesis: a great component model should be "the last plugin system you'll ever need." By compiling wash subcommands to WebAssembly components and defining their contract in WIT interfaces — plugin, auth, registry, plus the WASI CLI run world — wash gains language-agnostic extensibility (write a plugin in Go, ship it as a component), sandboxing via explicit access requests, and out-of-band, SemVer-compatible updates distributed over OCI. The same component boundary that isolates a workload also isolates a CLI plugin: it gets exactly the env vars, file paths, and capabilities it asks for and nothing more — deny-by-default, enforced at the component edge. As more of wash becomes components, the CLI converges on what it always wanted to be: a small Wasmtime host orchestrating plugins, with the component model as the universal contract.

Who Should Watch This​

This call is especially valuable for platform and security engineers evaluating zero-trust, secret-less identity for cloud-native workloads (start with Joonas's workload identity walkthrough at 3:09), wasmCloud operators and provider authors who want secret-less NATS and OCI access (the use-cases section at 5:20), and contributors and tooling developers interested in extending the wash CLI through Wasm component plugins (the wash RFC at 27:21).

Up Next​

Expect the workload identity RFC to land in the wasmCloud issue tracker, followed by a proof-of-concept demonstrating host-side NATS connectivity over SPIFFE-based identity (with a preview at KubeCon), and a tracking issue scoping host, provider, and component work. On the tooling side, watch for a draft RFC and community feedback on the wash plugin system (issue #4059), starting with wash drain and wash keys as the first plugins to prove out the architecture.

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 →