kprop across NAT boundaries (patching privsafe)

[Jorj Bauer]

Because the privsafe protocol bakes in the source and destination address and port, it’s not possible to run kprop through layers of NAT (without doing something that undoes the damage NAT does). In particular, I’m finding this to be one of the problems with being able to run Kerberos “for real” inside Kubernetes, where we have an F5 fronting multiple k8s clusters, whose ingresses fan out traffic to multiple pods inside each.

I saw a discussion on this list between 2015 and Janaury 2020, in which a brief discussion about the importance of the address in the privsafe discussion for kpropd culminated in (paraphrasing) “it doesn’t look like the address is important for this use case”.

Attached is a patch against 1.18.3 that lets kprop and kpropd specify a command line flag (“-U”) to allow unverified addresses to work. It’s a deeper hack than I would have liked, but given the current abstraction of privsafe (and the way it’s embedded in it) it seemed the cleanest approach.

Thoughts welcome. I’d love to see some solution to this problem make it in to a release in 2021, whether it’s this approach or not; if there are other approaches folks think are better, I’m all ears...

— j