Sealed-secret / existing secret support

For my clusters, I use gitops and sealed secrets to consistently represent the secrets in my cluster without exposing them or randomly generating them.

I am running v1.13.0 of the operator and a v16 postgresql db, on kubernetes 1.31.0. Notably I also have the configKubernetes.enable_owner_references=true option enabled for ArgoCD to be able to see the resources which contributes in part but wholly necessary.

My problem summary is that I cannot find a clean way to use an existing secret with a user definition for a given postgresql database:

• There appears to not be a way to reference an existing secret in v1.13.0 for a user's name and password.
• Alternatively, if I autogenerate a user then force replacement with an existing secret its list of owner references is emptied, and it now only references the postgresql CRD, along with requiring some manual intervention breaking automation. I would have expected that the owner reference would have been extended rather than replaced.

Are there any current ways to reference an existing secret for a database user's password in particular? I do not mind the lack of secret rotation.

Start by tracing the operator's reconciliation of PostgreSQL users and their Kubernetes Secrets, then inspect how owner references are assigned or replaced. Confirm the supported design for referencing an existing password Secret and preserving or extending owner references; done means the workflow works without manual intervention and without requiring secret rotation.