​​SPIFFE in Practice: Universal Identity for WebAssembly Workloads - Joonas Bergius & Colin Murphy

SPIFFE in Practice: Universal Identity for WebAssembly Workloads

Speakers: Joonas Bergius, Senior Software Engineer at Cosmonic; Colin Murphy, Senior Rust Engineer at Adobe

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=c0dEL_bBRVU

Overview

This talk, presented by Joonas Bergius and Colin Murphy, delves into the practical application of SPIFFE (Secure Production Identity Framework For Everyone) for establishing universal identity in WebAssembly (Wasm) workloads, particularly within the WasmCloud ecosystem. Colin Murphy, drawing from his challenging experiences managing infrastructure for Adobe Sign for GovCloud, highlights the critical need for robust workload identity and the significant burden of CVE (Common Vulnerabilities and Exposures) management in traditional containerized environments. He posits WebAssembly as a transformative technology that can address these inefficiencies and security concerns.

Joonas Bergius then takes a deep dive into how WasmCloud leverages SPIFFE, specifically utilizing Spire's non-standard but invaluable delegated identity API, to provide secure, attested identities to individual Wasm components running within a WasmCloud host. The talk demonstrates a compelling proof of concept where a Wasm component, via its host, obtains a SVID (SPIFFE Verifiable Identity Document) and exchanges it with AWS STS (Security Token Service) for temporary credentials to access AWS Bedrock, showcasing a secretless interaction with cloud services. The speakers advocate for SPIFFE as an indispensable tool for securing hyper-distributed, multi-tenant WebAssembly applications, emphasizing its role in reducing operational overhead and enhancing security posture in modern cloud-native landscapes.

Background

▶ Watch: Welcome and speaker introductions (0:00)

The journey into SPIFFE and WebAssembly for Colin Murphy began in the demanding environment of Adobe Sign for GovCloud in March 2020. As the manager for Adobe Document Cloud's infrastructure, he faced the arduous task of ensuring dozens of microservices met stringent compliance standards like HIPPA, SOC 2, PCI, and crucially, FedRAMP. A significant hurdle was the inability to port Adobe's internal Identity Management System (IMS), traditionally used for both user entitlements and service-to-service authentication, to the government cloud. This void highlighted a critical need for a robust, external workload identity solution.

Murphy found a lifeline in SPIFFE, specifically through a Solo.io agent, which seamlessly integrated with their non-containerized workloads, providing the necessary FIPS 140-2 compliance. This early positive experience cemented SPIFFE's value in his mind as an "invaluable tool for workload identity." However, the landscape dramatically shifted in March 2021 when FedRAMP mandated security scans for CVEs in all Docker images, just as they were preparing to go live. This requirement plunged Murphy's team into a "full-time job" of tracking and remediating vulnerabilities. With around a hundred different Docker images, and using scanning tools like JFrog Artifactory, they quickly identified "well over a thousand, maybe 2,000 vulnerabilities" in their images. This overwhelming task diverted resources from feature development and technical debt, exposing the inherent inefficiencies and operational burden of managing CVEs in traditional container ecosystems.

This experience led Murphy to a profound dissatisfaction with the "inherent inefficiencies of Docker or typical runC containerd type containers," particularly when running resource-intensive applications like Java. He became convinced there had to be a better way. Simultaneously, Adobe was already a heavy user of WebAssembly, seeing it as the successor to Flash and integrating it into all their web applications. Murphy delved into Wasm System Interface (WASI), the ABI for running WebAssembly outside the browser, and became involved in WasmCloud, a fledgling project aiming to be an ideal platform for server-side WebAssembly.

