Allow custom labels/annotations on the Secrets generated from operator-managed cert-manager Certificates #2459

Proposal

Expose a secretTemplate (labels + annotations) that the operator passes through to the Certificate objects it generates, so the resulting TLS Secrets — in particular <cluster>-ca-cert — can carry user-defined labels.

Today this is not merely inconvenient, it is impossible by any means available to a user:

• The Certificate objects are constructed in code with a fixed field set. pkg/psmdb/tls/certificate.go — caCert.Object() (:38) builds cm.CertificateSpec{SecretName, CommonName, IsCA, IssuerRef, Duration, RenewBefore} and tlsCert.Object() (:93) a similar set. SecretTemplate is never set on either.
• The CR offers no way to influence it. The entire spec.tls schema is four fields — mode, certValidityDuration, allowInvalidCertificates, issuerConf{name,kind,group}. secretTemplate does not appear anywhere in the CRD.
• The labels that are set (naming.ClusterLabels(), pkg/naming/labels.go:35) land on the Certificate object's own metadata, and cert-manager does not propagate Certificate metadata to the issued Secret — only spec.secretTemplate does that.
• There is no bring-your-own escape hatch for the CA. spec.secrets exposes ssl and sslInternal, but no field names the CA Secret; <cluster>-ca-cert is hardcoded in caCert.Name().
• Patching the generated Certificate by hand does not survive. ApplyCertificate() → createOrUpdate() → util.Apply() (pkg/util/apply.go) hashes the desired object into percona.com/last-config-hash and rewrites the live object on drift, so a manually added secretTemplate is reconciled away.

Verified against v1.22.0.

Use-Case

Automation that discovers CA material by label rather than by name — for example, a controller that publishes a key-free copy of ca.crt to clients so they can verify the server without ever being handed a private key. Selecting by label is the standard Kubernetes pattern and is what cert-manager's own secretTemplate exists to enable; without it, every consumer has to hardcode <cluster>-ca-cert, which couples external tooling to an operator naming convention and has to be special-cased per operator.

The operator already supports custom labels and annotations for Pods (replsets.<name>.labels/annotations, sharding.*), Services (*.expose.labels/annotations) and PVCs (K8SPSMDB-793). Secrets are the remaining gap — so this is a consistency request, not a new concept.

A minimal version would be a single passthrough, e.g. spec.tls.secretTemplate.{labels,annotations}, copied into CertificateSpec.SecretTemplate in certificate.go. A per-certificate variant (CA vs server vs internal) would be more flexible if you prefer.

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

Related, but not duplicates: #2323 (split-horizon cert automation), #1758 (toggle for automatic SSL cert creation), #1481 (custom issuer — closed, and the reason issuerConf exists). I could not find an existing request for custom metadata on operator-generated Secrets.