store the forge webhook secret and grafana's secret key in bao, seeded from the existing files
This commit is contained in:
parent
50c1f2a3d1
commit
a4e48a7bca
1 changed files with 697 additions and 142 deletions
|
|
@ -497,13 +497,16 @@ Only present on the one host running
|
|||
so it survives restarts and redeploys.
|
||||
|
||||
- `webhook-secret` — the HMAC key Forgejo signs the swarm's forge webhooks
|
||||
with. **Keep it.** It's handed to Forgejo when swarm-controller registers a hook,
|
||||
so replacing the file means every subsequent delivery fails
|
||||
verification until the hook is re-registered with the new value. It's
|
||||
generated automatically on first start; there's nothing to configure.
|
||||
with, as it was before the swarm secret store held it. **Keep it.** The
|
||||
controller stores its value in the swarm secret store at
|
||||
`swarm/controller/swarm-controller/forge/webhook-secret` the first time it
|
||||
starts with that path empty, and reads the store from then on. The file is the
|
||||
fallback while the store is unreachable or its policy doesn't grant the path
|
||||
yet, and nothing else reads or removes it. A host with neither the file nor a
|
||||
store value gets a new secret in the store, with nothing to configure.
|
||||
|
||||
<!-- vale write-good.Passive = NO -->
|
||||
If the file is unreadable at startup the daemon still starts and logs
|
||||
If the store can't answer and the file is unreadable or missing at startup, the daemon still starts and logs
|
||||
`webhook secret unavailable`; the webhook endpoint then answers 503
|
||||
rather than accepting deliveries it can't verify. Everything else the
|
||||
controller serves is unaffected.
|
||||
|
|
|
|||
Loading…
Reference in a new issue