Bring your own key storage

[c00kiemon5ter]

I watched the latest wasmCloud Community Meeting - 14 Jun 2023.

I really like the idea of being able to use Vault with wasmCloud.
This would be a requirement for the things I work for.

I would certainly be interested in such a direction 👍

[brooksmtownsend]

So we can keep brainstorming here, I want to just draw out a few secret keys that wasmCloud uses throughout its lifecycle. There are:

1. Nkey signing keys: each actor and capability provider must be signed with an issuer (account) and subject (module/service) key in order to run in wasmCloud. These, if not provided at build time, are stored under ~/.wash/keys with a 600 chmod permission
2. Nkey cluster keys: Each wasmCloud host must be launched with an nkey cluster seed, and an optional strict superset of corresponding cluster public keys. This key is used to sign each invocation that originates from this host, and the issuers are used to validate incoming invocations.
3. Nkey user keys, jwts, credentials: Each wasmCloud host may use a combination of nkey user seed keys and an identity JWT, or a credentials file that combines both, in order to connect to NATS over its control interface, RPC, or provider RPC connection.

Did I miss anything here @autodidaddict? Really looking to outline where our keys are today so we can understand when wash would need to read from vault, when wasmCloud would need to read from vault, and what we could use to build something like this

[aschrijver]

I think this is a good enhancement that @c00kiemon5ter suggests. Was just discussing with someone about Mozilla SOPS vs. Hashicorp Vault. There's some comparison out there, but I am using neither atm. Hashicorp Vault is excellent, I've heard. But for me personally - and possibly to consider as a sensible default for wasmCloud too - I'd start with a support (tested integration) for SOPS. Why? Because this represents the keep-it-simple(r) approach (and Git storage is appealing to me), at the lower end of scalability requirements and the more vendor-neutral approach.

I watched the latest wasmCloud Community Meeting - 14 Jun 2023.

For reference: 2023-06-14-community-meeting.md

This key storage is like an NFR and shouldn't that mean that there'd be something like a wasmcloud:keystore capability?

Aside: I really liked this terminology of "encrypted data vault" (from Rebooting the Web of Trust conference 2019), more aligned with Solid project, the notion of "personal data vaults" that you give applications controlled access to.

[autodidaddict]

This key storage is like an NFR and shouldn't that mean that there'd be something like a wasmcloud:keystore capability?

We do have an implementation of the wasmcloud:keyvalue contract supported by Vault, allowing the actor to think it's just reading/writing simple data while Vault is securing it under the hood. Is this what you're looking for or something more integrated?

https://github.com/wasmCloud/capability-providers/tree/main/kv-vault

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!

[aschrijver]

Hashicorp received a ton of criticism with its move to BSL and many people vowing to move away from HC. I see that Vault is also under the BSL license. An argument for BYOKS :)

Really looking to outline where our keys are today so we can understand when wash would need to read from vault, when wasmCloud would need to read from vault, and what we could use to build something like this

There's likely some Rust-native vaults. Quick search found https://lib.rs/crates/secret-vault

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!

[thomastaylor312]

@brooksmtownsend did we want to keep this around and mark so it doesn't go stale?

[aschrijver]

FYI a recent development around HashiCorp and their adoption of BUSL license is that after Terraform (to OpenTofu) now the intent is to also fork Vault into OpenBao under an MPL license and as a Linux Foundation project.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!

[aschrijver]

Is it stale?

[brooksmtownsend]

Now that you commented, it's not! The stalebot is a good reminder for us to come back to issues and figure out why we haven't had movement here. I know this is something we're interested in and I think the latest development is that we know we'll likely want to serve secrets to components using something like wasi:runtime/config, but behind the scenes wasmCloud should be assisting with pulling secrets out of a store 🤔

[thomastaylor312]

Bad stalebot, this wasn't stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!