Cert hot-reload misses Kubernetes projected-volume (`..data` symlink-swap) rotations

Aperta
  • Qualcosa non va?
#17 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
backend, security

Direzione di ricerca

Inizia leggendo l’implementazione standalone di hot-reload di symphony-server introdotta in #14, concentrandoti sul monitoraggio della directory padre, sul filtraggio per nome base e sulla riconciliazione con debounce. Confronta le opzioni proposte per gestire lo scambio del symlink e verifica il comportamento scelto rispetto alle rotazioni dei volumi in stile Kubernetes e agli aggiornamenti diretti dei file esistenti. Il lavoro è completato quando una rotazione di ..data in stile Kubernetes attiva il ricaricamento del certificato senza compromettere il filtraggio attuale o il comportamento di debounce.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Background

@harperfast/[email protected] (#14) added live cert-file hot-reload to the standalone symphony-server: it watches the parent directories of the cert/key files referenced by the config and, on a change event, filters by the referenced basename (certFilesByDir.get(dir)?.has(filename)) before triggering a debounced reconcile.

Limitation

Basename filtering handles in-place writes and renames of the real files — which is what host-manager does (writes keys/fullchain.pem / keys/privkey.pem directly). It does not handle rotation performed by swapping a symlinked directory, which is how several common environments rotate certs:

  • Kubernetes Secret / projected volumes (and cert-manager) update a mount atomically by writing a new timestamped dir (..2026_07_06_...) and re-pointing the ..data symlink. The watched directory sees rename events for ..data / ..2026_*, none of which match the configured basename (e.g. tls.crt), so they're filtered out and no reconcile fires.
  • Let's Encrypt live/ symlinks can hit the same shape depending on how the symlink is replaced.

Net: in a symlink-swap deployment the hot-reload silently no-ops, and symphony keeps serving the old cert until a restart or an unrelated config write. (Per-route KeyMismatch isolation and last-good carry-forward from #14 still hold — this is purely about noticing the rotation.)

Possible fixes

  1. Resolve symlinks (fs.realpathSync) and watch the real target directory, re-resolving on each reconcile.
  2. When the watched dir contains a ..data-style symlink, don't drop unmatched rename events — let them through to the debounced reconcile (it's already coalesced + cheap).
  3. A periodic re-stat fallback (compare mtime/inode of referenced files) as a backstop for watchers that miss events.

Option 2 is the smallest; option 1 is the most general. Both should stay bounded (dedup by dir, existing debounce).

Priority

Low for the current deployment model (host-manager writes real files in place, which works today). Relevant if symphony is ever run under Kubernetes projected volumes / cert-manager.

Filed as a follow-up to #14. Issue text generated by an LLM (Claude Opus 4.8) on Kris's behalf.

Lingua principale
Rust
Stelle
1
Fork
0
Merge medio
19h 12m
PR unite (30g)
13

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/symphony

Tutte le issue di HarperFast/symphony

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.