Ideas for Ziti TV?

Minimal Ziti service hosting / workload exposing for various k8s distributions, especially Rancher and Platform9 or others with Helm

simulating policies and observing service health with ziti edge policy-advisor

When I was setting up using a QuickInstall.. I realised that the controller needs to be triggered over port 1280 even if its on the same machine.. (because I had the 1280 port closed intentionally during an install).

This caused me to think a bit around all of the different configurations... because it means that despite where you install the binaries.. the controller can be anywhere... hence you probably want to install the controller and routers separately on different machines.

So.. I thought that a good video would be how to design a configuration with maximum security.. that really pushes the limits.. not to necessarily do a full implementation.. but rather to provide a high level architecture.. and a quick start that provides a framework to do the rest yourself.

Some specific questions are

how to install only a controller on a machine.. and avoid the admin password being located in the env file. Can this be retrieved from an alternative storage facility?

how do you customise the installation of the binaries so that a controller is not included in the deployment.. maybe some of this is in the quickinstall file.. let me know where I need to start to look to better understand this

What I am really asking for is a high level physical design pattern.. and considerations that need to be taken into account that will impact its implementation.

1 Like

you don't need to use port 1280 only. The 4th quickstart button - "host ziti anywhere" will let you change the port. https://openziti.github.io/ziti/quickstarts/network/hosted.html

1 Like

it’s the entry point into the 4th dimension :slight_smile:

It would be useful to do a session that extends this topic in more detail

I am working through setting up my own ssl enabled gloang server and are currently walking on air.

There is a big of difference between getting a http server working versus https.

As I was doing a walkabout… I found some possible tips in the enroll function…

Maybe walking through this could be useful… especially how the TLS service is managed using a golang server…

Hello, how can we zitify this usecase?

Hello, Mchorfa, and welcome to the OpenZiti community. Thank you for providing the diagram. Which of the data flows do you wish to Zitify?

Hi @gnz,
The flow would go from : the CICD job → ZitiFabric-> K8s … The idea is to send artifacts from CI jos to k8s via the ziti overlay.
Thank you

There are a few main options:

  1. daemonset (tunneler per node), e.g. developer-tools/ziti-daemonset-tun.yml at main · netfoundry/developer-tools · GitHub

  2. deployment pod (tunneler per namespace…like an ingress gw)

  3. sidecars

Some of the experts with prod experience in these scenarios can provide inputs on positives and negatives of each approach if you want to share more on your specific questions, architecture, preferences or constraints. Do you have full control of the K8s, or for example is it part of a managed service from a cloud provider?

Yes, we have control over the K8s instance

Hey @MChorfa. The answer from @gnz gives a great answer and a few quick options for deploying OpenZiti into your architecture in an application non-embedded scenario.

Your first question was ‘how can we zitify this usecase’… does non-aware deliver or were you specifically looking to do a ‘zitification’, i.e., use the SDKs to embed OpenZiti natively into the application?

I believe you are looking for the former as your diagram includes Ziti Edge icons but want to check for clarity.

@MChorfa are you looking to zitify the conveyor part of your CI/CD? Your picture is called zconveyor. Are you using this by any chance GitHub - remind101/conveyor: A fast build system for Docker images. ?

Yes The idea is to collect artifact and analyses resulting from the ci/cd pipeline and send them via a zitified conveyor that connects to a ziti overlay and a zitified endpoint would process those artifacts.
I am not using the conveyor repo that was pointed out.

Can you tell us more about the conveyor you are using? What language is written in? Trying to understand if we have a sdk for it that can be used in zitification.

@MChorfa I am not sure if you already looked this up, but here is the list of SDKs available that you can use to zitify the conveyor. https://openziti.github.io/. There are examples to get you started. As long as you have access to the conveyor source code, then you can zitify it. If you have specific question about one of the SDKs, you can post them here and will be answered.

As far as the k8s is concerned, but I am not clear what you want to zitify there. Though, you can also use the ziti tunnel there if it can not be zitified. Ziti is flexible, so you don’t need to zitify both sides of your connection. You can have a deployment where one side is zitified (i.e. conveyor) and the server side can be deployed as a ziti edge tunnel for example and reach the k8s APIs. It sounds to me that is what you trying to do on k8s side. Also, if your cluster is deployed in one of the public clouds, you can also use edge router with tunnel option. The ZET would probably be deployed on the k8s, but ERwT can be deployed on the virtual network next to k8s. If you need to access the k8s APIs, then that may be a better option in my opinion. Usually, ZETs are deployed on the k8s to access applications running on it.

Thank you for your guidelines :slight_smile: I’ll get back to you if I get stuck :sweat_smile:

1 Like

It would be great if a demo of each of the different API connection methods could be included in an upcoming ZitiTV session.

I was not aware of so many different way a connection could be made.