REDES-P4

En el Ejercicio 3 interactuaste directamente con el daemon de Docker a través del socket Unix /var/run/docker.sock usando curl, sin pasar por el comando docker. ¿Qué riesgo de seguridad implica que un proceso o contenedor tenga acceso a ese socket? ¿Qué podría hacer un atacante si lo comprometiera?.

En el Ejercicio 10 (Desplegar un contenedor con usuario diferente de root), se pedía examinar el Dockerfile del directorio customDVWA antes de modificarlo. Uno de los puntos de análisis señalaba que ese Dockerfile no contiene ninguna instrucción CMD ni ENTRYPOINT, y pedía investigar dónde está definido entonces el comando que arranca el servicio cuando se lanza el contenedor. ¿Dónde se encuentra realmente ese entrypoint?. El entrypoint debe definirse obligatoriamente en la sección command del fichero docker-compose.yaml cuando no aparece en el Dockerfile, y Docker lanza un error si ninguno de los dos lo especifica. Docker aplica por defecto el comando /bin/sh -c como entrypoint de arranque cuando detecta que el Dockerfile no contiene ninguna instrucción CMD ni ENTRYPOINT explícita durante el proceso de construcción. Está definido en la imagen base referenciada por la instrucción FROM del Dockerfile y se hereda automáticamente al construir la nueva imagen sin necesidad de redefinirlo en el Dockerfile hijo. DVWA no necesita ningún proceso principal definido como entrypoint porque todos sus servicios web y de base de datos arrancan automáticamente como daemons del sistema operativo gestionados por systemd.

En el Ejercicio 1 usaste la herramienta dive para explorar la imagen nginx. ¿Qué información te proporcionó dive que no aparece con docker history?.

En el Ejercicio 2 (Servicio DVWA con docker compose), otro punto de análisis pedía investigar qué le ocurre al volumen db, que almacena los datos de MySQL, cuando se ejecuta docker compose down para detener y eliminar los contenedores del servicio DVWA. ¿Qué ocurre realmente con ese volumen?. El volumen queda en estado dangling sin ningún proyecto que lo referencie y Docker lo marca para eliminación en el siguiente ciclo de limpieza automática del garbage collector del daemon. El volumen se desmonta del contenedor pero su contenido se mueve automáticamente a un directorio temporal en el host para evitar pérdidas de datos accidentales durante el ciclo de vida del proyecto. El volumen se elimina automáticamente junto con los contenedores porque docker compose down libera todos los recursos asociados al proyecto, incluidos los volúmenes nombrados definidos en el YAML. El volumen persiste en el host con todos sus datos intactos y vuelve a conectarse automáticamente al servicio de base de datos cuando se levanta de nuevo el proyecto compose.

Durante el Ejercicio 1 (Explorando los contenedores), al arrancar por primera vez un contenedor nginx desde cero, el sistema muestra en pantalla una línea con el texto Digest: sha256:... justo después de completar la descarga de la imagen. ¿Qué garantía concreta ofrece ese valor al estudiante que lo observa?. Indica que la etiqueta latest apunta efectivamente a la versión más reciente publicada y que no existe ninguna versión posterior disponible. Garantiza que en el momento de la descarga la imagen no contenía ninguna vulnerabilidad conocida registrada en bases de datos de CVEs. Confirma que la imagen ha sido revisada y firmada digitalmente por el equipo de seguridad del fabricante antes de publicarse en el registro. Permite verificar que la imagen descargada no ha sido alterada respecto a la que existe en el registro remoto, comparando el hash antes y después de la descarga.

En el Ejercicio 1, uno de los pasos consistía en localizar el fichero de logs del contenedor nginx en el sistema de ficheros del host usando docker inspect combinado con grep, y comparar su contenido con la salida del comando docker logs. Ambas salidas resultaban idénticas. ¿Qué conclusión de seguridad se extrae de esa observación?. El contenedor dispone de un canal de escritura bidireccional con el sistema de ficheros del host que permite sincronizar ficheros en tiempo real sin configuración adicional. Los logs se replican automáticamente desde el contenedor hacia el host mediante un volumen implícito que Docker crea sin que aparezca en la configuración del compose. Docker mantiene dos copias de los logs sincronizadas para garantizar alta disponibilidad en caso de que el daemon Docker falle y no pueda responder a comandos. Los logs del contenedor se almacenan físicamente en el host, por lo que cualquier usuario con acceso directo al host puede leer los logs de todos los contenedores sin necesidad de usar el comando Docker.

En el Ejercicio 5 ejecutaste unshare -r en el host y comprobaste con id que aparecías como root, pero al leer /proc/self/uid_map viste que ese root estaba mapeado a tu usuario sin privilegios. Explica por qué ese usuario root no tiene los mismos privilegios que el root real del sistema y qué limitaciones tiene.