language runtime vs application code

[pavelsavara]

I have few questions

• is there a way how to separate configuration intended for the language runtime (like dotnet) from application code (C#)
  • maybe it would suffice to make recommendations for namespaces of the keys and the convention for separator .
  • dotnet.runtime.GC.disable: "true"
  • foo.bar.baz:"quick brown fox"
• is this proposal intended for secrets ? Such as private keys, authentication tokens and passwords ?
• how does this interact with env variables ?
• how would the configuration be provided at cli ? Something like wasmtime --config-file abc.json
• if there are multiple components, each of them may need different part/scope of the configuration. In case of secrets, the other components can't really see the values. How do we express that when configuring the host ?
• is there limitation on size of the config ?
• are there use-cases for binary values ?

[pavelsavara]

for secrets https://github.com/WebAssembly/wasi-runtime-config/issues/16

[pavelsavara]

cc @Mossaka

[Mossaka]

These are great quesitons! I will give you my thoughts on some of them, but I'd like @thomastaylor312 to give a more detailed answer since he and his team implemneted wasi:config provider that is being used in production.

is there a way how to separate configuration intended for the language runtime (like dotnet) from application code (C#)

we currently don't have a guidence on how the wasi:config should be used specifically for each domain, and this is a good example showing that maybe we should provide some guidence. I like your namespaces approach

is this proposal intended for secrets ? Such as private keys, authentication tokens and passwords ?

we've been discussed how configs and secrets are different in the sense that secrets are much more sensitive. Thus I proposed #16 for a dedicated secrets interface. The general idea is that the host may not want applications to know the secret value, so there is a get function that returns a secret resource, and there is a separate reveal function to reveal the secret, which may or may not be imported by the guest Wasm component.

how does this interact with env variables?

My impression is that people are gonna use env variables to store secrets, but having a dedicated secrets interface will provide guidence on a more secure way of using them.

how would the configuration be provided at cli ? Something like wasmtime --config-file abc.json

That's up to the platform that provides host implementation of the wasi:config. Note that wasmtime is not the only one runtime. There are WasmCloud and Spin that are providing wasi:config capability to their applications. I am not sure the implementation of wasi:config in wasmtime, but I do know there is one, implemented by a community member.

if there are multiple components, each of them may need different part/scope of the configuration. In case of secrets, the other components can't really see the values. How do we express that when configuring the host ?

Hypothetically, you can have a component targets a World that only provides the API to fetch the secret, but no capability to reveal it. You can have a component (or host) that targets a World that provides the API to reveal the secret and does something with it, like signing data.

world A {
    import wasi:config/secrets-store;
}

world B {
    export data-signer;
    import wasi:config/secrets-reveal;
}

is there limitation on size of the config ?

currently no, but we should have one. A quick search tells me that Azure Key Vault has a limit of 25KB

are there use-cases for binary values ?

I don't see why not. Serialized JSON could be an use case of wasi:config.

[thomastaylor312]

Hey there! I can add some additional flavor here, but @Mossaka did a fairly good job answering things.

So with this:

is there a way how to separate configuration intended for the language runtime (like dotnet) from application code (C#)

When designing this, it was built for application code. By the time you're to a component level, the language runtime shouldn't matter. I think there is probably a need for some runtime config things, but that may be better as a separate interface or provided in a different way.

As you already mentioned, you can see an example of the secrets stuff in #16!

is there limitation on size of the config ?

We definitely should document this, but we've always anticipated this to be basically the same limitation of 1MB that wasi-keyvalue has. It shouldn't be so large as to be something that is streamed instead.

are there use-cases for binary values ?

So originally we had the value type of config be list<u8>. However, during implementation, that led to some annoying-to-use APIs for the 80% use case so we swapped it to be a string. Binary data can still be sent via base64 encoding. If you want more context about why we made the decision, see #8

how does this interact with env variables ?

This is a separate interface because many multitenant systems aren't going to provide environment variables (and don't want to support the relatively privileged wasi:cli interfaces for everything). However, once this stabilizes to phase 3, we are planning to have adapters (that could also be used with tools like wasi-virt) that can convert env vars to config and config to env vars.

[pavelsavara]

thanks for answers