Cómo mantener nuestros entornos al día con AWS System Manager.

En mis tiempos de SysAdmin había una cosa que me quitaba el sueño (literalmente) era mantener los sistemas actualizados. No era algo complicado, pero sí llevaba bastante tiempo y que tenía bastantes problemas:

• Se tenía que realizar fuera de horario (de ahí que me quitara el sueño).
• Requería muchas pruebas en los entornos.
• Bajarse las actualizaciones llevaba tiempo (la capacidad de descarga era limitada).
• Era inusual tener acceso a internet desde los servidores.
• Montarse un repositorio privado requería mucho tiempo y revisar muy bien el tema de licenciamiento.
• Las herramientas que permiten algo de automatización eran muy caras.

Cuando llegué al mundo AWS y descubrí AWS Systems Manager, pensé en lo bien que me hubiese venido en mis vidas anteriores. Por eso hoy vamos a ver como utilizar AWS System

¿Qué es AWS System Manager?

AWS System Manager se define como un centro de operaciones para las aplicaciones y recursos en AWS, permitiendo la administración de nuestro entorno de forma automatizada.

Además, AWS System Manager permite tanto gestionar instancias dentro de AWS como servidores en On-Prem y tiene un montón de capacidades o subproductos que realizan diferentes labores.

Hay multitud de tareas de operaciones que pueden automatizarse desde System Manager, ya que permite ejecutar scripts dentro de las instancias, realizar inventario de las instancias y el software instalado, planificar ventanas de mantenimiento e incluso acceder a las instancias sin necesidad de utilizar SSH o RDP (utilizando IAM de AWS).

Nos vamos a centrar en AWS Systems Manager Patch Manager, que es la capacidad que nos permite automatizar la aplicación de parches en instancias EC2 o servidores en On-Prem. Es importante recordar que esta capacidad es gratuita y que gestionar nuestras instancias EC2 con AWS System Manager es gratuito (no todas las capacidades lo son) y gestionar instancias en On-Prem es gratuito para las primeras 1000 instancias por cuenta.

De esta forma, podemos automatizar el parcheado de forma sencilla y económica.

Arquitectura de Patch Manager

Una arquitectura típica en Patch Manager sería la siguiente, para actualizar instancias EC2 e instancias On-Prem desde Patch Manager.

Esta arquitectura cuenta con diferentes políticas de parcheados para diferentes entornos y con instancias híbridas.

De forma que cada política de parcheado puede tener diferentes ventanas, utilizar diferentes Patch Baselines, que dependen de la criticidad de los parches e incluso del tipo de parches (seguridad, Fixes, etc.).

Un ejemplo con esta arquitectura sería el siguiente:

• Lanzar el parcheo de las instancias del entorno de desarrollo un lunes por la tarde.
• Lanzar el parcheado de PreProducción el miércoles por la tarde
• Lanzar el parcheado de Producción en la madrugada del sábado al domingo.

De esta forma podríamos en una semana tener todas nuestras instancias al último nivel en menos de una semana, cuando este tipo de actualizaciones puede tardar meses.

No tendríamos afectación a los equipos de desarrollo, ya que las instancias estarían disponibles el día después de la aplicación y se podrían lanzar pruebas para validar los parches de forma que al llegar a Producción todo esté probado.

También podríamos lanzar parcheados de emergencia en caso de alguna vulnerabilidad grave detectada. Este caso de uso lo he tenido que utilizar por desgracia, pero nos permitió tener el entorno totalmente actualizado en menos de un día y afrontar una vulnerabilidad crítica de forma rapidísima.

Pero, realmente, ¿es tan sencillo de usar?

La mejor manera de verlo es analizar cómo desplegaríamos este servicio. Analizamos los pasos necesarios para ello:

Preparando los entornos

Lo primero que necesitamos es preparar los entornos para que puedan ser gestionados por AWS System Manager. Para esto es necesario que las instancias tengan instalado el agente de AWS System Manager. Por defecto, este agente viene preinstalado en diferentes AMIs proporcionadas por AWS como: Amazon Linux, Suse, Ubuntu, Windows Server, etc. Se puede consultar la lista en el siguiente link. Si no usamos una instancia que tenga instalado el agente, se puede instalar de forma manual en instancias Linux, Windows y Mac. Aunque mi recomendación es que en instancias EC2 utilicemos siempre que sea posible imágenes que tengan instalado el agente (nos ahorremos la instalación y algunos problemas adicionales).

