Skip to main content

Security

Documentation Map​

Security

Zweck​

Diese Datei beschreibt die aktuellen Security-Grenzen des Repositories.

Aktueller Stand​

  • Auth-Modell: Repository- und CI-Zugriff ueber Gitea
  • Zugriffskontrolle: ausserhalb dieses Repositories, durch Gitea und Runner-Umgebung
  • sensible Datenarten: potenziell kuenftige Upgrade-Zielversionen, interne Hostnamen, spaetere Artefakt-Parameter
  • Secrets-Modell: keine Secrets im Repository; Nutzung vorhandener Gitea-Secrets erst bei realem Bedarf

Secret- und Credential-Contract​

Implementiert:

  • standalone nutzt nur operator-provided credentials ausserhalb des Repositories:
    • SSH-Zugriff auf OPENCLAW_HOST
    • lokale SSH-Konfiguration oder Agent-Weitergabe auf dem Operator-Host
    • optionale Host- oder Shell-Umgebungsvariablen ausserhalb des Git-Arbeitsbaums
  • helpifyr-integrated nutzt nur bereits vorhandene Execution-Substrate-Credentials ausserhalb dieses Repositories:
    • host-lokale Credentials im jhf-deployment Arbeitskontext
    • operator-provided credentials fuer SSH/SCP und Terraform-Ausfuehrung
    • vorhandene Gitea Secrets nur innerhalb bestehender CI-Workflows, wenn spaeter ein realer Bedarf entsteht
  • der Moduswechsel kopiert, rotiert oder generiert keine Secrets automatisch
  • read-first Fabric-Metadata transportiert keine Secrets und ersetzt keine operator-provided credentials

Geplant:

  • keine neue Secret-Management-Schicht
  • keine automatische Credential-Rotation
  • keine Uebernahme von Fabric als Secret-Quelle

Nicht implementiert:

  • Repo-Secrets
  • Write-Back oder Secret-Push nach Fabric
  • automatische Secret-Migration zwischen standalone und helpifyr-integrated
  • eigener Promotion- oder Live-Orchestrator ausserhalb von jhf-deployment und jhf-beam

Vertrauensgrenzen​

  • Repository-Inhalt ist vertrauenswuerdig nur nach Review und CI
  • Runner- und Host-Vertrauen liegt ausserhalb des Repos
  • externe Systeme wie OpenClaw duerfen nicht implizit ueber dieses Repo kontrolliert werden
  • Secret- und Credential-Ownership bleibt bei Operator, Host und vorhandenen CI-Secrets, nicht bei Repo-Artefakten

Gefaehrliche Eingaenge​

  • kuenftige Upgrade-Skripte mit schreibenden oder destruktiven Operationen
  • nicht validierte Konfigurations- oder Versionsparameter
  • unklare Shell-Annahmen auf unterschiedlichen Plattformen

Verbotene oder Approval-pflichtige Automatisierung​

  • direkte Host- oder Container-Aenderungen ohne expliziten Auftrag
  • Secret-Eintrag ins Repository
  • automatische Rollouts oder destructive Upgrades ohne manuelle Pruefung
  • automatische Credential-Uebernahme oder Rotation beim Moduswechsel
  • direkte Live-Host-Tests anderer Repositories ausserhalb des jhf-deployment -> jhf-beam Promotion-Pfads
  • unkontrollierte Wiederholung desselben Live-Applys ohne run_id-, Digest- und Lock-Pruefung

OpenClaw-nahe Delegations- und Sandbox-Policy​

  • sessions_spawn ist standardmaessig verboten, ausser der Bedarf ist explizit dokumentiert
  • subagents.allowAgents muss eng begrenzt bleiben
  • fuer sensible Flows gilt sandbox: require
  • Evidence fuer Stage 2 oder Stage 3 muss den beobachteten gateway.reload.mode ausweisen
  • gateway.reload.mode ohne nachvollziehbare Evidence ist kein gueltiger gruener Verify-Zustand

Besonders schuetzenswerte Integrationen​

  • Gitea-Secrets und Variablen
  • spaetere OpenClaw-Zugriffe
  • moegliche kuenftige Fabric-Control- oder Event-Schnittstellen
  • host-lokale jhf-deployment Credentials ausserhalb dieses Repositories

OAuth-Bewertung​

OAuth ist im aktuellen Scope nicht sinnvoll.

Begruendung:

  • keine menschliche Benutzeroberflaeche
  • keine externe API
  • keine Multi-Tenant- oder Partner-Zugriffsflaeche
  • aktueller Fokus liegt auf internen Repo-Artefakten und Dokumentation

Perspektive:

  • falls spaeter eine operatorische UI oder externe Zugriffsflaeche entsteht, muss OAuth neu bewertet werden

Offene Luecken​

  • Security Review fuer kuenftige Upgrade-Skripte ist noch nicht konkretisiert
  • es gibt noch keine dokumentierte Eingabevalidierung fuer spaetere Artefakte
  • ein realer Secret-Bedarf fuer weitere Upgrade-Pfade ist noch nicht belegt und darf nicht vorab verallgemeinert werden