- Omni
- Image Factory
- Container registry
- Authentication service
When running Talos with Omni you do not need to run additional services such as the Discovery Service because discovery functionality is built in to Omni.If you already have services such as a container registry, authentication service (SAML or OIDC), or a trusted certificate authority you can skip those sections of the guide. This guide will set up proof-of-concept deployment to get you started. We recommend talking with the Sidero team for production deployments.
Omni is licensed under the Business Source License and requires a support contract for production use.
Prerequisites
There are some expectations your environment has the following supporting services for the services to run. These include:- Networks that can route Talos nodes to the Omni service endpoints
- Basic networking services such as DNS, DHCP, and NTP
- An admin system that can connect to the internet to download assets
- A Linux server (e.g. RHEL, Ubuntu) to run the Sidero stack
The Sidero stack can be run on a single server or multiple servers, but we don’t recommend running Omni inside of Kubernetes for air gapped environments.In addition to these services you’ll need the following tools installed on the administrator machine and server.
Podman is known to work but has some flags that are different than docker and you may have to translate them for your version of podman.
Download required tools
Download required tools
Download static binaries of the required tools.
Docker and htpasswd should be provided by your distributions package manager.talosctlcfsslyqcraneExport endpoints
To make this guide easier to follow we will set global variables for each of the endpoints and ports we will use. Update the hostnames and ports if you change any of them from the defaults.1. Generate certificates
In order to run services securely, even in an air gapped environment, you should run with encrypted data in transit and at rest. There are multiple certificates and keys needed to secure your infrastructure.- CA certificate (root of trust)
- Domain certificates for the following endpoints
- Omni
- Authentication
- Image factory
- Container registry
- Container signing certificate
- Omni database encryption key
Create Root CA certificate (optional)
If you already have a trusted, internal root CA you can skip generating the CA (root of trust). You will need to use your existing CA to create certificates for the services in this guide. Skip to Generate endpoint certificates
cfssl command to make the CA and certificate signing easier, but openssl can be used if you have existing CA infrastructure.
ca-key.pem, a public key ca.pem, and a signing request ca.csr.
For any client that will be calling the internal services you will need to install the ca.pem file into your trusted store.
- Linux (RHEL)
- Linux (Ubuntu)
- macOS
- Windows
On Red Hat and Fedora based distros you can copy the
ca.pem file into the /etc/pki/ca-trust/source/anchors/ folder and then run the following command to generate the trusted root store:Generate endpoint certificates
Generate a single certificate that all services can use based on the CA we just created. For a production deployment you should generate individual certificates for each service. Create a signing configuration to letcfssl know we want a web server certificate that should expire in 1 year.
When using.internaldomains you will need to update your DNS server or/etc/hostsfile to make sure the endpoints resolve properly. The file should look something like this.
.internal TLD for service domains, but you can use any domain if you have it registered.
server-key.pem, a public server key, server.pem, a server signing request, server.csr, and a server-chain.pem, a server certificate with CA.
Services in this guide run with different user IDs so we will update the certificates to allow all users to read them. This is not suitable or secure for a production environment.
2. Image factory and container registry
Using the certificates we just created, follow the guide Deploy Image Factory On-prem. This will create a container registry and host the Image Factory in your environment. It will also sign container images with an offline key for verification.3. Authentication
If you have existing SAML or OIDC authentication available you can use that with Omni. Please see the configuration guides in the Authentication and Authorization section. For a PoC environment we will run dex with static users configured. Dex can be used for static configuration or to communicate with upstream providers. For this guide we will configure static users.Deploy dex (optional)
Because Omni does not have any user authentication Dex will be configured so we can log in to Omni with a static user. You will need to download the dex container from a machine that has internet access and push it to your internal registry.Download dex
Download the dex container image.Configure dex
We will create an example dex configuration to use with Omni. Create a password. Make sure you remember this password for logging in later.Run dex
Run dex with the provided configuration and certificate.
If your machine has SELinux in enforcing mode you may need to add :Z to the volume mounts in the docker command.
4. Run Omni
Omni will depend on the following URLs. If these services are not running or the hostnames do not resolve you may need to add them to your /etc/hosts file.- omni.internal
- factory.internal
- registry.internal
- auth.internal
Create etcd encryption key
Data in Omni’s database is encrypted and we need an encryption key to provide to Omni. Generate a GPG key:Note: Do not add passphrases to keys during creation.
Download Omni
Download the Omni container image. If your machine has access to the internal registry you can push the image directly. If you need to send the image to a remote machine or transfer it via an offline method you can export the container image. On the remote machine load the archive into the local image storage and then push it to the registry.Start Omni container
This will run Omni with an embedded etcd database mounted to the host. It is not recommended for production use cases. The command assumes the certificates generated earlier are available in the local directory where you run this command.We changed theThese flags mount the files and directories needed by Omni (e.g. certificates, etcd storage) and set flags to connect Omni to the upstream services (e.g. factory, authentication).--metrics-bind-addrto use port:2123to avoid port conflicts with Image Factory (if it’s running on the same host).
5. Create a cluster
Before you create a cluster you will need to generate installation media. When creating a cluster you’ll need to make sure you patch the machine config to redirect container registries to your internal registry.Download Kubernetes containers
Seed the internal registry with Kubernetes container images.- Internet available
- Air-gapped
If your machine can reach the public internet and the internal registry at the same time you can copy the images internally with this command.
Create installation media
The first step to create a cluster is to boot machines and connect them to Omni. In order to do that we will need to embed the self-signed CA certificate into Talos. Create a configuration for a TrustedRootsConfig:- Embedded config (Talos 1.12+)
- Kernel args (Talos 1.11)
Create an output directory for installation media and config.Download machine join configuration from Omni. You can do this from the Omni web interface home page by clicking on the Download Machine Join Config button or if you have Create a static hosts configuration for Omni and the registry.Append this configuration to the others.Embed both configurations and create an installation ISO with
omnictl installed you can download it withimager._out directory. You can use this to boot a machine and it will connect to Omni and trust the self-signed CA certificate.
Create cluster in Omni
Guides on creating a cluster on Omni can be found at creating an Omni cluster. Because we’re working in an airgapped environment we will need the following values added to our cluster configs so they know where to pull images from. We also need to provide the CA certificate to the node so it will trust the certificate that signedomni.internal endpoint.
NOTE: In this example, cluster discovery is also disabled. You may also configure cluster discovery via Omni. More information on the Discovery Service can be found here.