FR: Kubernetes operator: make it possible to resolve Tailnet FQDNs from within the Kubernetes cluster

[irbekrm]

What are you trying to do?

Today, tailnet services can be exposed to Kubernetes cluster workloads using cluster egress proxies via the Tailscale Operator.
Once an egress proxy has been set up in a Kubernetes cluster, any cluster workload can access the tailnet service by referring to it via the DNS name of the Kubernetes Service that we create for the egress proxy.

However, in some cases, it might be required that the workload can refer to the tailnet service using its MagicDNS name
There are two known use cases, a combination of both is possible:

• For a cluster workload to access a tailnet service over TLS (assuming Tailscale HTTPS) the workload needs to use the MagicDNS name (because that's what the Tailscale HTTPS cert is issued for).
• In some cases multiple components, some of which might be running in cluster and some might be user devices on tailnet, need to be configured to use the same URL to access a service, see Code path in tailscale cert does not respect --socket? #10027 (comment)

How should we solve this?

A possible solution was implemented in #9201

We could:

• deploy a simple nameserver in the cluster
• when a Tailscale operator creates an egress proxy it could also update the nameserver with an A record for the MagicDNS name to the IP address of a Kubernetes Service that points to the egress proxy

Users would have to:

• update their CoreDNS/KubeDNS config with a stub nameserver record for their tailnet's subdomain to the nameserver that we deployed.

Any cluster workload would then be able to access the exposed tailnet service via MagicDNS name.

What is the impact of not solving this?

Folks who need to access access tailnet services over HTTPS would need to manually configure DNS to make this possible.
Folks who need to access workloads exposed via tailscale ingress from within the cluster, might not be able to do this at all.

Anything else?

No response