telepresenceio / telepresence

Local development against a remote Kubernetes or OpenShift cluster

Home Page:https://www.telepresence.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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.