[External] Re: kprop across NAT boundaries (patching privsafe)

[Jorj Bauer]

Thanks for pointing it out. No, it’s not sufficient:

    ./kprop/kpropd: Incorrect net address while decoding database size from client

Both the source and destination address are changed in flight.

The kprop request (let’s say 10.0.0.10/24) contacts a load balancer (let’s say 10.1.0.10/24), which forwards to an ingress (10.1.3.220/25) which forwards to a pod (10.42.0.224) which is running kpropd in a container. From the kpropd service’s perspective, the source is the ingress (or perhaps the load balancer, depending on specific configuration) and the destination is the pod. From the kprop request’s perspective, the source is the kprop server and the destination is the load balancer.

I think there is one possible architecture where that patch is sufficient to make it work in a kubernetes cluster behind a load balancer - where the load balancer is using SNAT and where the service is not using an ingress in k8s (but is directly presenting on the network). That architecture isn’t feasible for me: it would mean having the entire k8s infrastructure behind SNAT (which creates other intercommunication problems), and it would mean bypassing the k8s ingress that’s being used to load balance while dynamically scaling deployments based on current load.

— j
On Jan 6, 2021, 8:56 PM -0500, Greg Hudson <ghudson at mit.edu>, wrote:
On 1/5/21 11:17 AM, Jorj Bauer wrote:
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.

1.18 and 1.19 beta have this commit:

https://github.com/krb5/krb5/commit/775e496aac2650343ec20826b1ba7f6306a12f3c

Is it not sufficient?