Conceptos básicos de seguridad de contenedores: cargas de trabajo

Si acabas de incorporarte a esta serie, quizá te interese empezar por el principio:
Fundamentos de la seguridad de contenedores: Introducción
Fundamentos de la seguridad de contenedores: Canalización
Fundamentos de la seguridad de contenedores: Orquestación

Carga de trabajo es un término relativamente reciente que suele utilizarse para describir aplicaciones, aunque también puede hacer referencia a servicios de infraestructura. Esto es importante, ya que en sus clústeres de contenedores puede haber diversas «cargas de trabajo» en ejecución que no procedan necesariamente de sus desarrolladores. El uso de servicios gratuitos y de código abierto para diversos fines dentro de los entornos de contenedores está aumentando. De hecho, esta tendencia se observa en todas las operaciones de TI, que durante el último año fueron la principal categoría de descargas de software gratuito y de código abierto.

Así pues, cuando hablamos de seguridad de las cargas de trabajo, nos referimos a cualquier software que haya descargado, desarrollado o implementado en su entorno de contenedores. Piense en Consul. Piense en el propio Kubernetes. Piense en Prometheus y Elasticsearch. Piense en NGINX e istio.

Añade también a esa lista todas las puertas de enlace de API, cachés y controladores de entrada que hayas implementado para dar soporte a tu entorno de Kubernetes. Aquí es donde resulta importante contar con una lista de materiales exhaustiva y por lo que realizar un inventario periódicamente es fundamental para mantener un entorno seguro.

Una vez que tenga la lista, es hora de abordar los principales problemas de seguridad de las cargas de trabajo.

• 1. La autenticación no es opcional
  Si has seguido toda esta serie, esto ya te resultará familiar. Es uno de los temas recurrentes en todos los aspectos de la seguridad de los contenedores: cerrar la puerta de entrada.
  
  Todos estos servicios se ejecutan como cargas de trabajo en un clúster. Esto suele implicar el uso de credenciales predeterminadas o una configuración inicial «abierta» para acceder a las API y a los datos. La seguridad de las cargas de trabajo abarca todos los componentes, el software y los servicios de aplicaciones necesarios para el funcionamiento de la aplicación y su operativa.
  
  
• 2. El contenido malicioso es malicioso
  Incluso después de haber cerrado la puerta exigiendo credenciales y aplicando controles de acceso, sigue siendo necesario preocuparse por el contenido malicioso. Esto se aplica a las aplicaciones, los microservicios y los servicios operativos en uso. Todas las cargas de trabajo que ofrecen una interfaz a un usuario (ya sea un operador o un consumidor) están potencialmente en riesgo. Aquí es imprescindible analizar y actuar. El primer paso es detectar vulnerabilidades en la capa de aplicación, ya sean de HTTP o de la lógica de la aplicación. Una vez detectadas, hay que tomar medidas. Si se trata de una aplicación personalizada, devuélvela al equipo de desarrollo. Si es un componente de terceros, comprueba si existe una versión corregida o actualizada. Los componentes de terceros suelen distribuirse en imágenes de contenedor y, como señala Snyk en su informe de 2019 sobre el estado de la seguridad del código abierto, el 44 % de ellos presenta vulnerabilidades conocidas para las que existen imágenes base más recientes y seguras disponibles.
  
  Repitámoslo: ejecutar un análisis no mejora en absoluto la seguridad si no se corrigen las vulnerabilidades.
  
  Si tuvieras un agujero en la pared que permitiera a posibles ladrones sortear fácilmente las puertas cerradas, lo repararías. Así que repara también los agujeros virtuales de tus paredes virtuales.
  
  El uso de un cortafuegos de aplicaciones web o de una puerta de enlace de seguridad de API puede servir para mitigar las vulnerabilidades cuando los desarrolladores no pueden corregirlas de inmediato o los proveedores externos aún no las han resuelto.
  
  La mejor forma de resumirlo es «filtra tus llamadas», porque se trata de inspeccionar y evaluar las solicitudes dirigidas a cualquier carga de trabajo antes de aceptarlas.
  
  
• 3. Los recursos compartidos implican riesgos compartidos
  Al igual que ocurre con la virtualización tradicional, los contenedores no están completamente aislados. En última instancia, los contenedores comparten el mismo sistema operativo físico. Esto significa que las vulnerabilidades del sistema operativo compartido afectan a todos los contenedores.

Si un atacante logra aprovechar una vulnerabilidad en los componentes del sistema operativo, puede poner en peligro una o varias cargas de trabajo. Estas vulnerabilidades podrían quedar expuestas por no «cerrar la puerta con llave» o no «filtrar las llamadas». No es una situación descabellada, como ya vimos con CVE-2019-5736, cuando una vulnerabilidad de runc en la capa del sistema operativo hizo cundir el pánico en Internet.

El principio fundamental de seguridad en este caso fue formulado célebremente por Dan Walsh, experto en SELinux y seguridad de contenedores de Red Hat, de la siguiente manera: «Los contenedores no contienen».

Es importante señalar que todo el tráfico de red con servicios y usuarios externos al nodo debe atravesar el sistema operativo del host. La comunicación de red entre los pods y los contenedores de un nodo se lleva a cabo mediante redes virtuales, con puentes virtuales y un uso ingenioso de iptables. Sin embargo, en última instancia, el tráfico tiene que salir de ese nodo físico, lo que implica que debe procesarse en el sistema operativo del host. Es posible que agentes, complementos y otros demonios estén observando o capturando ese tráfico con fines de seguridad o visibilidad. Estos son posibles puntos vulnerables que debería añadir al inventario que empezó a elaborar después de leer sobre Seguridad del pipeline.

• 4. Registro de datos confidenciales
  Puede que no esperase que un análisis sobre la seguridad de los contenedores incluyera una advertencia sobre los registros. Sin embargo, es necesario, ya que a veces la información confidencial acaba en los archivos de registro: tokens de autorización, claves del proveedor de cifrado o credenciales. Las cargas de trabajo pueden registrar o mostrar accidentalmente todos estos datos en stderr. A menudo, esto se debe a la necesidad de investigar problemas derivados de errores de autenticación. En general, debe desaconsejar —o prohibir, si es posible— que se registren secretos en el sistema.
  
  Para ayudar a garantizar que los desarrolladores sean conscientes de este riesgo, considere la posibilidad de proporcionar una guía de diseño de registros y especificar qué se puede y qué no se puede escribir en ellos.

Gran parte de la seguridad de las cargas de trabajo en un entorno de contenedores es la misma que la de cualquier otra carga de trabajo de aplicaciones que se ejecute en su entorno de producción. Controle el acceso y exija una autenticación robusta, esté atento al contenido malicioso y tenga en cuenta las vulnerabilidades compartidas y las de la plataforma.