function61 / edgerouter Goto Github PK

• Same format as Apache's standard log?
• Are there any implications on logging volume with Docker? With centralized logging delivery?

Investigate if this is possible

https://github.com/function61/holepunch-server

This service exposes multiple vhosts, one vhost per each internal port, let's say:

• 8080.punch.example.com forwards to localhost:8080
• 8082.punch.example.com forwards to localhost:8082
• etc.

Now from Edgerouter perspective we would like to setup a more meaningful hostname, perhaps password protect it, and have it reverse proxy to VHOST 8080.punch.example.com BUT obviously we need to connect to the container's IP instead of IP from DNS (which would be Edgerouter again).

Therefore, maybe:

• support for generating frontend-less apps from Swarm discovery
  • the name of the app has to be stable, so we can refer to it from the static app
• support for static app backend to refer to another app's backend by name? ("backend pointer")
  • also, tolerate not finding the backend by pointer, since Docker stuff can come and go. So there are "static app -> dynamic app" -dynamics at play here

Ideas:

• Pass through the token we get from Cloudflare? That way we have a single log token for CDN -> LB -> app server -> ... ?

This will effectively implement caching at server side (due to our production system being fronted by Cloudflare).

Edgerouter does not yet cache responses from S3.

https://docs.traefik.io/middlewares/circuitbreaker/

https://github.com/cozy/httpcache/blob/3f334f841945340a0dfd2529527fdc48850d45b6/diskcache/diskcache.go#L52

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests

We could use this as a heuristic here:

Counter-argument: this allows downgrade attacks by a MITM attacker removing the header

Further analysis required

Think some microservice being used to send enormous amount of spam.

You'd want to take it offline as first mitigation, then improve anti-spam measures, then re-publish the service again.

The application should not disappear entirely (not use 404), perhaps use 503 SERVICE UNAVAILABLE
:

The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.

Edgerouter is already used by a Ubiquiti product

Pros:

• Doesn't need its own port anymore
• Can be disabled (for minimized attack surface)
• Authentication support
• Makes the core simpler
• "Prometheus metrics app" now gets all the standard benefits like request stats etc.

Cons:

• Since Edgerouter will be found via service discovery, we need to identify Prometheus requests by some way.
  • IP-based virtual hosting?
  • Or configure TLS ServerName from Prometheus side?
• Might need global variable for promhttp.Handler() so we don't make new handlers (as backends are temporary in nature)

Now we have:

{
  "id": "example.net",
  "frontends": [
    {
      "kind": "hostname",
      "hostname": "example.net",
      "path_prefix": "/"
    }
  ],
  "backend": "..."
}

We want to be able to redirect www. => naked domain. Options:

• Without writing any code, we already have a redirect backend, but our design assumes one backend per app, so we'd have to write separate app for the redirect. => not good
• Support multiple backends per app (override with redirect backend on www. hostname). This is the only use case that requires it => not good
• Just have a flag on the frontend that it should redirect to naked domain, and have Edgerouter handle that internally somehow. That feels a bit dirty though, too.

The last idea looks something like:

{
  "id": "example.net",
  "frontends": [
    {
      "kind": "hostname",
      "hostname": "example.net",
      "path_prefix": "/"
    },
    {
      "kind": "hostname",
      "hostname": "www.example.net",
      "path_prefix": "/",
      "redirect_to_naked_domain": true
    }
  ],
  "backend": "..."
}

Currently we're using Cloudflare page rules for this, but I don't like it because I like the idea of turning Cloudflare off and not having behavioural changes

https://goharbor.io/docs/2.3.0/administration/configure-proxy-cache/

Not expecting to use/need this in the long term, but basic auth access is easy to implement and explore implementing middlewares - preparing for OAuth2 or JWT-based auth.