[Feature Request] Support same-level domain configuration for simplified certificate management

[Pger-Y]

Is your feature request related to a problem? Please describe. In the Production Readiness deployment guide, the documentation states the following certificate requirements:

A TLS certificate is required for the custom domains that you wish to use with Pixie. Suppose that your Pixie custom domain name is pixie.example.com. You need to obtain a single certificate that is valid for both pixie.example.com and work.pixie.example.com. Finally, create a Kubernetes secret (of type kubernetes.io/tls) named cloud-proxy-tls-certs in the plc namespace using the certificate.

Question I'm curious about the design rationale behind this domain structure. Why does Pixie require:

A 3rd level domain: pixie.example.com A 4th level domain: work.pixie.example.com

Instead of using same-level domains like:

pixie.example.com work-pixie.example.com

With the current approach, we need to purchase a specific certificate that covers both domains. If same-level domains were used, we could simply use a single wildcard certificate *.example.com to cover both. Specific Questions

What is the architectural reason for using work.pixie.example.com as a subdomain of the main Pixie domain? Are there any functional differences between the services hosted on these two domains? Would it be possible to support alternative domain configurations (like same-level domains) to simplify certificate management?

Context This question is primarily about understanding the design decisions and potentially exploring options to reduce certificate management complexity in production deployments. Additional Question - Deployment Issue I attempted to modify the nginx and envoy configurations to use same-level domains (pixie.example.com and work-pixie.example.com) so that I could use our existing *.example.com wildcard certificate. However, I encountered errors such as: Could not find hydra login state in cookie store: map[] Questions:

Is this type of domain modification feasible, or are there hard dependencies on the subdomain structure? Are there specific configuration changes needed beyond nginx/envoy to support same-level domains? Does the authentication system (Hydra) have dependencies on the specific domain hierarchy that would prevent this modification from working?

Thanks for any insights you can provide!