Conceptos básicos de seguridad de los contenedores: carga de trabajo

Si recién te estás iniciando en esta serie, quizás quieras empezar por el principio: 
Conceptos básicos de seguridad de contenedores: Introducción
Conceptos básicos de seguridad de contenedores: Tubería
Conceptos básicos de seguridad de contenedores: Orquestación

Carga de trabajo es un término bastante reciente que a menudo se utiliza para describir aplicações , pero también puede referirse a servicios de infraestructura. Esto es importante porque puede haber una variedad de "cargas de trabajo" ejecutándose en sus clústeres de contenedores que no necesariamente provienen de sus desarrolladores. El uso de servicios gratuitos y de código abierto para una variedad de propósitos dentro de entornos de contenedores está creciendo. De hecho, esto es cierto en las operaciones de TI, que fue la categoría número uno en descargas de open source software durante el año pasado.

Entonces, cuando decimos seguridad de la carga de trabajo, nos referimos a cualquier pieza de software que haya descargado, desarrollado o implementado en su entorno de contenedores. Piense en Cónsul . Piense en Kubernetes mismo. Piense en Prometheus y Elasticsearch . Piense en NGINX y istio .

Y luego también coloque en esa lista cualquier puerta de enlace de API, cachés y controladores de ingreso que haya implementado para respaldar su entorno de Kubernetes. Aquí es donde una lista detallada de materiales es importante, y por qué realizar un inventario periódicamente es fundamental para mantener un entorno seguro.

Una vez que tenga su lista, es hora de abordar los problemas clave de seguridad de la carga de trabajo.

• 1.La autenticación no es opcional
  Si has estado siguiendo toda esta serie, esto ya te resultará familiar. Es uno de los temas comunes 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. Eso a menudo significa credenciales predeterminadas o una configuración inicial “abierta” para acceder a las API y los datos. La seguridad de la carga de trabajo incluye todos los componentes, software y servicios de aplicação necesarios para la funcionalidad y el funcionamiento de la aplicação . 
  
  

• 2.El contenido malicioso es malicioso
  Incluso después de haber cerrado la puerta solicitando credenciales y aplicando control de acceso, todavía hay que preocuparse por el contenido malicioso. Esto es cierto para las aplicações, los microservicios y los servicios operativos en uso. Todas las cargas de trabajo que presentan una interfaz para un usuario (ya sea operador o consumidor) están potencialmente en riesgo.

  Aquí es donde escanear y actuar es imprescindible. Encontrar vulnerabilidades en la capa de aplicação (ya sea de HTTP o de la lógica de la aplicação ) es el primer paso. Una vez que los hayas encontrado, será hora de hacer algo al respecto. Si es una aplicación personalizada, envíela de vuelta al desarrollo. Si es un componente de terceros, determine si existe o no una versión parcheada/actualizada. Los componentes de terceros a menudo se entregan en imágenes de contenedores y, como señala Snyk en su informe State of Open Source Security de 2019 , el 44 % de ellos tienen vulnerabilidades conocidas para las cuales hay imágenes base más nuevas y más seguras disponibles.
  
  Digámoslo nuevamente: ejecutar un análisis no hace nada para mejorar la seguridad si no se soluciona el problema.
  
  Si tienes un agujero en la pared que permite a los posibles ladrones eludir fácilmente las puertas cerradas, deberías taparlo. Así que arregla los agujeros virtuales en tus paredes virtuales.
  
  El uso de un firewall de aplicação web o un gateway de seguridad API puede brindar un medio para remediar problemas cuando los desarrolladores no pueden abordar de inmediato las vulnerabilidades o los proveedores externos aún no las han resuelto.
  
  La mejor manera de resumirlo es diciendo "examinar sus llamadas", porque se trata de inspeccionar y evaluar las solicitudes de cualquier carga de trabajo antes de aceptarla.
  
  
• 3.Los recursos compartidos significan un riesgo compartido
  Al igual que la virtualización tradicional, los contenedores no están completamente aislados. Los contenedores, en última instancia, comparten el mismo sistema operativo físico. Esto significa que las vulnerabilidades en el sistema operativo compartido significan vulnerabilidades compartidas.

Si un atacante puede explotar una vulnerabilidad en los componentes del sistema operativo, puede comprometer una o más cargas de trabajo. Esas vulnerabilidades podrían quedar expuestas si no se cierra la puerta o no se filtran las llamadas. No es un escenario descabellado, como hemos visto con CVE-2019-5736 , en el que una vulnerabilidad runc en la capa del sistema operativo provocó pánico en Internet. 

El principio de seguridad central aquí fue enunciado por Dan Walsh , gurú de seguridad de contenedores de SELinux y RedHat, como sigue: "Los contenedores no contienen" . 

Es importante tener en cuenta que todo el tráfico de red con servicios y usuarios fuera del nodo debe atravesar el sistema operativo host. La creación de redes entre pods y contenedores en un nodo se logra a través de redes virtuales con puentes virtuales y un uso inteligente de iptables. Pero, en última instancia, el tráfico tiene que salir de ese nodo físico y eso significa procesarlo en el sistema operativo host. Es posible que agentes, complementos y otros demonios observen o capturen ese tráfico con fines de seguridad o visibilidad. Esos son puntos potenciales de compromiso que debes agregar al inventario que comenzaste a compilar después de leer sobre Pipeline Security .

• 4.Registro de detalles confidenciales
  Quizás no esperaba que una discusión sobre seguridad de contenedores incluyera una advertencia sobre los registros. Pero así es, y la razón es que a veces la información confidencial termina en archivos de registro. Tokens de autorización, claves de proveedor de cifrado, credenciales. Todo puede ser registrado o mostrado inadvertidamente por las cargas de trabajo en stderr . A menudo, esto se debe a la necesidad de rastrear problemas debidos a errores de autenticación. En general, se debe desalentar (y, si es posible, prohibir) el registro de secretos en el sistema.
  
  Para ayudar a garantizar que los desarrolladores sean conscientes de este riesgo, considere proporcionar una guía de diseño de registro y especificar qué es y qué no es aceptable escribir en el registro.

Gran parte de la seguridad de la carga de trabajo en un contexto de contenedor es la misma que la de cualquier otra carga de trabajo de aplicação que se ejecute en su entorno de producción. Controlar el acceso y exigir una autenticación fuerte, estar atento a contenidos maliciosos y estar al tanto de las vulnerabilidades compartidas y a nivel de plataforma.