Another point to keep in mind - many distros now ship Podman instead of Docker, with Fedora being at the forefront of that change. If you‘re currently running Docker, you might want to check if your setup is drop-in compatible with Podman as some images will not work (usually related to permission or user switching, privileged ports).
Ingress controllers usually use the standard k8s services. In fact metal-lb allows workloads (like the nginx ingress controller) in the cluster to use services of type LoadBalancer, which is the default configuration. This results in an actual IP being made available to your ingress controller.
To get nginx ingress to use the external clients IP, you can configure the ingress controllers traffic policy. Using the helm chart, I used these values:
controller:
service:
# this has a bunch of downsides, but allows source-ip based access white/deny listing.
externalTrafficPolicy: Local
For the ingress IP, I configured metal-lb to receive traffic on a static IP (using IP4AddressPool and L2Advertisement CRDs from metal-lb), which is then used for the port forwarding. I’ve never tested it because I only have a single worker node, but I expect the metal-lb controller will continue receiving traffic to that same static IP if a node goes down.
I tried both voidauth and authelia and found that I really like that you can (actually must, as far as I’ve seen) configure authelias OIDC clients as configuration files. That fits a gitops style approach much better when paired with e.g. sealed secrets. It was a real pain to figure out that authelia configuration, hard agree on that… The official helm chart felt way too over-parametrized and is badly documented. The project website has a lot of basically-copy-paste configs for all kinds if self hosted software though.