Fundamentos de la seguridad de contenedores: seguridad de la canalización

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

En la era del capital de las aplicaciones, el pipeline de CI/CD es un componente fundamental del que dependen la velocidad y la seguridad de las aplicaciones que crea y entrega.

Se trata de un complejo sistema de herramientas, integradas mediante API y ejecutadas por scripts o complementos que representan digitalmente el proceso que sigue para crear y, en última instancia, entregar aplicaciones en contenedores. Esto significa que existen múltiples puntos en los que un agente malintencionado podría comprometer el sistema. Aunque pueda parecer poco probable, recuerde que un buen número de organizaciones utilizan actualmente la nube, lo que implica necesariamente el acceso remoto.

Eso significa que la seguridad de la canalización consta de dos partes: en primer lugar, la seguridad de la propia canalización; en segundo lugar, la seguridad dentro de la canalización.

Seguridad de la canalización

1. La autenticación no es opcional
Si utiliza herramientas y servicios como parte de su canalización en la nube o como servicio alojado, estos están expuestos a ataques. Si permite que desarrolladores remotos o el personal de operaciones accedan a herramientas y servicios alojados internamente, estos también quedan expuestos a ataques. Antes de restar importancia a este riesgo, no olvidemos la cantidad de brechas de seguridad que se han producido en los últimos años como consecuencia de permitir el acceso externo a los sistemas. En lo que respecta a la seguridad de la canalización, la postura más prudente es asumir que, efectivamente, los agentes maliciosos pueden acceder a ella.

Por tanto, la primera prioridad debe ser proteger el acceso. Una autenticación robusta no es opcional. Se recomienda encarecidamente utilizar controles de acceso para ajustar con precisión el acceso a los sistemas críticos, incluso si cree que solo se puede acceder a ellos desde la red interna. En su red hay otros sistemas que los agentes maliciosos pueden utilizar para obtener acceso.

Una vez resuelta la autenticación, el siguiente paso es la autorización. La autorización determina qué puede hacer un usuario autenticado dentro del sistema. Es importante diferenciar los privilegios según las funciones, ya que cuantas menos credenciales tengan acceso a los componentes críticos, mayor será la seguridad.

Todos los componentes de la canalización deben exigir autenticación y autorización. Esto incluye desde los repositorios hasta las herramientas utilizadas para crear aplicaciones y contenedores.

2. Protección de los componentes del pipeline
Por desgracia, no es raro oír noticias de que los atacantes han descubierto auténticos tesoros (credenciales y otros secretos) al analizar repositorios públicos. Consulte el punto uno para recordar la importancia de exigir autenticación en los repositorios.

La realidad de los pipelines actuales es que constituyen una cadena integrada de herramientas, cada una de las cuales debería requerir autenticación. Por ello, las credenciales y los secretos (claves) suelen acabar almacenados en scripts que invocan las herramientas y los servicios que componen el pipeline. Esto es Algo Muy Malo™, especialmente cuando se combina con prácticas de autenticación deficientes en los repositorios donde podrían almacenarse dichos scripts.

Las credenciales son activos críticos que deben protegerse. Es importante saber dónde se encuentran, dónde se almacenan y cómo se protegen. Una herramienta útil para gestionar la «proliferación de secretos» es HashiCorp Vault. Vault almacena los secretos de forma segura en una ubicación centralizada.

Seguridad en el pipeline

3. Mantenga una lista de materiales
Antes de poder proteger un sistema —o un componente del sistema—, debe saber que existe. Es importante mantener una lista de materiales completa para saber qué hay en su entorno. Más concretamente, debe asegurarse de saber qué debería haber en su entorno y, a la inversa, qué no debería haber.

Un inventario bien mantenido puede ayudar a proteger frente a los intentos de introducir componentes contaminados o comprometidos en la cadena de suministro. Estandarizar el uso de un único contenedor base o, al menos, de un número reducido y manejable de contenedores puede mejorar considerablemente la capacidad para detectar posibles problemas. Por tanto, cualquier desviación debería activar una alerta que pueda investigarse. Por ejemplo, comparar los hashes y, si están disponibles, validar las firmas digitales de las imágenes de contenedor es un paso importante. Si se obtienen de un repositorio remoto, existe la posibilidad de que este se haya visto comprometido.

Eso fue lo que ocurrió cuando DockerHub sufrió una brecha de seguridad que expuso las credenciales y los tokens de 190.000 de sus usuarios. Con esa información, los atacantes podrían haber comprometido imágenes que posteriormente les permitieran acceder a otros sistemas.

No se limite a las imágenes de contenedores. Recuerde que los componentes de aplicaciones procedentes de fuentes externas pueden verse comprometidos. Un ejemplo concreto es la inserción de software de minería de criptomonedas en un paquete NPM de Node.js event-stream.

Estandarizar un inventario mantenido de imágenes y componentes también agiliza la corrección de vulnerabilidades cuando surgen —porque surgirán—. Actualizar una única capa base del sistema operativo es mucho más fácil de gestionar que intentar actualizar un conjunto heterogéneo de contenedores.

4. Analizar y corregir
Los entornos de contenedores pueden verse comprometidos o quedar expuestos a ataques de innumerables formas. Normalmente pensamos en las vulnerabilidades del software de una imagen de contenedor. Aunque debe prestarles atención —analizarlas y actualizar o aplicar parches—, también existen problemas de configuración que se suelen detectar y solucionar con menos frecuencia. Muchos de ellos pueden evitarse con la configuración adecuada. Su canalización debe incluir herramientas capaces de detectar vulneraciones o alertar sobre configuraciones no seguras.

Aqua Security ofrece herramientas que pueden ayudar a analizar y evaluar tanto los contenedores como las configuraciones. Kube-bench y kube-hunter son excelentes recursos para identificar errores de configuración habituales (pero críticos) en entornos de Kubernetes.

o FOSS
https://github.com/aquasecurity/kube-bench
https://github.com/aquasecurity/kube-hunter

o Comercial
https://www.aquasec.com/

Todos los análisis del mundo no ayudarán a evitar que los sistemas se vean comprometidos o que se produzca una brecha de seguridad si no se toman medidas al respecto. Informe de Tripwire sobre el estado de la seguridad de los contenedores en 2019 reveló que casi una de cada cinco organizaciones (el 17 %) conocía la existencia de vulnerabilidades en las imágenes de contenedores, pero aun así las implementaba. Teniendo esto en cuenta, probablemente no sorprenda que la encuesta revelara que más de la mitad de las organizaciones (el 60 %) había sufrido un incidente de seguridad relacionado con contenedores durante los doce meses anteriores.

Nunca se insistirá lo suficiente en este punto: si integra análisis de seguridad en su canalización (y debería hacerlo), es importante tomar medidas en función de los resultados. Ejecutar un análisis no sirve de nada para mejorar la seguridad si no corrige las vulnerabilidades detectadas.

Lo repetimos: ejecutar un análisis no sirve de nada para mejorar la seguridad si no se corrigen los problemas detectados.

La seguridad del pipeline es un problema complejo y con múltiples facetas. El pipeline debe tratarse como cualquier otro conjunto de aplicaciones porque, en última instancia, eso es lo que es, aunque tenga un carácter operativo. No descuides la seguridad del pipeline mientras integras la seguridad en el pipeline.

Lee el siguiente artículo de la serie:
Conceptos básicos de seguridad de contenedores: orquestación