Contenedores sin daemon: el enfoque que elimina el riesgo en tiempo de build
Hay una suposición que casi todos los equipos de desarrollo dan por sentada: para crear una imagen de contenedor, necesitas un daemon de Docker, un builder, y un Dockerfile que se ejecuta como un programa en tu infraestructura. Es el flujo de trabajo estándar, y funciona bien... hasta que el que escribe ese Dockerfile deja de ser una persona de tu equipo.
En agosto de 2026, con pipelines automatizados, agentes de IA generando configuraciones y dependencias descritas por sistemas externos, esa suposición se convierte en un vector de riesgo real. Un artículo publicado en Dev.to por Amartya Gaur plantea una alternativa que vale la pena analizar: generar imágenes de contenedor sin ejecutar nada en tiempo de build. Sin daemon, sin RUN, sin shell.
En este artículo exploramos cómo funciona este enfoque, qué ventajas concretas ofrece en seguridad y velocidad, y cuándo tiene sentido adoptarlo en equipos de desarrollo en Perú y América Latina.
Una imagen de contenedor no es magia — es solo archivos y un manifiesto
El primer insight del artículo es deceptivamente simple: una imagen OCI es un conjunto de tarballs más un documento JSON que los describe. Nada en esa definición exige que esos tarballs hayan sido producidos ejecutando comandos.
Esto lo aprovecha una herramienta llamada apko, desarrollada por Chainguard. En lugar de procesar un Dockerfile, apko recibe una lista declarativa de paquetes y genera la imagen directamente — resolviendo dependencias, armando las capas y escribiendo el manifiesto. El resultado es reproducible: la misma lista de paquetes siempre produce el mismo digest de imagen, porque no hay entropía de tiempo de ejecución que genere variación.
La configuración se ve así de limpia:
- Declaras los repositorios de paquetes (por ejemplo, el ecosistema Wolfi de Chainguard)
- Listas los paquetes que necesitas
- Defines el usuario con el que corre el contenedor
- Defines el entrypoint
No hay instrucciones RUN. No hay shell ejecutándose. No hay forma de insertar código arbitrario en ese flujo.
La ausencia de RUN es la feature de seguridad más importante
Aquí está el insight que más me llamó la atención del análisis de Gaur: con un Dockerfile tradicional, la entrada es un programa y el build es su ejecución — en tu builder, con acceso a tu red, tus secretos de CI y todo lo que ese entorno puede alcanzar.
Todas las medidas de hardening que aplicamos después — rootless containers, sin red, entorno limpio — son formas de re-imponer restricciones que el formato mismo del Dockerfile eliminó por diseño. Estás construyendo una sandbox para compensar una apertura que no tenías que hacer.
Con el enfoque declarativo, la pregunta de seguridad cambia completamente. Si un agente externo, un pipeline automatizado o una IA genera la descripción del entorno, lo peor que puede hacer una descripción maliciosa es pedir un paquete. No puede ejecutar curl para descargar un script. No puede leer tus secretos de build. No puede escribir en una capa y luego borrar la evidencia.
La entrada es tratada como datos, no como código. Esa distinción es la diferencia entre un vector de ataque activo y uno que simplemente no existe.
Velocidad real: 14 segundos vs 0.227 segundos
El beneficio de velocidad aparece especialmente cuando necesitas muchas imágenes similares — una base con pequeñas variaciones por job o por entorno. Dado que una imagen es capas más un manifiesto, cambiar la base debajo de un conjunto de capas es una operación de metadatos, no un rebuild completo.
La herramienta crane rebase hace exactamente eso contra el registry: intercambia la base sin descargar ni subir nada de gran tamaño. Los números del artículo son concretos:
- Construir la imagen base desde cero: 14 segundos
- Ensamblar una variante por rebase: 0.227 segundos
La segunda fila es literalmente una escritura de manifiesto. Una vez que la base está cacheada por el fingerprint de su lista de paquetes, cada variante es prácticamente instantánea. Para equipos con pipelines de CI/CD que generan muchas imágenes por día, ese ahorro acumulado es significativo.
¿Cómo aplica esto en equipos de desarrollo en Perú y LATAM?
Este enfoque no es para todos los proyectos, y el propio autor lo deja claro. Si tu equipo escribe todos los Dockerfiles, los revisa en pull requests y controla el proceso de principio a fin, un Dockerfile estándar funciona perfectamente y ya sabes cómo opera.
Pero hay escenarios donde este patrón paga inmediatamente:
- Pipelines con generación automática de entornos: cuando una IA o un sistema externo describe las dependencias de un job, eliminar la capacidad de ejecutar código arbitrario en el builder es una decisión de arquitectura de seguridad, no solo una optimización.
- Equipos con muchas variantes de imagen: proyectos con múltiples microservicios que comparten una base común se benefician enormemente del rebase en lugar del rebuild.
- Ambientes con restricciones de seguridad estrictas: sectores como fintech, salud o gobierno en Perú donde los controles de supply chain de software son cada vez más exigentes.
El costo real a considerar es que estás limitado a lo que está empaquetado en el ecosistema Wolfi. Si tu dependencia no está disponible como apk, tendrás que empaquetarla tú mismo — lo cual tiene un costo de mantenimiento. El patrón honesto es usar un builder real para compilar artefactos y luego usar apko para componer la imagen de runtime alrededor de ellos.
¿Cómo aplica esto en tu empresa?
Si tu equipo está evaluando cómo manejar la seguridad en pipelines de CI/CD, especialmente con automatización creciente, estas son las preguntas concretas que vale la pena hacerse:
- ¿Quién o qué escribe los Dockerfiles que llegan a producción? Si la respuesta incluye sistemas automatizados o agentes, el modelo declarativo merece evaluación seria.
- ¿Cuántas imágenes similares genera tu pipeline por semana? Si son muchas, el costo de rebuild acumulado puede justificar el cambio.
- ¿Tienen un proceso de revisión de Dockerfiles antes de que se ejecuten en el builder? Si no, están corriendo con una superficie de ataque abierta que no siempre es evidente.
No se trata de reemplazar Docker en todos lados. Se trata de entender cuándo el modelo de "la entrada es datos" ofrece garantías que el modelo de "la entrada es código" no puede dar.
Conclusión
El artículo de Amartya Gaur toca algo que los equipos de infraestructura suelen aprender tarde: la seguridad más efectiva no es la que añades encima, sino la que eliminas por diseño. No necesitar una sandbox porque nunca ejecutaste código arbitrario es fundamentalmente diferente a construir una sandbox robusta alrededor de código que sí se ejecuta.
En un contexto donde los pipelines son cada vez más automatizados y los agentes de IA participan en la generación de configuraciones, este tipo de decisiones de arquitectura se vuelven relevantes mucho antes de lo que parece.
En Consultoría-Ti trabajamos con equipos de desarrollo en Perú y América Latina que están modernizando su infraestructura y sus procesos de CI/CD. Si estás evaluando cómo mejorar la seguridad y la eficiencia de tus pipelines de contenedores, conversemos.
Agenda una consulta con nuestro equipo →
Fuentes y Referencias
Dev.to — A container per job, without a daemon — Amartya Gaur
✨ Contenido generado con ContentFlow — Consultoría-Ti