OK now this would make some sense but would definitely be a bit of a show stopper for me. I’ll give it a try though.
Comment on Podman: Issues with multiple users running containers simultaneously
rhymepurple@lemmy.ml 2 weeks ago
This is due to a security design deicison of Podman. Each user’s network(s) is only available to that user. This is great for most services, but can cause issues for some services - especially reverse proxies. Unfortunately, I’m not aware of an ideal solution. The only solution I’ve seen is moving the reverse proxy to another host and exposing the services’ ports on the localhost. I hope someone can provide a better solution!
MoogleMaestro@lemmy.zip 2 weeks ago
rhymepurple@lemmy.ml 2 weeks ago
I’m not trying to convince you of this solution (I personally don’t like it), but I am curious what didn’t work for you. Were you unable to get the reverse proxy to serve each service? Were you unable to have the services behind the reverse proxy to talk to each other?
Overspark@piefed.social 2 weeks ago
The solution to this can be multiple reverse proxies. Each user runs it’s own reverse proxy (if you actually need one, otherwise you let the container bind directly to a port on the host system). Then you run one main reverse proxy on port 80/443 that proxies to those other ports based on hostname.
The upside of this construction is that containers running as different users can’t directly access each others internal networks, which is much better for security, as those networks often contain barely protected services, which is why you’re using a reverse proxy in the first place.
rhymepurple@lemmy.ml 2 weeks ago
I think this is what OP was originally trying, but this approach breaks when each service’s Podman service runs on its own localhost user.
Overspark@piefed.social 2 weeks ago
You can use the per-user reverse proxies as a bridge between the host network and the user-specific internal network. So for a user coming from outside the path looks like this:
User -> main reverse proxy on main IP and port 80/443 -> user-specific proxy listening on main IP with port 8080 and proxying to user-specific internal network -> destination container listening on user-specific internal network.
And for a container running as a different user the path will be the same, but the user-specific reverse proxy will be listening on port 8081 and higher for example.
robber@lemmy.ml 2 weeks ago
No expert but don’t the logs look like the requests are coming through?
rhymepurple@lemmy.ml 2 weeks ago
I didn’t see the logs when I originally posted. However, I’m not sure what the logs indicate. It could be that nginx successfully received the request and received an authorization error from Podman’s networking stack then returned a 503 error to the client (or logged the 503 response that was returned to nginx).