Predictable Wildcard Certificates per Namespace in autoTLS

[voor]

/area networking

Describe the feature

I am interested in the current Provisioning certificates per namespace (wildcard certificates) capability, except I would like to leverage it in such a way that:

• I take on responsibility for making sure the secret is there per namespace. Even if that's defining some template, Knative Serving can dictate the secret name on a per namespace basis as long as it's predictable. For example, if the namespace is others then the secret in that namespace can just be default-tls-secret or it can be default-others-tls-secret etc.
• Knative Serving accepts that secret for all routes that are created inside that given namespace.

I have an organizational CA that issues certificates (let's call that PROD), and they'll do wildcards, but the process is still unfortunately manual. However, in certain environments I can also use Let's Encrypt (let's call that DEV). I can use similar installation methods in both environments (DEV and PROD) by simply dropping the ClusterIssuer into the Let's Encrypt environment ahead of time to issue a wildcard certificate (in DEV), or alternatively getting the necessary wildcard issued and placing it into the secret name (in PROD). That way my environments are consistent in their configuration.

[evankanderson]

It sounds like this is actually working, but the cluster was broken in a different way (proxy protocol was turned on).

@voor -- do we still need this? If not you can /close, but I don't want to close this if it's still needed.

Alternatively, is this something that we just need to document better?

[voor]

The only thing that might make it beneficial to keep this open is to have some way to configure the name of the secret that it's looking for. Right now if the wildcard domain is *.subdomain.example.com then the secret will be subdomain.example.com -- but it'd be nice if that could be configurable.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.