Allow user-defined SANs in operator-generated TLS certificates via spec.tls.SANs

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

Start at the PerconaPGCluster TLS spec and trace the cert-manager request used for the server certificate, including where generated SANs are assembled. Add the optional spec.tls.SANs field so its entries are appended to the existing SANs, and verify the resulting certificate request includes user-defined DNS names, wildcards, and IPs.