Skip owner references on user secrets when secret deletion is disabled (#3165)

* Skip owner references on user secrets when secret deletion is disabled

Kubernetes garbage-collects owner-referenced secrets as soon as the
owning Postgresql resource is deleted, regardless of the operator's
own EnableSecretsDeletion check in Delete() (which only guards the
operator's explicit deleteSecrets() call, not GC). This made
enable_secrets_deletion=false ineffective whenever
enable_owner_references was also enabled, since GC removed the
credential secrets anyway.

Now the generated secrets are not removed when
enable_owner_references: true, enable_secrets_deletion: false.

* Document skip-owner-refs on user secrets when deletion disabled

- refresh inline comment in generateSingleUserSecret
- extend enable_owner_references / enable_secrets_deletion docs in
  operator_parameters.md to describe the interaction
- clarify in operator_parameters.md that the protection takes effect
  on the cluster's next sync after the setting is applied
- add third exception in administrator.md "Owner References and Finalizers"
- add TestGenerateSingleUserSecret_OwnerReferences covering all four
  flag combinations plus the cross-namespace cases

---------

Co-authored-by: Serdar Dalgıç <sd@serdardalgic.org>
This commit is contained in:
adshin21
2026-08-20 19:28:36 +02:00
committed by Felix Kunde
co-authored by Serdar Dalgıç
parent ac36814bda
commit bd7f26ef55
4 changed files with 153 additions and 6 deletions
+2 -1
View File
@@ -285,11 +285,12 @@ will differ and trigger a rolling update of the pods.
## Owner References and Finalizers
The Postgres Operator can set [owner references](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) to most of a cluster's child resources to improve
monitoring with GitOps tools and enable cascading deletes. There are two
monitoring with GitOps tools and enable cascading deletes. There are three
exceptions:
* Persistent Volume Claims, because they are handled by the [PV Reclaim Policy]https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/ of the Stateful Set
* Cross-namespace secrets, because owner references are not allowed across namespaces by design
* User-credential secrets when [`enable_secrets_deletion`](reference/operator_parameters.md#enable_secrets_deletion) is `false`, so Kubernetes garbage collection does not cascade-delete them after the Postgresql resource is removed (the `enable_secrets_deletion` flag alone only suppresses the operator's own delete path, not K8s GC)
The operator would clean these resources up with its regular delete loop
unless they got synced correctly. If for some reason the initial cluster sync