Bastion ist ein selbstgehosteter Orchestrator für Hintergrundprogrammierungsagenten. Anstatt mehrere Agentenprozesse oder Container auf einem Entwickler-Laptop bereitzustellen, wird für jede Umgebung eine separate virtuelle Maschine Cloud Hypervisor erstellt. Vorlagen definieren CPU, Speicher, Festplatte, Agenten, Tunnel und Lebenszyklusaktionen als schemavalidiert JSON; Vorbereitete Ebenen werden wiederverwendet, während jede Aufgabe ein neues beschreibbares Overlay erhält.
Dies ist eine Infrastruktur, kein Codierungsmodell. Bastion integriert derzeit OpenCode direkt und stellt SSH für andere Tools bereit. Es kann Konflikte reduzieren und die Eindämmung verbessern, aber eine VM ist nur eine Sicherheitsgrenze. Der privilegierte Host-Daemon, der lokale API, die Vorlagenlieferkette, der Netzwerkausgang, Geheimnisse, Repositorys und der Zusammenführungspfad erfordern weiterhin eine explizite Richtlinie.
Wie Bastion zusammengesetzt wird
| Komponente | Verantwortung | Vertrauensimplikation |
|---|---|---|
| Gastgeber API | Speichert Metadaten in SQLite und stellt HTTP standardmäßig auf localhost:3148 bereit | Unprivilegierter Prozess, aber jeder Aufrufer kann Umgebungen erstellen, betreten und entfernen |
| bastiond | Führt privilegierte VM-Lebenszyklus- und Netzwerkvorgänge über einen Unix-Socket aus | Läuft als Root; Kompromisse können sich auf jedes Gast- und Host-Netzwerk auswirken |
| Cloud Hypervisor VM | Stellt Gastkernel, Root-Dateisystem, Prozesse und Netzwerk für eine Umgebung bereit | Stärkere Trennung als ein gemeinsamer Prozess, aber keine absolute Grenze |
| Basisbild | Gemeinsames Ubuntu-Kernel/initramfs/root-Dateisystem und Gastkomponenten | Eine anfällige oder vergiftete Basis breitet sich auf jede Vorlage aus |
| Vorlagenüberlagerung | Unveränderlich vorbereitete Projektabhängigkeiten und Init-Aktionen | Verbessert die Reproduzierbarkeit; Geheimnisse dürfen nicht in die Schicht eingebrannt werden |
| Umgebungsüberlagerung | Beschreibbarer Copy-on-Write-Datenträger für eine Aufgabe | Vom Design her wegwerfbar; Erforderliche Ausgaben müssen vor dem Entfernen exportiert werden |
Isolationsvorteile – und was sie nicht beweisen
Jede VM verfügt über einen eigenen Gastkernel, eigene Prozesse, ein eigenes Dateisystem und ein eigenes Netzwerk. Dies reduziert versehentliche Konflikte zwischen Agenten, die unterschiedliche Abhängigkeiten installieren, denselben Port binden oder einen gemeinsamen Arbeitsbaum bearbeiten. Es schafft auch eine klarere Zerstörungseinheit: Entfernen Sie die Umgebung, anstatt zu versuchen, einen unbekannten Prozessbaum von einem Laptop zu bereinigen.
Isolation allein garantiert keine sichere Autonomie. Eine VM mit einem breiten GitHub-Token kann weiterhin Zweige löschen; Uneingeschränkter ausgehender Datenverkehr kann immer noch Code herausfiltern. Ein Tunnel kann einen anfälligen Entwicklungsserver offenlegen. und eine böswillige Vorlagenaktion wird als Root im Gast ausgeführt. In der aktuellen Dokumentation von Bastion heißt es außerdem, dass Vorlagenaktionen als Gast-Root und der Host-Daemon als Root ausgeführt werden. Behandeln Sie beide Fakten als Design-Inputs und nicht als Fußnoten.
| Bedrohung | VM hilft dabei | Zusätzliche Kontrolle erforderlich |
|---|---|---|
| Zwei Agenten ändern dieselbe Abhängigkeit | Separate beschreibbare Festplatten und Prozesse | Trennen Sie Zweige/Arbeitsbäume und führen Sie die Überprüfung zusammen |
| Der Agent führt einen destruktiven Shell-Befehl aus | Schäden können im Einweggast verbleiben | Keine Host-Mounts, begrenzte Anmeldeinformationen und Ausgangsbeschränkungen |
| Schädliche Paketinstallation | Prozessisolation von anderen Gästen | Registrierungsrichtlinie, Sperrdateien, Scannen und Neuerstellen |
| Missbrauch von Anmeldedaten | Keine, wenn der Berechtigungsnachweis eine externe Autorität gewährt | Kurzlebige Pro-Task-Tokens und Einschränkungen auf Anbieterseite |
| Hypervisor- oder Daemon-Exploit | Die VM-Grenze kann die seitliche Bewegung verlangsamen | Host-Patching, minimale Dienste und dedizierte Worker-Knoten |
| Schlechter Code gelangt in die Produktion | Keine | Geschützte Zweige, CI, Überprüfungs- und Bereitstellungsgenehmigungen |
Host-Anforderungen und Installation
Die aktuelle Laufzeit erfordert Linux auf x86_64, Lese-/Schreibzugriff auf /dev/kvm und /dev/vhost-vsockund verschachtelte Virtualisierung, wenn der Bastion-Host selbst eine VM ist. macOS Apple Silicon ist nur für Clients verfügbar. Zu den erforderlichen Host-Dienstprogrammen gehören SSH/SCP, qemu-img, mkfs.vfat, mcopy, iptables und IP-Tools. Bastion kann fehlende Dienstprogramme automatisch über mehrere Paketmanager installieren, wenn dies explizit angefordert wird.
Die Homepage bietet ein Curl-to-Shell-Installationsprogramm, während GitHub Releases Archive bereitstellt. Überprüfen Sie für die Produktion das Skript, überprüfen Sie die Release-Herkunft und Prüfsumme, pinnen Sie eine Version an und zeichnen Sie installierte Cloud Hypervisor-, Gastkernel- und Basis-Image-Versionen auf. Lauf Überprüfung des Bastionssystems nach der Installation und nach Host-Upgrades. Stellen Sie den Standardwert API nicht direkt einem nicht vertrauenswürdigen Netzwerk zur Verfügung.
Vorlagen sind Infrastrukturcode
Eine Vorlage ist unveränderlich JSON und definiert Ressourcen, benannte Tunnel, Agenten und Lebenszyklusaktionen. Während der Erstellung startet Bastion eine temporäre VM, führt Init-Aktionen aus und speichert eine vorbereitete qcow2-Ebene. Neue Umgebungen fügen neue beschreibbare Overlays hinzu und führen optionale Startaktionen aus. Dies macht die Abhängigkeitsinstallation wiederverwendbar und Agentenumgebungen wiederholbar.
Versionsvorlage JSON neben dem Repository, aber getrennte Organisationsrichtlinie vom Projektkomfort. Pin-Paketversionen und Git-Commits. Vermeiden Locken | bash Insider-Init-Aktionen, schwebende Paket-Tags und ungeprüfte Binär-Downloads. Platzieren Sie niemals API-Schlüssel in JSON, Shell-Verlauf, Basis-Images oder Vorlagen-Snapshots. Ein Snapshot kann gelöschte Dateien und den Umgebungsstatus beibehalten.
| Vorlagenfeld | Überprüfungsfrage | Sicherer Standard |
|---|---|---|
| Ressourcen | Kann ein Job die CPU, den Speicher oder die Festplatte des Hosts erschöpfen? | Kleine Kontingente plus Host-Kapazitätsreserve |
| Agenten | Welcher Server ist installiert und welcher Berechtigungsmodus gilt? | Ein zugelassener Agent/eine zugelassene Version mit interaktiven Sicherheitsmaßnahmen |
| Aktionen.init | Was wird als Root ausgeführt und Teil der unveränderlichen Ebene? | Angeheftete, überprüfte, nicht geheime Abhängigkeitseinrichtung |
| Aktionen.Start | Was ändert sich bei jedem Start? | Idempotenter Checkout und Servicestart mit klaren Protokollen |
| Tunnel | Welche Gastports werden über den API erreichbar? | Kein Tunnel, es sei denn, eine Aufgabe erfordert eine überprüfte Vorschau |
| Authentifizierung/Geheimnisse | Können Anmeldeinformationen durch Protokolle, Datenträger oder untergeordnete Prozesse entkommen? | Kurzlebiges Task-Token, das nur zur Laufzeit eingefügt wird |
Repositorys, Zweige und Artefaktfluss
Geben Sie jeder Umgebung einen eindeutigen Problem-, Zweig- und Aufgabenschlüssel. Klonen Sie mit einem Token, der das Repository lesen und nur den angegebenen Zweig pushen kann. Erteilen Sie Agenten nicht die Berechtigung, geschützte Zweige zu umgehen, ihre eigenen Pull-Anfragen zu genehmigen oder Organisationseinstellungen zu verwalten. Ausgaben sollten über einen kontrollierten Pfad erfolgen: Commit/Diff, Testbericht, Build-Artefakt und maschinenlesbare Aufgabenzusammenfassung.
- Erstellen Sie ein Problem mit erlaubten Pfaden, verbotenen Änderungen und Akzeptanztests.
- Erstellen Sie kurzlebige Anmeldeinformationen, die auf ein Repository und einen Aufgabenzweig beschränkt sind.
- Erstellen Sie die Umgebung aus einer angehefteten Vorlagenrevision.
- Führen Sie den Agenten mit Ausgangs- und Laufzeitbeschränkungen aus.
- Sammeln Sie Protokolle, Unterschiede, Testergebnisse, Abhängigkeitsänderungen und Artefakt-Hashes.
- Widerrufen Sie die Berechtigung vor der menschlichen Überprüfung.
- Zusammenführung über normale Protected-Branch- und CI-Steuerelemente.
- Entfernen Sie die Umgebung und überprüfen Sie die Erwartungen zur Datenaufbewahrung.
Netzwerkdesign und Tunnel
Der API bindet standardmäßig an localhost und das Projekt warnt, dass jeder, der ihn erreichen kann, Umgebungen erstellen, entfernen und betreten kann. Wenn ein Fernzugriff erforderlich ist, platzieren Sie ihn hinter einer authentifizierten TLS-Grenze, beispielsweise einem sorgfältig konfigurierten privaten Netzwerk. Ändern Sie die Bindungsadresse nicht auf 0.0.0.0 und gehen Sie davon aus, dass eine Cloud-Firewall ausreicht.
Kontrollieren Sie den Gastausgang nach Ziel und Zweck. Paketregistrierungen, Modellanbieter und Quellhosts können zulässig sein; Metadatenendpunkte, interne Verwaltungssysteme und Produktionsdatenbanken sollten blockiert werden, es sei denn, eine bestimmte Aufgabe wird genehmigt. Benannte Diensttunnel sind für Vorschauserver nützlich, Vorschauanwendungen verfügen jedoch häufig über keine Authentifizierung und führen Entwicklungs-Middleware aus. Geben Sie Tunneln eine kurze Lebensdauer und vermeiden Sie öffentliche Sichtbarkeit.
Geheimnisse und Agentenberechtigungen
Die Beispielkonfiguration verweist auf gespeicherte Geheimnisse, anstatt Schlüsselwerte einzubetten. Das ist die richtige Richtung, doch die Injektion in eine Agent-VM macht das Geheimnis immer noch für einen Prozess mit Gast-Root-Kontrolle verfügbar. Bevorzugen Sie eng begrenzte Installationstoken, Workload-Identitäten oder vermittelte Anmeldeinformationen, die automatisch ablaufen. Trennen Sie Quellzugriff, Modellzugriff, Paketveröffentlichung und Cloud-Bereitstellung in verschiedene Identitäten.
Das Homepage-Beispiel zeigt den OpenCode-Berechtigungswert „allow“. Kopieren Sie ein freizügiges Beispiel nicht in die Produktion, ohne seine genaue Semantik abzubilden. Die VM-Isolierung reduziert die Auswirkungen auf den Host, macht jedoch nicht jede externe Aktion rückgängig. Lassen Sie Vorgänge mit schwerwiegenden Konsequenzen von einem menschlichen oder politischen Dienst außerhalb des Gastes abwickeln.
Einzelner Host versus Cluster
Ein einzelner KVM-Host ist das einfachste Evaluierungsziel. Der optionale Cluster fügt einen gemeinsamen Postgres-Status, S3-compatible-Speicher für Basis-/Vorlagenarchive, Knotenregistrierung, Planung und Proxy-Verbindungen hinzu. Dies erhöht die Kapazitäts- und Verfügbarkeitsmöglichkeiten, erweitert aber auch die Sicherheits- und Backup-Oberfläche.
| Design | Vorteil | Neue Verantwortung |
|---|---|---|
| Einzelner Host | Kleinste Steuerebene und einfachstes Debuggen | Kapazität, lokaler Ausfall und Wartungsfenster |
| Mehrere eigenständige Hosts | Manuelle Trennung nach Team oder Vertrauensebene | Doppelte Bilder, Richtlinien und Terminplanung |
| Bastion-Cluster | Gemeinsame Planung und Vorlagenverteilung | Postgres, Objektspeicher, Knotenauthentifizierung und -wiederherstellung |
| Cloud KVM Instanzen | Elastische Infrastruktur | Unterstützung für verschachtelte Virtualisierung, Instanzkosten und Cloud-IAM |
| Dediziertes Bare-Metal | Vorhersehbare Leistung und klarere Mietergrenzen | Hardwarevorgänge und langsamere Kapazitätsänderungen |
Kapazitäts- und Kostenplanung
Die VM-Isolation verursacht einen echten Overhead. Budgetieren Sie den Hostspeicher für das Betriebssystem, bastiond, den API, den Seitencache und den Spitzenwert gleichzeitiger Gäste. Der Festplattenverbrauch umfasst die gemeinsame Basis, Vorlagen-Overlays, alle beschreibbaren Umgebungen, Protokolle und Cluster-Archive. Copy-on-Write spart zunächst Platz, schreibintensive Builds können jedoch schnell wachsen.
Verfolgen Sie die Startlatenz der Umgebung, die Warteschlangenzeit, die CPU- und Speichersättigung, das Festplattenwachstum, den Netzwerkausgang, die Ausgaben für Agenten/Anbieter, die Bereinigung fehlgeschlagener Aufgaben und die Kosten pro akzeptierter Änderung. Legen Sie TTLs und Leerlaufterminierung fest. „Wegwerf“-Umgebungen werden zu dauerhaften Kosten, wenn kein Prozess für die Löschung zuständig ist.
Alternativen
| Option | Beste Passform | Kompromiss versus Bastion |
|---|---|---|
| Bastion | Selbstgehostete VMs pro Agent unter Linux/KVM mit deklarativen Ebenen | Vor 1.0 und erfordert privilegierte Infrastrukturoperationen |
| E2B | Verwaltete API-erste Cloud-Sandboxes | Weniger Eigenhost-Kontrolle und externer Datenprozessor |
| Daytona | Anbieterübergreifende Orchestrierung der Entwicklungsumgebung | Breiterer Fokus auf den Arbeitsbereich und anderes Isolationsmodell |
| GitHub Actions-Läufer | Überprüfbare, nicht interaktive Repository-Automatisierung | Weniger geeignet für hartnäckige Gesprächsagenten |
| Firecracker Plattform | Teams erstellen eine benutzerdefinierte microVM-Steuerungsebene | Viel mehr Technik, maximale architektonische Kontrolle |
| Rootless-Container | Geringerer Overhead für vertrauenswürdige Workloads | Gemeinsam genutzter Host-Kernel und schwächere Isolationsgrenze |
Häufig gestellte Fragen
Kann Bastion auf einem Mac ausgeführt werden?
Der VM-Host erfordert derzeit Linux x86_64 mit KVM. Apple Silicon macOS kann als Client fungieren, nicht als Virtualisierungshost.
Welche Codierungsagenten werden unterstützt?
OpenCode ist heute die integrierte Integration. SSH bietet einen Pfad für andere Tools, aber diese Arbeitsabläufe erfordern Ihre eigene Einrichtung und Validierung.
Befindet sich jeder Agent in einer separaten VM?
Jede Bastion-Umgebung erhält eine Cloud Hypervisor-VM mit eigenem Gastkernel, Dateisystem, Prozessen und Netzwerk.
Ist es produktionsreif?
Das Projekt beschreibt sich selbst als vor 1.0 und warnt davor, dass sich Schnittstellen ändern können. Führen Sie einen begrenzten Pilotversuch durch und pinnen Sie exakte Versionen.
Macht die VM-Isolation die automatische Genehmigung sicher?
Nein. Externe Anmeldeinformationen und Netzwerkautorität bleiben auch dann von Bedeutung, wenn Hostdateien isoliert sind.
Ist Bastion Open Source?
Ja. Das aktuelle Repository wird unter der MIT-Lizenz veröffentlicht.
Primärquellen
- Offizielle Produktübersicht und Arbeitsablauf
- Offizielles Repository, Architektur und Einschränkungen
- Offizieller Host- und Laufzeit-Setup-Leitfaden
- Offizieller Vorlagenführer
- Offizieller Leitfaden zur Cluster-Architektur
- Offizielles Beispiel für privaten Fernzugriff
- Offizielle MIT-Lizenz
- Cloud Hypervisor Dokumentation
Zuletzt überprüft am 25. Juli 2026. Bastion ist vor 1.0; Überprüfen Sie vor der Einführung das aktuelle Schema, die Version, die Sicherheitshinweise und die Infrastrukturanforderungen.
