Ziti Controller And Router Behind Traefik

Support General Questions
1

I currently have both the controller and router running on non-stardard ports, with LoadBalancers.

Is it possible to have all ziti services run with ClusterIPs behind a public traefik instance that listens on port 443?

I had a quick play around, but the android tunnel would not connect to the controller.

2

I believe it's possible. I've demonstrated before running all OpenZiti behind HAProxy using SNI (different host names), running behind a traefik instance should behave identically. I don't know where or how your config is going wrong, but I certainly expect it to be possible.

2 Likes
3

Yes, it's a feature of Traefik to route requests by server name. You can use Traefik's CRDs or their implementation of Gateway API. Here's an example of each.

This branch introduces a new template in the controller chart implementing Traefik's CRDs, e.g., IngressRouteTCP: helm-charts/charts/ziti-controller/templates/traefik-ingressroutetcp.yaml at upgrade-cert-manager · openziti/helm-charts · GitHub

That branch's controller chart is the v2 (breaking changes) where I'll also introduce clustered mode, so it's just one example how you can link Traefik's CRDs to the controller pod with SNI routing on an "entrypoint" and TLS passthrough.

Here's one more example (from our prior conversation, incidentally) that is using Traefik's CRDs, this time without all the Helm templating noise, but with Ansible noise in its place: vagrant/kubernetes/k3s/playbook.yaml at 33ad7d8d95e00860db950f0df3f70d8953b0d4f5 · openziti-test-kitchen/vagrant · GitHub

Finally, if your case tolerates v1alpha2 APIs, it may not be too soon to adopt Gateway API, and Traefik makes it easy! Here's another example of using Gateway API's CRDs, e.g., TLSRoute, to accomplish the same goal, i.e., SNI routing w/ TLS passthrough: vagrant/kubernetes/k3s/playbook.yaml at deb269775b9464bdc60a691c3298d6e437732367 · openziti-test-kitchen/vagrant · GitHub

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name: ziti-controller-client-api
  namespace: ziti
spec:
  parentRefs:
    - name: traefik-gateway
      namespace: kube-system
      kind: Gateway 
      sectionName: ziti
  hostnames:
    - ctrl1.ziti.example.com
  rules:
    - backendRefs:
        - name: ziti-controller-client
          namespace: ziti
          port: 443
4

I figured it would need an IngressRouteTCP, as that is what I needed to do with the ZAC previously.
Thank you for the confirmation :slight_smile:
I will have a play with that.

That is great that you are working traefik into the chart. That will be one less seperate thing to manage :slight_smile:
Do you have an approximate release date for the v2 chart?

Also, you should update your template to change the apiVersion from traefik.containo.us/v1alpha1 to traefik.io/v1alpha1

Quoting here:

In v2.10, the Kubernetes CRDs API Group traefik.containo.us is deprecated, and its support will end starting with Traefik v3. Please use the API Group traefik.io instead.
1 Like
5

I do have one related query.
Is there an easy way to change a ziti identity from one port to another?
For example, in wireguard, you can simply edit the properties of the host/port combination and point to a new address.

Given that I intend to change everything to be through standard HTTPS/port 443, I would rather a simple edit over needing to re-enroll every identity.

6

Noted! Thanks.

No, but I'll announce it here in Discourse, and you can watch the GitHub repo for release events if a notification would be helpful: GitHub - openziti/helm-charts: various helm charts for openziti-test-kitchen projects

You want to change the Ziti controller's client API port that's used by Ziti identities' sessions. Each edge SDK's enrollment operation saves the client API URL...somewhere. Your options are:

  1. perform surgery on the saved configuration to update the URL
  2. re-enroll the identity with a JWT having the new URL
  3. replace the identity

Surgery: Like a Wireguard configuration, which has an address for its peers, the Ziti configuration file has address information for the controller. Suppose you're using an edge SDK, including a Ziti tunneler, that happens to save its configuration in a JSON file. In that case, you can edit the value of the ztAPI property, which is the controller's client API.

Re-enroll: the re-enroll (revert) authenticator API operation: Edge Management API Reference | OpenZiti and feature request to add it to the CLI ziti cli: support identity re-enrollment · Issue #2378 · openziti/ziti · GitHub

7

Thank you for all of the information :slight_smile:

Everything is working properly behind traefik with IngressRouteTCPs.

For kubernetes identities, I was able to edit the identity.json configMaps.

It would be handy if there was a built-in way to modify this field from the tunnel UIs.

At the moment, re-enrolling is a more straightforward procedure for users :slight_smile:

8

Instead of manually editing the saved configuration, edge SDKs will "learn" new controller URLs in clustered mode. For example, to change a controller URL, the new controller will be added to the cluster at the new address or port, enrollments will "learn" the new control plane endpoint, then the old controller can be removed.