WasmCloud, at its core, combines two revolutionary technologies: NATS for distributed messaging and Wasmtime as a secure, high-performance WebAssembly runtime. The vision for WasmCloud was a platform that was fundamentally secure, efficient, and global. Security meant sandboxed execution of untrusted code, multi-tenancy without concern for tenant vulnerabilities, and critically, the elimination of vulnerabilities stemming from RPM packages or Debian packages, a direct response to Murphy's CVE nightmare. Efficiency was paramount, with WebAssembly offering "over 100 times faster cold start times than Docker." Globality aimed for a single control plane across regions and clouds, avoiding the complexity of managing dozens of separate Kubernetes clusters. While Wasmtime provides a secure runtime, the distribution layer and cross-component communication required robust identity. This is where SPIFFE, previously "merely nice to have in Kubernetes," became "absolutely required in a hyper-distributed system like WasmCloud."

Key Findings

▶ Watch: The unexpected CVE scanning crisis in Docker images (2:30)

The talk presents several crucial findings regarding the integration of SPIFFE with WebAssembly and WasmCloud:

1. SPIFFE's Indispensability for Hyper-Distributed Wasm: Colin Murphy's journey from struggling with Adobe's internal identity system to embracing SPIFFE for FedRAMP compliance underscored its value. In the context of WasmCloud's highly distributed, multi-tenant architecture, SPIFFE's workload identity capabilities transition from a beneficial feature in Kubernetes to an "absolutely required" component for security and trust across disparate environments.
2. The Delegated Identity API as a Critical Enabler: A major technical challenge in WasmCloud is that individual Wasm components, running as tiny virtual machines inside a WasmCloud host, are "completely invisible" to a standard Spire agent. The discovery and application of Spire's delegated identity API proved to be the pivotal solution. This API allows an authorized workload (the WasmCloud host) to obtain SVIDs and bundles on behalf of workloads (the Wasm components) that the Spire agent cannot directly attest.
3. Pioneering Rust Adoption of Delegated Identity API: Joonas Bergius revealed that WasmCloud is currently the only project in the Rust ecosystem utilizing Spire's delegated identity API. This highlights WasmCloud's innovative approach but also points to the nascent state of tooling and documentation for this specific API within the Rust community, necessitating significant foundational work by the WasmCloud team.
4. First-Time SPIFFE Integration within Wasm Components: The successful proof of concept demonstrated in the talk marks a significant milestone: it's "the first time we're actually brought Spiffy into components," enabling Wasm modules to acquire and leverage attested identities from within their execution environment.
5. Adaptation to Short-Lived SVIDs: A key lesson learned during implementation was the need to adapt WasmCloud's authentication handlers to effectively manage short-lived SVIDs, which can expire as frequently as every five minutes. This contrasts with traditional assumptions about long-lived authentication information and necessitates robust logic for token refreshing and connection re-establishment.
6. Extensive Customizability of Spire: The Spire project offers "incredible" customizability through its plugin system, built over a gRPC-based protocol. This allows users to implement custom attestation and authorization methods, as well as define how changes and notifications are handled, providing significant flexibility beyond out-of-the-box functionalities.
7. Active and Supportive SPIFFE Community: The speakers praised the SPIFFE community, particularly the Slack channel and active contributors, for providing invaluable resources, insights, and direct access to experts, which was crucial for navigating the complexities of the delegated identity API and other challenges.

Technical Deep Dive

▶ Watch: Discovering WebAssembly for server-side applications (4:10)

The core challenge addressed in this talk revolves around providing secure, verifiable identity to WebAssembly (Wasm) components running within a WasmCloud host, especially when these components are not directly visible or attestable by a standard Spire agent.

WasmCloud Architecture and Identity Requirements:

WasmCloud operates with two primary layers built upon NATS:

1. Control Layer: Facilitates communication between the WasmCloud host and other infrastructure components.
2. RPC Mesh Layer: Enables Wasm components to make calls to providers (binaries fulfilling specific interfaces, e.g., an S3 provider or an LLM provider). Crucially, the WasmCloud host mediates all component communication, meaning components never directly interact with external systems.

While Wasmtime provides a secure runtime sandbox for individual Wasm modules, the broader WasmCloud ecosystem, particularly its hyper-distributed nature and reliance on NATS for inter-component communication, demands a robust workload identity solution. This is where SPIFFE steps in.

The Attestation Gap:

