Seis límites y seis capas que los mantienen
Cómo mantiene Provisioning las llamadas a proveedores, SSH, los secretos y la autorización cada uno en un único lugar
Seis límites y seis capas que los mantienen
A medida que Provisioning pasó de ser una herramienta de línea de órdenes a un plano de control con varios servicios, apareció una y otra vez el mismo fallo: la CLI llamaba directamente a las herramientas de los proveedores en la nube. Las credenciales del proveedor terminaban en el entorno del proceso de la CLI, las llamadas hechas fuera del orquestador no dejaban rastro de auditoría, las operaciones SSH se saltaban la máquina de estados de tareas y su vuelta atrás, y las comprobaciones de autorización se duplicaban entre servicios.
La documentación no lo evitaba: con prisa, una regla escrita es una regla que se salta. La respuesta tenía que ser estructural.
Los seis límites
Cada responsabilidad vive en un único lugar:
- Las llamadas a las API de proveedor solo existen en el crate del orquestador.
- Las operaciones SSH solo existen en los crates del orquestador y de machines.
- La CLI nunca accede directamente a SurrealDB.
- Las credenciales secretas nunca viajan en mensajes de NATS.
- Las decisiones de autorización se toman solo en el Control Center.
- Los servicios nunca leen ficheros de secretos ni variables de entorno en bruto: tienen una concesión y piden el secreto al vault.
El resto de servicios llega a un proveedor a través de la API HTTP del orquestador, recibe un contexto de usuario en lugar de volver a validar tokens y trabaja con referencias de concesión en lugar de con valores secretos. Las políticas Cedar son el único mecanismo de autorización: no hay comprobaciones de rol improvisadas en la lógica de negocio.
Seis capas, y basta con una
Un límite vale lo que vale aquello que detecta su infracción. Provisioning aplica cada uno en seis capas independientes, y basta con que una sola detecte la infracción para impedir que se publique:
| Capa | Cómo detecta la infracción |
|---|---|
| Compilación | visibilidad de crates: lo que es privado del orquestador no se puede llamar desde fuera |
| Desarrollo | un hook de la herramienta rechaza la edición antes de escribirla |
| Antes del commit | un hook de git rechaza el cambio |
| CI | las pruebas de arquitectura hacen fallar la canalización |
| Ejecución | las políticas Cedar deniegan la petición |
| Auditoría continua | los eventos en un subject de auditoría de NATS dejan constancia de lo ocurrido |
Por qué importa al operador
Los límites no son una regla de orden interno: deciden hasta dónde puede llegar un incidente. Comprometer un servicio que no es el orquestador no entrega credenciales de proveedor, porque ese servicio nunca las tuvo. Un flujo de eventos filtrado lleva referencias, no secretos. Y como cada llamada a un proveedor y cada sesión SSH pasan por el orquestador, todas atraviesan su máquina de estados de tareas, con rastro de auditoría y con vuelta atrás.