Seguridad de contenedores e imágenes Docker de extremo a extremo

Los contenedores prometen una unidad de software limpia y reproducible, pero esa promesa solo se sostiene si la imagen, la canalización de compilación, el registro y el tiempo de ejecución se aseguran en conjunto. Una vulnerabilidad introducida en una imagen base, un secreto horneado en una capa o un paso de compilación comprometido puede viajar sin cambios a cada entorno que descarga el artefacto. Este artículo recorre el ciclo de vida del contenedor de principio a fin desde la óptica del defensor, con el marco entender para defender. Vemos dónde entra el riesgo en cada etapa, qué telemetría permite detectar el abuso y qué controles vuelven confiable una imagen de contenedor, del portátil del desarrollador al nodo de producción.

La cadena de suministro de contenedores como superficie de ataque

Ayuda pensar una imagen de contenedor no como un archivo sino como una cadena de custodia. El código fuente se vuelve compilación, la compilación descarga dependencias y una imagen base, el resultado se empuja a un registro, y un planificador finalmente lo ejecuta en algún lugar. Cada eslabón es un sitio donde un atacante o un accidente puede inyectar algo no previsto. La meta defensiva es la procedencia: en cualquier punto debería poder responder de dónde vino una imagen, qué la compuso, quién la construyó y si fue alterada desde entonces. Cuando falta la procedencia, una sola capa envenenada puede propagarse en silencio por toda su flota.

Por eso el pensamiento de cadena de suministro ocupa hoy el centro de la seguridad de contenedores. No basta con escanear la imagen final; hay que asegurar el proceso que la produce y poder probar que lo que corre en producción es exactamente lo que su canalización compiló.

Elegir y mantener imágenes base

La mayor parte de la superficie de ataque de una imagen viene de lo heredado, no de lo que usted escribió. Una imagen base llena de shells, gestores de paquetes y utilidades del sistema entrega a un intruso una caja de herramientas en el momento de aterrizar. Prefiera bases minimalistas o distroless que contengan solo su aplicación y sus dependencias de ejecución, y fíjelas a un digest inmutable en vez de a una etiqueta mutable como latest, para que una recompilación no descargue en silencio una imagen distinta y quizá manipulada. Recompile con regularidad para absorber correcciones de seguridad aguas arriba; un digest fijo que nunca se actualiza es seguro ante sorpresas pero acumula lentamente vulnerabilidades conocidas.

Rastree la procedencia de sus imágenes base. Favorezca editores oficiales o verificados y trate una fuente sin mantenimiento como un pasivo. Cuantos menos paquetes contenga una imagen, menor es la superficie que debe parchear y más silencioso su escáner de vulnerabilidades, lo que a su vez hace más visibles los hallazgos reales.

Construir imágenes de forma segura

La compilación es donde los secretos se filtran con más frecuencia. Una credencial pasada como argumento de compilación o copiada en una etapa y borrada en otra posterior sigue viviendo en el historial de la imagen, recuperable por cualquiera que la descargue. Use montajes de secreto en tiempo de compilación que nunca persistan en una capa y mantenga los secretos totalmente fuera del Dockerfile. Las compilaciones multietapa permiten compilar o instalar en una etapa constructora gruesa y copiar solo el artefacto terminado a una etapa final esbelta, dejando atrás compiladores, cachés de paquetes y credenciales intermedias.

Ejecute el contenedor como usuario no root declarando un usuario dedicado en la imagen, para que incluso un tiempo de ejecución que no sobreescriba el usuario aún no corra como root. Elija una disposición de sistema de archivos amigable con solo lectura, evite ADD con URLs remotas y prefiera COPY con fuentes explícitas. Genere una lista de materiales de software durante la compilación para tener un inventario de cada componente, que resulta invaluable el día en que se divulga una vulnerabilidad nueva y necesita saber al instante si está afectado.

Firmar y verificar la procedencia

Una firma convierte la procedencia de una afirmación en algo que puede imponer. Firme las imágenes al final de la compilación con una herramienta como cosign de Sigstore y registre atestaciones que describan cómo se construyó la imagen y qué la compuso. En el despliegue, un controlador de admisión o un motor de políticas verifica esa firma y se niega a ejecutar cualquier cosa sin firma o firmada con una clave inesperada. Esto cierra la brecha entre el registro y el tiempo de ejecución: aunque un atacante empuje una imagen maliciosa a su registro, no puede ejecutarse sin una firma válida de su canalización.

La firma sin claves atada a su identidad de CI elimina la carga de gestionar claves de firma de larga vida y liga cada firma a un flujo de trabajo verificable. La propiedad defensiva clave es que la confianza fluye de su sistema de compilación, no del mero hecho de que una imagen resida en su registro.

Escanear y bloquear

El escaneo de vulnerabilidades pertenece a varios puntos: en la solicitud de fusión para que los desarrolladores vean problemas temprano, en la canalización como puerta que puede fallar la compilación, y de forma continua contra imágenes ya en el registro, porque se divulgan vulnerabilidades nuevas contra imágenes que no cambiaron. Configure la puerta con una política acorde a su riesgo —por ejemplo, bloquear ante problemas críticos y altos corregibles mientras rastrea el resto— y dé a los equipos un camino claro de excepción con caducidad, para que las puertas no se desactiven sin más bajo presión de plazos. Escanee también en busca de secretos incrustados y malas configuraciones, no solo vulnerabilidades conocidas de paquetes.

Recuerde que un escáner reporta lo que sabe hoy. Combínelo con la lista de materiales de software para que, cuando aparezca una vulnerabilidad totalmente nueva, pueda consultar su inventario en vez de reescanear el mundo. La combinación de puerta e inventario es lo que le permite responder en minutos en vez de días.

Protección en ejecución e higiene del registro

Una vez que un contenedor corre, los controles se desplazan a restringirlo y observarlo. Descarte capacidades de Linux, aplique un perfil de seccomp, ejecute con un sistema de archivos raíz de solo lectura y nunca conceda la bandera privileged ni monte el socket de Docker del host en un contenedor, porque cualquiera de las dos entrega efectivamente el nodo. Del lado del registro, exija autenticación, acote con firmeza los permisos de descarga y empuje, habilite etiquetas inmutables para que una imagen publicada no se cambie bajo los consumidores, y purgue imágenes no confiables o rancias. Un registro al que cualquiera puede empujar es un canal de distribución para lo que un atacante quiera ejecutar.

Aísle los ejecutores de compilación de las credenciales de producción. Un ejecutor de CI comprometido con acceso amplio es uno de los puntos de apoyo más dañinos que un atacante puede obtener, porque puede reescribir las mismas imágenes en que usted confía. Dé a los ejecutores mínimo privilegio, identidades efímeras y ningún acceso permanente a producción.

Detección: señales a lo largo del ciclo de vida

La detección abarca toda la cadena. En la canalización, vigile compilaciones que descargan de fuentes inesperadas, fallos de verificación de firma y picos súbitos en hallazgos del escáner. En el registro, alerte ante empujes desde identidades inusuales, descargas de imágenes que nunca se promovieron y mutaciones de etiqueta donde esperaba inmutabilidad. En ejecución, un sensor de comportamiento como Falco o un EDR consciente de contenedores marca un shell abierto dentro de un contenedor, un proceso que escribe en una ruta de solo lectura, una conexión saliente inesperada o un intento de alcanzar el socket del runtime de contenedores. Correlacionar un empuje al registro con un comportamiento anómalo en ejecución a menudo revela una imagen envenenada antes de que se propague.

Retenga estos registros más tiempo que el tiempo típico de permanencia de un atacante y envíelos fuera de los hosts que los generan. Datos de procedencia, resultados de verificación de firma y alertas de ejecución juntos le permiten responder la pregunta de todo incidente: qué corrió, de dónde vino y si sigue corriendo en algún otro lugar.

Una lista de verificación práctica

Base: minimalista o distroless, fijada a un digest, de un editor verificado, recompilada con regularidad. Compilación: usuario no root, multietapa, montajes de secreto en vez de argumentos, lista de materiales de software generada, sin socket del host. Procedencia: imágenes firmadas, atestaciones registradas, la admisión verifica firmas. Escaneo: en la fusión, en la canalización como puerta, continuo en el registro, escaneo de secretos y malas configuraciones incluido, excepciones con caducidad. Registro: autenticado, empuje de mínimo privilegio, etiquetas inmutables, imágenes rancias purgadas. Ejecución: capacidades descartadas, seccomp, sistema de archivos de solo lectura, sin privileged, sin montaje del socket de Docker. Detección: alertas de canalización, registro y ejecución correlacionadas, registros retenidos más allá del tiempo de permanencia.

FAQ: ¿El escaneo vuelve seguras mis imágenes?

El escaneo es necesario pero no suficiente. Informa de vulnerabilidades conocidas en componentes conocidos, lo cual es valioso, pero no dice nada de un paso de compilación malicioso, un secreto filtrado que no reconoce, un tiempo de ejecución con exceso de privilegios o una vulnerabilidad nueva divulgada mañana. Trate el escaneo como una capa junto a procedencia, firma, imágenes minimalistas, confinamiento en ejecución y detección. La seguridad viene de la combinación, no de una sola puerta.

FAQ: ¿Las imágenes distroless o minimalistas son siempre mejores?

Reducen drásticamente la superficie de ataque y el ruido del escáner, y para la mayoría de los servicios de producción son la elección correcta por defecto. La contrapartida es la depurabilidad, ya que no hay shell ni gestor de paquetes para hurgar cuando algo se rompe. La respuesta madura es mantener las imágenes de producción minimalistas y usar contenedores de depuración efímeros o una imagen separada más rica para diagnóstico, de modo que tenga una superficie pequeña en producción sin perder la capacidad de investigar.

Conclusión

La seguridad de contenedores no es un control único sino una cadena que solo es tan fuerte como su eslabón más débil. Parta de una base minimalista, fijada y verificada; compile sin filtrar secretos y como usuario no root; firme y ateste para que la procedencia sea imponible; escanee y bloquee en cada etapa; asegure el registro y el tiempo de ejecución; e instrumente todo el ciclo de vida para que el abuso sea visible. Cuando la procedencia fluye sin quiebre de la fuente al contenedor en ejecución, una capa envenenada no tiene dónde esconderse, y la reproducibilidad que hace atractivos a los contenedores también los hace defendibles.