Repository navigation
tribelt and estate-dashboard sign in to Postgres with rotating credentials #448
Description
Parent
What to build
tribelt and the estate dashboard sign in to Postgres with rotating credentials. Both declare credentials: on their edge to platform-postgres and read the credential as environment. Their fixed logins and cluster.sh's two database stages are removed.
Acceptance criteria
- Both Processes connect with credentials Vault issued, and survive a credential rotation.
- The
tribeltandestate-dashboardlogins are dropped, and so are their documents undersecret/<project>-system/database. -
cluster.shhas no database stage.
Activity
feat: connect with the libpq variables where DATABASE_URL is unset (#48)
feat: publish fragments with deploy-kit 0.18.0 (#161)
feat: sign in to Postgres with the rotating login the edge derives (#33)
feat: sign in to Postgres with the rotating login the edge derives (#50)
ExtraToast commentedon Oct 16, 2026
Status 2026-10-16: tribelt 0.10.0 and estate-dashboard 0.5.0 sign in to Postgres with logins Vault issues from
tribelt-ownerandestate-dashboard-owner(pg_stat_activityshows onlyv-kubernet-…users on both databases). Each lease is 3600 s and renewable; the role'smax_ttlis 24 h, after which VSO issues a new login and restarts the Process.Left, once each app has come through its first rotation (by 2026-10-17 about 14:30 UTC):
tribeltandestate-dashboard, reassigning anything they still own to the owner role first.estate-dashboardis the role the catalog adopted the database from, so it is a member ofestate-dashboard-owner.secret/tribelt-system/databaseandsecret/estate-dashboard-system/database.bootstrap/cluster.shstages 8 and 9 in JorisJonkers-dev/estate.The rollout tripped #466: removing the old grant pruned the Secret the old primary still read, and both canaries failed until the primaries were rolled back by hand and the canaries re-run.
chore(bootstrap): drop the two database stages that rotating credenti…
ExtraToast commentedon Oct 21, 2026
The logins
tribeltandestate-dashboardare dropped, their documents undersecret/<project>-system/databaseare deleted, and JorisJonkers-dev/estate#179 removescluster.sh's two database stages. Both apps connect only asv-kubernet-…users. Left: observe both surviving a credential rotation.ExtraToast commentedon Oct 21, 2026
Watched both Processes across one credential rotation on 2026-10-21. The last criterion holds.
Rotation (18:16:37Z for tribelt, 18:17:07Z for estate-dashboard). Vault Secrets Operator issued a new lease for each VaultDynamicSecret (
database/creds/tribelt-owner,database/creds/estate-dashboard-owner), rewrote the destination Secret, and restartedtribelt-primaryandestate-dashboard-primarythroughrolloutRestartTargets(RolloutRestartTriggered,restartedAtset by the operator). After that the operator only renewed the 1 h leases (18:58:41Z and 19:01:23Z) and left the Secrets untouched. A credential expiring at its max TTL rotates through the same path.The login changed, and the old one is gone. Read from
pg_rolesandpg_stat_activityon the platform Postgres at about 19:38Z, without printing a login name:Each Project has exactly one Vault-issued login, the one issued at the rotation, and all of its sessions use it. The login from before the rotation no longer exists.
Both Processes keep working on the new credential, more than an hour after the old lease stopped renewing.
https://tribelt.jorisjonkers.dev/with 200.readyon/readyz(five probes each).estate-dashboard's readiness probe times out on single probes now and then (
not ready: context deadline exceeded, never three in a row). Its log shows no authentication error, so these timeouts are latency, not the credential. This is noted as a separate observation, not part of this issue.