Skip to main content
A Helm chart to deploy Omni on a Kubernetes cluster.
This chart is for new installations only. Upgrading or migrating from the deprecated v1 chart is not supported. All new Omni installations should use this chart. Only Omni 1.5.0 and above is supported.
For all available configuration options, see the values.yaml file and the Values section below.

Installation

1. Generate an etcd Encryption Key

Omni requires a GPG private key to encrypt its database. If you don’t have one, generate one with:

2. Create a values.yaml file

Create a values.yaml file with your configuration. See the example below.

3. Install the Chart

The chart version corresponds to the Omni release version, but with a major version of 2 instead of 1. For example, Omni v1.7.2 maps to chart version 2.7.2.
To upgrade an existing installation:

Authentication

One of the following authentication providers must be enabled and configured under config.auth:
  • auth0 - Auth0 authentication
  • saml - SAML authentication
  • oidc - OpenID Connect authentication
Additionally, at least one initial admin user must be specified in config.auth.initialUsers.

Example

For Omni configuration reference, see the Omni config schema. This example uses the Traefik ingress controller and cert-manager for TLS certificates (with a wildcard certificate for *.example.com). The example assumes three DNS entries pointing to your ingress controller:
The main service serves both the web UI and all gRPC APIs (Omni API and Talos API proxy) from the same port using h2c (HTTP/2 cleartext). The backend demuxes traffic by Content-Type header, so no separate gRPC ingress is needed.

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 an HTTP Service from a Cluster.

Domain Structure

The workload proxy domain is a subdomain of Omni. For example:
  • Omni: omni.example.com
  • Workload Proxy (with subdomain proxy): *.proxy.omni.example.com
  • Workload Proxy (with empty subdomain): *.omni.example.com
Exposed services have URLs in the format:
For example:
  • With subdomain: proxy: https://grafana.proxy.omni.example.com/
  • With empty subdomain: https://grafana.omni.example.com/
Where:
  • <prefix> is randomly generated, or user-specified via a Service annotation (dashes are allowed, e.g., my-grafana)
  • <subdomain> is the value of config.services.workloadProxy.subdomain (can be empty for the simplest setup)
  • <omni-domain> is the full domain of your Omni installation
Without useOmniSubdomain: true, the proxy domain is placed as a sibling of Omni (e.g., *.omni-workload.example.com) with a different URL format. This is not recommended for new installations.

Requirements

To set up workload proxy, you need:
  1. Enable workload proxy in values:
  2. Wildcard TLS certificate for *.<subdomain>.<omni-domain> (e.g., *.proxy.omni.example.com). You can use cert-manager to create one.
  3. Wildcard DNS record pointing *.<subdomain>.<omni-domain> to your ingress controller IP address.
  4. Ingress/routing rule to route traffic matching *.<subdomain>.<omni-domain> to the Omni service. Standard Kubernetes Ingress does not support wildcard hostnames well, so you may need to use ingress controller-specific resources.

Traefik Example

With Traefik, you can use an IngressRoute custom resource via extraObjects:

Values

Here are the configurable parameters of the Omni chart and their default values.
Some configuration options are not listed here, as they are commented out in values.yaml.For the full list, refer to the values.yaml file and the Omni config schema.