Hi Vault Config Operator maintainers,
While looking at the DatabaseSecretEngineConfig root-password rotation path, I noticed a possible retry/idempotency issue around the status marker.
The reconcile path decides to rotate when root-password rotation is enabled and Status.LastRootPasswordRotation is zero, or when the configured rotation period is mostly elapsed:
databasesecretengineconfig_controller.go:100-L105
databasesecretengineconfig_controller.go:114-L120
rotateRootPassword then performs the external Vault operation first, and only afterwards writes Status.LastRootPasswordRotation:
databasesecretengineconfig_controller.go:136-L143
The concern is the window between those two actions:
reconcile observes LastRootPasswordRotation as zero or expired
rotateRootPassword calls instance.RotateRootPassword(ctx)
Vault root password rotation succeeds
Status().Update fails, conflicts, or the next reconcile observes stale status
next reconcile still sees the old LastRootPasswordRotation
root password rotation can be attempted again
The existing timestamp guard makes sense, but because the marker is persisted after the external rotation, a transient status-write problem can leave the controller without a durable record that the rotation already happened.
Would it be reasonable to make the post-rotation marker write more robust before allowing another rotation attempt? For example, the controller could retry/refetch on status update conflicts, or otherwise avoid re-entering the rotation branch until it has reconciled the post-rotation status.
Hi Vault Config Operator maintainers,
While looking at the
DatabaseSecretEngineConfigroot-password rotation path, I noticed a possible retry/idempotency issue around the status marker.The reconcile path decides to rotate when root-password rotation is enabled and
Status.LastRootPasswordRotationis zero, or when the configured rotation period is mostly elapsed:databasesecretengineconfig_controller.go:100-L105databasesecretengineconfig_controller.go:114-L120rotateRootPasswordthen performs the external Vault operation first, and only afterwards writesStatus.LastRootPasswordRotation:databasesecretengineconfig_controller.go:136-L143The concern is the window between those two actions:
The existing timestamp guard makes sense, but because the marker is persisted after the external rotation, a transient status-write problem can leave the controller without a durable record that the rotation already happened.
Would it be reasonable to make the post-rotation marker write more robust before allowing another rotation attempt? For example, the controller could retry/refetch on status update conflicts, or otherwise avoid re-entering the rotation branch until it has reconciled the post-rotation status.