Support for cloudflared path and originRequest parameters

[christidis]

This is a great project! This operator, along with cloudflare-zero-trust-operator can provide a smooth integration between Kubernetes, Cloudflare Tunnels and Zero Trust Policies. Thank you.

However, I am having some issues migrating my configuration to the operator.

Here's the currently supported format for the TunnelBinding CRD

>kubectl explain tunnelbinding.subjects.spec
KIND:     TunnelBinding
VERSION:  networking.cfargotunnel.com/v1alpha1

RESOURCE: spec <Object>

DESCRIPTION:
     <empty>

FIELDS:
   caPool	<string>
     CaPool trusts the CA certificate referenced by the key in the secret
     specified in tunnel.spec.originCaPool. tls.crt is trusted globally and does
     not need to be specified. Only useful if the protocol is HTTPS.

   fqdn	<string>
     Fqdn specifies the DNS name to access this service from. Defaults to the
     service.metadata.name + tunnel.spec.domain. If specifying this, make sure
     to use the same domain that the tunnel belongs to. This is not validated
     and used as provided

   noTlsVerify	<boolean>
     NoTlsVerify sisables TLS verification for this service. Only useful if the
     protocol is HTTPS.

   protocol	<string>
     Protocol specifies the protocol for the service. Should be one of http,
     https, tcp, udp, ssh or rdp. Defaults to http, with the exceptions of https
     for 443, smb for 139 and 445, rdp for 3389 and ssh for 22 if the service
     has a TCP port. The only available option for a UDP port is udp, which is
     default.

   target	<string>
     Target specified where the tunnel should proxy to. Defaults to the form of
     <protocol>://<service.metadata.name>.<service.metadata.namespace>.svc:<port>

I don't see there's support for the Origin configuration documented here and available under the originRequest key. In addition, there's no support for the path parameter which is crucial if you are exposing different services under different paths of the same fqdn.

At the moment, there's only support for the noTLSVerify parameter (which is under the spec key and not under the originRequest key).

Assumming this is fixed, TunnelBinding could support services like this which is not supported at the moment.

apiVersion: networking.cfargotunnel.com/v1alpha1
kind: TunnelBinding
metadata:
  name: svc-binding
subjects:

  - kind: Service # Default
    name: my-gpu-svc-foo
    spec:
      fqdn: my-gpu-svc.example.com
      protocol: http
      target: http://keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local:8080
      path: ^/foo
      originRequest:
        connectTimeout: 600s
        disableChunkedEncoding: true
        httpHostHeader: my-gpu-svc-int.example.com
        noTLSVerify: true

  - kind: Service
    name: my-gpu-svc-bar
    spec:
      fqdn: my-gpu-svc.example.com
      protocol: http
      target: http://keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local:8080
      path: ^/bar
      originRequest:
        connectTimeout: 600s
        disableChunkedEncoding: true
        httpHostHeader: my-gpu-svc-int.example.com
        noTLSVerify: true

  - kind: Service
    name: my-cpu-svc
    spec:
      fqdn: my-cpu-svc.example.com
      protocol: http
      target: http://my-cpu-svc.ns.svc.cluster.local:8080
      originRequest:
        connectTimeout: 30s
        noTLSVerify: true

  - name: svc02  # Points to the second service
tunnelRef:
  kind: ClusterTunnel # Or Tunnel
  name: cf-gke-operator-01
  disableDNSUpdates: true

In my example, I added a section of using different paths for the same fqdn. I have also added a use-case of using Keda-HTTP by injecting the originRequest.httpHostHeader parameter which allows me to route requests through Keda-HTTP and scale my GPU workloads down to zero.

Is there a plan to provide support for these parameters in the CRD?

[adyanth]

Yeah, any spec part of the cloudflared yaml can be provided via the operator. I started out with a few and have expanded later. Should be a straightforward one. Path wasn't even supported iirc when I started this and there is a PR for it as well #89. Will take a look soon.

Thanks for providing the use case as well!