Actualizando Auto Scaling Groups con EC2 Image Builder.

Hace poco hablábamos de cómo parchear máquinas con AWS System Manager y planteamos algún problema con los grupos de autoescalado o Auto Scaling Group.

El problema es que si actualizamos una instancia que pertenece a un Auto Scaling Group, la propia actualización puede detectar el reinicio de la máquina tras la actualización, como una caída del servicio y reemplazar la instancia actualizada por una nueva instancia sin actualizar. Incluso si conseguimos actualizar la instancia pausando los procesos del Auto Scaling Group, nos seguimos encontrando problemas, porque si es necesario lanzar una nueva instancia, por cualquier evento del Auto Scaling Group, esta no estará actualizada.

Podemos pensar que es buena idea añadir una actualización en el proceso de arranque de una nueva instancia, pero esto puede provocar que las versiones utilizadas no sean iguales en todas las instancias. Esto puede llegar a ser un gran problema, además de que añadiremos tiempo desde que se detecta un evento de autoescalado hasta que la instancia esté activa.

Entonces llegamos a un punto en el que no podemos actualizar nuestras instancias dentro Auto Scaling Groups, lo cual no es muy buena idea. Y aquí es donde entra EC2 Image Builder para ayudarnos.

¿Qué es EC2 Image Builder?

EC2 Image Builder es un servicio gestionado de AWS que nos permite construir imágenes custom en AWS de forma sencilla y totalmente automatizada.

Inicialmente en AWS para generar una imagen custom se hacía levantando una instancia EC2 y ejecutando nuestra customización. También era posible añadir esta customización en el arranque de nuestras instancias, pero ninguna de las opciones eran muy eficientes en el caso de Auto Scaling Groups. Por este motivo, se lanzó este servicio, que nos permite generar la imagen de forma automática.

Básicamente, el servicio genera una instancia de EC2, ejecuta las automatizaciones que nosotros le digamos y genera una nueva imagen o AMI (Amazon Machine Image).

Es un servicio totalmente gratuito, que únicamente factura los servicios de AWS utilizados, ya que nos levantará una instancia temporal para generar la AMI y generará el storage de la propia AMI.

Este servicio tiene muchas utilidades, pero en la que nos vamos a centrar es en cómo actualizar nuestras Imágenes de un Auto Scaling Group. Podríamos utilizarlo para muchas más cosas.

Now Go Build

Como con Patch Manager, la mejor forma de ver cómo de sencillo es este servicio, es ponernos a desplegarlo, por eso vamos a ver cómo utilizamos EC2 Image Builder para generar y mantener actualizada una AMI de Amazon Linux 2023.

EC2 Image Builder Component

Lo primero que necesitamos es EC2 Image Builder Component. Un Component es una automatización que usa AWSTOE (AWS Task Orchestrator and Executor) de forma que definiendo un YAML muy sencillo podemos generar cualquier automatización para instalar componentes, actualizarlos o, básicamente, cualquier acción que ocurra dentro de un servidor.

Existen Components ya generados por AWS y hay dos bastante interesantes para nuestro caso de uso llamados update-linux y update-windows que serían perfectos si no quisiéramos excluir algún parche, ya que parchean la instancia al último nivel. Pero en este caso vamos a querer tener la posibilidad de excluir algún parche específico.

Por este motivo vamos a ver cómo generar un Component:

• Hay dos tipos de Component, en este caso vamos a generar un Component de tipo Build.

• Tenemos que definir el tipo de Sistema Operativo y las versiones elegidas, Por ejemplo, podemos crear un Component válido para todas las versiones soportadas de Linux. Y además definir una versión para nuestro Component, ya que podemos actualizarlo a futuro.

• La última parte es definir la configuración de nuestro Component.

• Es un lenguaje muy sencillo y que permite muchas acciones, en nuestro caso vamos a usar UpdateOS, que nos permite actualizar el Sistema Operativo. Simplemente, tenemos que definir las fases, siendo Build la única que necesitamos en este caso (podemos definir una de Test si quisiéramos) y la acción que queremos ejecutar en ese step. Vamos a definir una exclusión de los parches del Kernel, pero podríamos definir cualquier otra.

En el ejemplo, estamos utilizando la acción UpdateOS, pero podríamos añadir más acciones para customizar, utilizando otras acciones como ExecuteBash o ExecutePowerShell para ejecutar un script de Bastionado, por ejemplo.

EC2 Image Builder Recipe

Una vez que tenemos un Component tenemos que generar un recipe o receta, para generar nuestra AMI.

Este recurso básicamente es el que define qué va a tener nuestra AMI y qué Components vamos a ejecutar.

Igual que en caso anterior tenemos que definir un nombre y versión:

Y en este caso definir el Sistema Operativo a utilizar y la versión:

