Joonas shared the demo from his KubeCon talk on using SPIFFE for WebAssembly workload identity.
SPIFFE is a standard specification for asserting trust between software components in heterogeneous environments and zero-trust circumstances. SPIRE is the reference implementation.
This demo runs on a Kubernetes cluster, with a SPIRE server and SPIRE agent running on the cluster along with a wasmCloud host.
In Joonas’ demo, after a curl to the API gateway running on a wasmCloud host, the AWS token we get from the first endpoint can be shared securely with a second endpoint.
The tokens generated by this process are short-lived, so even if they were to leak, they would only be available for exploitation for about 5-15 minutes.
Masoud: How do we handle version mismatches in interdependent foundational dependencies, such as issues we’ve seen with wasi:io? What are the thoughts about countering this issue?
Bailey: One is we’re working really hard on “canonicalizing” wasi:io in order to basically get rid of it, dramatically reducing the blast radius of wasi:io specifically. Those types from wasi:io will be part of the component model ABI. The next thought is applying both forward and backwards compatibility for APIs.
Masoud: Forward and backwards compatibility would be great news.
Jorge: The recommendation is to deploy wasmCloud via Helm chat, but how can you deploy with two or more NATS clusters?
Bailey: Largely it will be at the NATS level, since our Helm chart uses the upstream NATS chart.
Masoud: If the config you want is available in the main Helm chart of that product (NATS or anything else), then you can also do that here, but if it’s not, then you can’t. So you’ll need to look upstream at the NATS chart to verify that what you want to achieve is possible there, and then since that chart is a subchart nested in ours, you can implement it the same way here.
