Hello, I'm looking for a way to "route" Kerberos requests incoming to a single IP to different backend depending on the requested realms.
This issue I'm trying to solve is related to the scalability of automated deployment for new Kerberos realms on a cloud infrastructure. My company is an IDP startup where we currently rely only on mTLS and WebAuthN only (no password support at all), and we would also like to support also Kerberos with PKINIT. However, as a SaaS company, we need to think at the scalability and integration in our deployment pattern. Currently our production clusters use TLS SNI to evaluate incoming communication and to route them to the appropriate tenant. Which allow us to have end to end TLS communication between our customers and their tenant. Which is mandatory for our mTLS. But without consuming one public IP per tenant to keep cost under control. Here with Kerberos, I'm wondering how we can achieve something equivalent, using a shared IP for multiple Kerberos realms and having the incoming requests routed to the appropriate backend by some kind of inspection. Current solution we seen require to write custom decoder for existing ingress solutions. But before going that way I prefer to ask if another solution exist. Is there a way to deploy some kind of proxy/router in between clients on a public network and different KDC inside our different Kubernetes namespaces? Best regards Yoann Gini ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
