I have worked over the past week to create a “system extension” for Talos OS allowing to connect to API of Talos using OpenZiti overlay network! Not only that but you could also serve your k8s services directly from the node within the default Talos k8s pod network.
There were multiple hard points to solve. From having the build for ziti-tunneler-sdk-c to fail on Alpine Linux(thanks scareything for a fast resolution), to trying to figure out how to force building a fully static binary of the tunneler. As well as figuring out that only hosting is allowed(no dialing) in this particular state of networking stack of Talos.
It's been a great week diving deep into ziti-tunneler-sdk, to see how it works and how it evolved into having run-host mode.
Merge request is still being reviewed but I hope it would get merged soon.
In the meantime you could either build an installer yourself and include my openziti image.
Or just use my installer that I built which includes openziti tunneler.
Hope that OpenZiti sees more adoption through this.
If we can find a compatible build configuration, a Talos extension would be very cool. I'll follow those PRs.
Summary of the PR conversations thus far: Talos needs to build the tunneler from the source with pinned dependencies. However, many build dependencies were perceived as friction or a liability. Alternatively, OpenZiti can ship a static variant of the release binary.
Are you aware of the tunneler daemonset? This is not equivalent to baking the tunneler into Talos OS, but you could do something similar like this daemonset to ensure that ziti-edge-tunnel run-host is always active on worker nodes. The daemonset seems like the most natural way to ensure one tunneler per node, but it would probably need to be modified (or customize the input values to the chart) to change the tunneler run mode to run-host and stop running in privileged mode, which is only necessary for creating routes. There would be no need for the CoreDNS node local cache in this case because the tunneler is not providing DNS.
Still, the run-host mode does not require elevated privileges, and you might need to control which Ziti identity is running in specific Kubernetes namespaces. You could configure this Helm chart openziti/ziti-host that provides a reverse-proxy pod. The same Ziti service hosting functionality can also be achieved by deploying the openziti/ziti-router chart in "host" mode.
Yeah, I am aware of the DaemonSet for k8s, but I wanted to have an alternative to Tailscale for controlling Talos using OpenZit overlay, as well as contributing to OpenZiti to see its adoption in Talos community as well.
Alright, good news.
Meanwhile the merge is getting done, I managed to create a routing rule to route traffic to the overlay.
So it is now possible not only to host, but also to dial other services!