Open wcoateRR opened 2 years ago
Looking back I found it's possible to do this with the UI, just not obvious (you add a cert but fill in the hostname but not the cert secret), so it's not strictly necessary. I think it might be nice to make it a bit more obvious by just adding a text blurb that you can add a cert entry with no cert but just a hostname to get this functionality, but not sure it's worth a code change.
My bad on not noticing earlier.
Here is a screenshot of the form in question:
That second field is what gets added to spec.tls.hosts
:
I can see why that would get missed, as I wouldn't think to look for hosts on the Certificates tab. We should discuss with UX.
Detailed Description Please add a spot to the UI for adding/editing Ingress objects to allow populating the spec.tls.host array. The purpose of this is for cert-manager to be able to automatically issue certificates rather than requiring either a wildcard cert be set up for the IngressController or each Ingress to have its own certificate manually created outside Kubernetes and saved to a secret and added to the Ingress object.
Question asked on Slack at https://rancher-users.slack.com/archives/C3ASABBD1/p1655311710544539 and user Kevin Brewer pointed to https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources as the cert-manager docs for the functionality and Rancher dev @brandond also mentioned this is how it's done.
Context The reason I'm requesting this change is because I'm investigating Rancher in order to document procedures and how to do things to be passed off/used by a maintenance team which has historically sometimes faced a bit more turnover than is ideal. For this reason, I'm attempting to document procedures through the UIs as much as possible and reduce the need to instruct using CLI or directly editing YAML, JSON, XML, etc.
The reason that populating the spec.tls.host array is needed, is because without it the ingress seems to default to an "Acme Co" certificate for host "ingress.local" which browsers tend to reject, not allowing traffic through to the site.
I believe this will benefit other users as an ease of use convenience and, while I haven't looked at the Rancher UI code, shouldn't be high complexity to implement. So seems like a good cost/benefit ratio.