Build self-serve developer platforms in minutes, not months with out-of-the-box Kubernetes multi-tenancy, virtual clusters, cloud-based dev environments, customizable templating, and more.
We want to use "wildcard" TLS certificates to stop relying upon third-party certificate authorities for each new deployment. This should increase reliability and sometimes speed of new deployments. The easiest way to implement this is to use a single wildcard TLS certificate for all deployments. This requires that all deployments be subdomains of a single domain.
For example, a certificate for *.example.com will match foo.example.com but will not match foo.bar.example.com. As Wikipedia says:
[...] the wildcard only covers one level of subdomains (the asterisk doesn't match full stops.)
Maybe we can easily change how our app generates hostnames to only use a single level of subdomain. This could be as easy as replacing . with -. Other tickets will describe changes to our controller and infrastructure.
This is a feature we want to become the most common case, so I don't think we need a feature "gate" like an environment variable.
We want to use "wildcard" TLS certificates to stop relying upon third-party certificate authorities for each new deployment. This should increase reliability and sometimes speed of new deployments. The easiest way to implement this is to use a single wildcard TLS certificate for all deployments. This requires that all deployments be subdomains of a single domain.
For example, a certificate for
*.example.com
will matchfoo.example.com
but will not matchfoo.bar.example.com
. As Wikipedia says:Maybe we can easily change how our app generates hostnames to only use a single level of subdomain. This could be as easy as replacing
.
with-
. Other tickets will describe changes to our controller and infrastructure.This is a feature we want to become the most common case, so I don't think we need a feature "gate" like an environment variable.
Be mindful of RFC 1035 which specifies "Labels must be 63 characters or less."! https://datatracker.ietf.org/doc/html/rfc1035