Problem: multiple vsock_proxies may need to be launched

[scirner22]

Is your feature request related to a problem? Please describe.
In the enclave.toml there's a [vsock_proxy] block where the kms vsock is configured. When running the cosmos node on a separate node than the tmkms node, having a vsock proxy between 5000 and whatever port you assign to the cosmos node in the field priv_validator_laddr is needed.

Describe the solution you'd like
Allow enclave.toml to take a list of [vsock_proxy] blocks, i.e. [[vsock_proxy]], or define another field like [[additional_vsock_proxies]] if a breaking change is not desirable. This would allow launch-all to manage any number of additional vsock proxies.

Describe alternatives you've considered
Open to suggestions, but the two solutions above are the only alternatives I've come up with.

Additional context
If either of the solutions above are accepted, I can work on implementing this.

[tomtau]

@scirner22 thanks for the suggestion. Maybe one alternative would be to patch the vsock_proxy itself: https://github.com/aws/aws-nitro-enclaves-cli/tree/main/vsock_proxy to allow proxying to multiple remote hosts?
Right now, one needs to configure the allowlist for vsock_proxy: https://github.com/aws/aws-nitro-enclaves-cli/blob/main/vsock_proxy/configs/vsock-proxy.yaml
so perhaps adding a "proxy-all" option to vsock_proxy could be a more convenient solution. What do you think?

[scirner22]

That's an interesting concept. If I understand, you're suggesting a single vsock-proxy would run and on new incoming connections, dynamically create a persistent proxy? OR would you configure all at the command line so they could all be launched up front? Are either of those in the spirit of what vsock_proxy is intended for? I haven't had any problems running multiple vsock_proxies manually, this issue was more around usability so that they don't have to be managed externally anymore.

[tomtau]

That's an interesting concept. If I understand, you're suggesting a single vsock-proxy would run and on new incoming connections, dynamically create a persistent proxy? OR would you configure all at the command line so they could all be launched up front?

More of the former, because providing many command-line arguments may be a hassle... vsock_proxy requires the allowlist, so perhaps adding an extra config item there to specify the corresponding vsock ports?

Are either of those in the spirit of what vsock_proxy is intended for?

I don't know. It's probably worth opening an issue on the AWS repo: https://github.com/aws/aws-nitro-enclaves-cli/issues/new to see whether that's something they had in mind themselves or are willing to merge.
If not, we can probably go with the "Allow enclave.toml to take a list of [vsock_proxy] blocks" solution here.