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

Đang mở
  • Có gì không ổn?
#17 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
backend, security

Hướng nghiên cứu

Bắt đầu bằng việc đọc triển khai hot-reload độc lập của symphony-server được giới thiệu trong #14, tập trung vào việc theo dõi thư mục cha, lọc theo basename và reconcile có debounce. So sánh các tùy chọn xử lý việc hoán đổi symlink được đề xuất và xác minh hành vi đã chọn dựa trên các lần xoay volume theo kiểu Kubernetes cũng như các cập nhật tệp trực tiếp hiện có. Hoàn tất có nghĩa là một lần xoay ..data theo kiểu Kubernetes kích hoạt việc tải lại chứng chỉ mà không phá vỡ hoạt động lọc hoặc debounce hiện tại.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
1
Fork
0
Merge trung bình
19 giờ 12 phút
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của HarperFast/symphony

Tất cả issue của HarperFast/symphony

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.