Aun cuando los procesos aislados en contenedores se ejecutan en el mismo kernel, Docker utiliza una serie de técnicas de aislamiento para protegerlos mutuamente. Las más importantes son las funciones centrales del kernel de Linux como Cgroups y Namespaces. Cada contenedor recibe un nombre de host propio, identificadores de proceso individuales y una interfaz de red particular y en su campo de visión se sitúa únicamente el fragmento del sistema de archivos que se le ha asignado. El reparto de los recursos del sistema (memoria, CPU, ancho de banda) tiene lugar por medio de un mecanismo Cgroup que garantiza que cada contenedor solo pueda consumir el contingente reservado para él.
Con ello, los contenedores no ofrecen el mismo grado de aislamiento que el que se puede alcanzar con máquinas virtuales. En el caso de que un atacante se hiciera con una máquina virtual, no tendría apenas posibilidades de entrar en contacto con el núcleo del sistema host subyacente. Los contenedores, en cambio, como instancias encapsuladas de un kernel host común, proporcionan un mayor margen de libertad a cualquier tipo de ataque.
A pesar de las técnicas de aislamiento que se han descrito, desde los contenedores es posible alcanzar importantes sistemas secundarios del kernel como Cgroups o las interfaces del kernel en los directorios /sys y /proc y estos ofrecen a los atacantes la posibilidad de esquivar las funciones de seguridad del host. Y dado que todos los contenedores se ejecutan en el mismo sistema host en el mismo espacio de nombres del usuario, un contenedor al que le hayan sido asignados derechos admin (root) también los mantiene en la interacción con el núcleo del host. En consecuencia, los administradores solo deberían iniciar los contenedores con derechos limitados.
El demonio de Docker, responsable de la gestión del contenedor en el sistema anfitrión, también disfruta de derechos root, así que un usuario con acceso al demonio obtiene automáticamente acceso a todos los directorios a los que se le ha autorizado el acceso así como la posibilidad de comunicarse con una API REST utilizando HTTP. Es por esto que en su documentación Docker recomienda proveer de acceso al demonio solo a usuarios de confianza.
El equipo de desarrollo detrás de Docker también es consciente de estos problemas de seguridad, considerándolos un obstáculo para la consolidación de esta tecnología en sistemas productivos. Junto a las técnicas de aislamiento fundamentales del kernel de Linux, las últimas versiones del Engine Docker soportan, en consecuencia, los frameworks AppArmor, SELinux y Seccomp, que actuarían como una especie de cortafuegos para los recursos del kernel:
- AppArmor permite regular los derechos de acceso de los contenedores al sistema de archivos.
- SELinux presenta un complejo sistema de reglas con el cual se pueden implementar controles de acceso a los recursos del kernel.
- Seccomp (Secure Computing Mode) supervisa la llamada de systemcalls.
Sumándose a estos frameworks, Docker también utiliza las llamadas “capabilities” de Linux con las que se pueden limitar los derechos raíz con los cuales el Docker Engine arranca los contenedores.
Algunas debilidades de software contenidas en componentes de las aplicaciones que se expanden a través del registry de Docker también son fuente de objeciones. En principio no hay restricciones en cuanto a la creación y publicación de imágenes en el Docker Hub y esto es lo que conlleva el riesgo de introducir código maligno en un sistema por la descarga de una imagen. Por ello, antes del despliegue de una aplicación, los usuarios de Docker siempre deberían asegurarse de que el código completo suministrado por una imagen para ejecutar contenedores proceda de una fuente fiable. Docker ofrece desde comienzos de 2017 en la edición Enterprise (EE) un programa de certificación con la cual se pueden examinar y galardonar a proveedores de infraestructura, de contenedores y de extensiones. Para obtener un certificado han de cumplirse los siguientes requisitos:
- Certificado de infraestructura: aquellos desarrolladores de software con intención de suministrar componentes infraestructurales certificados para el ecosistema de Docker han de probar con ayuda de las herramientas correspondientes que su producto ha sido optimizado para trabajar conjuntamente con la plataforma Docker.
- Certificado de contenedores: un contenedor solo puede ser distinguido con un certificado oficial de Docker cuando se crea según las mejores prácticas y cuando ha superado todos los tests de software, los exámenes de debilidades y los chequeos de seguridad.
- Certificado de plugins: un plugin para Docker EE solo puede certificarse cuando se crea siguiendo las mejores prácticas y ha superado todos los exámenes de API Compliance y de debilidades.
Además de un aumento de la seguridad para los usuarios, los certificados de Docker aspiran a ofrecer a los desarrolladores de software la posibilidad de destacar con sus proyectos entre los numerosos recursos disponibles.