Secret token on both ghostcloud-kube and ghostcloud-cosmos-frontend site, loaded as an env var in both apps
Token is used to generate a deterministic hash of the deployment, using a common library on both systems
Ghostcloud frontend instructs the user to create the TXT record with the hash value.
Only the logged-in user will be able to retrieve the generated hash from their dashboard
The hash is visible on a deployment create/edit popup, or in the deployments table (tbd)
Ghostcloud-kube verifies the hash exists as a TXT record before creating the domain
Once a domain has successfully been used, we can prevent creation on both sides
Frontend: When creating a domain, do a check for an existing A record for the load balancer. If it exists with a TXT that also conforms to the hash requirements, then prevent the user from attaching that custom domain.
Backend: When creating a domain, check to see if it exists already. Kube will prevent this as well, but we can add a check to see if the domain is already registered to an existing deployment.
Ghostcloud-kube can additionally verify the presence of both A records and TXT records for every ingress domain on a daily/hourly schedule and delete ingresses that no longer conform to the requirement.
It's possible for a user to re-use an existing A record of a domain that no longer has an active site, but the record was left in place.
Describe the solution you'd like
Describe alternatives you've considered
Additional context