You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We will be using Talos+Omni to deliver applications/services in edge and on-prem scenarios.
Today, using Omni in SaaS model, it's no possible use a domain different than .omni.siderolabs.io
As our nodes will be mostly hosted directly on VMs managed by our customers, using .omni.siderolabs.io exposes more than what we would like what platforms we are using to our customers.
Using our own FQDN slightly reduces a bit how much our customers will see what's under the hood.
Today this is possible just using a self-hosted scenario, and we do not want to deal with that complexity.
Solution
On the step of specifying the domain to be used on omni in SaaS, create an option that allow to specify domain not directly owned by siderolabs, but owned by omni customer.
Considering that Omni uses multiple FQDNs for each Tenant, and from what I could understand these FQDNs are provisioned automatically, my suggestion is to create a subdomain and delegate this zone to the authoritative DNSs of siderolabs.
It is worth remembering that this could be the target of DNS poisoning in order to obtain some kind of access to the resources of this environment. So I suggest considering that this delegation involves DNSSEC or some other type of validation.
Alternative Solutions
As a way to avoid possible complexities with zone delegation using DNSSEC (although I don't consider this complex), perhaps the use of DNS Entries of type 65 HTTPS Binding, and respective treatment in reverse proxy certificates can alleviate a little the problem caused by the lack of DNSSEC.
Notes
No response
The text was updated successfully, but these errors were encountered:
Problem Description
We will be using Talos+Omni to deliver applications/services in edge and on-prem scenarios.
Today, using Omni in SaaS model, it's no possible use a domain different than .omni.siderolabs.io
As our nodes will be mostly hosted directly on VMs managed by our customers, using .omni.siderolabs.io exposes more than what we would like what platforms we are using to our customers.
Using our own FQDN slightly reduces a bit how much our customers will see what's under the hood.
Today this is possible just using a self-hosted scenario, and we do not want to deal with that complexity.
Solution
On the step of specifying the domain to be used on omni in SaaS, create an option that allow to specify domain not directly owned by siderolabs, but owned by omni customer.
Considering that Omni uses multiple FQDNs for each Tenant, and from what I could understand these FQDNs are provisioned automatically, my suggestion is to create a subdomain and delegate this zone to the authoritative DNSs of siderolabs.
It is worth remembering that this could be the target of DNS poisoning in order to obtain some kind of access to the resources of this environment. So I suggest considering that this delegation involves DNSSEC or some other type of validation.
Alternative Solutions
As a way to avoid possible complexities with zone delegation using DNSSEC (although I don't consider this complex), perhaps the use of DNS Entries of type 65 HTTPS Binding, and respective treatment in reverse proxy certificates can alleviate a little the problem caused by the lack of DNSSEC.
Notes
No response
The text was updated successfully, but these errors were encountered: