Proposal
Add an optional list field spec.tls.SANs to the PerconaPGCluster CR. Entries are appended to the Subject Alternative Names of the server certificate the operator requests from cert-manager, alongside the names it already generates.
spec:
tls:
SANs:
- pg.example.com
- "*.pg.internal.example.com"
- 10.20.30.40
Use-Case
There’s already an issue for external-DNS operator integration, where the operator adds the single external hostname it manages to the certificate. That covers the case where external-DNS owns the record. spec.tls.SANs is the general escape hatch for everything it doesn’t:
• more than one external name (blue/green, per-tenant CNAMEs, legacy hostnames kept during a migration)
• wildcard names
• IP SANs for clients connecting to a VIP or LoadBalancer address directly
• DNS records managed outside the cluster entirely - corporate DNS, an air-gapped internal zone, or anything not reconciled by external-DNS
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response
Proposal
Add an optional list field spec.tls.SANs to the PerconaPGCluster CR. Entries are appended to the Subject Alternative Names of the server certificate the operator requests from cert-manager, alongside the names it already generates.
Use-Case
There’s already an issue for external-DNS operator integration, where the operator adds the single external hostname it manages to the certificate. That covers the case where external-DNS owns the record. spec.tls.SANs is the general escape hatch for everything it doesn’t:
• more than one external name (blue/green, per-tenant CNAMEs, legacy hostnames kept during a migration)
• wildcard names
• IP SANs for clients connecting to a VIP or LoadBalancer address directly
• DNS records managed outside the cluster entirely - corporate DNS, an air-gapped internal zone, or anything not reconciled by external-DNS
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response