Question: Access a directory through a running Wasm plugin

[aleksousa]

Hello everybody. I'm a beginner in Rust and Wasm, so this doubt can be something very simple.

During the execution of my plugin, I'm trying to access a directory to search for a configuration, which is constantly being updated, but the code presents the following error message.

wasm log my-vm: cannot open config file: Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/etc/envoy/config.json\" could be opened" }

This is the snippet of my code that tries to access the file:

let result = File::open("/etc/envoy/config.json");
    match result {
        Ok(f) => {
            let reader = BufReader::new(f);
            let config: Config = serde_json::from_reader(reader).unwrap();
        },
        Err(status) => {
            error!("cannot open config file: {:?}", status)
        }
    }

and this is the command I'm using to generate wasm:

cargo build --target wasm32-wasi --release

is this a possible operation today in proxy-wasm? If so, would anyone know how to help me?
Tks.

[PiotrSikora]

This is on the roadmap (see: envoyproxy/envoy#22557, proxy-wasm/proxy-wasm-cpp-host#127), but it's not implemented yet.

As for the workaround for accessing Envoy's configuration, you might want to use HTTP callouts to access the admin port and fetch config from there. It will include dynamic parts as well, whereas local file will not.

[aleksousa]

Thanks for the reply @PiotrSikora .

Just to confirm if I understood correctly.
Today I can't open a file (any file, a txt for example) by the plugin running, correct? In your answer I was in doubt if you had understood that I wanted to access the envoy.yaml configuration file, which was not my case. I was trying to access another file, which would serve as a basis for my plugin.

About your suggestion, would it be to use get_plugin_configuration? If not, could you give a small example?

Thanks in advance

[PiotrSikora]

Did you look at examples/http_config? Does it address your use case?

[aleksousa]

Yes, I already knew the example. I use the feature of capturing the settings defined in the envoy.yaml file via get_plugin_configuration in other contexts, but maybe my current use case is too specific.

We use a WasmService plugin that every 30-60 seconds grabs a new configuration and updates the shared_data to be used in http wasm filters. This configuration is very extensive, reaching a few thousand lines. Also, we are unable to update the envoy.yaml file frequently due to internal security rules and flows.

Initially we were getting the configuration via http request using dispatch_http_call, but we needed to change to an approach using a file made available in an instance directory and read by the plugin for performance and security reasons.

[antonengelhardt]

@aleksousa If you want to use dispatch_http_call, you can use that in a RootContext (inside the on_tick-Function) which gets the config, handles it and creates HttpContexts with that config. I also did that in my OIDC Plugin...

[aleksousa]

@antonengelhardt, Initially we were using dispatch_http_call, but as the plugin runs on millions of instances (multiple instances of various applications) all querying the same API to fetch the settings, this was becoming an issue.

Using a request to the Envoy admin to update the configuration and using get_plugin_configuration is also not feasible because as I said there are millions of instances. The ideal for us would be to make the configuration available in one place and each instance download and read the file.

We managed to do this by adding the configuration file in json format to AWS S3, and calling dispatch_http_call to fetch it from there. It works, but we are still analyzing other points.

[aleksousa]

Thanks for the help.

[PiotrSikora]

Did you consider using ECDS to update only Proxy-Wasm plugin's configuration and not "complete" envoy.yaml, or is that also not possible due to security rules?

In any case, the read-only file access is expected to be available in the foreseeable future (Q4-ish?), but that's probably better tracked in one of the linked host-side issues, since there are no changes in the SDK required to support it, the only missing parts are on the host side.

[aleksousa]

Good morning @PiotrSikora .

I reopened the issue because I hadn't seen your response, but I still have a question. Does ECDS work for WasmServices?

From what I saw in Envoy, there is still no ECDS support for bootstrap_extension (link)