Repository navigation
Conversation
…tered With --watch-for-secrets the controller picks up sealing keys created or restored after startup, but SealedSecrets that already failed with "no key could decrypt secret" are never retried: they exhaust --max-unseal-retries within milliseconds and nothing requeues them, so they stay Synced=False until the controller is restarted. Requeue every SealedSecret that is not known to be synced whenever a key is added or updated in the registry. Signed-off-by: Lucas Barros <lucasbarros.kam@gmail.com>
This branch has not been deployed
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
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.
Description of the change
With
--watch-for-secrets(added in #2034) the controller registers sealing keys that show up after startup, for example a key restored from backup after it was deleted by mistake. SealedSecrets that already failed withno key could decrypt secretare never retried, though: they burn through--max-unseal-retrieswithin milliseconds, get forgotten by the queue, and nothing requeues them when the key comes back. They staySynced=False(and the Secret stays missing) until the controller restarts.This change requeues every SealedSecret that is not known to be synced (no status, or
SyncednotTrue) whenever a key is added to or updated in the registry. Synced SealedSecrets are left alone, so a normal key renewal does not re-process the whole cluster.Benefits
Restoring a lost key heals the affected SealedSecrets without a controller restart, and the
Syncedcondition (and alerts/health checks built on it, e.g. Argo CD) clears on its own.Possible drawbacks
Each key add/update walks the SealedSecret cache of that controller once. Only unsynced items are queued, and the queue deduplicates.
Applicable issues
Additional information
TestNewKeyRequeuesUnsyncedSealedSecretsruns the real controller against fake clients: the SealedSecret is sealed with a key that is not in the registry, the controller gives up (maxRetries=1), then the key Secret is created. It fails on main (expected Synced=True after the key was added, got "False") and passes with the change.go test ./pkg/... ./cmd/...andgolangci-lint run ./pkg/controller/are clean.