Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[sdk-v2]: ability to create a custom HttpClient with custom TLS certificates/connect via proxy #249

Open
bacongobbler opened this issue Jun 24, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@bacongobbler
Copy link
Member

bacongobbler commented Jun 24, 2024

Currently, Spin's v2 SDK doesn't support self-signed server certificates which are used by almost all Kubernetes deployments, including AWS and Google. This is because we're using the web platform's fetch() API, which does not allow programs to load custom TLS certificates due to the security implications of the browser APIs.

It would be great if there was a way to create a custom HttpClient to use with fetch(). This would be an extension of the web platform Fetch API which would allow applications to load custom TLS certificates and connect via a proxy while using fetch().

See also https://deno.land/[email protected]?s=fetch&unstable=

@bacongobbler
Copy link
Member Author

@lann mentioned an idea in fermyon/spin#2596 (comment):

I think ideally we could define a standard API in terms of wasi:http, possibly using proposed WebAssembly/wasi-http#4 (TLS config was one of my use cases for that proposal).

@karthik2804
Copy link
Collaborator

I believe this will need changes upstream before the SDK can support it. @tschneidereit can you confirm that?

@tschneidereit
Copy link
Contributor

It would be great if there was a way to create a custom HttpClient to use with fetch(). This would be an extension of the web platform Fetch API which would allow applications to load custom TLS certificates and connect via a proxy while using fetch().

@bacongobbler do you think it's strictly necessary to do this in content? A potential alternative could be to add a way to specify certificates to use for specific connections in the Spin.toml manifest.

That way, content would never see the certificate, and we'd not have the overhead of loading it for every instance.

We could do the same thing for proxies, in addition or alternatively to building something on top of WASI extensions, along the lines of a sketch I did a while ago.

@bacongobbler
Copy link
Member Author

bacongobbler commented Jun 25, 2024

@tschneidereit it's not strictly necessary, no. fermyon/spin#2596 adds it to runtime-config.toml. In that PR, it would result in a runtime-config.toml file that looks like this:

[[client_tls]]
hosts = ["kubernetes"]
component_ids = ["app"]
custom_root_ca_file = "certs/ca.crt"
cert_chain_file = "certs/client.pem"
private_key_file = "certs/client.key"

Adding it to guest code would allow things like kubernetes client libraries to continue to work as expected, though. It expects to load TLS certificates from the filesystem. To work around this, we're loading certificates into the host via runtime-config and making raw fetch calls to the API.

Have you read @endocrimes's comment in that thread? Might be worth considering that use case and seeing if we may need to implement it on the guest side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants