D-20260727-04｜週邊 repo 容器安全基線¶
背景與驅動力¶
三顆公版 Template repo 的公開前稽核顯示：canon 對它們的容器安全完全未著墨——
runAsNonRoot、securityContext、非 root 執行、runtime 映像內容，在資安規範、
程式架構與三份 repo 規格中皆零命中。結果是三顆 repo 各自為政：signaling 與 pinning
的 Node 映像都以 root 執行且把完整開發工具鏈（型別檢查器、test runner、雲端 CLI）
裝進 runtime，k8s manifests 則完全沒有 securityContext。
pinning 是三者中唯一發布 public image 的（CI 推 GHCR）。映像一旦公開，使用者是直接
docker pull 執行，硬化責任無法下推給部署者——這使缺口從「各自的部署選擇」升級為
公版交付物的品質問題。
缺的是規範而不只是修補：逐 repo 各修一次，下一顆 repo 或下一次改版仍會漂回去。
考慮過的選項¶
- 逐 repo 直接修 Dockerfile／manifest，不立規範：能解當下，但沒有可驗證的基準， 新增 repo 或改版時無所依歸，棄。
- 寫進
程式架構/security.md：該檔為type: impl、記主 reposrc/security/的實作， 週邊 repo 的容器形狀不屬其權威範圍，棄。 - 立於
資安規範.md為跨 repo 要求，三份 repo 規格各自回指（採納）。
決定¶
資安規範.md新增「週邊服務容器安全基線」一節，涵蓋四項：執行身分（不得 root、 Dockerfile 明示USER、k8s 至少runAsNonRoot＋allowPrivilegeEscalation: false）、 映像內容（runtime 不含建置／部署工具鏈，雲端 CLI 尤甚——它是部署憑證載體）、 埠與特權（監聽埠 >1024、不索取CAP_NET_BIND_SERVICE）、例外須於該 repo README 寫明理由與補償措施。- 適用範圍限自建映像與 k8s manifests；直接引用的上游官方 image（coturn／kubo／ ipfs-cluster）其內部硬化屬上游責任，但承載它們的 manifest 仍受約束。
resources與探針明確不納入基線，維持「公版範本省略、README 要求部署者於 overlay 自補」的既有作法——其合理值隨部署規模差異過大，訂死反而有害。- 發布 public image 的 repo 在首次發布前必須滿足基線。
- 本節插入為第 8 節，其後各節順移一號；全 corpus 入站引用同批更新（歷史記錄依既有 歷史快照豁免不動）。
後果與影響¶
三顆 repo 的容器安全從各自為政收斂為單一可驗證基準，新增週邊 repo 時有現成依據。
基線刻意只約束「能一體適用」的項目，把規模相關的參數留給部署者，避免公版訂出
對誰都不合身的數字。實作面的對齊 gate 在主 repo 轉 public 之前——那也是 pinning
首次推 GHCR、check:vendor 上游比對轉綠的同一個時點。