Add the ability to suffix a TLD to the DNS entries for intercepts
msd-olo opened this issue · comments
Please describe your use case / problem.
Currently, the DNS TLD for an intercept is the namespace name itself. This is problematic because it doesn't work well with security solutions that don't allow client side hijacking of random TLDs and it creates the ability to accidentally mask resolution for real TLDs.
Describe the solution you'd like
Add the ability to configure a suffix TLD to append to the DNS for intercepts e.g.
if I configure a TLD suffix of telepresence
then intercepts for svc.default
would become svc.default.telepresence
Describe alternatives you've considered
The immediate work around would be to include the TLD suffix in the namespace itself, but is both ugly and doesn't work if you need to intercept a service in a namespace like default
. Additionally, if you decided you need to change the suffix you would need to rename all of your namespaces.
Versions (please complete the following information)
- 2.18.1
- EKS 1.28.1
Additional context
NA
Not sure what you mean with "would become". Where would this happen? What DNS server would ultimately resolve the svc.default.telepresence
name?
Yes. My understanding that the telepresence tries to take over resolution for *.<namespace>
but a lot of orgs won't allow DNS hijacking of random TLDs so I would like functionality added to be able to specify a TLD for telepresence to use so if I set that to telepresence
then the telepresence resolver would resolve *.<namespace>.telepresence
instead of *.<namespace>
The objective would be to have everything under a defined TLD without having to bake the TLD into the namespace name.
If you intercept a workload, and run its code locally, it will connect to other services in the cluster using either just a single-label <service>
, or <service>.<namespace>
. We dispatch the resolution of those names to the cluster. If we don't, then the service running locally will no longer function. This is the normal use-case. The service running locally should have a network that is similar to what the remote service have.
So, I'm curious about what use-case it is that you want support for. Who (or what) would append the .telepresence
suffix?
Closing this as no further details were added.