In a typical SPIFFE deployment, a Spire agent runs alongside a workload (e.g., in a Kubernetes pod or on a VM) and directly attests to its identity (e.g., via Kubernetes service account tokens, process IDs, or file paths). Once attested, the Spire agent can issue a SVID (SPIFFE Verifiable Identity Document) to the workload.

The problem in WasmCloud is that a single WasmCloud host can run "a whole bunch of these little virtual machines" – the Wasm components. These components are isolated and ephemeral, making them "completely invisible to the Spire agent." The Spire agent cannot directly inspect or attest to these nested Wasm workloads.

The Solution: Spire's Delegated Identity API:

The breakthrough came with the discovery of Spire's delegated identity API. This API, while not part of the official SPIFFE specification but an extension within the Spire project, is designed for scenarios where an authorized workload needs to obtain SVIDs on behalf of other workloads that it manages but which cannot be directly attested by the Spire agent.

In the WasmCloud context:

• The WasmCloud host acts as the authorized workload. It runs alongside the Spire agent and is itself attested by the agent.
• The Wasm components are the unattestable workloads.

The WasmCloud host, using its own attested identity, is granted permission to call the delegated identity API on the local Spire agent. It can then request SVIDs for its individual Wasm components, providing attributes or claims that identify the specific component (e.g., its module ID, application name, or tenant).

Implementation Details and Use Cases:

The delegated identity API is gRPC-based, making it relatively straightforward to integrate. WasmCloud, being written in Rust, uses a custom Rust implementation for this API, as there were no existing Rust SDKs or examples at the time.

Key use cases for SPIFFE within WasmCloud, enabled by this delegated identity approach, include:

• Securing NATS Communication: Ensuring mutual authentication and authorization for messages exchanged over the NATS control and RPC mesh layers, preventing unauthorized access or impersonation.
• Secretless OCI Pulls: Allowing Wasm components to pull their images from OCI registries (like Docker Hub or AWS ECR) without hardcoding credentials. An SVID tied to the component's identity can be exchanged for temporary registry access tokens.
• Secretless Access to Third-Party Resources: This was the focus of the demo. Components can obtain SVIDs and exchange them for temporary cloud provider credentials (e.g., AWS IAM roles via AWS STS) to access services like S3 buckets or LLMs (AWS Bedrock) without ever handling long-lived secrets.
• Mutual Authentication for Providers: As WasmCloud expands to support providers communicating over HTTP or TCP (beyond NATS), SPIFFE can ensure mutual TLS authentication, verifying the identity of both the provider and the host.
• Cross-Cloud/Region Trust: SPIFFE facilitates the establishment of trust relationships between WasmCloud clusters deployed across different clouds, regions, or edge environments, forming a truly global, secure fabric.

SVID Lifecycle Management:

A critical operational aspect highlighted is the management of short-lived SVIDs. Unlike traditional, long-lived API keys or certificates, SVIDs (especially JWT-SVIDs) often have short expiry times, such as five minutes. This necessitates that WasmCloud's authentication handlers and connection management logic are designed to:

• Continuously monitor SVID expiry.
• Proactively refresh SVIDs before they expire.
• Re-establish connections or re-authenticate with external services using fresh credentials.

This paradigm shift from static secrets to dynamic, frequently rotating identities is a cornerstone of modern zero-trust architectures enabled by SPIFFE.

Demo / Proof of Concept

▶ Watch: Concise definition of WebAssembly for this discussion (6:00)

Joonas Bergius presented a live demonstration showcasing the practical application of SPIFFE within WasmCloud for achieving secretless access to third-party cloud resources. The demo focused on a specific flow within a broader WasmCloud application, specifically how a WebAssembly component interacts with its host to gain authenticated access to AWS STS and AWS Bedrock.

Demonstration Setup:

The setup involved a locally running WasmCloud installation with an API gateway application deployed onto it. Crucially, a Spire agent was running next to the WasmCloud host on the same node.

The Workflow:

The demonstration illustrated the following sequence of events:

