I was scratching my head trying to figure out how he got Internet to access qbittorrent on a private IP, but then I read this:
"you see, at some point in time the password was bypassed for users on local network 192.168.1.0/24, however the traefik ingress lives on 192.168.1.1"
which of course is his real problem (reverse proxy, microservices). And of course he has to double down and pile on even more complexity as the solution, instead of throwing out all the crap he's stacked together and coming up with something simple, performant and sane.
I think he wants Traefik's proxied requests to come from a different subnet, that way externally you need to authenticate but internally you don't.
Personally I wouldn't bother with that and instead I would not directly expose the service to the internet at all, and just use a VPN. I don't trust that any services I run are safe to expose to the internet unless they are very intentionally designed for that.
That's fair, a VPN might've been a better approach. I've been having some weird routing issues with WireGuard, that seem to work differently based on the client, but I've not had time to sort that out.
At the end of the post I mention, that having proper separation would've helped, but again, that's a whole project...
It's not really "piling on more complexity". I already have a well-configured OIDC provider that already handles a lot of home lab software that supports OIDC natively.
For things not supporting OIDC natively there's OIDC Proxy for traefik. So in this case the solution is adding a label requesting the OIDC Proxy Middleware, and adding a redirect URL to the OIDC application.
You could argue that it's "more complexity", but routing it through a home vpn, for instance, is also "more complexity".
What, in your opinion is "simple, performant, and sane"? You casually throw that around, but never explain...
I was scratching my head trying to figure out how he got Internet to access qbittorrent on a private IP, but then I read this:
"you see, at some point in time the password was bypassed for users on local network 192.168.1.0/24, however the traefik ingress lives on 192.168.1.1"
which of course is his real problem (reverse proxy, microservices). And of course he has to double down and pile on even more complexity as the solution, instead of throwing out all the crap he's stacked together and coming up with something simple, performant and sane.
I think he wants Traefik's proxied requests to come from a different subnet, that way externally you need to authenticate but internally you don't.
Personally I wouldn't bother with that and instead I would not directly expose the service to the internet at all, and just use a VPN. I don't trust that any services I run are safe to expose to the internet unless they are very intentionally designed for that.
That's fair, a VPN might've been a better approach. I've been having some weird routing issues with WireGuard, that seem to work differently based on the client, but I've not had time to sort that out.
At the end of the post I mention, that having proper separation would've helped, but again, that's a whole project...
It's not really "piling on more complexity". I already have a well-configured OIDC provider that already handles a lot of home lab software that supports OIDC natively.
For things not supporting OIDC natively there's OIDC Proxy for traefik. So in this case the solution is adding a label requesting the OIDC Proxy Middleware, and adding a redirect URL to the OIDC application.
You could argue that it's "more complexity", but routing it through a home vpn, for instance, is also "more complexity".
What, in your opinion is "simple, performant, and sane"? You casually throw that around, but never explain...
netns, wireguard