¿Cómo deberíamos reconstruir automáticamente la infraestructura inmutable cuando hay nuevos paquetes disponibles?

Vamos a utilizar Terraform para automatizar nuestra implementación de infraestructura y Packer para crear las imágenes de máquina implementadas por Terraform. Al seguir los principios de diseño de infraestructura inmutable, implementaremos parches creando una nueva imagen con el parche aplicado y luego redistribuiremos nuestra infraestructura.

Con esta configuración, ¿hay alguna herramienta adicional que podamos usar para detectar automáticamente cuándo un paquete o el sistema operativo en nuestra imagen base necesita actualizarse y activar la canalización de compilación?

Chef Automate parece cercano a lo que estoy buscando, sin embargo, parece escanear los nodos en ejecución para el cumplimiento en lugar de analizar el manifiesto de la imagen en sí.

¡Gracias!

Parte de adoptar el Patrón de Infraestructura Inmutable es descomponer su sistema en pequeñas piezas manejables que pueden moverse a través de la canalización de CI / CD muy rápidamente, esto significa que los parches del sistema operativo se pueden hacer de manera rápida y controlada. A menudo veo clientes que terminan en una casa intermedia donde la infraestructura es mayormente inmutable.

Sin embargo, hay algunos enfoques para esto que he usado en implementaciones a gran escala de la arquitectura de la nube, por lo general, implemento más de uno como parte de una estrategia de Defensa en Profundidad :

• Información de seguridad y gestión de eventos (SIEM) : estos productos, por ejemplo, LogRhythm Security Intelligence Platform y otros productos más genéricos, como ElasticStack, reciben información del sistema operativo, que incluye la salida de una comprobación frecuente de actualizaciones. El truco aquí es obtener la información sobre qué parchear rápida y automáticamente para informar las decisiones sobre cuándo pasarlos por su tubería.

• Los sistemas de gestión de vulnerabilidades están más personalizados que SIEM, ya que solo se centran en las vulnerabilidades en todo el sistema, por lo que podrían detectar problemas con las bibliotecas instaladas como parte del software implementado en el sistema pero no administrado por el sistema operativo. Esto podría resaltar vulnerabilidades para las cuales no hay parche (todavía ... con suerte).

• Las herramientas de verificación de dependencia forman parte de su canalización y pueden configurarse para fallar la compilación si los registros agregan vulnerabilidades, esto también funciona si se agrega una nueva vulnerabilidad a la herramienta desde el último registro.

Podría hacer un análisis de vulnerabilidades con AWS Inspector y buscar vulnerabilidades de CVE. El inspector tiene una métrica de CloudWatch para provocar una acción cuando hay hallazgos. Sería complicado determinar QUÉ paquetes deben actualizarse, pero podría actualizarlo todo. No tiene que usar Inspector, cualquier herramienta de escaneo de vulnerabilidades que pueda conectar funcionaría. El escaneo de vulnerabilidades es una práctica recomendada en general.

Otra idea sería configurar un trabajo cron que haga apt-get update && apt-get upgrade —dry-run> stuff-that-should-be-updated.txt y analice el archivo de texto para obtener una lista de paquetes que se actualizarán y retroalimente eso en su proceso de construcción.

Este enfoque busca resolver su propósito utilizando la auditoría de Chef, pero tiene sus propios problemas. https://joshuakugler.com/using-chef-zero-audit-mode-and-packer.html

Una solución personalizada: si desea utilizar una Política de cumplimiento (por ejemplo, CIS, HIPPA), cree un trabajo que ejecutará un analizador de auditoría al ejecutar imágenes de paquetes y notificará una tarea de actualización cuando no haya una queja. Hay analizador OVAL y definición OVAL disponibles de forma gratuita para las políticas anteriores. Para políticas aduit personalizadas, puede escribir su propio analizador y auditar la imagen.