metalbear-co / mirrord

Connect your local process and your cloud environment, and run local code in cloud conditions.
https://mirrord.dev
MIT License
3.81k stars 104 forks source link

Support HTTP filtering in TLS traffic #2771

Open aviramha opened 1 month ago

aviramha commented 1 month ago

Today, we require traffic to be plaintext HTTP to apply http filter to it. This makes sense, as in many cases where TLS is on the pod level, it is done by a side car (mesh/nginx/etc) that terminates the TLS - but in some cases it is still the application doing the TLS. For those cases, we can support by having the user configure the TLS settings (usually file settings to where to load certificates from, which should be available in the target pod anyway)- - the issue is that it's more diverse - certificate types, tls, and mTLS.

For example, in Goland we just need cert file + key

    err := http.ListenAndServeTLS(":443", "server.crt", "server.key", nil)

Then we can have

{
  "feature": {
    "network": {
      "incoming": {
        "http_filter": {
          "path_filter": "/api",
          "tls": {
            "ports": [443, 8443],
            "certificate": "/etc/app.crt",
            "key": "/etc/app.key"
          }
        }
      }
    }
  }
}

The agent would steal that traffic, and retransmit bypass traffic as TLS - problem is mTLS ofc (also, how do we trust application? do we not verify? shouldn't be the worst but need to have this as a known thing) For mTLS we can also specify the client certificate to use, but I'd put it as another step, and develop as needed.

Also, do we transmit to local application TLS or HTTP? Probably need to support both but should develop based on what users would want.

This issue is for brainstorming and collecting use cases, and should create smaller issues that are more specific.

linear[bot] commented 1 month ago

MBE-404 Support HTTP filtering in TLS traffic