‫El siguiente.
‫Este es un grande.
‫No ejecute sus aplicaciones como root en el contenedor si
‫puede evitarlo.
‫Si hago esto muy rápido, en una pequeña
‫demostración aquí.
‫Todo bien. Tengo a Docker corriendo, al
‫menos debería. Todo bien.
‫Y si solo corro ...
‫Si solo ejecuto Nginx, correcto, y hago un
‫docker top en ese
‫contenedor.
‫¿Qué vemos aquí?
‫Dentro del contenedor, Nginx inició un proceso
‫en la raíz, y luego creó
‫un nuevo proceso como usuario no
‫root. Vea cómo ese usuario es 101.
‫Esto es común en muchos programas basados en daemon
‫como MySQL, Postgres, Nginx.
‫Muchos de ellos que no son lenguajes de programación
‫lo harán automáticamente. Entonces, esto es seguro.
‫Lo que está haciendo es permitir que Nginx genere
‫procesos de trabajo que no se ejecutan como root
‫para realizar la mayor parte del trabajo.
‫Por lo tanto, tienen un proceso maestro que se ejecuta como root, pero
‫eso no es lo que acepta las conexiones y hace la
‫mayoría del trabajo. La mayor parte de
‫eso está en estos procesos de trabajo. Se ejecutan como un usuario
‫normal, lo que significa que si hay una vulnerabilidad en
‫Nginx, es probable que cuando entren
‫conexiones entrantes y alguien intente explotar el protocolo HTTP
‫de Nginx, se bloqueará o encarcelará en este usuario en
‫... . la mayoría de las veces,
‫a menos que haya una vulnerabilidad grave aquí.
‫Aquí abajo, y luego están limitados a lo que
‫pueden hacer, ¿verdad? Incluso si se hicieran cargo
‫de ese proceso de alguna manera, todavía están limitados como usuario.
‫Entonces, esto está bien.
‫Esto todavía no se ejecuta como raíz
‫verdadera dentro del contenedor. De lo que realmente estoy
‫hablando es de que
‫si ejecutas una aplicación Python, o una
‫aplicación Node, o algo así cuando es un lenguaje de programación,
‫entonces eso será algo predeterminado para root porque
‫el lenguaje de programación en el contenedor no No sé cómo
‫funciona su programa. No sabe lo que quieres que haga.
‫Por lo tanto, va a hacer root de forma predeterminada,
‫y eso es más sobre compatibilidad de aplicaciones.
‫Podríamos decir que queremos que esto sea seguro de forma
‫predeterminada, pero Docker eligió que todos estos contenedores oficiales realmente se ejecuten como
‫raíz para los lenguajes de programación.
‫Vamos a ver eso.
‫Ups Ése no.
‫Firefox
‫Entonces, si vamos, digamos, a Hub.
‫Solo hagamos Nodo.
‫Esto es común en la mayoría de los idiomas.
‫Solo voy a elegir Node como ejemplo.
‫Inside Node,
‫si entro en uno de los Dockerfiles aquí.
‫Luego busco usuario.
‫Notarás que en realidad no encuentro nada.
‫Es solo este usuario agregar aquí.
‫Notarás que hace esto, correcto.
‫Técnicamente está agregando un grupo llamado Nodo y está
‫agregando un usuario llamado Nodo.
‫Si busca el resto de este archivo, se dará cuenta de que nunca cambia
‫a ese usuario con la estrofa U S E R,
‫a la derecha.
‫Debería ver el nodo de usuario allí en algún lugar como una línea.
‫No hacen eso porque ese es tu trabajo.
‫Entonces, ¿qué deberías estar haciendo en tu Dockerfile
‫de nivel inferior? Entonces, cualquier Dockerfile
‫que esté creando a partir de estas
‫imágenes oficiales para lenguajes de programación, debería aprovechar los usuarios
‫que están creando para usted. Si no están creando esos usuarios, puede crear uno
‫usted mismo de la misma manera. Simplemente puede robar
‫esta pequeña cosa de dos líneas y cambiar a cualquier
‫usuario que quiera que sea. Si es para Python,
‫podría llamarlo usuario de Python, lo que sea.
‫Si está haciendo eso, las aplicaciones que
‫ejecuta no se ejecutarán como raíz en el
‫contenedor. De manera
‫predeterminada, si solo ejecuta una aplicación de nodo estándar, utilizará al usuario
‫raíz en un contenedor.
‫¿Por qué es esto tan importante?
‫Bueno, dos cosas.
‫Uno, si alguien puede romper su aplicación y
‫hackear su aplicación y obtener acceso al sistema
‫de archivos, si ... si esa aplicación es root, entonces
‫en el contenedor, pueden hacer lo que quieran en
‫el contenedor, correcto. Pueden escribir archivos
‫en el sistema de archivos. Pueden instalar más programas en ese
‫contenedor que pueden ejecutarse cuando lo deseen en ese contenedor.
‫Entonces, realmente no queremos que hagan eso.
‫Preferimos que sean muy limitados.
‫Entonces, si sus aplicaciones lo admiten,
‫ya sabes, haz esto. Básicamente, se asegura de tener
‫al usuario disponible.
‫Entonces tengo un ejemplo de DockerCon por aquí.
‫En DockerCon, tuve una charla completa sobre Node. js, y uno
‫de los temas fue sobre el usuario.
‫Déjame ver si puedo encontrar eso.
‫¿Ves lo que hice aquí? Es un archivo bastante simple.
‫Voy a vincular esto y ponerlo.
‫En este Dockerfile.
‫Entonces, en este Dockerfile tengo ...
‫No creé un usuario porque la imagen del Nodo
‫ya lo creó para mí. Solo estoy cambiando al nodo de usuario.
‫Luego estoy instalando mis paquetes con estas dos líneas, y luego,
‫voy a ejecutarlo.
‫Notarás que tengo que comenzar a
‫usar la opción chown en mis comandos de copia para asegurarme de
‫que mis archivos ahora sean el mismo usuario que el que
‫ejecutará mi programa. De lo contrario, podría haber problemas,
‫¿verdad? Mi aplicación probablemente ... si
‫no puede leer los archivos, entonces no puede ejecutarlo, correcto.
‫Entonces, necesito los cambios de esos permisos.
‫Puedo hacer eso con una línea en un comando de copia.
‫También verás aquí que estoy creando el directorio y también lo
‫estoy creando, de modo que cada vez que se copia
‫la aplicación, solo quiero asegurarme de que los
‫permisos están ahí para que pueda escribir.
‫Debido a que en el momento en que cambio este
‫usuario, este comando de copia, o específicamente este comando de ejecución, se ejecutará
‫como ese usuario. Si no tiene
‫permisos para escribir en los directorios, también fallará.
‫Entonces, la razón por la que Docker no hace esto por usted
‫es porque saben que sus cosas probablemente se romperán.
‫Por lo tanto, debe seguir estos pasos adicionales.
‫Pero no es tan difícil. Realmente no lo es.
‫Probablemente pueda hacer todas estas pruebas en un día, y luego
‫querrá ejecutar sus sistemas a través de CI completo y pruebas
‫completas en sus servidores porque a veces, y PHP es uno de
‫los que es malo en esto.
‫A PHP le gusta ejecutar un montón de archivos de registro y
‫escribir mucho en el disco.
‫Realmente, cualquier cosa que permita las cargas de los usuarios escribirá
‫en el disco. Por lo tanto, debe asegurarse
‫de que esos permisos sean correctos para que cuando las personas escriban archivos, como digamos
‫que estén ejecutando un blog de WordPress.
‫Ese blog de WordPress se escribirá en el disco cuando
‫los usuarios carguen imágenes en su blog.
‫Desea asegurarse de que esos permisos van a funcionar.
‫Entonces, definitivamente tendrás que hacer algunas pruebas.
‫Una vez que haya hecho eso, ahora su aplicación no
‫se ejecutará como root. Por lo tanto, no puede tener
‫control total en el contenedor. La otra razón
‫por la que desea hacer esto es si hay
‫una vulnerabilidad en Linux, que es rara, o Docker, que
‫también es muy rara, entonces hay menos probabilidades de
‫que salgan de este contenedor. Eso solo sucedió, bueno, una
‫vez que soy muy consciente, y en realidad documenté
‫un poco aquí.
‫VACA sucia. Dirty COW era
‫una vulnerabilidad en Linux que le permitía
‫salir
‫de un contenedor, correcto. El cambio de su
‫usuario aquí,
‫no necesariamente resolvería todo el problema,
‫pero ciertamente no perjudicó ese problema.
‫Otras vulnerabilidades, probablemente protegería contra.
‫Pero esta es una mejor práctica.
‫Creo que si tienes un equipo de seguridad,
‫van a insistir en que no ejecutes las cosas como root.
‫Entonces, harías eso.