Comment on Assign privileged port to caddy running with rootless podman
El_Quentinator@lemmy.world 1 week ago
You can use rootless caddy via systemd socket activation, here’s a basic setup:
- rootless-caddy.service
[Unit] Description=rootless-caddy Requires=rootless-caddy.socket After=rootless-caddy.socket [Service] # a non root user here User=El_Quentinator ExecStart=podman run --name caddy --rm -v [...] docker.io/caddy:alpine [Install] WantedBy=default.target
- rootless-caddy.socket
[Socket] BindIPv6Only=both ### sockets for the HTTP reverse proxy # fd/3 ListenStream=[::]:443 # fdgram/4 ListenDatagram=[::]:443 [Install] WantedBy=sockets.target
- Caddyfile
{$SITE_ADDRESS} { # tcp/443 bind fd/3 { protocols h1 h2 } # udp/443 bind fdgram/4 { protocols h3 } [...] }
And that’s it really.
You can find a few more examples over here: github.com/…/podman-caddy-socket-activation
Systemd socket activation has a few more interesting advantages on top of unlocking binding priviliged ports:
- allowing to not bind any port on the container, which itself allows to use
–network nonewhile still being able to connect to it via systemd socket, pretty neat to expose some web app while completely cutting it’s external access. - getting rootful networking performance
- starting up your service only when connecting to it (and potentially shutting it back down after some time)
Drawbacks is that the file descriptor binding is a bit awkward and not always supported. And that podman pods / kube do not support it (or at least not yet).
SinTan1729@programming.dev 1 week ago
It seems that I’d still need to modify
net.ipv4.ip_unprivileged_port_start=80in sysctl, which I don’t want to do. If I do it, the socket isn’t even strictly necessary.El_Quentinator@lemmy.world 1 week ago
TBH I haven’t played with passing caddy’s podman network to other containers, mine is a simple reverse proxy to other standalone containers but not directly connected via
podman run --network(or quadlet network). In my scenario I can at least confirm thatnet.ipv4.ip_unprivileged_port_startdoesn’t need to be modified, the only annoyance is that I cannot use a systemd user service, even though the end process doesn’t run as root.