Tunnel mix-up with multiple ngrok Instances

[dkrystki]

What happened

We use the ngrok ingress controller to expose a local kind cluster endpoint (Kubernetes in Docker) for connecting with an external service. Every developer has their own local setup with an ngrok ingress controller running. Things work fine with just one ngrok controller, but when there are two, we notice the routing mix-up. My domain's traffic ends up at my coworker's station.

I've followed the setup guide on this GitHub repo and not sure if I missed something or if it's a controller issue.

Can sharing logs or more info help fix this?

What you think should happen instead

Traffic from my ngrok domain should route to my tunnel.

How to reproduce

No response

[euank]

Thanks for the report!

I think that what you're describing is a controller issue, and I think that we have to fix something on our end.
I can reproduce the issue you're describing.

As a workaround, if everyone uses either a different k8s namespace, or a different ngrok account, that should avoid this issue. Those are only workarounds though, I do think the controller should ideally support what you're trying to do now (even though it doesn't currently).

So, why does this issue happen?
The way the ingress controller works under the hood is creating labeled tunnels and edges that match those labels.
The labels currently used are:

https://github.com/ngrok/kubernetes-ingress-controller/blob/c4387eac3270d373fd64efd351fd89e614acef3d/internal/store/driver.go#L653-L660

The edge similarly has a backend that matches those labels.

That means two different clusters with the ingress controller that have the same k8s service name, k8s service port, and k8s namespace will be identically matched or not matched by edges.

The ingress controller does have a "manager name" option which seems like it could potentially help here, but the "manager name" isn't used for tunnel labels, so it doesn't help here.

cc @nikolay-ngrok I'm curious on your take here.
Do you think we should add the "manager name" label for tunnel + edge labels too so that if people set different manager names they don't get cross-routing?

Should we have a different label for it? Should we have both the manager label, and a new "k8s-cluster-id" label?

Also, to spitball an alternative option, I think using the k8s service uid as a label, instead of trying to generate a unique selector combination by combining namespace+port+name, would also fix this, since uids will be unique.

[dkrystki]

@euank
Thanks for the quick reply and explanation!
The workarounds you discribed will not work in our case unfortunatelly.
Happy to wait for this to be fixed if it's not too difficult.

[jrobsonchase]

Also, to spitball an alternative option, I think using the k8s service uid as a label, instead of trying to generate a unique selector combination by combining namespace+port+name, would also fix this, since uids will be unique.

Yeah, I like this approach better than adding the manager name to the set of labels, since you'd then have to verify uniqueness across disjoint k8s clusters, which feels wrong to me.

[dkrystki]

Hey guys, is there an ETA for the next release that includes this fix?