Going off of the documentation here, I want to configure my helm deployments to whatever the accepted standard is.
Would these chart values be correct?
Controller:
ctrlPlane:
advertisedPort: 8440
clientApi:
advertisedPort: 8441
Router:
edge:
advertisedPort: 8442
Also, what would the benefit be of exposing the ctrlPlane publicly?
You can use port 443 for everything if you're using a LoadBalancer to route requests by SNI, and you must use 443 for everything if you're using the K8s Ingress resource.
Still using K3S? It's been a minute since I installed Ziti on that distro, but it's about time for a refresher. I'll do that. As I recall, Traefik was the default ingress controller and I only needed to specify service type LoadBalancer to get hostname routing with passthrough TLS, which is a requirement for Ziti APIs because they conduct client certificate authentication.
I am using K3S, and the default ingress is traefik.
However, my ingress is not publicly exposed.
My thought was to assign ziti resources/ports LoadBalancers, and have that be the only public-facing entity, and then privately route everything to traefik internally.
Yes, that sounds like the simplest way to go with K3S's built-in Traefik. For the controller's Helm chart input values, use port 443 for all advertisedPort properties, and ensure the advertisedHost properties are identical to a domain name that resolves to the value of the ExternalIP occupied by Traefik's ServiceLB, the LoadBalancer provider.
I wrote this "Minimal Installation" section with K3S in mind because that's what I used to explore the first few versions of the controller chart when @marvkis first contributed it.
To make sure I understand the wiring:
LoadBalancer, and is exposed publicly on port 443traefik.domain.com, which needs a DNS record that is publicly available, like: traefik.domain.com A 192.168.1.100, where 192.168.1.100 is the LoadBalancer IP address for traefik, which is internal-onlyDo I have all of that correct?
The thing I am not quite seeing, is say that I have a web service handled by traefik, accessible internally via a private DNS record at service.domain.com. How will openziti resolve that DNS record to traefik?
Those two bullet points sound correct except for the "which is internal-only" part of the second one. Traefik's load balancer provider ServiceLB should assign any services in the cluster of type LoadBalancer an ExternalIP that will become visible in the "EXTERNAL-IP" column of kubectl get services output. That's the IP address to which the controller's advertisedHost domain name must resolve.
A little more colour to my configuration. All of my web services are ClusterIP only (for the most part).
Traefik has an EXTERNAL-IP, manually assigned via MetalLB.
Currently, the mechanic is to connect via a traditional VPN, which then gives access to split-horizon DNS.
This allows users to connect to traefik, which is internal-only (only accessible inside the VPN).
Addressing my first bullet point, I can give the ziti controller an EXTERNAL-IP by assigning it an IP address from MetalLB.
I am not exactly certain what to do with ziti, given that my traefik ingress is not exposed to the world.
Did I understand correctly the external IPs assigned to Traefik by MetalLB are only reachable by VPN clients, and that they resolve those IPs using a nameserver provided by the VPN?
Yes. Traefik is the only service that has an external IP address. All of the services handled by Traefik are ClusterIP. Finally, yes there is an internal/VPN provided DNS server that allows web services to be resolved.
And you want your Ziti Controller to be exposed outside the VPN so that it provides an alternative path to the cluster services?
Yes.
My thought was to have the VPN as a backup of sorts, and ziti to be a more granular control.
From what I understand, ziti provides a sort of DNS hijacking where it can intercept things like service.tld.com, so it would be able to pass things through to traefik, which would then provide the service.