Supongamos que soy un desarrollador y quiero fortalecer mi entorno de aplicación web. Si mi aplicación no utiliza binarios como sh, ls, find, echo, etc., ¿debería simplemente eliminarlos de mi imagen?
Supongamos que soy un desarrollador y quiero fortalecer mi entorno de aplicación web. Si mi aplicación no utiliza binarios como sh, ls, find, echo, etc., ¿debería simplemente eliminarlos de mi imagen?
Puede mejorar la seguridad, pero es una forma muy extraña de hacer las cosas.
Lo que estás sugiriendo es comenzar con una imagen con el software "innecesario" instalado y eliminar algunas de las cosas que no necesitas (bash, echo, ...). Esto no solo se arriesga a romper cosas, sino que también aumenta el tamaño del contenedor porque la capa base con las herramientas innecesarias aún se envía.
Un mejor enfoque es comenzar con una imagen mínima. No es alpino, sigue siendo un sistema operativo completo. El enfoque más mínimo es utilizar una imagen base que solo contenga el tiempo de ejecución del idioma requerido, como las imágenes sin color de Google enlace . Para los binarios estáticos, incluso puede comenzar con una imagen vacía.
De esta manera, obtienes una imagen lo más pequeña posible y no proporciona la "superficie de ataque" de bash.
No debes eliminar bash ni ningún archivo ejecutable que exista en la imagen base. Una gran cantidad de ejecutables están interconectados, y la eliminación de un ejecutable puede hacer que otros ejecutables aparentemente no relacionados no se ejecuten correctamente en algún caso de esquina. En su lugar, debe usar una imagen base que no contenga nada que realmente no necesite. alpine hace una gran imagen de base minimalista, con un peso de 5 MB, contiene solo las cosas más útiles y nada más.
Si sabe que su aplicación no utiliza ningún binario o shell externo, o si sabe exactamente qué binario externo necesitará, puede considerar compilar en un binario enlazado estáticamente y luego basar su contenedor de imagen scratch .
La respuesta es: depende. La eliminación de bash y de todos los demás intérpretes reduce la superficie de ataque del contenedor. Lo mismo se aplica a, por ejemplo, compiladores, nc, wget, ...
La verdadera pregunta es: ¿es esta la mejor manera de gastar el dinero?
Por ejemplo,
Una mejor forma de gastar el dinero podría ser endurecer la propia aplicación invirtiendo en otras medidas de seguridad como las pruebas de penetración regulares, el monitoreo de seguridad, la aplicación de parches automatizados, ...
Depende hasta qué punto estás siguiendo la filosofía del contenedor. Si no lo necesita, debe evitar usar cualquier cosa que no sea estrictamente necesaria. Debe definir y hacer referencia a todo lo que necesita en el Dockerfile, y el punto de entrada de un servidor web debe ser el propio binario de apache (o cualquier otro servidor web que esté utilizando). Pero lo que es más importante, tenga en cuenta que muchos archivos binarios (como ls, find, etc.) están vinculados a la capa de imagen base del contenedor, por lo que debe dejarlos intactos o crear una imagen base más personalizada. Cualquier imagen base de Ubuntu, Debian, etc., tendrá estos binarios, y no se recomienda manipular la imagen base.
Sería un enfoque mucho más seguro para definir una red aislada para bases de datos u otras entidades backend, dejando solo el puerto que está exponiendo al mundo como superficie de ataque.
Obviamente, es fundamental que la máquina se convierta en lo que está conteniendo en sus servicios.
No me preocuparía mucho por estos binarios. Me preocuparía mucho más acerca de asegurar el acceso a los comandos de Docker para evitar invocar estos binarios durante el tiempo de ejecución del contenedor.
Quería agregar algunos recursos más a las respuestas hasta ahora. En general, se considera la mejor práctica para que una imagen de contenedor de SO sea lo más básica posible. Eliminar cáscaras innecesarias es solo el comienzo. Existen múltiples imágenes de SO endurecidas específicamente para un despliegue seguro de contenedores, pero también hay muchas otras cosas a considerar, como los privilegios más bajos posibles, sistemas de archivos de solo lectura y mucho más.
Esta página: enlace tiene varios enlaces a muchos artículos buenos. El blog Red-Hat de Dan Walsh también es muy bueno para información a nivel profundo. enlace
Esta página tiene mucho más que ayuda directamente a esta pregunta en el sentido de las prácticas, incluso más útil que eliminar aplicaciones innecesarias: enlace
Y aquí hay un sistema operativo endurecido para contenedores. Revelación completa: no lo he usado, nuestra Ingeniería de Sistemas trabajó con mi equipo de seguridad para crear una imagen de oro para nosotros en nuestra implementación en la nube. Es más un ejemplo: enlace