Preparación en instancias EC2 en AWS

Antes de instalar el agente necesitamos tener un rol que permita a nuestras instancias utilizar AWS System Manager.

Para esto generamos una rol con una Trusted Policy para EC2.

Y le añadimos la política AmazonSSMManagedInstanceCore que es la que permite utilizar SSM.

Este rol es el que utilizaremos como instancia profesional en nuestras instancias EC2.

Adicionalmente, necesitamos que nuestros entornos tengan o bien conectividad con internet vía Nat Gateway o que tengan varios VPC Endpoints configurados para permitir el acceso a los endpoints de AWS System Manager:

• ssm
• ssmmessages
• ec2messages
• s3

El endpoint de S3 es necesario para que se puedan descargar los parches.

Preparación en instancias On-Prem fuera de AWS

Para los servidores fuera de AWS, es necesario generar otro rol con una Trusted Policy para System Manager.

La diferencia es que en el rol para EC2 dejamos que el rol se asuma desde el servicio de EC2, pero en este caso tenemos que dejar que el rol se asuma desde System Manager, ya que no podemos impersonarnos desde los servidores de On-Prem, pero el agente puede hacer de pasarela.

Y le añadimos la política AmazonSSMManagedInstanceCore que es la que permite utilizar SSM.

Y con este rol podemos generar una clave de activación híbrida para que System Manager pueda gestionar un grupo de servidores utilizando este rol. Esto se puede realizar desde la consola de AWS System Manager en Hybrid Activations:

Con el ID generado, nos proporcionará una clave de activación para añadir nuestras instancias On-Prem a SSM.

Para ello tenemos que instalar el agente de SSM dentro de nuestros servidores y activar el entorno híbrido utilizando la clave de activación. El procedimiento está descrito en este link.

Es necesario que los servidores tengan conectividad a AWS, esto se puede realizar vía internet con conectividad directa o incluso es posible utilizar un Proxy o en casos en los que se disponga de AWS Direct Connect utilizarlo para la interconectividad con este servicio.

Una vez registradas las instancias, estas podrán utilizar el rol que hemos generado de forma segura, ya que AWS las registra con la clave de activación.

Revisando que las instancias estén correctamente registradas

Dentro de Fleet Manager podemos observar las instancias que tienen el agente instalado y están registradas en AWS System Manager:

En este caso vemos 2 instancias, una instancia EC2, que empieza por i-xxxxxx y una instancia gestionada con el formato de Instance Id mi-xxxxxx (Esta instancia es una Servidor registrado desde fuera de AWS).

Definiendo una Patch Baseline Custom (Opcional)

Una Patch Baseline es el nivel de parches que queremos aplicar, por defecto existen una serie de Patch Baseline generadas y gestionadas por AWS que permiten tener el último nivel de parches, pero en ciertos casos puede ser interesante desplegar una Patch Baseline Custom para tener más control.

Es más sencillo utilizar las Baselines por defecto, sobre todo cuando empezamos con este servicio, por lo que a no ser que tengáis muy claro las excepciones que vais a generar, mi recomendación es empezar a trabajar con este servicio utilizando las Default Patch Baselines y obviar esta parte de la configuración.

Este paso se tiene que realizar antes de generar la configuración de Patch Manager, para poder utilizar estas Patch Baselines Custom.

Para ello accedemos a la consola de Patch Manager al topic de Patch Baselines y generamos una:

• Primero, definimos el nombre y el Sistema Operativo de la Baseline (Cada tipo de Sistema Operativo tiene su propia Baseline).

• Después generamos las reglas para aprobar los parches:

De forma que podemos elegir a qué productos aplicamos (en Amazon Linux 2023 solo tenemos uno, pero en otros tipos de sistemas operativos podemos tener más).

Podemos seleccionar el nivel de severidad que queremos aprobar para nuestros parches y la clasificación, con esto generamos una BaseLine de parches que podemos autoaprobar directamente o que espere unos días para que podamos revisar los parches propuestos por nuestra base y poder aprobarlos o no.

En el caso de Windows además podemos generar Approval Rules para diferentes aplicaciones de Windows, como Active Directory, Exchange, Office, etc.

