Zero-Trust Invocations
The concept of cluster keys and issuers is a classic example of an architectural pattern based on zero trust environments. Once a wasmCloud host has authenticated with its two NATS connections (discussed next), that host is open to sending and receiving both control signals and Remote Procedure Call (RPC) traffic.
wasmCloud assumes a zero-trust environment, so even with compromised access to a NATS cluster, an attacker cannot communicate with actors and providers.
Zero Trust Invocations
Invocations are how actors communicate with other actors and providers over wasmCloud's RPC protocol.
What does it mean for invocations to be "zero trust"? In short, the host does not assume that the sender of any invocation is authorized to do so. We need to verify the invocation we received for authenticity and authorization.
This verification happens in multiple phases:
-
The first step requires that an embedded JSON Web Token (JWT) be placed on the invocation. The signature on this JWT is verified by the receiving host: the entity which signed this token must be among the list of valid cluster issuers known to the host. This prevents anyone from signing an invocation's JWT who doesn't possess one of the known keys.
-
Next, we examine the contents of the JWT. We verify that the invocation has not been tampered with after its signing by verifying the hash of the invocation's target, origin, operation, and payload.
-
Finally, we verify that the target and origin IDs in the JWT matches those of the invocation.
Key Management
Cluster issuer key seeds should be treated as secrets and stored securely.
When deployed to any real environment, key management is crucial. It is necessary to maintain a set of valid seed (private) keys and their corresponding public keys in order to provide them to hosts via host config.
Each host must be given a single cluster seed (WASMCLOUD_CLUSTER_SEED
) that it uses for signing invocations, and one or more public keys (WASMCLOUD_CLUSTER_ISSUERS
) that identify the list of valid issuers (invocation signers) in the lattice. If these values are not provided, an ad hoc key and issuer will be generated, effectively partitioning the host to a single-node lattice.
Hosts which do not share cluster issuers will not be able to communicate with each other, even though they are running in the same lattice.