Leer un Dockerfile como auditor

La primera línea de un Dockerfile, FROM, decide sobre qué se construye todo lo demás. Una etiqueta como latest o 2.4 es un nombre que alguien puede mover: hoy apunta a una imagen y mañana a otra, sin que tu archivo cambie ni una letra. Dos construcciones del mismo Dockerfile, con una semana de diferencia, pueden producir imágenes distintas, y cuando algo falla nadie puede reproducir lo que se desplegó. El digest (@sha256:…) es la huella del contenido: identifica una imagen concreta y no se puede reasignar.

Fijar la base por digest —y actualizarlo a propósito, con una revisión— convierte «lo que salió ayer» en algo que se puede volver a construir y auditar. Es lo contrario de confiar en que la etiqueta no se mueva.

ADD y COPY se parecen y no son lo mismo. COPY trae archivos del contexto de construcción, que es lo que tú le entregas al constructor. ADD además sabe descargar una dirección de internet y descomprimir archivos, y por eso es una puerta: lo que baja entra en una capa de la imagen sin que nada compruebe de dónde viene ni que sea el mismo archivo de ayer. La práctica segura es usar COPY para lo propio y, si hay que descargar algo, hacerlo con una suma de verificación comprobada o, mejor, traerlo a través del proceso de dependencias que ya se controla.

Abre el Dockerfile de api-envios y busca la instrucción que descarga algo de una dirección externa.

COPY . /app copia todo el contexto: cada archivo de la carpeta desde la que se construye. Si en esa carpeta hay un archivo de variables de un desarrollador, el historial de git o un informe, también entran en la imagen y viajan con ella a cada registro y a cada nodo. El archivo .dockerignore es el filtro del contexto: lista lo que no debe entrar. Un .dockerignore que excluye los módulos instalados y los registros pero olvida un archivo de configuración local no protege nada de lo importante.

Un buen .dockerignore se escribe por exclusión de lo sensible y, mejor aún, la receta copia solo las carpetas que necesita en vez de todo el contexto.

Si un Dockerfile no tiene instrucción USER, el proceso final corre como root dentro del contenedor. Dentro del contenedor, root no es root del servidor, pero sigue siendo el usuario más poderoso del aislamiento: si el servicio tiene una falla, quien la aproveche parte con los permisos más altos, puede escribir en todo el sistema de archivos de la imagen y tiene a mano todos los mecanismos de escape que existan. Declarar un usuario sin privilegios no arregla la falla, pero reduce lo que se consigue con ella.

El linter marca esta ausencia como la única que bloquea la fusión, porque es una decisión de la receta y se corrige con una línea.

Un linter devuelve una lista de hallazgos y no todos pesan igual. Una etiqueta mutable, una herramienta de depuración que sobra o una copia que rompe el caché de capas son deuda: se corrigen en el ciclo. Que el proceso corra como root es distinto: es una puerta abierta de una línea. La política del equipo ya decide qué efecto detiene la fusión; tu trabajo es leerla y señalar cuál de los hallazgos es el que la dispara, no inventar una lista de prioridades propia.

Abre el informe del linter y busca la fila cuyo efecto es el que detiene la fusión.