trading-system-docs/red-queen-architecture/control-plane/cp2a2_2b/SECURITY.md

145 lines
4.5 KiB
Markdown

# CP2A2.2B — L1 Red Queen Worker: Security-Dokumentation
# STRICTLY NON-AUTONOMOUS / NON-PRODUCTIVE. NO AUTONOMY. NO HEARTBEAT. NO SCHEDULER.
## 1. Zweck
Separate minimale L1 Worker Runtime (`l1-red-queen-worker`) als technische
Sandbox/Foundation fuer spaetere Read-only-Autonomie. In CP2A2.2B:
- KEINE Autonomie
- KEINE Mission Execution
- KEIN Heartbeat
- KEIN Scheduler
- KEIN autonomer Tick
Der bestehende interaktive Container `hermes-red-queen` bleibt UNVERAENDERT.
## 2. Security-Invarianten (permanent)
RED_QUEEN_TRADING_AUTHORITY=NEVER
Der L1 Worker darf niemals erhalten:
- Broker Credentials
- Broker APIs
- Trading Tokens
- Trading Execution Authority
- Trading Kill-Switch Authority
Trading ist eine separate Security Domain.
Zusaetzlich:
- MISSION != AUTHORIZATION
- COMMAND != AUTHORIZATION
- RQ_DECISION != AUTHORIZATION
- GATE_CHECK != CAPABILITY_GRANT
## 3. Credential Zero Policy
Im L1 Worker sind ABSENT:
- FORGEJO_WRITE_TOKEN, NOTION_API_KEY, TELEGRAM_BOT_TOKEN
- SAVE_TOKEN, DELETE_TOKEN
- SSH private keys, Git write credentials, .netrc, .git-credentials
- credential helpers mit Secrets
- Cloud Credentials, DB Credentials (produktive externe DBs)
- Service Account Credentials, Webhook Secrets, Generic Bearer Tokens
- Docker Credentials, Broker Credentials, Trading Credentials
Geprueft werden: ENV files, mounted secrets, process environment, config,
home directory, git config, credential helpers.
Report: NUR PRESENT/ABSENT. NIEMALS Secret-Werte ausgeben.
## 4. Container-Hardening
- non-root UID/GID: hermes-User (UID 10000 / GID 10000)
- read-only rootfs
- cap_drop ALL
- no-new-privileges
- kein privileged
- kein Docker-Socket
- keine Host-Root-Mounts
- keine Host-Namespaces
- keine Device-Mounts
- keine unnecessary Linux capabilities
Writable nur: worker-owned internal state volume + technisch zwingende tmpfs-Pfade.
## 5. Tool-Capability-Model
Der Worker darf NICHT haben:
- terminal, generic shell, execute_code
- write_file auf externe/shared Ziele, patch
- git push, SSH, Docker, cronjob, send_message, delegation
- arbitrary command execution
MAX_SUBAGENTS=0. Nur minimal erforderliche Read-only-Faehigkeiten.
Ground-Truth-Verifikation: prueft die tatsaechlich geladenen Toolsets,
nicht nur die Config.
## 6. Network-Model
KEIN allgemeiner Internet-Egress. Worker erreicht nur:
- A. Gate Evaluator (internal)
- B. Ollama (internal)
- C. Tolaria READ/Search (internal)
NICHT erreichbar:
- Telegram API, Notion API, Forgejo public Host
- Internet allgemein, Trading Networks, Broker endpoints
- Docker API, Host management interfaces
- SAVE executor, DELETE executor
Keine generische Proxy-/Relay-Loesung.
## 7. Gate Evaluator
Worker darf den bestehenden Gate Evaluator erreichen. CP1 bleibt unveraendert.
Aktuell: GLOBAL_AUTONOMY=OFF, PRODUCTIVE_MUTATIONS=OFF, SAVE=OFF, DELETE=OFF,
EMERGENCY_STOP=ON. Daher muss jeder produktive AUTONOMOUS_TICK_START weiterhin
DENY ergeben. KEIN State aendern, um ALLOW zu testen.
## 8. Tolaria
Nur READ/Search. Worker darf KEINEN Tolaria SAVE/DELETE Token erhalten.
NICHT produktiv schreiben. Keine Mutation als Test.
## 9. Ollama / LLM
Worker darf Ollama erreichen (fuer Hermes-Start erforderlich). Keine
Credentials noetig. Keine dadurch entstehende externe Mutation Capability.
KEINE autonome Mission ausfuehren.
## 10. Internal State Volume
Worker-eigenes persistentes State-Volume. Noch KEINE produktive A2-A5
Initialisierung. Erlaubt: leeres/verifiziertes State-Verzeichnis bzw.
Foundation-Struktur. Noch NICHT: missions.db produktiv initialisieren,
safety runtime starten, orchestration runtime starten, heartbeat starten,
tick loop starten. Worker State darf ausschliesslich vom Worker beschrieben
werden. Bestehende interaktive RQ darf dieses Volume NICHT schreiben.
## 11. Mission Transfer — NOT YET
In CP2A2.2B: KEIN Shared Mission Volume, KEINE Mission Queue, KEIN Mission
Broker, KEIN Mission Snapshot produktiv anbinden. Mission Transfer kommt
separat danach.
## 12. No Autostart Autonomy
Nach Host-Reboot, Docker-Reboot, Container-Restart, Compose-up darf NICHT
automatisch ein autonomer Tick beginnen. Worker Foundation darf existieren/
starten, aber autonome Mission Execution bleibt unmoeglich. Gate DENY allein
ist nicht die einzige Schutzschicht. Es darf noch gar kein autonomer
Scheduler/Loop existieren.
## 13. Resource Limits
Konservative Foundation-Limits (siehe docker-compose / deploy):
- CPU limit
- memory limit
- pids limit
- bounded tmpfs
- log rotation
Ein fehlerhafter Worker darf den Host nicht durch Ressourcenverbrauch
beeintraechtigen.