Automatically configure dns subdomain for workspaces on GitLab.com

Problem

For people that want to try out using workspaces on GitLab.com today they need to register a domain name. This is likely a large source of friction (possibly more so than creating a kubernetes cluster).

Solution

If we provided automatic DNS for them (like we do for GitLab pages by default) then this could enhance adoption. It could be something like project-<project-id>.workspaces.gitlab.com and we provide a way for the user to give the IP address of their load balancer (or we figure it out automatically via the agent).

This would likely require certmanager to be installed in your cluster to provide the certificates for you because you can only configure wildcard certificates with a DNS challenge in let's encrypt. But you don't need a wildcard certificate for workspaces so long as a certificate is created for each provisioned workspace.

Technical challenges

This may not be so easy to use a single domain like *.workspaces.gitlab.com because let's encrypt sets limits of 50 SSL certs per week per registered domain (see https://letsencrypt.org/docs/rate-limits/). In this example gitlab.com, so all our users would be count towards this limit. It would probably only be feasible if we somehow got our domain allowlisted with a higher limit or we had a large pool of registered domains.

The do have a form for requesting to increase the limit (perhaps we've already gone through this process before):

If you are a large hosting provider or organization working on a Let’s Encrypt integration, we have a rate limiting form that can be used to request a higher rate limit. It takes a few weeks to process requests, so this form is not suitable if you just need to reset a rate limit faster than it resets on its own