Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Custom Domain for omni in SaaS model #762

Open
fischerdouglas opened this issue Dec 5, 2024 · 0 comments
Open

[feature] Custom Domain for omni in SaaS model #762

fischerdouglas opened this issue Dec 5, 2024 · 0 comments

Comments

@fischerdouglas
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant