Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "ignoring" a TunnelBinding? #79

Open
KAllan357 opened this issue Mar 28, 2023 · 1 comment
Open

Support for "ignoring" a TunnelBinding? #79

KAllan357 opened this issue Mar 28, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@KAllan357
Copy link
Contributor

I ended up configuring a series of TunnelBindings in an undocumented fashion and while it works, there was a funny issue that cropped up.

Use Case:

I wanted to use the disableDNSUpdates: true feature in the tunnelRef and a Proxied Wildcard in my cluster - but to also let the operator create the initial tunnel instead of bringing my own.

kind: ClusterTunnel
spec:
  newTunnel:
    name: foo
  ...
---
kind: TunnelBinding
metadata:
  name: wildcard
subjects:
  - name: dummy
    spec:
      fqdn: "*.fizz.buzz.me.com"
tunnelRef:
  name: foo
---
kind: TunnelBinding
metadata:
  name: a
subjects:
  - name: real-thing
    spec:
      fqdn: "traefik.fizz.buzz.me.com"
      target: "http://traefik.traefik.svc.cluster.local"
tunnelRef:
  name: foo
  disableDNSUpdates: true

When configured in this manner, I would get a good Cloudflare config yaml, albeit with a funky entry for "wildcard"

kind: ConfigMap
data:
  config.yaml: |
    tunnel: abc123
    ingress:
      - hostname: traefik.fizz.buzz.me.com
        service: http://traefik.traefik.svc.cluster.local
      - hostname: '*.fizz.buzz.me.com'
        service: http_status:404

When I repeated this configuration, but with slightly different name values, I noticed a different behavior:

    ingress:
      - hostname: '*.fizz.buzz.me.com'
        service: http_status:404
      - hostname: traefik.fizz.buzz.me.com
        service: http://traefik.traefik.svc.cluster.local

When the config ended up in this configuration, the first ingress would always match because of the wildcard, and the tunnel would respond with a 404. It wasn't until I renamed the TunnelBinding objects that I received a different layout of the config.

I suspect that TunnelBindings are returned alphabetically by name in getRelevantTunnelBindings and the loop here https://github.com/adyanth/cloudflare-operator/blob/main/controllers/tunnelbinding_controller.go#L561.

I was thinking there could be a feature to allow for the optional ignoring of a TunnelBinding. Or perhaps a priority number? Some sort of feature so that we could better order the resulting config.

@adyanth adyanth added the bug Something isn't working label Mar 28, 2023
@adyanth
Copy link
Owner

adyanth commented Mar 28, 2023

Oh interesting. The wildcard is added by the fallback_target on the tunnel rather than the binding. The sort order was necessary so as to not unnecessarily update the deployment just due to the order in which k8s decides to return the bindings.

I had not considered the edge case of adding a wildcard in the binding, which does cause issues. By design, the wildcard only comes in the end when using fallback_target. In that case, I think it would be ideal to use the sort order for non wildcards, and then sort the wildcards with longest matching first, and also officially allow overriding the fallback_target with a tunnel binding. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants