add http-acl to wasi-http

[veeshi]

Similar to #6401 I added support to use our http-acl crate which allows settings ACL rules to allow/deny HTTP requests based on the:

• method
• host
• port
• scheme
• resolved IP addresses if they are in an allowed or denied range
• blocking private IP addresses
• setting the default action if no ACL match is found

This also fixes the broken IPv6 authority support in the wasi-http crate which currently just splits the authority on : and then takes the second split value as the port.

[jameysharp]

This looks like a rebase that went wrong and is pulling in commits from other branches. I think only 0b024af was supposed to be in this PR, and GitHub automatically tagging in Cranelift folks is a false positive as a result. So I'm removing the review request for Chris.

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen, @peterhuene

Details

This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:meta", "cranelift:module", "cranelift:wasm", "isle", "wasmtime:c-api", "wasmtime:docs"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle
• peterhuene: wasmtime:c-api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[veeshi]

I rebased on the 12.0 release branch so we can use this in our platform. I can see in the 13.0 pre-release wasi-http has a WasiHttp trait so this PR will no longer be needed.

[jameysharp]

I'm not particularly familiar with the status of wasi-http, but it sounds to me like you don't expect to merge this PR because we have a different solution that will meet your needs. In that case, can we close this PR?

[pchickey]

Sorry I didn't chime in earlier. We have had various wasi-http implementation plans we would get to "real soon now" for a while now.

The short version is: I don't believe that we should implement ACLs as a host functionality in any of our component interfaces, including HTTP. Instead, we want to see ACLs implemented as a component which attenuates component interfaces.

Over in the wasi-virt project, Guy has been demonstrating some of the patterns possible for component composition which interpose between the host and the user's component. In that project, he is demonstrating providing extra environment variables, a read-only filesystem image, and other basic on/off functionality for wasi interfaces.

I think the best design for an http ACL is a component generator like wasi-virt that, given an ACL, generates a component that exports a wasi-http interface to the user's component, and imports a wasi-http implementation. When wiring that export to that import, the ACL component will make any access control checks and accept (by forwarding) or reject (by returning an error) the user's import calls.

This has a bunch of advantages over building it into the host: 1. it works on any component runtime, not just wasmtime, 2. it minimizes the amount of code we need to trust in the host. practically this shows up when we cargo vet our dependencies, but that only covers safety and not correctness. 3. users (embedders) get to pick and choose whatever ACL implementation they like. For instance, #6401 is a similar, but different, implementation of this same sort of ACL. Which one is better? I personally don't know, but the person embedding wasmtime to provide some service is in a better position to know, so I want the decision be as late-binding as possible. I'd like the embedder to choose whatever attenuators that are appropriate for their needs, wasm-compose them with their user's component, and load them into wasmtime.

[veeshi]

I'm not particularly familiar with the status of wasi-http, but it sounds to me like you don't expect to merge this PR because we have a different solution that will meet your needs. In that case, can we close this PR?

Yep this PR can be closed. It was more of a proof of concept to highlight one possible solution to this problem and to give us something to work with in our platform.

I think the best design for an http ACL is a component generator like wasi-virt that, given an ACL, generates a component that exports a wasi-http interface to the user's component, and imports a wasi-http implementation. When wiring that export to that import, the ACL component will make any access control checks and accept (by forwarding) or reject (by returning an error) the user's import calls.

I wasn't aware of wasi-virt till now but it is a better approach and one which gives flexibility to end users.

[pchickey]

Thanks. Please stay in touch with what your platform needs from wasmtime, whether here or on the bytecode alliance discord.