Generate the datastore-token on deployment instead of by hand #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Originally filed by @coilysiren on 2026-05-22T20:32:57Z - https://github.com/coilysiren/backend/issues/88
Problem - the
datastore-tokenis minted by hand. It lives in SSM/coilysiren/backend/datastore-tokenand is hand-mirrored into theDATASTORE_TOKENGitHub Actions secret, so two manual copies have to be rotated together. The token is functionally a deploy secret with no human meaning. There is no reason a human should ever generate or touch it.Proposal - generate a fresh random token as a step in the deploy pipeline. Write it to SSM
/coilysiren/backend/datastore-tokenas a SecureString. The ExternalSecret indeploy/main.ymlalready syncs SSM into the cluster, so the running service picks up the new value with no further change.The GHA-secret mirror only exists so the release pipeline can POST CI status with the token. Once the deploy job mints the token itself, that run has the value in hand as a step output, so the
DATASTORE_TOKENGitHub Actions secret can be retired entirely.Effect
Touch points
coilysiren/backend- add a generate-and-write-to-SSM step.deploy/main.ymlExternalSecret - likely unchanged, it already reads SSM.DATASTORE_TOKENGitHub Actions secret.SSM.mdinagentic-os-kai- the "mirrored as a GHA secret, rotate both together" note goes away.Watch out - rollout ordering. The deploy should write SSM early enough that the ExternalSecret syncs before the new pods roll. During the overlap window, pods still running the old token will fail auth. A rolling restart gated on the secret sync, or accepting a short auth blip, needs a deliberate call when this is built.
Origin context: SSM entry
/coilysiren/backend/*, coilysiren/backend#65 and #79.