Skip owner references on user secrets when secret deletion is disabled - #3165
Merged
FxKu merged 2 commits intoAug 11, 2026
Conversation
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.
- 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
adshin21
requested review from
FxKu,
Jan-M,
idanovinda,
jopadi and
mikkeloscar
as code owners
August 11, 2026 09:54
Contributor
|
👍 |
idanovinda
approved these changes
Aug 11, 2026
github-project-automation
Bot
moved this from Good state for merge
to Done
in Postgres Operator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3162
enable_secrets_deletion: falseis supposed to keep user-credential Secrets when apostgresqlCR is deleted. The operator's ownCluster.Delete()does guarddeleteSecrets(), butgenerateSingleUserSecretattaches a controllerOwnerReferenceto every generated Secret wheneverenable_owner_referencesistrue, and K8s garbage collection then removes the Secret independently of the operator's deletion logic. This madeenable_secrets_deletion=falsea no-op wheneverenable_owner_references=true.This PR makes
generateSingleUserSecretskip the controller owner reference on user-credential Secrets wheneverenable_secrets_deletionisfalse, so the two flags compose as documented.How to reproduce / verify
With
enable_owner_references: trueandenable_secrets_deletion: false, delete apostgresqlCR — the user-credential Secret now survives.With the default (
enable_secrets_deletion: true) the Secret still cascades-delete as before. See #3162 for the full reproduction steps.Notes
TestGenerateSingleUserSecret_OwnerReferences) covers all four flag combinations plus the cross-namespace cases.