controller.wildcardTLS.secret - what is used for and how?

[XDavidT]

We start a new app with a TLS certificate we just generated.
I've understood from IT, the certificate is a wildcard for all subdomains under the domain that is used for our cluster, for example, our domain is devops.cls, then any subdomain under *.devops.cls will point to cluster (round-robin), and the certificate is for *.devops.cls.
I've read the docs and saw at first controller.defaultTLS.secret, but once I've started to read this one, I saw controller.wildcardTLS.secret.

1. Using this parameter, do I still need to specify a secret on other ingresses in the cluster?
2. Probably other services, will not be on the same NS of nginx, is it a problem?
3. Can someone show me an example of:
   3.1. Secret YAML, and command to deploy it? (what about namespace?)
   3.2. How to put a relevant secret name under controller.wildcardTLS.secret? (controller.wildcardTLS.secret: example/example)
   3.3. Ingress who use my nginx ingress class, and want to use HTTPS & TLS (not sure if need to specifiy http?)

[brianehlert]

You are thinking about this the exact same way I did when I first ran across it.
The 'wildcard' has no reference to this being a 'wildcard certificate' - as in it is *.domain
Instead it refers to how the certificate is used.

If fact the wildcard certificate pattern with Ingress was available long before K8s officially supported a wildcard hostname.

The pattern with a wildcard secret is that you can define it once and continue to use it without specifically referencing it again.
This pattern is unique to the Ingress resource and is legacy at this point.

Personally, I recommend getting accustomed to the pattern of defining a secret and then referencing it explicitly each time you use it.
That is the better pattern, and you will also run into in the future with the Gateway API.

Basically, a secret is a secret. Put your certificate into one, name it, reference it each time you use it.

If you want to grasp how Gateway API will be working in the future, take a look at the CRDs this project offers as they are extremely similar to the evolving Gateway API. https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/

[XDavidT]

Nice to hear I'm not alone :)
The solution of the certificate is for internal use, not for users outside the organization, so maybe have a certificate for each ingress is not relevant in my situation, but thank you