Escape de contenedor (Container escape)
En seguridad cloud, un escape de contenedor es salir de un contenedor y conseguir acceso al host sobre el que corre. Es el hallazgo que convierte un contenedor comprometido en un nodo comprometido, y es lo que decide la severidad de una evaluación de Kubernetes: fallo de aplicación contenido, o pie dentro del host que hay debajo.
Cómo funciona
Un contenedor está aislado de su host por funciones del kernel (namespaces y control groups) y por un conjunto restringido de capacidades, pero ese aislamiento es fino comparado con el de una máquina virtual: el contenedor comparte el kernel del host. Un escape aprovecha una vulnerabilidad de esa frontera para llegar al host. Las rutas que se repiten son un contenedor que corre como privilegiado o con capacidades peligrosas, una ruta del host montada dentro o el socket de contenedores del host expuesto dentro del contenedor, una vulnerabilidad del kernel alcanzable desde dentro, o un montaje con escritura que lleva de vuelta al sistema de ficheros del host. Una vez en el host, el atacante ha salido del radio de daño de la aplicación y ya está en el nodo, con alcance a todos los demás contenedores que hay en él y a las credenciales del propio nodo.
Qué sale mal
El fallo es tratar la frontera del contenedor como si fuera la de una máquina virtual. En los clústeres que probamos, es frecuente que los contenedores corran con más privilegio del que necesitan porque así funcionaba algo: un flag de privilegiado para un trabajo de compilación, un montaje del host para los registros, el socket de contenedores expuesto por comodidad. Desde el asiento del atacante, una sola vulnerabilidad de aplicación en un contenedor así no es un suceso contenido; es una ruta al nodo, y del nodo al clúster. La diferencia de severidad es enorme, y la decide por completo si se permitió o no que el contenedor llegara al host, que es una decisión de configuración tomada mucho antes del ataque.
Dónde aparece esto en una auditoría
Evaluamos el aislamiento del nodo como pregunta de primer orden: qué contenedores corren privilegiados o con capacidades peligrosas o con montajes del host, si el socket de contenedores está expuesto, y si en Kubernetes los controles de admisión impiden de verdad que se planifiquen cargas así. Donde hay un pie dentro, demostramos el escape y la escalada de privilegios que habilita. El hallazgo se escribe contra la configuración que permitió la salida, y se enseña el acceso al host que se alcanza. Esto forma parte de cómo probamos el aislamiento de contenedores y nodos.