Analiza sesji 60 — rozbudowa role-secret-manager i architektura SOPS reset
Data: 2026-07-07
Sesja: 60
Autor: Radek Konarski + Claude Sonnet 4.6
1. Kontekst i cel
Celem sesji było umożliwienie workerowi bms-4 (rola secret-manager) pełnej autonomicznej rotacji kluczy w systemie SOPS+age — bez udziału dewelopera — dla jak największej liczby sekretów (Tier 1 i Tier 2).
Punkt wyjścia: role-secret-manager.env.sops miał 7 kluczy (PAT, Vercel token, Supabase token, Mailgun admin, OpenAI admin, Sentry token, git signing key). Brak kluczy admin niezbędnych do autonomicznej rotacji.
2. Analiza czasu rotacji wszystkich SOPS (przed sesją)
Szacowany czas pełnej rotacji wszystkich sekretów we wszystkich SOPS plikach:
| Scenariusz | Czas |
|---|---|
| Tier 1 (w pełni autonomiczne) | ~2–3h wall-clock |
| Tier 1+2 (semi-auto, z Playwright) | ~4–5h |
| Tier 1+2+3 (z udziałem człowieka przy dashboardach) | 2–3 dni (blokady ludzkie równolegle) |
| Fast path: tylko Pinbox24 W3+W4 | ~20 min (Tier 1+2, skrypt) |
Główny bottleneck: ~30 kluczy Tier 3 wymagających ręcznego logowania do zewnętrznych dashboardów (Twilio, OneSignal, PayU, Przelewy24, GitHub PATs, Cloudflare Global Key, MongoDB rs0 admin).
3. Gap analysis — co brakowało w role-secret-manager.env.sops
Przed sesją brakujące klucze admin blokujące autonomię:
| Klucz | Problem |
|---|---|
| CF_GLOBAL_API_KEY | Bez niego: brak możliwości rotacji CF scoped tokenów przez API |
| WASABI_ADMIN_AK/SK | Bez nich: brak rotacji IAM keys żadnego użytkownika Wasabi |
| IONOS_API_TOKEN_PREFIX/ENC | Bez nich: brak dostępu do IONOS API |
| MONGODB_RS0_ADMIN_PASSWORD | Bez niego: brak zmiany haseł użytkowników MongoDB |
| VPS_SSH_PRIVATE_KEY | Bez niego: brak możliwości restartu kontenerów po dystrybucji |
| GCP_SA_KEY_JSON | Bez niego: brak sync GCP credentials do pinbox24-w4 |
| CONVERTAPI_API_TOKEN | Bez niego: brak autonomicznej rotacji V42_CONVERT_API |
| BMS4_N8N_API_KEY | Bez niego: brak rotacji n8n vault credentials |
Dodatkowo expired w momencie sesji:
- MAILGUN_ADMIN_API_KEY — nowa wartość dodana z pliku Downloads
- OPENAI_ADMIN_KEY — nowa wartość dodana z pliku Downloads
- OPENAI_PROJECT_DEFAULT_API_KEY — nowy klucz (pierwszy raz)
4. Architektura SOPS — kluczowe ustalenia
administration.env.sops vs role-secret-manager.env.sops
administration.env.sops
- 1 recipient (developer only — age key lokalna)
- zawiera: CF_GLOBAL_API_KEY, WASABI_ADMIN, IONOS, MongoDB, GCP, GitLab, CF Tunnel
- NIGDY nie deployowany przez CI
role-secret-manager.env.sops
- 6 recipients (developer + CI + vps-i1 + bms-4 + dev-laptop + vps-h1)
- zawiera: klucze operacyjne workera secret-manager
- bms-4 worker ma pełny dostęp
Wniosek: nie trzeba zmieniać .sops.yaml — wystarczyło skopiować klucze admin z administration do role-secret-manager. Worker bms-4 był już 4. recipientem.
ConvertAPI — odkrycie JWT self-sign
ConvertAPI wspiera HS256 self-signed JWT — token podpisany lokalnie przy użyciu API Token jako sekretu HMAC. Bez HTTP call do ConvertAPI:
CONVERTAPI_API_TOKEN (stały, w role-secret-manager)
↓ HS256 sign lokalnie (PowerShell HMACSHA256)
V42_CONVERT_API = JWT (90 dni, w pinbox24-w4.env.sops)
Zmienia V42_CONVERT_API z Tier 3 → Tier 1 — pełna autonomia.
Mailgun domain keys — odkrycie API (sierpień 2024)
Mailgun udostępnił w sierpniu 2024 REST API do tworzenia kluczy domenowych:
POST https://api.mailgun.net/v1/keys
Authorization: Basic <MAILGUN_ADMIN_API_KEY>
Body: domain_name=<domena>&kind=domain
→ nowy klucz domenowy dla V42_MAILGUN_API_KEY
Zmienia V42_MAILGUN_API_KEY z Tier 3 → Tier 1 — ale wymaga znajomości nazwy domeny Pinbox24 w Mailgun (do uzupełnienia).
5. Zakres sekretów Pinbox24 W3+W4 — finalna mapa
pinbox24-w3.env.sops (33 klucze)
| Tier | Klucze | Metoda |
|---|---|---|
| 1 — auto | V32_s3Bucket_api_accessKeyId/SK, V32_JWT_TOKEN_SECRET, V32_monitoringToken, V32_LOGDNA_KEY | Wasabi boto3, random, Mezmo API |
| 2 — SSH | V32_REDIS_PASSWORD | random + SSH redis-cli CONFIG SET |
| 3 — human | V32_MONGODB_URL, V32_PMONGODB_URL, V32_DB_URI | MongoDB rs0 user password (downtime akceptowalny) |
| skip | V32_twilioAuthToken, V32_onesignal_*, V32_jabber_PASSWORD | klienci nie używają modułu tel. |
| static | V32_VIRTUAL_HOST, V32_NODE_ENV, V32_port, URLs, nazwy kontenerów | nie rotujemy |
pinbox24-w4.env.sops (65 kluczy)
| Tier | Klucze | Metoda |
|---|---|---|
| 1 — auto | V42_s3Bucket_, V42_pinbox24Public, V42_JWT_TOKEN_SECRET, V42_tokenGenSecret, V42_tokenGenIV, V42_INVOICE_AUTH_TOKEN, V42_monitoringToken, V42_CONVERT_API (JWT), V42_MAILGUN_API_KEY | Wasabi boto3, random, HS256 JWT, Mailgun API |
| 2 — SSH | V42_REDIS_PASSWORD, V42_RABBIT_MQ_URL | random + SSH |
| 3 — human | V42_NEW_MONGODB_URI, V42_v3MongoUrl, V42_GOOGLE_APPLICATION_CREDENTIALS | MongoDB, GCP (TBD) |
| skip | V42_twilioAuthToken, V42_onesignal_, V42_przelewy24, V42_PAYU_*, V42_G_MAP_API, V42_PM2_PUBLIC/SECRET_KEY | nie używane lub nie rotujemy |
| static | adresy, konfiguracja, TZ, nazwy kontenerów | nie rotujemy |
Ważne zastrzeżenia przy JWT_TOKEN_SECRET: rotacja invaliduje wszystkie aktywne sesje użytkowników — wykonywać w oknie serwisowym.
6. Równoległa architektura multi-agent reset
8 niezależnych agentów możliwych do uruchomienia równolegle (Wave 1):
[A] pinbox24-w3 + pinbox24-w4 → scripts/sops-reset-pinbox24.ps1
[B] monitoring.env.sops → CF tokens, Wasabi p24-infra, Mezmo, randoms
[C] n8n-bms4.env.sops → n8n API key, webhooks
[D] vps-h1.env.sops → CF tunnel, Traefik
[E] art-agency.env.sops → Wasabi art-agency, Resend
[F] brandpilot.env.sops → Wasabi, Resend, Anthropic
[G] et-operational-platform.env.sops → Vercel sync
[H] bms-servers.env.sops → BMS root passwords (human-only)
Zależności blokujące Wave 1:
- CF_GLOBAL_API_KEY musi być świeży zanim Agent B rotuje CF scoped tokens
- GitHub PAT musi być świeży zanim CI/GH Actions może działać
Wave 2 (po merge wszystkich PR): secrets-sync.yml deployuje automatycznie na serwery.
7. Wyniki sesji — co zostało zrobione
Zmiany w SOPS
| Plik | Zmiana |
|---|---|
secrets/role-secret-manager.env.sops | 7 → 21 kluczy; nowe wartości MAILGUN_ADMIN, OPENAI keys; transfer 9 kluczy admin |
secrets/gcp.env.sops | źródło GCP_SA_KEY_JSON (bez zmian) |
Nowe pliki
| Plik | Opis |
|---|---|
scripts/sops-reset-pinbox24.ps1 | Autonomiczny reset W3+W4, parametry -DryRun/-W3Only/-W4Only/-SkipMongoDB/-SkipRedis |
docs/playbooks/sops-autonomous-reset.md | Pełny reset wszystkich SOPS od zera (DR) |
docs/playbooks/sops-parallel-reset-plan.md | Architektura multi-agent, mapa agentów, harmonogram |
docs/playbooks/convertapi-token-management.md | JWT HS256 self-sign, Tier 1 rotacja V42_CONVERT_API |
Otwarte PRy
| PR | Branch | Zawartość |
|---|---|---|
| #3173 | feat/expand-role-secret-manager-sops | SOPS expansion 7→21 + skrypt + plany |
| #3175 | feat/convertapi-token-management | Playbook ConvertAPI JWT |
8. Otwarte pytania do wyjaśnienia
| Pytanie | Status |
|---|---|
| Jaka jest nazwa domeny Pinbox24 w Mailgun? | ❓ do sprawdzenia — potrzebne do Mailgun domain key rotation; domeny są w V42_MAILGUN_US_DOMAIN / V42_MAILGUN_EU_DOMAIN w pinbox24-w4.env.sops |
| Czy V42_GOOGLE_APPLICATION_CREDENTIALS jest aktywne w kodzie v42? | ✅ ZAMKNIĘTE — node “resync google sheet of kasa” w n8n jest Deactivated; zmienna REMOVED z running env 2026-07-05; bezpiecznie usunąć z pinbox24-w4.env.sops |
| Czy JWT_TOKEN_SECRET rotacja ma okno serwisowe? | ❓ decyzja operacyjna — invaliduje sesje użytkowników |
9. Następne kroki
- **Merge PR #3173 i 3175 — odblokuje workera bms-4 do Tier 1 rotacji
- Ustalić domenę Mailgun dla Pinbox24 — uzupełnić skrypt
sops-reset-pinbox24.ps1Faza 5 - Zbadać GCP w kodzie v42 — usunąć z SOPS jeśli nieużywane, lub dodać procedurę sync
- Test dry-run skryptu na bms-4 —
.\sops-reset-pinbox24.ps1 -DryRun - Zaplanować pierwsze uruchomienie — okno serwisowe dla JWT_TOKEN_SECRET rotation