secrets(kuma): rotate the Uptime Kuma password that AutoKuma logs in with #347
No reviewers
Labels
No labels
backlog
bug
enhancement
in-progress
review
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ymrtech/nix-config!347
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "task/kuma-pw-rot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
secrets(kuma): rotate the Uptime Kuma password AutoKuma logs in with
uptime-kuma-autokuma-envheld a Kuma login that no longer matches theaccount: the value in the store fails bcrypt verification against the live
user row (
bcrypt.compareSync(env_password, user.password)= false) and alogin attempt with it is rejected ("Incorrect username or password for user
truva"). AutoKuma was only still working because it kept the session it
opened before the account password was changed at the issuer - the next
autokuma restart would have taken declarative monitor reconciliation down
with it. The value is rotated here to one that is known-good again.
Rotation was done at the issuer with Uptime Kuma's own reset path
(
extra/reset-password.jssemantics:User.resetPassword+ a freshinitJWTSecret), then verified by logging in over the local socket withthe new value (accepted) and the old one (rejected).
Also declares
restartUnitsfor the secret: AutoKuma reads its login fromthe environment file at start, so the rotated value only takes effect once
the unit is restarted - without it the deploy would leave the old password
in the running process until something else happened to bounce it.
`uptime-kuma-autokuma-env` held a Kuma login that no longer matches the account: the value in the store fails bcrypt verification against the live user row (`bcrypt.compareSync(env_password, user.password)` = false) and a login attempt with it is rejected ("Incorrect username or password for user truva"). AutoKuma was only still working because it kept the session it opened before the account password was changed at the issuer - the next autokuma restart would have taken declarative monitor reconciliation down with it. The value is rotated here to one that is known-good again. Rotation was done at the issuer with Uptime Kuma's own reset path (`extra/reset-password.js` semantics: `User.resetPassword` + a fresh `initJWTSecret`), then verified by logging in over the local socket with the new value (accepted) and the old one (rejected). Also declares `restartUnits` for the secret: AutoKuma reads its login from the environment file at start, so the rotated value only takes effect once the unit is restarted - without it the deploy would leave the old password in the running process until something else happened to bounce it.