Conceptos básicos de seguridad de los contenedores: seguridad de la distribución

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

En una era de capital de aplicação , el flujo de trabajo de CI/CD es un componente fundamental sobre el cual se basan la velocidad y la seguridad de las aplicações que crea y entrega.

Se trata de un sistema complejo de herramientas, integrado a través de API e invocado por scripts o complementos que representan digitalmente el proceso que estás siguiendo para construir y, en última instancia, entregar aplicações en contenedores. Lo que eso significa es que hay múltiples puntos en los que un actor malicioso podría comprometer el sistema. Si bien esto puede parecer descabellado, recuerde que un buen número de organizaciones están aprovechando hoy la nube, lo que necesariamente significa acceso remoto.

Esto significa que hay dos aspectos de la seguridad del ducto: primero, la seguridad del ducto mismo. En segundo lugar, la seguridad en el oleoducto.

Seguridad del oleoducto 

1.La autenticación no es opcional
Si utiliza herramientas y servicios como parte de su canalización en la nube o como un servicio alojado, están expuestos a ataques. Si permite el acceso de desarrolladores o operaciones remotos a herramientas y servicios alojados internamente, estarán expuestos a ataques. Antes de descartar esa preocupación, no olvidemos la cantidad de violaciones ocurridas en los últimos años como resultado de la apertura de los sistemas al acceso externo. La mejor postura a adoptar cuando se trata de la seguridad de los ductos es que sí, son accesibles para los actores maliciosos.

A su vez, eso significa que el primer paso es asegurar el acceso. La autenticación fuerte no es opcional. Se recomienda encarecidamente el uso del control de acceso para ajustar con precisión el acceso a sistemas críticos. Incluso si piensas que los sistemas sólo son accesibles internamente. Hay otros sistemas en su red a través de los cuales los actores maliciosos pueden obtener acceso.

Una vez que haya abordado la autenticación, el siguiente paso es la autorización. La autorización especifica lo que un usuario autenticado puede hacer dentro del sistema. Es importante distinguir los privilegios según los roles porque cuantas menos credenciales tenga con acceso a componentes críticos, mejor será.

Cada componente del pipeline debe requerir autenticación y autorización. Esto significa todo, desde los repositorios hasta las herramientas utilizadas para crear aplicações y contenedores.

2.Protección de los componentes de la tubería
Lamentablemente, no es inusual escuchar informes de que atacantes han descubierto grandes cantidades de tesoros (credenciales y otros secretos) al escanear repositorios públicos. Consulte el número uno para obtener un recordatorio para solicitar autenticación en los repositorios.

La realidad de los pipelines actuales es que son una cadena integrada de herramientas, cada una de las cuales debe requerir autenticación. Debido a eso, las credenciales y los secretos (claves) a menudo terminan almacenados en scripts que invocan las herramientas y los servicios que componen el pipeline. Esto es algo muy malo™, en particular cuando se combina con malas prácticas de autenticación en los repositorios en los que podrían estar almacenados esos scripts.

Las credenciales son activos críticos que deben protegerse. Tenga en cuenta dónde residen, dónde se almacenan y cómo están protegidos. Una herramienta útil para gestionar la “proliferación de secretos” es HashiCorp Vault . Vault almacena de forma segura los secretos en una ubicación central.

Seguridad en el oleoducto

3.Mantener una lista de materiales
Antes de poder proteger un sistema (o un componente del sistema), es necesario saber que existe. Es importante mantener una lista completa de materiales para asegurarse de saber qué hay en su entorno. Más concretamente, debes asegurarte de saber qué debería haber en tu entorno y, a la inversa, qué no.

Un inventario bien mantenido puede ayudar a proteger contra intentos de insertar componentes contaminados o comprometidos en la tubería. La estandarización en un único contenedor base o al menos en un puñado manejable de contenedores puede mejorar drásticamente su capacidad para detectar problemas potenciales. Las desviaciones deberían entonces generar una alerta que pueda ser investigada. Por ejemplo, comparar hashes y, si están disponibles, validar las firmas digitales de las imágenes de contenedores es un paso importante. Si está extrayendo desde un repositorio remoto, existe la posibilidad de que esté comprometido.

Ese fue el caso cuando DockerHub sufrió una vulneración y expuso las credenciales y tokens de 190.000 de sus usuarios. Utilizando esa información, los atacantes podrían haber comprometido imágenes que luego les dieron acceso a otros sistemas.

No te quedes solo con imágenes de contenedores. Recuerde que los componentes de aplicação de origen externo están sujetos a riesgos. Un ejemplo concreto es la inserción de software de minería de criptomonedas en un flujo de eventos de un paquete NPM NodeJS .

La estandarización de un inventario mantenido de imágenes y componentes también agiliza la remediación de vulnerabilidades cuando surgen (no si surgen). Actualizar una sola capa base del sistema operativo es mucho más fácil de gestionar que intentar actualizar un conjunto dispar de contenedores.

4.Escanear y remediar
Existen innumerables formas en las que los entornos de contenedores pueden verse comprometidos o volverse vulnerables a ataques. La mayoría de las veces pensamos en las vulnerabilidades del software en una imagen de contenedor. Si bien debes prestarles atención (escanearlos y actualizarlos o aplicar parches), también hay problemas basados en la configuración que se detectan y solucionan con menos frecuencia. Muchos de estos problemas se pueden prevenir con la configuración adecuada. Su canalización debe incluir herramientas capaces de detectar compromisos o alertar sobre configuraciones inseguras.

Aqua Security ofrece herramientas que pueden ayudar a escanear y evaluar contenedores y configuraciones por igual. Kube-bench y kube-hunter son excelentes recursos para identificar errores de configuración comunes (pero críticos) en entornos de Kubernetes.
 

Todos los análisis del mundo no ayudarán a prevenir vulneraciones o infracciones si no se toman medidas al respecto. El informe State of Container Security de 2019 de Tripwire descubrió que casi una de cada cinco (17 %) organizaciones conocía las vulnerabilidades en las imágenes de contenedores, pero las implementaban de todos modos. Teniendo en cuenta eso, probablemente no sea una sorpresa que la encuesta haya encontrado que más de la mitad (60%) de las organizaciones habían experimentado un incidente de seguridad relacionado con contenedores en los doce meses anteriores.

No se puede enfatizar este punto con la suficiente frecuencia ni en voz alta: si integra análisis de seguridad en su flujo de trabajo (y debería hacerlo), es importante realizar un seguimiento de los hallazgos. Ejecutar un análisis no hace nada para mejorar la seguridad si no se soluciona el problema.

Repetimos: ejecutar un análisis no hace nada para mejorar la seguridad si no se soluciona el problema.

La seguridad de las tuberías es un problema multifacético que puede representar un desafío. El pipeline debe ser tratado como cualquier otro conjunto de aplicações porque, en definitiva, eso es lo que es, aunque sea un conjunto operativo. No ignore la seguridad del pipeline mientras integra la seguridad en el pipeline.

Lea el siguiente blog de la serie: 
Conceptos básicos de seguridad de contenedores: Orquestación