Bastion est un orchestrateur auto-hébergé pour les agents de codage en arrière-plan. Au lieu de confier plusieurs processus ou conteneurs à des agents sur un ordinateur portable de développeur, il crée une machine virtuelle Cloud Hypervisor distincte pour chaque environnement. Les modèles définissent le processeur, la mémoire, le disque, les agents, les tunnels et les actions de cycle de vie comme JSON validé par le schéma ; les couches préparées sont réutilisées, tandis que chaque tâche reçoit une nouvelle superposition inscriptible.
Il s’agit d’une infrastructure, pas d’un modèle de codage. Bastion intègre actuellement OpenCode directement et expose SSH pour d'autres outils. Elle peut réduire les conflits et améliorer le confinement, mais une VM ne constitue qu’une frontière de sécurité. Le démon hôte privilégié, le API local, la chaîne d'approvisionnement du modèle, la sortie réseau, les secrets, les référentiels et le chemin de fusion nécessitent toujours une politique explicite.
Comment Bastion est assemblé
| Composant | Responsabilité | Implication de confiance |
|---|---|---|
| Hôte API | Stocke les métadonnées dans SQLite et sert HTTP sur localhost:3148 par défaut | Processus non privilégié, mais n'importe quel appelant peut créer, entrer et supprimer des environnements |
| bastiond | Effectue des opérations privilégiées de cycle de vie et de mise en réseau des machines virtuelles via un socket Unix | S'exécute en tant que root ; un compromis peut affecter chaque réseau invité et hôte |
| Cloud Hypervisor VM | Fournit un noyau invité, un système de fichiers racine, des processus et un réseau pour un seul environnement | Une séparation plus forte qu'un processus partagé, mais pas une frontière absolue |
| Image de base | Noyau Ubuntu partagé/initramfs/système de fichiers racine et composants invités | Une base vulnérable ou empoisonnée se propage à chaque modèle |
| Superposition de modèles | Dépendances de projet préparées immuables et actions d'initialisation | Améliore la reproductibilité ; les secrets ne doivent pas être intégrés à la couche |
| Superposition d'environnement | Disque de copie sur écriture inscriptible pour une tâche | Jetable par conception ; les sorties requises doivent être exportées avant la suppression |
Les avantages de l’isolement – et ce qu’ils ne prouvent pas
Chaque VM possède son propre noyau invité, ses processus, son système de fichiers et son réseau. Cela réduit les conflits accidentels entre les agents installant différentes dépendances, liant le même port ou modifiant une arborescence de travail commune. Cela crée également une unité de destruction plus claire : supprimez l'environnement au lieu d'essayer de nettoyer une arborescence de processus inconnue d'un ordinateur portable.
L’isolement ne garantit pas en soi une autonomie sûre. Une VM avec un jeton GitHub large peut toujours supprimer des branches ; une sortie sans restriction peut toujours exfiltrer le code ; un tunnel peut exposer un serveur de développement vulnérable ; et une action de modèle malveillante s'exécute en tant que root à l'intérieur de l'invité. La documentation actuelle de Bastion indique également que les actions de modèle s'exécutent en tant que root invité et que le démon hôte s'exécute en tant que root. Traitez les deux faits comme des intrants de conception, et non comme des notes de bas de page.
| Menace | La VM aide à | Contrôle supplémentaire requis |
|---|---|---|
| Deux agents modifient la même dépendance | Disques inscriptibles et processus séparés | Séparer les branches/arbres de travail et fusionner l'examen |
| L'agent exécute une commande shell destructrice | Les dommages peuvent rester à l'intérieur de l'invité jetable | Pas de montage d'hôte, d'informations d'identification étendues et de limites de sortie |
| Installation de package malveillant | Isolement des processus par rapport aux autres invités | Politique de registre, fichiers de verrouillage, analyse et reconstruction |
| Utilisation abusive des informations d'identification | Aucun si le titre accorde une autorité externe | Jetons par tâche de courte durée et restrictions côté fournisseur |
| Exploit d'hyperviseur ou de démon | La limite de la VM peut ralentir le mouvement latéral | Correctifs hôtes, services minimaux et nœuds de travail dédiés |
| Un mauvais code arrive en production | Aucun | Branches protégées, CI, approbations de révision et de déploiement |
Configuration requise et installation de l'hôte
Le runtime actuel nécessite Linux sur x86_64, un accès en lecture/écriture à /dev/kvm et /dev/vhost-vsock, et la virtualisation imbriquée lorsque l'hôte Bastion lui-même est une VM. Le silicium Apple macOS est réservé au client. Les utilitaires hôtes requis incluent SSH/SCP, qemu-img, mkfs.vfat, mcopy, iptables et les outils IP. Bastion peut installer automatiquement les utilitaires manquants via plusieurs gestionnaires de packages lorsque cela est explicitement demandé.
La page d'accueil propose un programme d'installation curl-to-shell, tandis que GitHub Releases fournit des archives. Pour la production, inspectez le script, vérifiez la provenance et la somme de contrôle de la version, épinglez une version et enregistrez les versions Cloud Hypervisor, invité et image de base installées. Courir vérification du système de bastion après l'installation et après les mises à niveau de l'hôte. N'exposez pas le API par défaut directement à un réseau non approuvé.
Les modèles sont du code d'infrastructure
Un modèle est immuable JSON définissant des ressources, des tunnels nommés, des agents et des actions de cycle de vie. Lors de la création, Bastion démarre une VM temporaire, exécute des actions d'initialisation et stocke une couche qcow2 préparée. Les nouveaux environnements ajoutent de nouvelles superpositions inscriptibles et exécutent des actions de démarrage facultatives. Cela rend l’installation des dépendances réutilisable et les environnements d’agent reproductibles.
Modèle de version JSON à côté du référentiel, mais séparez la politique de l'organisation de la commodité du projet. Épinglez les versions du package et les commits Git. Éviter boucler | coup à l'intérieur des actions d'initialisation, des balises de package flottantes et des téléchargements binaires non vérifiés. Ne placez jamais les clés API dans JSON, l'historique du shell, les images de base ou les instantanés de modèles. Un instantané peut conserver les fichiers supprimés et l'état de l'environnement.
| Champ de modèle | Question de révision | Valeur par défaut sûre |
|---|---|---|
| ressources | Une tâche peut-elle épuiser le processeur, la mémoire ou le disque de l'hôte ? | Petits quotas plus réserve de capacité d'accueil |
| agents | Quel serveur est installé et quel mode d'autorisation s'applique ? | Un agent/version approuvé avec des protections interactives |
| actions.init | Qu'est-ce qui s'exécute en tant que root et fait partie de la couche immuable ? | Configuration des dépendances épinglée, révisée et non secrète |
| actions.start | Qu'est-ce qui change à chaque démarrage ? | Paiement idempotent et lancement de service avec des journaux clairs |
| tunnels | Quels ports invités deviennent accessibles via API ? | Pas de tunnel sauf si une tâche nécessite un aperçu révisé |
| authentification/secrets | Les informations d’identification peuvent-elles s’échapper via les journaux, les disques ou les processus enfants ? | Jeton de tâche de courte durée injecté uniquement au moment de l'exécution |
Dépôts, branches et flux d'artefacts
Attribuez à chaque environnement une clé de problème, de branche et de tâche unique. Clonez avec un jeton capable de lire le référentiel et de pousser uniquement la branche désignée. N'autorisez pas les agents à contourner les branches protégées, à approuver leurs propres demandes d'extraction ou à gérer les paramètres de l'organisation. Les sorties doivent sortir par un chemin contrôlé : validation/diff, rapport de test, artefact de construction et résumé des tâches lisible par machine.
- Créez un problème avec des chemins autorisés, des modifications interdites et des tests d'acceptation.
- Créez un identifiant de courte durée limité à un référentiel et une branche de tâches.
- Créez l'environnement à partir d'une révision de modèle épinglée.
- Exécutez l'agent avec des limites de sortie et d'exécution.
- Collectez les journaux, les différences, les résultats des tests, les modifications de dépendances et les hachages d'artefacts.
- Révoquez les informations d'identification avant l'examen humain.
- Fusionnez via les contrôles normaux de branche protégée et CI.
- Supprimez l’environnement et vérifiez les attentes en matière de conservation des données.
Conception de réseau et tunnels
Le API se lie à localhost par défaut et le projet avertit que toute personne pouvant l'atteindre peut créer, supprimer et accéder à des environnements. Si un accès à distance est nécessaire, placez-le derrière une limite TLS authentifiée telle qu'un réseau privé soigneusement configuré. Ne modifiez pas l'adresse de liaison en 0.0.0.0 et supposez qu'un pare-feu cloud suffit.
Contrôlez la sortie des invités par destination et par objectif. Les registres de packages, les fournisseurs de modèles et les hôtes sources peuvent être autorisés ; les points de terminaison de métadonnées, les systèmes d’administration internes et les bases de données de production doivent être bloqués à moins qu’une tâche particulière ne soit approuvée. Les tunnels de service nommés sont utiles pour les serveurs de préversion, mais les applications de préversion manquent souvent d'authentification et exécutent un middleware de développement. Donnez aux tunnels une durée de vie courte et évitez leur exposition au public.
Secrets et autorisations des agents
L'exemple de configuration fait référence à des secrets stockés plutôt qu'à des valeurs de clé intégrées. C'est la bonne direction, mais l'injection dans une VM d'agent rend toujours le secret disponible à un processus avec un contrôle racine invité. Préférez les jetons d’installation à portée étroite, les identités de charge de travail ou les informations d’identification négociées qui expirent automatiquement. Séparez l’accès aux sources, l’accès aux modèles, la publication de packages et le déploiement cloud en différentes identités.
L'exemple de page d'accueil montre une valeur d'autorisation OpenCode de « autoriser ». Ne copiez pas un exemple permissif en production sans cartographier sa sémantique exacte. L'isolation des machines virtuelles réduit l'impact sur l'hôte mais ne rend pas toutes les actions externes réversibles. Gardez les opérations à conséquences élevées derrière un service humain ou politique en dehors de l’invité.
Hôte unique ou cluster
Un seul hôte KVM est la cible d'évaluation la plus simple. Le cluster facultatif ajoute un état Postgres partagé, un stockage S3-compatible pour les archives de base/modèle, l'enregistrement des nœuds, la planification et les connexions par proxy. Cela augmente les options de capacité et de disponibilité, mais étend également la surface de sécurité et de sauvegarde.
| Conception | Avantage | Nouvelle responsabilité |
|---|---|---|
| Hôte unique | Le plus petit plan de contrôle et le débogage le plus simple | Capacité, panne locale et fenêtre de maintenance |
| Plusieurs hôtes autonomes | Séparation manuelle par équipe ou niveau de confiance | Images, politiques et planification dupliquées |
| cluster Bastion | Planification partagée et distribution de modèles | Postgres, stockage d'objets, authentification et récupération des nœuds |
| Instances cloud KVM | Infrastructure élastique | Prise en charge de la virtualisation imbriquée, coût de l'instance et IAM cloud |
| Métal nu dédié | Performances prévisibles et limites de locataires plus claires | Opérations matérielles et changements de capacité plus lents |
Planification des capacités et des coûts
L’isolation des machines virtuelles entraîne une réelle surcharge. Mémoire hôte budgétaire pour le système d'exploitation, bastiond, API, cache de pages et invités simultanés de pointe. La consommation de disque inclut la base partagée, les superpositions de modèles, chaque environnement inscriptible, les journaux et les archives de cluster. La copie sur écriture permet d'économiser de l'espace au départ, mais les versions nécessitant beaucoup d'écriture peuvent se développer rapidement.
Suivez la latence de démarrage de l'environnement, le temps d'attente, la saturation du processeur et de la mémoire, la croissance des disques, la sortie du réseau, les dépenses des agents/fournisseurs, le nettoyage des tâches ayant échoué et le coût par modification acceptée. Définissez les durées de vie et la terminaison d'inactivité. Les environnements « jetables » deviennent une dépense permanente lorsqu'aucun processus ne possède la suppression.
Alternatives
| Options | Meilleur ajustement | Compromis par rapport à Bastion |
|---|---|---|
| Bastion | Machines virtuelles par agent auto-hébergées sous Linux/KVM avec couches déclaratives | Pré-1.0 et nécessite des opérations d’infrastructure privilégiées |
| E2B | Sandbox cloud gérés, API-premiers | Moins de contrôle auto-hôte et de processeur de données externe |
| Daytona | Orchestration de l’environnement de développement entre les fournisseurs | Un espace de travail plus large et un modèle d'isolement différent |
| Coureurs d'actions GitHub | Automatisation du référentiel non interactif auditable | Moins adapté aux agents conversationnels persistants |
| Plateforme Firecracker | Équipes créant un plan de contrôle microVM personnalisé | Beaucoup plus d'ingénierie, un contrôle architectural maximal |
| Conteneurs sans racines | Charges de travail fiables à moindre surcharge | Noyau hôte partagé et limite d'isolation plus faible |
Questions fréquemment posées
Bastion peut-il fonctionner sur un Mac ?
L'hôte de la VM nécessite actuellement Linux x86_64 avec KVM. Apple Silicon macOS peut agir en tant que client et non en tant qu'hôte de virtualisation.
Quels agents de codage sont pris en charge ?
OpenCode est l'intégration intégrée aujourd'hui. SSH fournit un chemin vers d'autres outils, mais ces flux de travail nécessitent votre propre configuration et validation.
Chaque agent se trouve-t-il dans une VM distincte ?
Chaque environnement Bastion reçoit une VM Cloud Hypervisor avec son propre noyau invité, son système de fichiers, ses processus et son réseau.
Est-il prêt pour la production ?
Le projet se décrit comme pré-1.0 et prévient que les interfaces peuvent changer. Exécutez un pilote limité et épinglez les versions exactes.
L’isolation des VM sécurise-t-elle l’approbation automatique ?
Non. Les informations d’identification externes et l’autorité réseau restent conséquentes même si les fichiers hôtes sont isolés.
Bastion est-il open source ?
Oui. Le référentiel actuel est publié sous la licence MIT.
Sources primaires
- Présentation officielle du produit et flux de travail
- Dépôt officiel, architecture et limitations
- Guide officiel de configuration de l'hôte et du runtime
- Guide des modèles officiels
- Guide officiel de l'architecture de cluster
- Exemple officiel d'accès à distance privé
- Licence officielle MIT
- Documentation Cloud Hypervisor
Dernière révision le 25 juillet 2026. Bastion est antérieur à la version 1.0 ; Vérifiez le schéma actuel, la version, les notes de sécurité et les exigences d'infrastructure avant le déploiement.
