OPS-009: Secret Rotation #160

New issue

Closed

opened 2026-04-11 05:50:39 +00:00 by Mark · 2 comments

Mark commented

2026-04-11 05:50:39 +00:00

Owner

Required

API key rotation
DB password rotation
TLS cert rotation
No restart required

Acceptance Criteria

Rotate without downtime
Atomic rotation
Audit log of rotations
Automatic on schedule

## Required - API key rotation - DB password rotation - TLS cert rotation - No restart required ## Acceptance Criteria - [ ] Rotate without downtime - [ ] Atomic rotation - [ ] Audit log of rotations - [ ] Automatic on schedule

Mark added the

feature-request

label

2026-05-12 23:26:54 +00:00

Mark added

blocked:needs-decision

and removed

feature-request

labels

2026-05-18 00:36:18 +00:00

Mark commented

2026-05-18 00:36:18 +00:00

Author

Owner

Feature Triage Assessment

Scope: medium
Risk: high
Spec Alignment: partial
Summary: Add a secret rotation subsystem with scheduled, atomic rotation of API keys, DB passwords, and TLS certs without requiring service restarts.
Recommendation: Implement as an ops worker capability (opworker pattern) — the rotation engine emits intent.rotate signals consumed by a dedicated rotation worker, keeping infrastructure thin. Add a file-based audit log under a known path (substrate/audit/). For no-restart TLS/DB, wire file watchers or SIGUSR2 handlers into api_gateway.py and the DB pool. Start with one secret type (env-backed API key) as a proving ground before tackling TLS.
Rationale: SCOPE: medium — extends existing runtime/secrets_manager.py with a rotation engine and adds 5-8 new/modified files (rotator module, config, audit logger, integration hooks, tests). Not small because 'no restart required' touches multiple subsystems (TLS socket, DB pool). Not large because it's additive, not a refactor. RISK: high — TLS cert rotation without restart is genuinely dangerous (mis-rotation drops live connections), DB password rotation requires coordinated pool drain, and atomic rollback across distributed nodes is complex. Existing infrastructure issues (#98, #102) are still open, adding integration risk. SPEC: partial — the agentic architecture supports this cleanly via a rotation worker intent pattern, but the issue body describes a traditional ops approach (no mention of intents/workers), and AGENTS.md has zero ops/rotation coverage. The project's current focus is agent orchestration capability, not ops tooling.

Labeled blocked:needs-decision — unblock on Forgejo to dispatch to the fixer pipeline.

## Feature Triage Assessment **Scope:** medium **Risk:** high **Spec Alignment:** partial **Summary:** Add a secret rotation subsystem with scheduled, atomic rotation of API keys, DB passwords, and TLS certs without requiring service restarts. **Recommendation:** Implement as an ops worker capability (opworker pattern) — the rotation engine emits intent.rotate signals consumed by a dedicated rotation worker, keeping infrastructure thin. Add a file-based audit log under a known path (substrate/audit/). For no-restart TLS/DB, wire file watchers or SIGUSR2 handlers into api_gateway.py and the DB pool. Start with one secret type (env-backed API key) as a proving ground before tackling TLS. **Rationale:** SCOPE: medium — extends existing runtime/secrets_manager.py with a rotation engine and adds 5-8 new/modified files (rotator module, config, audit logger, integration hooks, tests). Not small because 'no restart required' touches multiple subsystems (TLS socket, DB pool). Not large because it's additive, not a refactor. RISK: high — TLS cert rotation without restart is genuinely dangerous (mis-rotation drops live connections), DB password rotation requires coordinated pool drain, and atomic rollback across distributed nodes is complex. Existing infrastructure issues (#98, #102) are still open, adding integration risk. SPEC: partial — the agentic architecture supports this cleanly via a rotation worker intent pattern, but the issue body describes a traditional ops approach (no mention of intents/workers), and AGENTS.md has zero ops/rotation coverage. The project's current focus is agent orchestration capability, not ops tooling. Labeled `blocked:needs-decision` — unblock on Forgejo to dispatch to the fixer pipeline.

Mark removed the

blocked:needs-decision

label

2026-05-28 07:19:05 +00:00

Mark added the

triage-approved

ops-task

labels

2026-06-07 05:05:16 +00:00

Mark removed the

ops-task

label