Los contenedores y orquestadores como Kubernetes marcan el comienzo de una nueva era de métodos de desarrollo de aplicaciones, respaldando la arquitectura de microservicios y el desarrollo y entrega continuos. Según nuestro último Informe sobre el estado de los contenedores y la seguridad de Kubernetes, Docker es, con diferencia, el motor de ejecución de contenedores dominante, con una tasa de penetración del 91 %.
La contenedorización tiene muchos beneficios y, por lo tanto, se adopta ampliamente. Según Gartner, para 2020, más del 50% de las organizaciones globales ejecutarán aplicaciones en contenedores en entornos de producción. Sin embargo, el uso de contenedores Docker para crear aplicaciones también conlleva nuevos desafíos y riesgos de seguridad. Un único contenedor Docker comprometido puede amenazar a todos los demás contenedores, así como al host subyacente, lo que resalta la importancia de la seguridad de Docker.
La protección de seguridad de Docker se puede dividir aproximadamente en dos aspectos: proteger y reforzar el host para que las fugas de contenedores no provoquen fugas del host y proteger los contenedores de Docker. Centrándose en la seguridad de los contenedores, este artículo destaca los riesgos y desafíos de seguridad de los contenedores Docker y proporciona las mejores prácticas para reforzar su entorno durante las fases de construcción e implementación y proteger los contenedores Docker en tiempo de ejecución.
Dada la adopción generalizada de Kubernetes y su papel fundamental en la organización de contenedores, también compartimos las mejores prácticas para proteger Kubernetes. Finalmente, proporcionamos 11 preguntas de seguridad críticas que una plataforma de seguridad de contenedores debería poder responder, brindándole la información y la protección que necesita para ejecutar contenedores y Kubernetes de forma segura en producción.
8 desafíos de seguridad de contenedores que Docker debe resolver
Las empresas llevan mucho tiempo implementando aplicaciones en máquinas virtuales (VM) o servidores bare metal. La seguridad para este tipo de infraestructura implica proteger sus aplicaciones y los hosts en los que se ejecutan, y luego protegerlos mientras las aplicaciones se están ejecutando. La contenerización introduce nuevos desafíos que deben abordarse.
-
Los contenedores permiten microservicios, lo que aumenta la complejidad del tráfico de datos, así como el control de acceso y red.
-
Los contenedores se basan en imágenes base y puede resultar complicado saber si la fuente de la imagen es segura o no. Las imágenes también pueden contener vulnerabilidades que pueden propagarse a todos los contenedores que utilizan la imagen.
-
Los contenedores tienen un ciclo de vida corto, por lo que monitorearlos, especialmente mientras están en funcionamiento, puede resultar difícil. Otro riesgo de seguridad proviene de la falta de visibilidad del entorno cambiante de los contenedores.
-
A diferencia de las máquinas virtuales, los contenedores no están necesariamente aislados unos de otros. Un contenedor de mala calidad puede causar daños a otros contenedores.
-
Los entornos en contenedores tienen más componentes que las máquinas virtuales tradicionales, incluido Kubernetes, que presenta su propio conjunto de desafíos de seguridad. ¿Puede saber qué implementaciones o clústeres se ven afectados por una vulnerabilidad de alta gravedad? ¿Estuvo expuesto a Internet? Si se explota una vulnerabilidad determinada, ¿cuál es el radio de explosión? ¿Los contenedores se ejecutan en un entorno de producción o en un entorno de desarrollo/prueba?
-
La configuración de contenedores es otra área que plantea riesgos de seguridad. ¿El contenedor se ejecuta con privilegios más altos de los que debería? ¿La imagen lanza servicios innecesarios que aumentan la superficie de ataque? ¿Hay secretos almacenados en la imagen?
-
Como uno de los mayores impulsores de la seguridad, el cumplimiento puede ser un desafío especial dado el rápido crecimiento de los entornos de contenedores. Muchos componentes tradicionales que ayudan a demostrar el cumplimiento, como las reglas de firewall, adoptan formas muy diferentes en un entorno Docker.
-
Por último, las soluciones de seguridad de cargas de trabajo de servidores existentes son insuficientes para abordar los desafíos y riesgos de seguridad de los contenedores.
26 mejores prácticas de seguridad de Docker
La siguiente es una lista de las mejores prácticas de los estándares de la industria y de los clientes de StackRox para configurar de forma segura sus contenedores e imágenes de Docker.
-
Utilice siempre la última versión de Docker. Por ejemplo, la vulnerabilidad runC de principios de este año se parchó rápidamente después del lanzamiento de la versión 18.09.2 de Docker.
-
Asegúrese de que solo los usuarios confiables sean miembros del grupo Docker para que solo los usuarios confiables puedan controlar el demonio Docker. Consulte este artículo para obtener más información sobre cómo reducir la superficie de ataque del demonio Docker.
-
Asegúrese de que las reglas apropiadas puedan proporcionar una pista de auditoría:
-
demonio acoplable
-
Archivos y directorios de Docker:
-
/var/lib/docker
-
/etc/acoplador
-
Servicio Docker
-
Docker.socket
-
/etc/default/docker
-
/etc/docker/daemon.json
-
/etc/sysconfig/docker
-
/usr/bin/containerd
-
/usr/sbin/runc
-
-
-
Proteja todos los archivos y directorios de Docker asegurándose de que sean propiedad del usuario adecuado (generalmente root) y que sus permisos de archivo estén configurados en valores restrictivos (consulte la sección CIS Baseline del archivo de configuración del demonio Docker).
-
Utilice un registro con un certificado de registro válido o uno que utilice TLS para minimizar el riesgo de intercepción de tráfico.
-
Si está utilizando un contenedor que no tiene un usuario de contenedor explícito definido en la imagen, debe habilitar la compatibilidad con el espacio de nombres de usuario, lo que le permitirá reasignar usuarios de contenedor a usuarios de host.
-
Impide que el contenedor adquiera nuevos permisos (de forma predeterminada, los contenedores pueden adquirir nuevos permisos), por lo que esta configuración debe establecerse explícitamente. Otro paso que puede tomar para mitigar los ataques de escalada de privilegios es eliminar los permisos setuid y setgid de la imagen.
-
Como práctica recomendada, los contenedores deben ejecutarse como un usuario no root (UID distinto de 0). (El valor predeterminado es que el contenedor se ejecute como raíz dentro del contenedor).
-
Utilice únicamente imágenes base confiables al crear contenedores. Este consejo puede parecer obvio, pero los registros de terceros a menudo no tienen políticas de gobernanza para las imágenes almacenadas en ellos. Es importante saber qué imágenes están disponibles en un host Docker, comprender de dónde provienen y ver qué hay dentro. También debe habilitar la confianza en el contenido para Docker para la verificación de imágenes e instalar solo paquetes verificados en la imagen.
-
Utilice una imagen base mínima que no contenga paquetes innecesarios que puedan generar una superficie de ataque mayor. Menos componentes en un contenedor reducen la cantidad de vectores de ataque disponibles y las imágenes más pequeñas también producen un mejor rendimiento porque hay menos bytes en el disco y menos tráfico de red para copiar la imagen. BusyBox y Apline son dos opciones para crear una imagen base mínima.
-
Implementar una política de gobernanza sólida que imponga escaneos de imágenes frecuentes. Antes de entrar en la fase de creación, se deben rechazar las imágenes obsoletas o se deben volver a escanear las imágenes que no se hayan escaneado recientemente.
-
Cree un flujo de trabajo para identificar y eliminar periódicamente imágenes y contenedores obsoletos o no utilizados de los hosts.
-
No almacene secretos en imágenes/Dockerfiles. De forma predeterminada, puede almacenar secretos en un Dockerfile, pero almacenar secretos en una imagen hace que el secreto sea accesible para cualquier usuario de esa imagen. Cuando necesite texto cifrado, utilice la herramienta de gestión de texto cifrado.
-
Al ejecutar un contenedor, elimine todas las funciones necesarias para que se ejecute. Puede utilizar la función CAP DROP de Docker para eliminar funciones (también conocidas como funciones de Linux) de un contenedor específico y CAP ADD para agregar solo aquellas funciones necesarias para que el contenedor funcione correctamente.
-
No ejecute contenedores con el indicador --privileged, ya que este tipo de contenedor tendrá la mayor parte de la funcionalidad disponible para el host subyacente. Este indicador también anula cualquier regla que establezca mediante CAP DROP o CAP ADD.
-
No monte directorios confidenciales del sistema host en contenedores, especialmente en modo de escritura, ya que esto puede exponerlos a cambios maliciosos que pueden comprometer el host.
-
No ejecute sshd dentro de un contenedor. El demonio ssh no se ejecuta en el contenedor de forma predeterminada y no debe instalarse para simplificar la gestión de seguridad de los servidores SSH.
-
No asigne ningún puerto inferior a 1024 dentro del contenedor, ya que se consideran puertos privilegiados y transmitirán datos confidenciales. De forma predeterminada, Docker asigna puertos de contenedores a puertos en el rango 49153–65525, pero permite asignar contenedores a puertos privilegiados. Como regla general, asegúrese de que solo los puertos requeridos estén abiertos en el contenedor.
-
No comparta el espacio de nombres de red, el espacio de nombres de proceso, el espacio de nombres de IPC, el espacio de nombres de usuario o el espacio de nombres UTS del host a menos que sea necesario para garantizar un aislamiento adecuado entre el contenedor Docker y el host subyacente.
-
Especifique la cantidad de memoria y CPU necesarias para que el contenedor se ejecute según lo diseñado, en lugar de depender de cantidades arbitrarias. De forma predeterminada, los contenedores Docker comparten sus recursos por igual y sin restricciones.
-
Configure el sistema de archivos raíz del contenedor en solo lectura. Una vez en ejecución, el contenedor no requiere cambios en el sistema de archivos raíz. Cualquier cambio realizado en el sistema de archivos raíz puede tener fines maliciosos. Para mantener la naturaleza inmutable de los contenedores (los contenedores nuevos no se parchean, sino que se recrean a partir de imágenes nuevas), no debe hacer que se pueda escribir en el sistema de archivos raíz.
-
Aplicar restricciones PID. Una de las ventajas de los contenedores es el estricto control del identificador de proceso (PID). Cada proceso en el kernel tiene un PID único y los contenedores aprovechan el espacio de nombres PID de Linux para proporcionar a cada contenedor una vista separada de la jerarquía de PID. Limitar el PID limita efectivamente la cantidad de procesos que se ejecutan en cada contenedor. Limitar la cantidad de procesos en un contenedor evita la generación excesiva de nuevos procesos y movimientos laterales potencialmente maliciosos. La imposición de límites de PID también evita las bombas fork (procesos que se replican continuamente) y los procesos anormales. En la mayoría de los casos, si su servicio siempre ejecuta una cantidad específica de procesos, establecer el límite de PID en ese número exacto puede mitigar muchos comportamientos maliciosos, incluidos shells inversos y la inyección remota de código.
-
No configure reglas de propagación de montaje para recursos compartidos. La propagación de montaje compartido significa que cualquier cambio realizado en un montaje se propagará a todas las instancias de ese montaje. La propagación del montaje debe configurarse en modo esclavo o privado para que los cambios necesarios en el volumen no se compartan (ni se propaguen) con contenedores que no requieren el cambio.
-
No utilice el comando docker exec con privilegios o la opción usuario=root, ya que esta configuración puede proporcionar capacidades extendidas de Linux al contenedor.
-
No utilice el puente predeterminado "docker0". El uso del puente predeterminado lo expone a ataques de suplantación de ARP y de inundación de MAC. En cambio, el contenedor debe estar en una red definida por el usuario, no en el puente predeterminado "docker0".
-
No monte un socket Docker dentro del contenedor, ya que este enfoque permitirá que el proceso dentro del contenedor ejecute comandos, dándole control total del host.
Siete mejores prácticas para la seguridad de Kubernetes
Como estándar de facto para la orquestación de contenedores, Kubernetes desempeña un papel clave a la hora de garantizar la seguridad de las aplicaciones. Para proteger eficazmente las aplicaciones en contenedores, debe aprovechar la información contextual de Kubernetes y sus capacidades nativas de aplicación de políticas. Por ejemplo, Kubernetes tiene varias funciones de seguridad integradas que facilitan el funcionamiento de la seguridad de los contenedores durante todo su ciclo de vida, incluidos Kubernetes RBAC, políticas de red y controladores de admisión. Aproveche el poder de estos controles inherentes a Kubernetes para proteger su entorno en contenedores.
A continuación se presentan algunas prácticas recomendadas de seguridad de Kubernetes para ayudar a proteger los contenedores durante todo su ciclo de vida.
-
Para RBAC, asigne roles y ClusterRoles a usuarios o grupos específicos en lugar de otorgar privilegios de administrador de clúster a cualquier usuario o grupo.
-
Evite duplicar permisos cuando utilice Kubernetes RBAC, ya que hacerlo puede crear problemas operativos.
-
Elimine los roles RBAC no utilizados o inactivos para centrarse en los roles activos al solucionar problemas o investigar incidentes de seguridad.
-
Utilice las políticas de red de Kubernetes para aislar los pods y permitir explícitamente solo las rutas de comunicación necesarias para que se ejecute su aplicación. De lo contrario, enfrentará amenazas horizontales y de norte a sur.
-
Si un pod requiere acceso a Internet (ya sea de entrada o de salida), cree una política de red adecuada para aplicar las reglas correctas de segmentación de red/firewall, luego cree una etiqueta para dicha política de red y finalmente asocie el pod con esa etiqueta.
-
Utilice el controlador de admisión PodSecurityPolicy para garantizar que se apliquen las políticas de gobernanza adecuadas. El controlador PodSecurityPolicy puede evitar que un contenedor se ejecute como raíz o garantizar que el sistema de archivos raíz del contenedor esté montado en modo de solo lectura (estas sugerencias deberían resultarle familiares, como lo fueron ambas en la lista anterior de medidas de Docker).
-
Aplique políticas de gobernanza de registros de imágenes mediante el controlador de admisión de Kubernetes para denegar automáticamente todas las imágenes obtenidas de registros que no sean de confianza.
Reflexiones finales: asegúrese de responder estas 11 preguntas de seguridad sobre los entornos de contenedores Docker
Para ayudar a evaluar rápidamente su postura de seguridad, hemos compilado una lista de preguntas que su equipo de seguridad, DevSecOps o DevOps debería poder responder fácilmente si su pila nativa de la nube se ha creado con las medidas de seguridad adecuadas.
-
¿Cuántas imágenes hay en un host cuya última fecha de escaneo fue hace más de 60 días?
-
¿Cuántas imágenes/contenedores tienen vulnerabilidades de alta gravedad?
-
¿Qué implementaciones se ven afectadas por estos contenedores vulnerables de alta gravedad?
-
¿Hay algún contenedor en la implementación afectada que almacene secretos?
-
¿Alguno de los contenedores vulnerables se ejecuta con indicadores raíz o privilegiados?
-
¿Hay algún contenedor vulnerable en el pod que no tenga una política de red asociada (lo que significa que permite todas las comunicaciones)?
-
¿Hay algún contenedor que se esté ejecutando en producción afectado por esta vulnerabilidad?
-
¿De dónde vienen las imágenes que utilizamos?
-
¿Cómo bloqueamos imágenes extraídas de registros que no son de confianza?
-
¿Podemos ver qué procesos se están ejecutando mientras se ejecuta el contenedor?
-
¿Qué clústeres, espacios de nombres y nodos no cumplen con los puntos de referencia CIS para Docker y Kubernetes?
Si sigue estas mejores prácticas recopiladas en esta lista, podrá tomar los pasos más importantes para fortalecer con éxito sus entornos Docker y Kubernetes y proteger sus aplicaciones críticas para su negocio.