Bastion es un orquestador autohospedado para agentes de codificación en segundo plano. En lugar de proporcionar procesos o contenedores a varios agentes en una computadora portátil de desarrollador, crea una máquina virtual Cloud Hypervisor separada para cada entorno. Las plantillas definen CPU, memoria, disco, agentes, túneles y acciones del ciclo de vida como JSON validado por esquema; las capas preparadas se reutilizan, mientras que cada tarea recibe una nueva superposición grabable.
Esto es infraestructura, no un modelo de codificación. Bastion actualmente integra OpenCode directamente y expone SSH para otras herramientas. Puede reducir los conflictos y mejorar la contención, pero una VM es sólo un límite de seguridad. El demonio del host privilegiado, el API local, la cadena de suministro de la plantilla, la salida de la red, los secretos, los repositorios y la ruta de fusión aún requieren una política explícita.
Cómo se ensambla Bastion
| Componente | Responsabilidad | Implicación de confianza |
|---|---|---|
| Anfitrión API | Almacena metadatos en SQLite y sirve HTTP en localhost:3148 de forma predeterminada | Proceso sin privilegios, pero cualquier persona que llama puede crear, ingresar y eliminar entornos. |
| bastiond | Realiza operaciones de red y ciclo de vida de VM privilegiadas a través de un socket Unix | Se ejecuta como root; el compromiso puede afectar a todas las redes de invitados y anfitriones |
| Cloud Hypervisor máquina virtual | Proporciona kernel invitado, sistema de archivos raíz, procesos y red para un entorno | Separación más fuerte que un proceso compartido, pero no un límite absoluto |
| Imagen base | Kernel de Ubuntu/initramfs/sistema de archivos raíz compartido y componentes invitados | Una base vulnerable o envenenada se propaga a cada plantilla. |
| Superposición de plantilla | Dependencias de proyectos preparados inmutables y acciones de inicio. | Mejora la reproducibilidad; Los secretos no deben incorporarse a la capa. |
| Superposición de entorno | Disco grabable de copia en escritura para una tarea | Desechable por diseño; Los resultados requeridos deben exportarse antes de eliminarlos. |
Beneficios del aislamiento y lo que no prueban
Cada VM tiene su propio kernel invitado, procesos, sistema de archivos y red. Eso reduce los conflictos accidentales entre agentes que instalan diferentes dependencias, vinculan el mismo puerto o editan un árbol de trabajo común. También crea una unidad de destrucción más clara: elimina el entorno en lugar de intentar limpiar un árbol de procesos desconocido desde una computadora portátil.
El aislamiento no garantiza por sí solo una autonomía segura. Una máquina virtual con un token de GitHub amplio aún puede eliminar ramas; la salida sin restricciones aún puede filtrar código; un túnel puede exponer un servidor de desarrollo vulnerable; y una acción de plantilla maliciosa se ejecuta como root dentro del invitado. La documentación actual de Bastion también dice que las acciones de la plantilla se ejecutan como raíz invitada y el demonio del host se ejecuta como raíz. Trate ambos hechos como aportaciones de diseño, no como notas a pie de página.
| Amenaza | VM ayuda con | Se requiere control adicional |
|---|---|---|
| Dos agentes alteran la misma dependencia | Separar discos grabables y procesos | Separar ramas/árboles de trabajo y fusionar revisión |
| El agente ejecuta un comando de shell destructivo | El daño puede permanecer dentro del huésped desechable. | Sin montajes de host, credenciales con alcance ni límites de salida |
| Instalación de paquete malicioso | Proceso de aislamiento de otros huéspedes | Política de registro, archivos de bloqueo, escaneo y reconstrucción |
| Uso indebido de credenciales | Ninguno si la credencial otorga autoridad externa | Tokens por tarea de corta duración y restricciones del lado del proveedor |
| Explotación de hipervisor o demonio | El límite de VM puede ralentizar el movimiento lateral | Parches de host, servicios mínimos y nodos trabajadores dedicados |
| El código incorrecto llega a producción | Ninguno | Sucursales protegidas, CI, revisión y aprobaciones de implementación |
Requisitos e instalación del host
El tiempo de ejecución actual requiere Linux en x86_64, acceso de lectura/escritura a /dev/kvm y /dev/vhost-vsocky virtualización anidada cuando el host Bastion es una máquina virtual. macOS Apple Silicon es solo para cliente. Las utilidades de host requeridas incluyen SSH/SCP, qemu-img, mkfs.vfat, mcopy, iptables y herramientas IP. Bastion puede instalar automáticamente las utilidades que faltan a través de varios administradores de paquetes cuando se solicita explícitamente.
La página de inicio ofrece un instalador curl-to-shell, mientras que GitHub Releases proporciona archivos. Para producción, inspeccione el script, verifique la procedencia de la versión y la suma de verificación, fije una versión y registre el Cloud Hypervisor instalado, el kernel invitado y las versiones de la imagen base. correr verificación del sistema bastión después de la instalación y después de las actualizaciones del host. No exponga el API predeterminado directamente a una red que no sea de confianza.
Las plantillas son código de infraestructura.
Una plantilla es inmutable JSON y define recursos, túneles con nombre, agentes y acciones del ciclo de vida. Durante la creación, Bastion inicia una VM temporal, ejecuta acciones de inicio y almacena una capa qcow2 preparada. Los nuevos entornos agregan nuevas superposiciones de escritura y ejecutan acciones de inicio opcionales. Esto hace que la instalación de dependencias sea reutilizable y que los entornos de agentes sean repetibles.
Plantilla de versión JSON junto con el repositorio, pero separa la política de la organización de la conveniencia del proyecto. Anclar versiones de paquetes y confirmaciones de Git. evitar rizo | fiesta acciones de inicio internas, etiquetas de paquetes flotantes y descargas binarias no verificadas. Nunca coloque claves API en JSON, historial de shell, imágenes base o instantáneas de plantilla. Una instantánea puede preservar los archivos eliminados y el estado del entorno.
| Campo de plantilla | Pregunta de revisión | Valor predeterminado seguro |
|---|---|---|
| recursos | ¿Puede un trabajo agotar la CPU, la memoria o el disco del host? | Cuotas pequeñas más reserva de capacidad de host |
| agentes | ¿Qué servidor está instalado y qué modo de permiso se aplica? | Un agente/versión aprobado con protecciones interactivas |
| acciones.init | ¿Qué se ejecuta como raíz y pasa a formar parte de la capa inmutable? | Configuración de dependencias fijadas, revisadas y no secretas |
| acciones.inicio | ¿Qué cambia en cada arranque? | Pago idempotente y lanzamiento de servicios con registros claros |
| túneles | ¿A qué puertos invitados se puede acceder a través de API? | Sin túnel a menos que una tarea requiera una vista previa revisada |
| autenticación/secretos | ¿Pueden escapar las credenciales a través de registros, discos o procesos secundarios? | Token de tarea de corta duración inyectado solo en tiempo de ejecución |
Repositorios, sucursales y flujo de artefactos
Proporcione a cada entorno una clave de problema, rama y tarea única. Clona con un token que pueda leer el repositorio y enviar solo la rama designada. No dé permiso a los agentes para eludir sucursales protegidas, aprobar sus propias solicitudes de extracción o administrar la configuración de la organización. Las salidas deben salir a través de una ruta controlada: confirmación/diferenciación, informe de prueba, artefacto de compilación y resumen de tareas legible por máquina.
- Cree un problema con rutas permitidas, cambios prohibidos y pruebas de aceptación.
- Crea una credencial de corta duración con alcance en un repositorio y una rama de tareas.
- Cree el entorno a partir de una revisión de plantilla fijada.
- Ejecute el agente con límites de salida y tiempo de ejecución.
- Recopile registros, diferencias, resultados de pruebas, cambios de dependencia y hashes de artefactos.
- Revocar la credencial antes de la revisión humana.
- Fusionar a través de controles normales de rama protegida y CI.
- Elimine el entorno y verifique las expectativas de retención de datos.
Diseño de redes y túneles.
El API se vincula al localhost de forma predeterminada y el proyecto advierte que cualquiera que pueda acceder a él puede crear, eliminar e ingresar a entornos. Si es necesario el acceso remoto, colóquelo detrás de un límite TLS autenticado, como una red privada cuidadosamente configurada. No cambie la dirección de enlace a 0.0.0.0 y asuma que un firewall en la nube es suficiente.
Controle la salida de huéspedes por destino y propósito. Es posible que se permitan registros de paquetes, proveedores de modelos y hosts de origen; Los puntos finales de metadatos, los sistemas de administración internos y las bases de datos de producción deben bloquearse a menos que se apruebe una tarea en particular. Los túneles de servicios con nombre son útiles para los servidores de vista previa, pero las aplicaciones de vista previa a menudo carecen de autenticación y ejecutan middleware de desarrollo. Proporcione a los túneles una vida útil corta y evite la exposición del público.
Secretos y permisos de agentes
La configuración de ejemplo hace referencia a secretos almacenados en lugar de incrustar valores clave. Esa es la dirección correcta, pero la inyección en una VM agente aún hace que el secreto esté disponible para un proceso con control de raíz invitada. Prefiera tokens de instalación de alcance limitado, identidades de carga de trabajo o credenciales intermediadas que caduquen automáticamente. Separe el acceso a fuentes, el acceso a modelos, la publicación de paquetes y la implementación en la nube en diferentes identidades.
El ejemplo de la página de inicio muestra un valor de permiso OpenCode de "permitir". No copie un ejemplo permisivo en producción sin mapear su semántica exacta. El aislamiento de la máquina virtual reduce el impacto en el host, pero no hace que todas las acciones externas sean reversibles. Mantenga las operaciones de alto impacto detrás de un servicio humano o de políticas fuera del huésped.
Host único versus clúster
Un único host KVM es el objetivo de evaluación más simple. El clúster opcional agrega estado de Postgres compartido, almacenamiento S3-compatible para archivos base/plantillas, registro de nodos, programación y conexiones proxy. Esto aumenta las opciones de capacidad y disponibilidad, pero también amplía la superficie de seguridad y respaldo.
| Diseño | ventaja | Nueva responsabilidad |
|---|---|---|
| anfitrión único | Plano de control más pequeño y depuración más sencilla | Capacidad, falla local y ventana de mantenimiento |
| Múltiples hosts independientes | Separación manual por equipo o nivel de confianza | Imágenes, políticas y programación duplicadas |
| Bastion clúster | Programación compartida y distribución de plantillas. | Postgres, almacenamiento de objetos, autenticación y recuperación de nodos. |
| Instancias de nube KVM | Infraestructura elástica | Soporte de virtualización anidada, costo de instancia e IAM en la nube |
| Metal desnudo dedicado | Rendimiento predecible y límites de inquilinos más claros | Operaciones de hardware y cambios de capacidad más lentos |
Planificación de capacidad y costes.
El aislamiento de VM tiene una sobrecarga real. Memoria de host presupuestada para el sistema operativo, bastiond, API, caché de página e invitados simultáneos pico. El consumo de disco incluye la base compartida, las superposiciones de plantillas, todos los entornos de escritura, registros y archivos del clúster. La copia en escritura ahorra espacio inicialmente, pero las compilaciones con mucha escritura pueden crecer rápidamente.
Realice un seguimiento de la latencia de inicio del entorno, el tiempo de cola, la saturación de CPU y memoria, el crecimiento del disco, la salida de la red, el gasto de agente/proveedor, la limpieza de tareas fallidas y el costo por cambio aceptado. Establezca TTL y terminación inactiva. Los entornos “desechables” se convierten en un gasto permanente cuando ningún proceso es dueño de su eliminación.
Alternativas
| Opción | Mejor ajuste | Compensación versus Bastion |
|---|---|---|
| Bastion | Máquinas virtuales por agente autohospedadas en Linux/KVM con capas declarativas | Pre-1.0 y requiere operaciones de infraestructura privilegiadas |
| E2B | Gestionados, API: primeros entornos sandbox en la nube | Menos control de host propio y procesador de datos externo |
| Daytona | Orquestación del entorno de desarrollo entre proveedores | Enfoque más amplio en el espacio de trabajo y modelo de aislamiento diferente |
| Corredores de acciones de GitHub | Automatización de repositorios no interactivos auditables | Menos adecuado para agentes conversacionales persistentes |
| Plataforma Firecracker | Equipos que crean un plano de control microVM personalizado | Mucha más ingeniería, máximo control arquitectónico |
| Contenedores desarraigados | Cargas de trabajo confiables con menores gastos generales | Núcleo de host compartido y límite de aislamiento más débil |
Preguntas frecuentes
¿Se puede ejecutar Bastion en una Mac?
El host de VM actualmente requiere Linux x86_64 con KVM. Apple Silicon macOS puede actuar como cliente, no como host de virtualización.
¿Qué agentes de codificación son compatibles?
OpenCode es la integración incorporada hoy. SSH proporciona una ruta para otras herramientas, pero esos flujos de trabajo requieren su propia configuración y validación.
¿Está cada agente en una máquina virtual separada?
Cada entorno Bastion recibe una máquina virtual Cloud Hypervisor con su propio kernel invitado, sistema de archivos, procesos y red.
¿Está listo para producción?
El proyecto se describe a sí mismo como anterior a 1.0 y advierte que las interfaces pueden cambiar. Ejecute un piloto limitado y fije versiones exactas.
¿El aislamiento de VM hace que la aprobación automática sea segura?
No. Las credenciales externas y la autoridad de la red siguen siendo importantes incluso si los archivos del host están aislados.
¿Bastion es de código abierto?
Sí. El repositorio actual está publicado bajo la licencia MIT.
fuentes primarias
- Descripción oficial del producto y flujo de trabajo
- Repositorio oficial, arquitectura y limitaciones.
- Guía oficial de configuración de host y tiempo de ejecución
- Guía de plantillas oficiales
- Guía oficial de arquitectura de clústeres
- Ejemplo oficial de acceso remoto privado
- Licencia oficial del MIT
- Cloud Hypervisor documentación
Última revisión el 25 de julio de 2026. Bastion es anterior a 1.0; Verifique el esquema actual, la versión, las notas de seguridad y los requisitos de infraestructura antes de la implementación.
