Zero-Trust Architektur für Cloud-Bots: Least-Privilege & Linux-Sandbox-Isolation

Beim Betrieb einer Multi-Tenant Hosting-Plattform wie KiroCloud teilen sich hunderte fremde Bot-Prozesse dieselben physischen Server-Knoten. Wenn ein Benutzer schadhaften Code ausführt (z. B. einen Bot mit Path-Traversal, Krypto-Minern oder Reverse-Shells), darf dieser Prozess unter keinen Umständen auf benachbarte Bots, Systemdateien oder Datenbank-Credentials zugreifen können.

Das Zero-Trust-Sicherheitsmodell geht davon aus, dass jeder ausgeführte Prozess potentiell bösartig ist ("Never Trust, Always Verify"). In diesem Leitfaden erläutern wir die Isolationsebenen moderner Cloud-Bot-Umgebungen.

1. Die drei Säulen der Zero-Trust Bot-Isolation

1. Dateisystem-Sandbox (Chroot & Linux Namespaces): Jeder Bot sieht ausschließlich sein eigenes Verzeichnis (/home/kiro/bots/{botId}). System-Binaries (/bin, /usr) werden nur schreibgeschützt (read-only) bereitgestellt.
2. Netzwerk-Segmentierung (Egress Filtering): Bots dürfen ausschließlich ausgehende Verbindungen zu den Discord-API-Endpunkten und definierten Datenbank-Ports aufbauen. Der Zugriff auf interne Cloud-Management-Netzwerke (wie 169.254.169.254 oder interne Docker-Subnetze) ist auf Kernel-Ebene gesperrt.
3. Flüchtige Zugangsdaten (Ephemeral Tokens): Zugriffstoken für Datenbanken und APIs besitzen kurze Lebensdauern (15 bis 60 Minuten) und werden automatisch erneuert.

┌────────────────────────────────────────────────────────────────────────┐
│                        Physischer Host-Server                          │
├───────────────────────────────────┬────────────────────────────────────┤
│  Sandbox A (Bot 1)                │  Sandbox B (Bot 2)                 │
│  - PID Namespace (isoliert)       │  - PID Namespace (isoliert)        │
│  - Mount Namespace (Read-Only OS) │  - Mount Namespace (Read-Only OS)  │
│  - Cgroup RAM Cap: 512 MB         │  - Cgroup RAM Cap: 512 MB          │
│  - Netfilter: Outbound Whitelist  │  - Netfilter: Outbound Whitelist   │
└───────────────────────────────────┴────────────────────────────────────┘

2. Linux Namespaces & Unprivileged User Execution

Ein Bot-Prozess darf unter keinen Umständen als Root oder mit sudo-Rechten ausgeführt werden. Beim Start eines Node.js-Workers wird der Prozess auf einen unprivilegierten System-Benutzer herabgestuft:

import { spawn } from 'node:child_process';

export function spawnSandboxedBot(botId: string, botEntrypoint: string) {
  const botDir = `/var/kiro/bots/${botId}`;

  const child = spawn('node', [botEntrypoint], {
    cwd: botDir,
    uid: 1005, // Unprivilegierter System-Nutzer 'kiro-runner'
    gid: 1005,
    env: {
      NODE_ENV: 'production',
      PATH: '/usr/local/bin:/usr/bin',
      BOT_ID: botId,
    },
    // Trennung von Standard-Ein- und Ausgabe
    stdio: ['ignore', 'pipe', 'pipe'],
  });

  child.stdout.on('data', (chunk) => {
    // Weiterleitung in den KiroCloud WebSocket Live-Log-Stream
    broadcastBotLog(botId, chunk.toString());
  });

  return child;
}

3. Schutz vor Path-Traversal in Dateimanagern

Wenn Nutzer Dateien über das Web-Dashboard hochladen oder editieren, muss jeder Pfad gegen Directory-Traversal-Angriffe (../../etc/passwd) verifiziert werden:

import path from 'node:path';

export function resolveSafeBotPath(baseBotDir: string, userPath: string): string {
  // Normalisierung und Auflösung des absoluten Pfads
  const resolved = path.resolve(baseBotDir, userPath);

  // Verifikation, dass der Pfad strikt innerhalb des Bot-Verzeichnisses liegt
  if (!resolved.startsWith(baseBotDir + path.sep) && resolved !== baseBotDir) {
    throw new Error('Sicherheitsverletzung: Zugriff außerhalb des Bot-Verzeichnisses verweigert (Path Traversal erkannt).');
  }

  return resolved;
}

4. Least-Privilege Datenbankzugriff

Wenn ein Bot mit einer SQL-Datenbank interagiert, sollte niemals der PostgreSQL-Superuser verwendet werden:

• Eigene Datenbank und eigener Datenbanknutzer pro Bot
• Keine Rechte für DROP DATABASE oder Manipulation von Systemtabellen
• Maximale Verbindungslimits pro Bot (z. B. max_connections = 10), um Denial-of-Service auf dem Datenbank-Server zu verhindern

Auf KiroCloud sorgt diese Architektur dafür, dass jeder Bot in einer vollständig isolierten Sandbox läuft – für maximale Stabilität und Sicherheit aller gehosteten Kunden-Instanzen.