tailscale: Code path in `tailscale cert` does not respect `--socket`?

@flimamacedo I’ve created a separate issue for resolving Tailscale FQDNs in cluster https://github.com/tailscale/tailscale/issues/10499. I’ve also added a possible workaround to that issue.

Let me check if there is one way to make it work

OK, do let us know if it does not work.

We are planning to make Tailscale FQDNs resolvable from within cluster too (cc @knyar ), but are currently looking for more use cases for this functionality.

(It might be that you are hitting https://github.com/tailscale/tailscale/issues/10027#issuecomment-1827763853, however I saw that your setup was working previously (?) so I assumed that you were somehow able to expose Dex with a kube DNS name)

The issue was fixed after adding the missing metadata value (namespace). In my case, my ingress was defined this way:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubeflow
  namespace: istio-system
spec:
  defaultBackend:
    service:
      name: istio-ingressgateway
      port:
        number: 80
  ingressClassName: tailscale

Thanks @irbekrm !

Yes.

@flimamacedo how/where is Dex deployed and how is it exposed to your browser and to the app? is it running in the same cluster?

Hi @irbekrm,

The app was deployed using this repository/instructions. We also have on the same repo the instructions to connect to the web app using port-forward.

Am I able to set the app URL?

Tailscale Funnel works by examining the SNI header of an incoming TLS connection to determine which tailnet it is destined for, and forwards the encrypted TLS bits to that node on that tailnet. Funnel does not possess the HTTPS certificate for your site, the node on your tailnet handles decryption and responding to any requests.

All of which is to say: Funnel cannot make any changes in the request like rewriting the URL path, it does not have the capability to decrypt the stream.

If you follow these steps and still don’t see an FQDN on Ingress’ status, the next thing to do would be to look at the operator logs.

It does not look like the operator picked it up. Did you actually create the Tailscale Kubernetes operator? Also you did not need to create a tailscale sidecar proxy as well.

The steps that you should follow are:

• create the Kubernetes operator like in https://tailscale.com/kb/1236/kubernetes-operator/#setting-up-the-kubernetes-operator
• deploy your app in Kubernetes as usual (no Tailscale proxy)
• create a Service that points at your application if you don’t already have one, for example

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  ports:
  - name: http
    port: 
    targetPort: 80 <- where ever your app container is listening to
  type: ClusterIP

• create a Tailscale Ingress that points at the Service for your app

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  defaultBackend:
    service:
      name: my-app
      port:
        number: 80
  ingressClassName: tailscale

The Tailscale Kubernetes operator will then create a proxy for you and issue certs for that proxy’s tailnet FQDN- you should be able to then access your ap via the ingress hostname that you can see on its status over HTTPS.

If you want to expose an app running in Kubernetes over HTTPs, you can use Tailscale Kubernetes operator with Ingress resource https://tailscale.com/kb/1236/kubernetes-operator/#ingress-resource. Would that work for you?

Let me check it. Thanks!