Compartir comentarios
Las respuestas se generan en base a la documentación.

Modelo de confianza para archivos de Compose

Tabla de contenidos

Docker Compose trata cada archivo de Compose como una entrada de confianza. Cuando un archivo de Compose solicita privilegios elevados, acceso al sistema de archivos del host o cualquier otra configuración, Compose la aplica tal como está escrita. Este es el mismo comportamiento que pasar banderas directamente a docker run.

Esto significa que cualquier archivo de Compose que ejecutes, ya sea que se encuentre en tu sistema de archivos local, en un repositorio de Git o en un registro de OCI, tiene control total sobre cómo interactúan los contenedores con tu host. El límite de seguridad no reside en la procedencia del archivo, sino en si confías en el autor.

Evaluar la confianza implica preguntarse: ¿Quién es el autor de este archivo? ¿Ha cambiado desde la última vez que lo revisaste? ¿Entiendes cada privilegio que solicita?

La cadena de dependencias

Una aplicación de Compose se puede ensamblar a partir de múltiples fuentes. La directiva include importa archivos de Compose completos, mientras que extends hereda la configuración de un servicio específico en otro archivo. Ambas admiten referencias remotas y pueden encadenarse:

Tu comando
  └─ compose.yaml                                    (local o remoto)
       ├─ services, volumes, networks                (configuración directa)
       ├─ include:
       │    └─ oci://registry.example.com/base:v2   (dependencia remota)
       │         └─ services, volumes, networks      (configuración indirecta)
       └─ services:
            └─ app:
                 └─ extends:
                      └─ file: oci://registry.example.com/templates:v1
                           └─ service: webapp        (configuración heredada)

Cada nivel tiene las mismas capacidades. El archivo de nivel superior que inspeccionas puede parecer seguro, mientras que un include o extends anidado puede introducir servicios con privilegios elevados, montajes de tipo bind del host o imágenes que no son de confianza. Estas dependencias también pueden cambiar de forma independiente. Se pueden introducir configuraciones de riesgo mediante una dependencia anidada que nunca verás a menos que inspecciones la salida completamente resuelta.

Important

Compose te advierte cuando una configuración hace referencia a fuentes remotas. No aceptes esto sin comprender cada referencia en la cadena.

Buenas prácticas

Inspeccionar la configuración completa

Para ver exactamente qué es lo que Compose aplica, incluyendo todos los includes y extends resueltos, los valores sobrescritos fusionados y las variables interpoladas, utiliza:

$ docker compose config

Para referencias remotas:

$ docker compose -f oci://registry.example.com/myapp:latest config

Revisa esta salida antes de ejecutar up or create, especialmente cuando la configuración provenga de una fuente que no hayas auditado.

Campos a tener en cuenta

Una configuración de Compose tiene un amplio control sobre cómo interactúan los contenedores con el host. La siguiente es una lista no exhaustiva de campos que tienen implicaciones de seguridad cuando son establecidos por un autor que no es de confianza:

CampoEfecto
privilegedConcede al contenedor acceso total al host
cap_addAñade capacidades de Linux como SYS_ADMIN o NET_RAW
security_optConfigura perfiles de seguridad, incluyendo seccomp y AppArmor
volumes / montajes bindMonta directorios del host en el contenedor
network_mode: hostComparte el stack de red del host
pid: hostComparte el espacio de nombres PID del host
devicesExpone dispositivos del host al contenedor
imageDescarga y ejecuta una imagen de contenedor arbitraria

En caso de duda, investiga el efecto de cualquier campo desconocido antes de ejecutar la configuración.

Entornos de CI/CD

Las pipelines (tuberías) automatizadas son especialmente sensibles porque a menudo se ejecutan con acceso a credenciales, tokens de proveedores de nube o sockets de Docker.

  • Evita hacer referencia a configuraciones de Compose públicas o no verificadas en pipelines automatizadas.
  • Restringe las actualizaciones condicionándolas a tu proceso habitual de revisión de código.
  • Utiliza montajes de socket de Docker de solo lectura siempre que sea posible para limitar el riesgo.

Fijar referencias remotas a resúmenes (digests)

Las etiquetas (tags) son mutables, lo que significa que cualquiera con acceso de subida a un registro puede sobrescribir una etiqueta de forma silenciosa, por lo que una referencia que revisaste la semana pasada puede apuntar a un contenido diferente más adelante.

Los resúmenes (digests) son inmutables. En lugar de hacer referencia por etiqueta, fíjala al digest.

include:
  - oci://registry.example.com/base@sha256:a1b2c3d4...

Trata cualquier actualización de un digest fijado como un cambio de código. Asegúrate de revisar el contenido antes de actualizar la referencia.

Otros

  • Utiliza un registro privado: Aloja los artefactos OCI en un registro que controle tu organización. Restringe quién puede subir contenido a él.
  • Audita las dependencias transitivas: Comprueba cada referencia remota de include y extends en la cadena, no únicamente el archivo de nivel superior.
  • Revisa todas las solicitudes de confirmación de Compose: Al cargar archivos de Compose remotos, Compose muestra solicitudes de confirmación para las variables de interpolación, los valores de entorno y los includes remotos. Revisa estos valores antes de aceptarlos.

Más información