Proposal
I’m trying to set up mTLS between PGBouncer and clients (where clients have certs signed by my own CA), but I’m struggling to find a "middle ground" in the current PKI logic.
The Goal:
I want to keep using PGO’s awesome default behavior—where it automatically generates the internal CA as well as the PostgreSQL and PgBouncer certs—but I need PgBouncer to also trust an external CA that I provide.
The Blocker:
In order to get auth_type: cert working, the trusted CA in PgBouncer needs to contain the CA that signed the client certs. Currently, if I touch .spec.proxy.pgBouncer.customTLSSecret to provide that CA, the operator goes into "Manual Mode." It stops auto-generating the leaf certs for PGBouncer, expecting me to manage the entire PKI lifecycle myself.
Basically, it feels like an all-or-nothing choice right now:
- Full Automation: Operator handles everything, but I can't trust external clients.
- Full Manual: I can trust whoever I want, but I lose the "zero-ops" certificate management for the cluster itself.
The "Ask":
How feasible would it be to support an additionalTrustedCAs (or similar) field in the spec?
Ideally, the controller would just take the internally generated CA and append the user-provided CA(s) into the final PgBouncer trusted CA. That way, the internal cluster components still talk to each other using the operator-managed PKI, but PGBouncer can successfully verify my external clients.
Use-Case
No response
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response
Proposal
I’m trying to set up mTLS between PGBouncer and clients (where clients have certs signed by my own CA), but I’m struggling to find a "middle ground" in the current PKI logic.
The Goal:
I want to keep using PGO’s awesome default behavior—where it automatically generates the internal CA as well as the PostgreSQL and PgBouncer certs—but I need PgBouncer to also trust an external CA that I provide.
The Blocker:
In order to get
auth_type: certworking, the trusted CA in PgBouncer needs to contain the CA that signed the client certs. Currently, if I touch.spec.proxy.pgBouncer.customTLSSecretto provide that CA, the operator goes into "Manual Mode." It stops auto-generating the leaf certs for PGBouncer, expecting me to manage the entire PKI lifecycle myself.Basically, it feels like an all-or-nothing choice right now:
The "Ask":
How feasible would it be to support an
additionalTrustedCAs(or similar) field in the spec?Ideally, the controller would just take the internally generated CA and append the user-provided CA(s) into the final PgBouncer trusted CA. That way, the internal cluster components still talk to each other using the operator-managed PKI, but PGBouncer can successfully verify my external clients.
Use-Case
No response
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response