También podemos gestionar las excepciones para aprobar parches que no entren en nuestra Baseline o denegar parches específicos. Esto es interesante para aplicaciones legacy que no se pueden actualizar.

• Y, por último, podemos configurar fuentes adicionales de parches para que podamos utilizar otros repositorios como por ejemplo un repositorio privado de parches.

Una vez definidas las Baseline que vayamos a utilizar, podemos empezar con Patch Manager.

Generando la configuración de Patch Manager

Patch Manager tiene una utilidad bastante reciente que se llama Patch Policy (se lanzó a principios de 2023 y lo destacamos en nuestro post de novedades de enero).

Una Patch Policy no es más que una política que nos permite definir los grupos de parcheado, así como las ventanas de mantenimiento etc.

Antiguamente, esto se realizaba utilizando Patch Groups y era un poco más complejo.

Lo primero sería definir los parámetros de nuestra configuración:

Tenemos que especificar el tipo de operación: escaneamos e instalamos los parches y definimos diferentes periodos.

En este caso, le estamos indicando que nuestra política escaneara parches diariamente a la 1:00 UTC y que instalaremos los parches los sábados a las 2:10 UTC, este tipo de expresión es totalmente configurable. También le indicamos que reinicie si fuese necesario.

También podemos definir la Baseline, en este caso utilizamos la por defecto:

Podríamos utilizar la Custom Patch Baseline que hemos generado:

Es posible almacenar los logs en un bucket de nuestra elección:

Elegiremos el target.

En una cuenta que administre la organización podremos elegir toda la organización, o diferentes OUs, pero aplicará a todas las instancias EC2.

En el caso de elegir la propia cuenta, podremos definir el target de forma más acotada.

Si optamos por la región en la que estamos desplegando esta Patch Policy, podemos elegir entre todos los nodos, un resource Group, un tag o elegir las instancias de forma manual.

Si optamos por elegir regiones (es posible elegir todas las regiones), solo podremos optar por todos los nodos o un tag.

Lo más óptimo en nuestro caso utilizar tags. En este caso utilizamos el tag Patch Manager con el valor pro, de forma que podemos generar varias Patch Policies para diferentes entornos.

Por último, podemos definir los límites para la concurrencia de parcheado y para marcar la policy como errónea si alguna actualización falla.

También es posible añadir las políticas a las instancias, por si se nos hubiese olvidado, pero recomiendo hacerlo de forma manual (o vía IaC preferiblemente).

Podemos ver el reporte que, inicialmente, nos indicará que no hay reporte de Compliance, básicamente porque todavía no se ha ejecutado.

Una vez ejecutado el reporte y aplicados los parches nuestro informe nos indicará si tenemos nuestro entorno parcheado al último nivel o si nos faltan parches:

Conclusiones

Como vemos, AWS System Manager es bastante sencillo de desplegar, podemos desplegarlo utilizando IaC tanto CloudFormation o Terraform. Es posible realizar políticas de parcheo dentro de una organización, pero si no queremos aplicarlo a todas las instancias, debemos usarlo cuenta a cuenta. Pero esto no es un problema, ya que vía IaC podemos desplegar Patch Manager como parte de nuestra BaseLine al desplegar cuentas si utilizamos nuestra propia Landing Zone o utilizando las customizaciones de Control Tower. Lo que implicaría que podemos añadir estas Patch Policies de forma automática a cada nueva cuenta. De esta forma, solamente sería necesario que un proyecto utilizase las tags definidas para permitir el parcheo automático de sus instancias.

Además, como hemos visto, es posible utilizar entornos híbridos registrando y parcheando servidores fuera de AWS. Lo que nos da la posibilidad de utilizar esta funcionalidad fuera de AWS.

Y, como último punto, no es una herramienta que tenga coste adicional, lo cual es una ventaja competitiva increíble.

Realmente todo son ventajas, tendremos todos las instancias parcheadas de forma automática y sin coste.

¡Ojo! Porque en los grupos de Auto Escalado o Auto Scaling Group no funciona correctamente, ya que no podremos reiniciar las instancias después de instalar los parches. Esto ocasionará que en caso de reinicio, se lance una nueva instancia con la AMI sin actualizar. Pero esto tampoco es un problema porque existe otra herramienta para automatizar esos casos y de la que hablaremos en una segunda parte de este post …

Así que nos vemos en el siguiente post ;)