Where should I start if I want to try out or run ZITADEL?
Dev Ops Engineer
Where should I start if I want to try out or run ZITADEL?
The first step to integrate a new application into an existing infrastructure is always to determine what the requirements are and the process you need to follow until it is ready to start with the first tests. See what we prepared to make it easy for you to start with ZITADEL and how few requirements you have to try out ZITADEL in the near future yourself.
What is ZITADEL
ZITADEL is a "Cloud Native Identity and Access Management" solution built for the cloud era. ZITADEL uses a modern software stack consisting of Golang, Angular and CockroachDB as storage and follows an event sourced pattern. The Project is Open Source and we offer a SaaS solution or managed instances. Our approach is somewhat different to other open source alternatives, as we want to ship the APIs, GUIs, Database, and, if necessary the infrastructure automation, together for secure and easy day 2 operations.
To get more information about ZITADEL you can head over to our Website zitadel.com or to the published blog "Our Vision for ZITADEL" and if you want to try out ZITADEL without the hassle to prepare infrastructure or to just integrate an IAM into you application then I would recommend to use our cloud service at zitadel.com.
What is ORBOS
In this post I will sometimes mention ORBOS, which is our solution to provide you with our option of optimal automation to streamline your ZITADEL, or any other application for that matter. It consists of different types of operators, where every single one covers a different component from infrastructure to Kubernetes, ops-tooling, networking, database and also ZITADEL.
Where do I start?
As I already mentioned, if it’s just to test ZITADEL I would recommend registering your organisation on zitadel.com, otherwise there are still a lot of possible options. Our focus will be to run ZITADEL on a Kubernetes cluster, so as long as you have a Kubernetes cluster available in any way, you can use ZITADEL. Other constellations are possible as well, but we will currently only focus on running ZITADEL on Kubernetes as it brings so many advantages with the provided orchestration.
There are different points where you can start off to get a working Kubernetes cluster, if you not already have one available already:
- Managed K8s-cluster with GKE, Amazon EKS, AKS
- No available K8s-cluster, but an account on a Hyperscaler for VM provisioning (for example Google Cloud)
- No available K8s-cluster, but an account for a VM-provider(for example Cloudscale)
- No available K8s-cluster, but available VMs or servers internally
If you currently have no available cluster and don’t/can’t use any managed instances, you can use kubeadm or our product ORBOS to quickly have one up and running on any VMs or hardware-nodes you have available.
We focus fully on the operator pattern to manage our infrastructure and our applications on the resulting Kubernetes cluster, which gives us full control over the applied resources and the possibility to reconcile the current state with the desired state. For example, if you want to upgrade an application, you only upgrade the operator and the newly deployed operator will take it from there.
To make it as easy as possible upgrading to a newer version, the operators are self-reconciling, which is only possible through the orchestration-functionality of Kubernetes and provides the option to change the desired version of the operator in the respective desired state and the operator will deploy itself with the newer version.
How do I start with ZITADEL
The fastest way to start ZITADEL in your cluster is currently to use our provided ZITADELCTL and all the necessary steps are explained in our quickstarts. As result you will have two running operators in your cluster, that start ZITADEL and CockroachDB in your desired configuration. These operators can be run in two modes, the GitOps-mode, which reads the desired configuration out of a git repository, and the CRD-mode which reads the desired configuration out of an CRD inside the cluster.
Our recommendation is to run the operators in GitOps-mode, to always have the desired state reconciled into the cluster, but it’s also possible to start the operators in CRD-mode and provide the configuration you want to see in ZITADEL as CRD, which you can also reconcile with a GitOps-tool like ArgoCD or Flux if you still want to work with the GitOps-pattern.
Requirements to run ZITADEL
First off, there are minimal requirements to run ZITADEL which also depend on how you intend to use it and on what functionality you need. That being said, for this we go for a full configuration to provide an example to run ZITADEL with all functions it provides.
The requirements can be split into three groups:
- “used by ZITADEL”
- “needed to run ZITADEL”
- “optional to better operate ZITADEL”
Let’s start with the requirements which are used, to this group belongs the SMTP configuration to be able to send emails, access to a Twilio account to send SMS’s and a database to store the data which has to be CockroachDB currently.
For the group “needed to run ZITADEL” there is only the need for a domain, where different subdomains can be registered to point at ZITADEL, optional through an Ingress/ API-Gateway/ LoadBalancer which manages the connections from outside the cluster to inside.
In “optional to operate ZITADEL” are some components that are less important for a first test, but will get more important later. Most functionalities are covered through our second product ORBOS with a component called BOOM which reconciles a defined toolset. If you need to manage the infrastructure yourself and/or can’t use BOOM then take this as our recommended components to add to your ops-stack.
As with most of the current applications you have exposed metrics from ZITADEL in format of the Prometheus data model which can be handled by most current time-based databases. Some examples for this are (obviously) Prometheus, OpenTSDB, InfluxDB and a lot of others. Besides the metrics there are also logs which can be persistent to have the ability to analyse them if an error occurs.
Stay tuned for the second part where I will provide more details about our current setup to run zitadel.com.
Stefan is a software engineer specialized, amongst many other domains, in DevOps and is deeply committed to Cloud Computing. When he's not listening to music while typing away, you may spot him cruising the mountain roads by motorcycle or car.
