Passing resource specific configuration to plugins

[onselakin]

How can we pass the configuration to the plugins, including authentication data? For instance, if we install a runtime to check Azure resources, how should we configure the identities that the plugins would use? They must be configured within the runtime itself, rather than on the control plane.

If we desire a path where we can install the runtime and forget about it, then we need a mechanism that allows the plugins to download their resource-specific configurations.

[gusfcarvalho]

For me, this one would probably be a case where PoC ing a plugin would already provide some info. For me it's still not clear that we can go full on WASM yet.

Generally speaking, for sensitive information, I think we can provide a path for a file which contains the credentials as expected. (and then leverage secrets mounting on k8s for instance). This interface would be an easy one to produce.

Injecting the credentials, I really don't see any other way than during the installation / UI (where the UI would essentially be a proxy to some sort of sensitive data flow). It would simply not be safe if it isn't with this flow.

[gusfcarvalho]

Added blocking here as if this issue is not solved, there is a big impact to our architectural decisions (i.e. we might need to drop plugin systems as a whole).

[onselakin]

Let's see what happens with the plugin POC first.

Even if we decide to drop it, we don't need to cram everything into a single executable. As long as all the plugins are developed in the chosen language (be it Golang or Rust), we can have a flexible system in which assessment runtimes are compiled ad-hoc, based on selected plugins.

Imagine a UI where users can select plugins and specify their configurations, or a YAML file that lists the required plugins, facilitating the compilation of a custom assessment runtime. This approach would still allow the use of desired plugins.

[onselakin]

^^ Just brainstorming some possibilities! :-D