Is there an existing issue already for this feature request/idea?

• I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?

The current Pooler interface in CloudNativePG does not allow users to customise TLS certificates for PgBouncer. This limits the ability to have full control over TLS configuration across the stack (applications → PgBouncer → PostgreSQL).

At the moment, PgBouncer reuses the PostgreSQL server certificates provided by the Cluster resource. The only configurable option in the Pooler CRD is .spec.pgbouncer.authQuerySecret, which is restricted to authentication queries against PostgreSQL (the name is also misleading).

Reasons why this is important:

• Organisations often need to manage TLS certificates independently for different stack components.
• Security/compliance requirements may mandate separation between application-side and server-side certificates.
• Consistent support for TLS configuration across PostgreSQL, PgBouncer, and applications will make CNPG more flexible and enterprise-ready.

Describe the solution you'd like

Extend the Pooler API (.spec.pgbouncer) to allow custom TLS configuration by referencing Kubernetes secrets. The following fields could be introduced:

• clientTLSSecret: Provides PgBouncer’s client_tls_key_file (private key) and client_tls_cert_file (certificate) used to accept client connections.
• clientCASecret: Provides PgBouncer’s client_tls_ca_file, the root CA for validating client certificates.
• serverTLSSecret: Provides PgBouncer’s server_tls_key_file and server_tls_cert_file, used when authenticating against PostgreSQL.
• serverCASecret: Provides PgBouncer’s server_tls_ca_file, the root CA for validating PostgreSQL certificates.

Describe alternatives you've considered

N/A

Additional context

Migration considerations:

• serverTLSSecret would replace (with broader scope) the existing authQuerySecret.
• authQuerySecret should be marked as deprecated, with admission webhooks to guide users during the transition.

Backport?

No

Are you willing to actively contribute to this feature?

Yes

Code of Conduct

• I agree to follow this project's Code of Conduct