Hello, great to find this project! I would like to replace our current Zero Trust network with Open Ziti. I need to connect it to our Kubernetes cluster and to our Aurora databases.
Can I self host Open Ziti on a private Kubernetes cluster in a private AWS VPC and still reach it from my local machine?
If I bring up a second Kubernetes cluster with Open Ziti on it in the same network, do I need any special configuration to make sure both are mutually discoverable and do not conflict?
How can I use the Open Ziti on the Kubernetes cluster to enable me to connect to the Aurora database from my local machine?
Hi @sarasensible, welcome to the community and to OpenZiti (and zrok and BrowZer)!!
Well, the answer will be "it depends". ENTIRELY private, meaning no ingress, right? A qualified "not by itself" as there will be no way to get traffic into the cluster whatsoever. You need at least the controller's edge api and at least one edge router available on the public internet (or whatever network, but here we're talking public internet). All other resources can be private. If you wanted, you could put a separate OpenZiti instance up - away from the cluster and then you could do a 100% offline with no "k8s ingress" but I don't think that's what you actually want/need, is it? You can keep the kubernetes API entirely off the internet though that would be a good idea and only access it via the OpenZiti overlay. You'll be able to access your cluster via OpenZiti, yes. kubectl, helm etc would all work fine.
I'm afraid I've never dealt with multiple clusters and interacting amongst them. There are other forum members that I have I believe, but i'd image the only right answer is "it depends on what you mean". OpenZiti solves networking needs elegantly, so it can solve the issue of two clusters being in different networks easily so the clusters are able to communicate to the other, but I don't have a foundational understanding of multi-cluster k8s to be able to have an intuition as to what you mean. You might need to describe that in more detail. I'll also point other people to the post to see if they have other clarifying questions. Maybe a specifc example you have in mind would help?
This one is easy. Here, you would follow a few steps:
deploy an OpenZiti overlay network "somewhere" (same k8s cluster if you like or elsewhere)
deploy one or more OpenZiti routers into your kubernetes cluster and have it join the OpenZiti overlay
create a service and configs for the Aurora database
authorize the k8s router to "bind" the aurora service meaning the k8s router is an 'exit point' for the traffic from clients
create and enroll an identity for your local tunneler software (mac/linux/windows etc)
authorize your identity to "dial" the aurora service meaning your tunneler will intercept traffic and send it to the database
I think that covers everything, it's not a "final answer" but we can iterate and figure out how OpenZiti can help out. hth
Great to see you in here Clint! Thanks so much for the quick response!
We definitely have public facing ingress on there so I'm talking more about the control plane and the API as you hinted at. So that checks that box, excellent.
I don't necessarily need the clusters to talk to each other, I'm more concerned about the scenario in which auto-provisioning spools up Open Ziti on one cluster, then we need to bring up a second cluster for disaster recovery or just as a back-up in general in the same vpc. Will the second cluster try to "take over" the network if the first cluster is the access point for everything? Happy to get anyone's hot take if they have experience trying this out.
Great to hear the Aurora connectivity is a no brainer. I checked out your Youtube vid on private postgres (which is what we run) and I saw you were referring to a VM so I wasn't sure if it was required that the db be on a VM as opposed to in a managed service like Aurora.
Say hi to Dave and Bill for me, it's been what /checks watch ... ten years?? Awesome to find you guys fighting the good fight over here!
Ah, yes. That's one I'll probably have to run by @qrkourier, he is manning our kubernetes effort and probably has a better take on this. In that scenario, I would expect the second cluster to simply have one or more edge routers deployed within the cluster, providing the reach and extending the OpenZiti overlay. We are working towards making that process automatic but at the moment I believe the routers would need to be brought online when the cluster was (or after). @qrkourier can you comment more on that process?
No, the important part is that the Aurora service can be made entirely private. It should not have a public IP address. The OpenZiti router would provide reach into whatever subnet/VPC you decide to deploy it to. The edge router(s) would just need to be able to connect to the database and then you'll be able to make connections from anywhere to it with a sufficiently authorized OpenZiti identity.
I think you're wondering if Ziti software uses any broadcast protocols that would prevent them from co-existing on the same subnet. No, all the components in a Ziti network use specific addresses, which can be a unicast IP address or domain name.
