Secrets Rotation Log — 2026-07-13

DateSecretReasonRotatorConfirmed in sync
2026-07-13 — LOG ONLY, no rotationV32_MONGODB_URL, V32_PMONGODB_URL, V32_PINBOX_PROD_DB (secrets/pinbox24-w3.env.sops) — full mongodb://user:pass@host URIs with embedded passwords (w3_app ×2 distinct historical values, pinbox_production ×1)exposure — appeared in chat output while diagnosing a separate W3 upload/import investigation (redis-v32 missing container, bms-1). Source: tail/grep of /var/log/s3-v32-prod/pm2/pm2_s3-v32-prod_production_out.log, lines dated 2026-07-09 (written during the cascading-outage incident, see docs/incidents/2026-07-09-w3-cascading-outage-postmortem.md). The safety filter used (grep -v -iE 'token|password|secret|...') excludes lines containing those words, but a mongodb://user:pass@host URI doesn’t contain the literal word “password” — so 3 stale connection strings passed through and were echoed to chat. Filter corrected mid-session (now excludes any line matching mongodb:// outright) before further log reads. Per playbook Step 0b (docs/playbooks/static-api-key-incident-rotation.md), these values are near-certainly already dead: w3_app was rotated twice since the July 9 log lines were written — 2026-07-11 (PR 3694) and 2026-07-12 (#3911, this log’s own entry directly below). User explicitly reviewed and directed “log only” — no rotation performed.claude (orchestrator session) — user-directed log-only, no rotatorn/a — not rotated. If a future audit needs certainty rather than inference: compare SHA-256 of the exposed value against the current live SOPS value (safe True/False pattern, no value printed) before assuming safe.
2026-07-13 00:00 UTC — SOPS ROTATED, distribution pending PR mergeCRON_SECRET (secrets/et-operational-platform.env.sops + secrets/monitoring.env.sops), INSPECTION_WEBHOOK_SECRET (secrets/et-operational-platform.env.sops + secrets/n8n-bms4.env.sops), DOCUMENT_INGEST_SECRET (secrets/et-operational-platform.env.sops only)exposure (#4057, Fala A sub-batches A1+A2 — carved from the #2824 27-key plaintext exposure; these 3 are internal random-HMAC/token secrets, Tier 2 autonomous). Independently re-verified SOPS topology before writing (key-name counts only, no values): CRON_SECRET → et-op+monitoring; INSPECTION_WEBHOOK_SECRET → et-op+n8n-bms4; DOCUMENT_INGEST_SECRET → et-op only — matches the prior consumer-map comment on #4057. Generated fresh 64-char hex (openssl rand -hex 32) for each; applied per-file via decrypt→awk-replace→re-encrypt with a canary decrypt AND a 6/6 age-recipient-count check before each atomic move; verified cross-file consistency by SHA-256 fingerprint (CRON matches across both files, INSPECTION matches across both files — no value printed); confirmed QUEUE_API_KEY + EXTERNAL_DB_SYM_KEY were NOT altered (fingerprint-equal to origin/main) and only the 3 intended keys changed. INSPECTION_WEBHOOK_SECRET is NOT an n8n credential object — the inspection-sticker-processor workflow reads it via {{ $env.INSPECTION_WEBHOOK_SECRET }} (sender side, x-webhook-secret header) sourced from the bms-4 container env (docker-compose.yml passes it to n8n + n8n-worker-1/2/3), so no n8n REST credential PATCH is needed — but those 4 containers require RECREATE (not restart) after secrets-sync so the new env value takes effect (same pattern as N8N_HU_SP_REPORT_SECRET, 2026-07-09 entry). A1 DOCUMENT_INGEST_SECRET external-caller check (positive clearance to rotate): cloned et-operational-platform@main and grepped — ZERO references to DOCUMENT_INGEST_SECRET / any ingest endpoint anywhere in the codebase (control: CRON_SECRET has 7 hits, so the search method works); no p24-infra or n8n workflow references it; docs/sops-templates/et-operational-platform.keys classes it internal random-HMAC; and it was already blind-rotated to a fresh random value during the 2026-07-05 et-op full rebuild with no downstream breakage in the 8 days since — proving nothing external validates against it. Confirmed no external caller → rotated. Out of scope this pass (untouched): QUEUE_API_KEY (B — self-referential to the dispatch queue, sequenced maintenance job), EXTERNAL_DB_SYM_KEY (C — symmetric data-at-rest key, random rotation = data loss, needs migration), PINBOX24_W4_WASABI_* (A3 — Wasabi IAM + bms-1 recreate).claude (secret-manager worker, bms-4)SOPS: et-operational-platform.env.sops (3 keys) ✅ canary OK 6/6 recipients · monitoring.env.sops (CRON_SECRET) ✅ canary OK 6/6 recipients · n8n-bms4.env.sops (INSPECTION_WEBHOOK_SECRET) ✅ canary OK 6/6 recipients · cross-file fingerprints MATCH (CRON, INSPECTION) · branch feat/4057-fala-a-a1-a2, PR → main · Distribution PENDING PR merge: secrets-sync.yml → et-op keys to Vercel (CRON + DOCUMENT_INGEST + INSPECTION receiver side); monitoring → vps-i1 .env; n8n-bms4 → bms-4 .env then RECREATE n8n + n8n-worker-1/2/3 (not restart) · GH Secret CRON_SECRET (used by rotate-credentials.py flow) refresh pending · old values revoked at provider: N/A (internal secrets, no provider)