Simplemente diga no a la raíz (en contenedores)

Me preguntan todo el tiempo sobre las diferentes medidas de seguridad utilizadas para controlar lo que pueden hacer los procesos de contenedor en un sistema. La mayoría de estos los cubrí en artículos anteriores en Opensource.com:

• ¿Son realmente seguros los contenedores Docker?
• Incorporación de nuevas funciones de seguridad a Docker
• La seguridad de Docker en el futuro

Casi todos los artículos anteriores tratan sobre el control de lo que puede hacer un proceso privilegiado en un sistema en un contenedor. Por ejemplo:¿Cómo ejecuto root en un contenedor y no permito que se rompa?

Contenedores Linux

• ¿Qué son los contenedores de Linux?
• Una introducción a la terminología de contenedores
• Descargar:Introducción a los contenedores
• Operadores de Kubernetes:automatización de la plataforma de orquestación de contenedores
• eBook:Patrones de Kubernetes para diseñar aplicaciones nativas de la nube
• ¿Qué es Kubernetes?

El espacio de nombres de usuario tiene que ver con la ejecución de procesos privilegiados en contenedores, de modo que si se rompen, ya no tendrían privilegios fuera del contenedor. Por ejemplo, en el contenedor mi UID es 0 (cero), pero fuera del contenedor mi UID es 5000. Debido a problemas con la falta de compatibilidad con el sistema de archivos, el espacio de nombres de usuario no ha sido la panacea que parece ser. Hasta ahora.

OpenShift es la plataforma de contenedores de Red Hat, basada en contenedores de Kubernetes, Red Hat Enterprise Linux y OCI, y tiene una excelente función de seguridad:de forma predeterminada, ningún contenedor puede ejecutarse como raíz. Un administrador puede anular esto; de lo contrario, todos los contenedores de usuarios se ejecutan sin ser root. Esto es particularmente importante en los clústeres de OpenShift Kubernetes de múltiples inquilinos, donde un solo clúster puede estar sirviendo a múltiples aplicaciones y múltiples equipos de desarrollo. No siempre es práctico o incluso recomendable que los administradores ejecuten clústeres separados para cada uno. Lamentablemente, una de las mayores quejas sobre OpenShift es que los usuarios no pueden ejecutar fácilmente todas las imágenes de contenedores de la comunidad disponibles en docker.io. Esto se debe a que la gran mayoría de las imágenes de contenedores en el mundo actual requieren root.

¿Por qué todas estas imágenes requieren root?

Si realmente examina las razones para ser root, en un sistema, son bastante limitadas.

Modificar el sistema anfitrión:

• Una de las principales razones para ser root en el sistema es cambiar la configuración predeterminada del sistema, como modificar la configuración del kernel.
• En Fedora, CentOS y Red Hat Enterprise Linux, tenemos el concepto de contenedores de sistema , que son contenedores privilegiados que se pueden instalar en un sistema usando el atomic dominio. Pueden ejecutarse con todos los privilegios y se les permite modificar el sistema y el kernel. En el caso de contenedores del sistema estamos usando la imagen del contenedor como un sistema de entrega de contenido, sin buscar realmente la separación del contenedor. Los contenedores del sistema son más para los servicios de host del sistema operativo central que para los servicios de aplicaciones de los usuarios que ejecutan la mayoría de los contenedores.
• En los contenedores de aplicaciones, casi nunca queremos que los procesos dentro del contenedor modifiquen el kernel. Esto definitivamente no es requerido por defecto.

Tradición Unix/Linux:

• Los proveedores y desarrolladores de software de sistemas operativos han sabido durante mucho tiempo que ejecutar procesos como root es peligroso, por lo que el kernel agregó muchas capacidades de Linux para permitir que un proceso se inicie como root y luego pierda los privilegios lo más rápido posible. La mayoría de las capacidades de UID/GID permiten que procesos como un servicio web se inicien como root y luego se conviertan en no root. Esto se hace para enlazar a puertos por debajo de 1024 (más sobre esto más adelante).
• Para empezar, los tiempos de ejecución de contenedores pueden iniciar aplicaciones como no root. A decir verdad, systemd también puede hacerlo, pero la mayoría del software que se ha creado en los últimos 20 años asume que comienza como root y elimina los privilegios.

