Skip to main content
This guide shows you how to run Omni on Kubernetes. This guide assumes that Omni will be deployed on a Kubernetes cluster with 1 controlplane and 1 worker node. Small differences should be expected when using different components. For SAML integration sections, this guide assumes Azure AD will be the provider for SAML. Omni is available via a Business Source License which allows free installations in non-production environments. If you would like to deploy Omni for production use please contact Sidero sales. If you would like to subscribe to the hosted version of Omni please see the SaaS pricing;

1 Prerequisites

There are several prerequisites for deploying Omni on Kubernetes. We will assume you have an Kubernetes cluster available with a CNI and CSI plugin installed.
You should not run Omni on a Talos cluster that is managed by Omni. It can be deployed on a standalone Talos cluster or another managed Kubernetes offering.

1.1 Certificates

We need to have a component that will manage SSL certificates for Omni. In this example, we are using cert-manager. The best way to install cert-manager is with Helm.

1.2 Issuers

We also need to have issuers in order to request certificates. These can be a Issuer or a ClusterIssuer. In this example we’re using DNS Challenge with CloudFlare and a ClusterIssuer.

1.3 LoadBalancer (optional)

If you want to expose Omni with a LoadBalancer service, you will need to have a LoadBalancer available in your cluster. If you do not have a LoadBalancer available, you can still expose Omni with an Ingress and a NodePort service. In this example, we are using MetalLB as a LoadBalancer in on-prem Kubernetes clusters. You can install MetalLB with kubectl apply or helm install.
We also need to configure an address pool and a L2 advertisement for MetalLB to use. This can be done with the following manifest:
If you try to create the IPAddressPool and L2Advertisement resources immediately after installing MetalLB, you might encounter an error. If that happens, please wait until the MetalLB pods are running and try creating the resources again.
If you used Helm to install MetalLB and are running a Kubernetes version that enforces Pod Security Admission Policies, the namespace for MetalLB must be labeled to allow privileged containers. Click here. for more info.

1.4 Ingress Controller

You will also need to have an ingress controller installed in your cluster. In this example, we are using Traefik, but any ingress controller should work.

2 Configure authentication

Because Omni does not have any user authentication we need to add a additional component that handles authentication. Omni supports OIDC and SAML providers, so we can use a variety of different components for this.
Create an Auth0 account.On the account level, configure “Authentication - Social” to allow GitHub and Google login.Create an Auth0 application of the type “single page web application”.Configure the Auth0 application with the following:
  • Allowed callback URLs: https://<domain name for omni on k8s>
  • Allowed web origins: https://<domain name for omni on k8s>
  • Allowed logout URLs: https://<domain name for omni on k8s>
Disable username/password auth on “Authentication - Database - Applications” tab.Enable GitHub and Google login on the “Authentication - Social” tab.Enable email access in the GitHub settings.Take note of the following information from the Auth0 application:
  • Domain
  • Client ID

3 Run Omni on Kubernetes

3.1 Create etcd encryption key

Generate a GPG key:
Do not add passphrases to keys during creation.

3.2 Deploy Omni

First we need to create a namespace for Omni to run in.
If you are running a Kubernetes version that enforces Pod Security Admission Policies. The namespace for Omni must be labeled to allow privileged containers.
Now that we have out namespace created, we need to create a secret with the GPG key we just generated. This will be used by Omni to encrypt data in etcd.
You can install Omni with Helm, but before we can do that we need to create a values file with the necessary configuration. You can use the following template as a starting point. For the full list of configuration options, please see the Helm chart documentation.
With the values file created, we can now install the Helm chart. Congratulations! You have now deployed Omni on Kubernetes.

3.3 Workload Proxy (Optional)

Workload Proxy allows you to expose HTTP services running in your managed clusters through Omni. Once configured, you can annotate Kubernetes Services to make them accessible, protected by Omni’s authentication. For details on exposing services, see Expose a Workload via Service Proxy. The workload proxy domain is not a subdomain of Omni—it exists alongside it. For example:
  • Omni: omni.example.com
  • Workload Proxy: *.omni-workload.example.com
To enable the workload proxy, you need to enable the workloadProxy component in the Helm chart values and create an additional Ingress resource with the help of extraObjects section.
You can then upgrade the updated Helm chart with this command.