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

Abierto
  • ¿Algo no está bien?
#17 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
backend, security

Línea de trabajo

Empieza leyendo la implementación independiente de hot-reload de symphony-server introducida en #14, centrándote en la supervisión del directorio padre, el filtrado por nombre base y la reconciliación con debounce. Compara las opciones propuestas para gestionar el intercambio de symlinks y verifica el comportamiento elegido frente a las rotaciones de volúmenes de estilo Kubernetes y las actualizaciones directas de archivos existentes. Se considera terminado cuando una rotación de ..data al estilo de Kubernetes activa la recarga del certificado sin romper el filtrado ni el comportamiento actual de debounce.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
1
Forks
0
Merge medio
19 h 12 min
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de HarperFast/symphony

Todos los issues de HarperFast/symphony

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.