1. SVID Acquisition by Wasm Component:

• A curl command was used to make an API call to the local WasmCloud API gateway application.
• This call, from within the Wasm component, requested an SVID from its host. The request specified an audience for the SVID, e.g., kubecon.uk 2025 spiffy in practice API gateway.
• The WasmCloud host, acting as an authorized workload, internally called the local Spire agent using the delegated identity API. It requested an SVID for the specific Wasm component that initiated the request.
• The Spire agent generated and returned a JWT-SVID to the WasmCloud host, which then forwarded it back to the originating Wasm component.
• Bergius then used jwt.ms to inspect the returned JWT, verifying that it contained the requested audience and a subject (wasn't cloud dev/spiffy in practice/api gateway) identifying the Wasm component. This confirmed that a real, attested SVID had been successfully minted for the WebAssembly workload.

1. SVID Exchange for AWS Credentials and Bedrock Access:

• In a real-world scenario, the SVID would typically be used directly in subsequent calls. For the purpose of this demo, the acquired SVID was stored in an environment variable.
• A second curl command was then executed. This command initiated another call to the WasmCloud API gateway application, but this time to a different endpoint designed for AWS interaction.
• The Wasm component, again via its host, took the previously acquired SVID and sent it to AWS STS (Security Token Service).
• AWS STS, configured to trust SVIDs issued by the Spire server, validated the SVID's identity and audience. Upon successful validation, it returned a set of temporary AWS security credentials (access key ID, secret access key, and session token) to the WasmCloud host.
• The WasmCloud host then used these temporary AWS credentials to make an authenticated API call to AWS Bedrock, Amazon's large language model service.
• The request to Bedrock specifically asked for "a poem about workload identity and spiffy."
• Bedrock successfully processed the request and returned a delightful poem, demonstrating that the Wasm component, through the host, had gained secretless, temporary, and authorized access to a sophisticated cloud service based purely on its SPIFFE identity.

Key Takeaways from the Demo:

The demonstration effectively proved that:

• A WebAssembly component can acquire a verifiable identity (SVID) from a SPIFFE/Spire infrastructure.
• This SVID can be exchanged for temporary, fine-grained access credentials to external cloud services like AWS.
• The entire process is "secretless," meaning no long-lived API keys or static credentials need to be hardcoded or stored within the Wasm component or its host for accessing AWS resources.
• The WasmCloud host acts as a secure intermediary, abstracting away the complexities of identity attestation and credential management from the individual Wasm components.

Defensive Implications

▶ Watch: WAMCloud's vision for an ideal microservices platform (6:20)

The integration of SPIFFE with WebAssembly (Wasm) in WasmCloud offers significant defensive advantages and shifts paradigms for securing modern, distributed applications. Defenders should consider the following implications:

1. Mitigate CVE Fatigue with Wasm: The core motivation for Colin Murphy's move to Wasm was the overwhelming burden of CVE management in Docker images. By adopting WasmCloud, organizations can drastically reduce their attack surface. Wasm modules are sandboxed, typically much smaller, and do not carry the baggage of system libraries, RPMs, or other packages that are common sources of vulnerabilities in traditional containers. This means less time spent patching, scanning, and remediating, freeing up security teams for higher-value work.

1. Embrace Universal Workload Identity: Workload identity, as provided by SPIFFE, is no longer a "nice-to-have" but a "required" security primitive, especially in highly distributed or multi-tenant environments. Defenders should prioritize implementing strong, verifiable identities for every workload, moving away from IP-based access controls or shared, long-lived secrets. This enables fine-grained authorization and a true zero-trust architecture.

1. Design for Short-Lived Credentials: The frequent expiry of SVIDs (e.g., every 5 minutes) necessitates a fundamental shift in application design. Defenders must ensure their systems are built to gracefully handle credential rotation, proactive refreshing, and re-authentication. This drastically reduces the impact of compromised credentials, as their lifespan is inherently limited.

1. Leverage Delegated Identity for Embedded Runtimes: For environments where workloads run within a host that cannot be directly attested by a Spire agent (like Wasm components in WasmCloud, or other nested/embedded runtimes), the delegated identity API is a crucial mechanism. Defenders should understand its capabilities and ensure that the authorized hosts are themselves strongly attested and that their permissions to delegate identity are tightly controlled and audited.

1. Secure Inter-Service Communication with SPIFFE/NATS: If adopting NATS for communication within WasmCloud or other systems, SPIFFE provides the robust identity layer needed to secure the control and RPC mesh layers. This ensures that only authenticated and authorized workloads can exchange messages, preventing impersonation and unauthorized data access within the communication fabric.

1. Enable Secretless Access to Cloud Resources: The ability to exchange SVIDs for temporary cloud provider credentials (e.g., via AWS STS) is a powerful defensive tool. It eliminates the need to distribute, store, and manage static cloud secrets within applications, significantly reducing the risk of secret leakage and compromise. Defenders should promote this pattern for all cloud interactions.

1. Utilize Spire's Customizability for Policy Enforcement: Spire's extensive plugin system, built on gRPC, allows for highly customized attestation and authorization policies. Security teams can develop custom plugins to enforce organization-specific security requirements, integrate with existing identity providers, or implement unique attestation methods tailored to their specific infrastructure.

1. Stay Engaged with the SPIFFE Community: Given the ongoing evolution of SPIFFE, including proposals to standardize the delegated identity API and introduce new features like workload tokens, defenders should actively follow the community. This ensures they can anticipate and leverage new security capabilities and contribute to improving the standard.

1. Prepare for AI Agent Identity: The speakers highlighted the increasing importance of workload identity with the proliferation of AI agents. Defenders must consider how these autonomous agents will be identified, authenticated, and authorized within their ecosystems, emphasizing that SPIFFE provides a foundational solution for managing their identities securely.

Key Takeaways

• Universal Workload Identity is Essential: SPIFFE provides a robust framework for universal workload identity, which is critical for securing hyper-distributed, multi-tenant architectures like WasmCloud and for enabling zero-trust principles.
• WebAssembly Mitigates CVE Overload: WebAssembly offers a compelling alternative to traditional containers, significantly reducing the attack surface and operational burden associated with managing CVEs due to its sandboxed nature and minimal dependencies.
• Spire's Delegated Identity API Bridges the Attestation Gap: The delegated identity API is crucial for scenarios where workloads (e.g., Wasm components) are nested within a host and cannot be directly attested by a Spire agent, allowing the host to obtain SVIDs on their behalf.
• Secretless Access to Cloud Resources is Achievable: By exchanging SVIDs with cloud identity providers like AWS STS, Wasm components can obtain temporary, fine-grained credentials to access cloud services (e.g., AWS Bedrock) without needing to store or manage long-lived secrets.
• SPIFFE/Spire Ecosystem is Powerful and Customizable: The Spire project offers extensive customizability through its gRPC-based plugin system for attestation, authorization, and notification, allowing organizations to tailor the identity solution to their specific security needs.
• Workload Identity is More Critical Than Ever: With the rise of AI agents and increasingly complex distributed systems, establishing verifiable and short-lived identities for every workload is paramount for making informed security decisions and maintaining control.

About the Speaker(s)

Colin Murphy is a Senior Rust Engineer at Adobe and a maintainer of the WasmCloud project. His background includes managing infrastructure for Adobe Document Cloud's services, notably Adobe Sign for GovCloud. This experience deeply informed his appreciation for robust workload identity solutions like SPIFFE and his subsequent advocacy for WebAssembly as a more secure and efficient alternative to traditional containerization, particularly in high-compliance environments.

Joonas Bergius is a Senior Software Engineer at Cosmonic and also a maintainer of the WasmCloud project. He brings deep technical expertise to the WasmCloud ecosystem, having been instrumental in pioneering the integration of SPIFFE, specifically utilizing Spire's delegated identity API, within WebAssembly components. His work focuses on building secure and scalable distributed systems with WebAssembly.