Si queremos utilizar múltiples versiones o múltiples Sistemas Operativos, tenemos que generar múltiples recipes, una por cada AMI que vayamos a generar.

Adicionalmente, podemos definir la configuración de la instancia e incluso añadir un script en el arranque automático:

Aquí elegimos los Components a instalar, en nuestro caso vamos a elegir el que hemos generado:

También definimos el tamaño del storage de nuestra Imagen:

De esta forma ya tenemos configurado nuestro recipe con todos lo que requerimos.

EC2 Image Builder pipelines

El último componente de EC2 Image Builder es el principal, que es la propia pipeline para la generación de las imágenes y que permite generarlas de forma automática.

Como en los recursos anteriores definimos los parámetros generales:

EC2 Image Builder tiene integración con Amazon Inspector de forma que se puedan analizar las vulnerabilidades de nuestras imágenes generadas para solventarlas.

Definimos el calendario de ejecución de esta pipeline. En nuestro caso, vamos a usar una expresión de Cron, aunque podríamos generarlo de forma manual e invocar por otros medios (EventBridge, por ejemplo):

Y definimos qué recipe vamos a utilizar.

Se puede definir la infraestructura a utilizar, en nuestro caso vamos a utilizar la configuración estándar:

Además, podemos configurar ciertas opciones como la región utilizada, KMS, el nombre de AMI, compartir la AMI, etc.

Incluso podemos llegar a definir una Launch Template Configuration asociada a esta pipeline.

Y con estos pasos ya tenemos nuestra pipeline y podemos ejecutarla:

La pipeline genera una instancia para ejecutar los pasos y crear la AMI:

El proceso consta de varios pasos, que incluyen la creación de la AMI y el borrado del entorno generado:

En total, en este caso ha tardado 5 minutos en ejecutar todos los pasos, dependiendo del número de customizaciones que ejecutemos tardará más o menos.

Una vez terminado el proceso tendremos una AMI válida que podremos utilizar perfectamente:

Casos de uso

Hay múltiples arquitecturas para realizar este proceso e incluso podemos generar una pipeline que realice todas las tareas. Realmente esta sería la mejor alternativa, de forma que podamos ejecutar todo el proceso de forma totalmente automatizada. Pero, por ejemplo, podemos generar una arquitectura que responda a los eventos de EC2 Image Builder. De esta forma se generaría la imagen, basándose en la pipeline de EC2 Image Builder y, que una vez terminada, se invocará a una Lambda desde SNS (que se integra con EC2 Image Builder), y capture los datos de la AMI generada para actualizar Parameter Store.

Este método permite referenciar este parámetro en nuestras plantillas de IaC para generar nuevas versiones de nuestro Launch Template con la nueva AMI y lanzar una actualización de nuestros AutoScaling Groups.

Esto podemos realizarlo de múltiples maneras. Bien utilizando IaC, bien utilizando la opción de Instance Refresh para AutoScaling Groups o generando una pipeline para el refresco de nuestra infraestructura. Incluso podemos llegar a lanzar estas actualizaciones cuando se genera la AMI, ya que la integración con SNS puede integrarse con múltiples servicios de AWS.

EC2 Image Builder es una herramienta muy útil no solo para el parcheo, sino también para generar AMIs de forma automatizada y que permite integrarse con otros sistemas para automatizar también el despliegue de estas nuevas AMIs.

Además del caso de uso que hemos visto para Patch Manager, EC2 Image Builder nos da muchas oportunidades, ya que podemos generar imágenes con customizaciones propias, o con un Harden propio que generemos.

También podemos generar imágenes con la instalación de ciertas aplicaciones que utilicemos y que requieran configuraciones propias, de esta forma podemos homogeneizar entornos y además ganar agilidad a la hora de desplegarlos.

Por otro lado, al generar AMIs podemos compartir estas AMIs con diferentes cuentas y utilizando otros servicios como Parameter Store o incluso DynamoDB podemos tener las referencias de la última versión de la AMI para que los proyectos utilicen la última versión de nuestras diferentes AMIs.

Una opción es centralizar la generación de AMIs en una única cuenta y compartirlos a nivel organizacional, OU o a cuentas determinadas y así aprovecharnos en múltiples proyectos de esta funcionalidad.

Conclusión

Podemos utilizar EC2 Image Builder de diferentes formas: integrándose en nuestro pipeline de despliegue para actualizar las imágenes o podemos generar una centralización para disponibilizar las imágenes en diferentes cuentas.

El servicio nos permite tanto el parcheado de imágenes como el caso de uso que hemos usado, pero podemos utilizarlo para diferentes propósitos tales como un Hardening o preparar imágenes custom con nuestros aplicativos.

Teniendo en cuenta que este servicio es gratuito, ahorra mucho tiempo y es bastante sencillo de utilizar. Es altamente recomendable utilizarlo, así que si no lo estáis usando, os recomiendo aprovechad y empezad ahora.