Whiskers ist Infrastruktur-Management mit KI-Schnittstelle — Sicherheit ist ein erstklassiges Designziel, kein Nachgedanke. Diese Seite beschreibt das Modell und seine Kompromisse ehrlich; sie ist keine Behauptung perfekter Sicherheit.
Threat-Model (auf hoher Ebene)
Das klassische Risiko ist ein einzelner gespeicherter SSH-Key auf dem Controller: wird er kompromittiert, fallen alle verwalteten Hosts — denn dieser Key ist beliebige-Shell-“God Mode”. Whiskers ist darauf ausgelegt, diese stehende Zugangsberechtigung zu entfernen und zu begrenzen, was ein Akteur — Mensch oder KI — tun kann: auf explizite, berechtigte, auditierte Werkzeuge.
Authentifizierung & Rollen
Lokale Konten (E-Mail + Passwort) oder Google / generisches OIDC, mit E-Mail-Whitelist und drei Rollen (Viewer / Operator / Admin). Autorisierung ist fail-closed: jeder Endpunkt verlangt Authentifizierung, sofern er sich nicht ausdrücklich ausnimmt. MCP-Zugriff ist pro API-Key begrenzt (Read / Write / Admin), und der handelnde Agent kann nie die Rechte dessen überschreiten, der ihn ausgelöst hat.
Secrets & Vault
Gespeicherte Secrets sind ruhend verschlüsselt in einem Vault (AES-256-GCM, Schlüssel aus VAULT_KEY abgeleitet). Sensible Werte werden vor Logging und Persistierung redigiert. Secrets liegen im Datenvolume und in der .env, nie im Image oder im Repository.
Webhooks (HMAC)
Eingehende Webhooks brauchen ein Pflicht-Secret; Aufrufe müssen über den Raw-Body per HMAC-Signatur (X-Hub-Signature-256) signiert sein — kompatibel mit GitHub, GitLab und Gitea. Das Secret wird einmal angezeigt.
SSH-Bootstrap & Host-Key-Verifikation
Das Onboarding eines Hosts nutzt eine einmalige Bootstrap-SSH-Verbindung; die Bootstrap-Zugangsdaten werden danach entfernt. Jeder SSH-Pfad pinnt Host-Keys (Trust-on-first-use); ein geänderter Key scheitert hart, statt still mit einem Man-in-the-Middle zu reden. Wir behaupten nicht, dass SSH nie genutzt wird — das Ziel ist ein Regelbetrieb ohne stehenden Privatschlüssel.
Mesh + mTLS im Regelbetrieb
Nach dem Bootstrap werden Hosts über ein privates WireGuard-Mesh (Tailscale / NetBird) erreicht. Docker-Steuerung läuft über gegenseitiges TLS (ghostunnel + ein Verb-whitelistender Socket-Proxy) statt SSH-Tunnel; Management-Ports hängen am Mesh, nie am öffentlichen Internet. Siehe das Architektur-Dokument.
Docker-Socket & Container-Profile
Das Standard-Profil ist privilegiert, damit Whiskers seinen eigenen Host verwalten kann (Firewall / Nginx / systemd via einmaligem nsenter-Helfer). Nur zum Überwachen entfernter Hosts läuft ein gehärtetes Profil non-root, nicht privilegiert, read-only rootfs, mit Docker-Zugriff über einen verb-restringierten Socket-Proxy — deutlich kleinere Angriffsfläche.
Supply Chain
Release-Images werden vor der Veröffentlichung von Trivy gescannt (der Lauf scheitert bei jedem CRITICAL), multi-arch mit SLSA-Provenance und SBOM gebaut und keyless mit cosign signiert (Sigstore, in Rekor protokolliert). Die Signatur lässt sich vor dem Ausführen prüfen.
Grenzen & Beta
Whiskers ist Beta und noch nicht API-stabil; Single-Replica by design. Keine Software ist unzerbrechlich — betreibe es in einem vertrauenswürdigen Netz, halte Guardrails restriktiv und vergib wenig Rechte. Sicherheitslücken bitte privat über die Security-Policy des Repos melden.
Im Produkt
