I have a single Podman stack & Podman network - ingress via Caddy with crowdsec that forwards stuff to the various things I’ve got going. All self-contained in the Podman network.
I want to put Caddy in a VM to establish a “DMZ” (separate kernel) as I’ve seen recommended for directly internet-facing infrastructure. But to do that, I’ll break my single Podman network across two “servers”.
Because it is across two “servers”, I need to publish the ports for the services on the non-VM server so that the VM can address them externally - which allows the services to talk to the internet (even if they don’t need it) and allows the services to talk to each other on published ports (before I could have separate networks for each service, so BookOrbit can’t talk to Jellyfin for instance).
How can I have the Caddy in the VM that deals with the WWW forward things to the server running everything but retain that closed Podman network topology?
And ancillary Q, what other things should be in that “DMZ” VM? Auth ODIC? Headscale? Just Caddy?
Edit: Caddy forwards everything to the Auth OIDC which forwards it along if the connection attempt is logged in. Will be adding mTLS to bypass that check eventually. That’s why I’m thinking Auth ODIC should be in the “DMZ” VM too.
And lastly, Podman networking works just like Docker networking, so any topology is transferable if you’ve solved this in Docker!
WRT = with respect to
I use pangolin as the front, which checks in with Authentik as the SSO before it lets anyone through to the actual apps. Pangolin itself acts a bit like my reverse proxy so my caddy takes a back seat and isnt used for too much. Pangolin comes with crowdsec as well.
Pangolin has a lot more going on than I expected, I thought it was just a mesh system. That might be a one-stop shop, thanks for sharing!!
Instead of caddy -> auth OIDC -> services, can you do auth OIDC -> caddy -> services? That way you can put the auth OIDC in the DMZ VM, while putting caddy in the other VM with all the services? Alternatively maybe caddy (DMZ) -> auth OIDC (DMZ) -> caddy (LAN) -> services (LAN)
If you can’t, you can always use firewalls on the services VM to prevent services from talking to each other. Preventing them from talking to the internet can be achieved by putting them in an “internal” network (if using docker compose, set “internal: true” when defining the network)
I do see Authentik can apparently act as a reverse proxy, so it can sit at the very front. But I’d lose out on caddy + crowdsec then…
I’ll have to do some reading if caddy can actually just forward to caddy, and where the TLS is terminated and all that.
And I do use the internal setting now, but I need it off if I want to publish the port on the LAN so that the VM can see the ports on the LAN. But if I can have WAN caddy do the auth check and forward along good stuff to the LAN caddy, then I’ll only need to publish LAN caddy’s port and that’s not the worst at all.
Thanks for the ideas, I’ll try to cook “caddy (DMZ) -> auth OIDC (DMZ) -> caddy (LAN) -> services (LAN)”!
How are you running podman? As a rootful systemd service or as a rootless user systemd services?
Rootful to get the cross-user networking
Edit: cross-user via running the containers withuserNS&userorvolume idmapfrom root Podman. Containers can be run by different users and share networks, but the containers don’t have root access