Enlazar a puertos <1024

• En las décadas de 1960 y 1970, cuando había pocas computadoras, la incapacidad de los usuarios sin privilegios para conectarse a puertos de red <1024 se consideraba una característica de seguridad. Debido a que solo un administrador puede hacer esto, puede confiar en las aplicaciones que escuchan en estos puertos. Los puertos> 1024 podrían estar vinculados por cualquier usuario del sistema, por lo que no se podría confiar en ellos. Los beneficios de seguridad de esto han desaparecido en gran medida, pero aún vivimos con esta restricción.
• El mayor problema con esta restricción son los servicios web donde a la gente le encanta que sus servidores web escuchen en el puerto 80. Esto significa que la razón principal por la que apache o nginx comienzan a ejecutarse como root es para que puedan vincularse al puerto 80 y luego convertirse en no root.
• Los tiempos de ejecución de contenedores, mediante el reenvío de puertos, pueden resolver este problema. Puede configurar un contenedor para escuchar en cualquier puerto de red y luego hacer que el tiempo de ejecución del contenedor asigne ese puerto al puerto 80 en el host.

En este comando, el tiempo de ejecución de podman ejecutaría un apache_unpriv contenedor en su máquina escuchando en el puerto 80 en el host, mientras que el proceso de Apache dentro del contenedor nunca fue root, comenzó como apache usuario, y se le dijo que escuchara en el puerto 8080.

podman run -d -p 80:8080 -u apache apache_unpriv

Alternativamente:

docker run -d -p 80:8080 -u apache apache_unpriv

Instalación de software en una imagen de contenedor

• Cuando Docker introdujo la creación de contenedores con docker build , el contenido de los contenedores era solo software estándar empaquetado para distribuciones. El software generalmente venía a través de paquetes rpm o paquetes Debian. Bueno, distribuciones de paquetes de software para ser instalados por root. Un paquete espera poder hacer cosas como manipular /etc/passwd agregar usuarios y colocar contenido en el sistema de archivos con diferentes UID/GID. Gran parte del software también espera iniciarse a través del sistema de inicio (systemd) y comenzar como root y luego eliminar los privilegios después de que se inicie.
• Lamentablemente, cinco años después de la revolución de los contenedores, este sigue siendo el status quo. Hace unos años, intenté que el paquete httpd supiera cuándo lo está instalando un usuario no root y que tenga una configuración diferente. Pero dejé caer la pelota en esto. Necesitamos que los empaquetadores y los sistemas de administración de paquetes comiencen a comprender la diferencia, y luego podríamos crear contenedores agradables que se ejecuten sin necesidad de root.
• Una cosa que podríamos hacer ahora para solucionar este problema es separar los sistemas de compilación de los sistemas de instalación. Uno de mis problemas con #nobigfatdaemons es que el demonio Docker hizo que los contenedores se ejecutaran con los mismos privilegios para ejecutar un contenedor que para crear una imagen de contenedor.
• Si cambiamos el sistema o usamos diferentes herramientas, digamos Buildah, para construir un contenedor con restricciones más flexibles y CRI-O/Kubernetes/OpenShift para ejecutar los contenedores en producción, entonces podemos construir con privilegios elevados, pero luego ejecutar el contenedores con restricciones mucho más estrictas, o con suerte como no root usuario.

Conclusión

Casi todo el software que está ejecutando en sus contenedores no requiere raíz. Sus aplicaciones web, bases de datos, balanceadores de carga, procesadores de números, etc. no debe ejecutarse como root siempre. Cuando consigamos que la gente empiece a crear imágenes de contenedores que no requieran root en absoluto, y que otros basen sus imágenes en imágenes de contenedores sin privilegios, veremos un gran salto en la seguridad de los contenedores.

Todavía hay mucha educación por hacer sobre la ejecución de root dentro de los contenedores. Sin educación, los administradores inteligentes pueden tomar malas decisiones.