Parcheado de equipos con Patch Manager
Introducción a SSM
SSM son las siglas de Systems Manager, un conjunto de herramientas que nos facilitan la vida, no sólo para acceder a las máquinas a través de una consola virtual, sino también para la ejecución de comandos remotos, extraer registros de los equipos, y como no, aplicar actualizaciones.
Con la suite de programas de SSM se pueden actualizar no sólo instancias EC2, si no también equipos on-prem, así como máquinas virtuales, equipos on-the-edge (IoT) como raspberrys, etc.
Systems Manager es un servicio que ejecuta un agente en el propio equipo (ec2 / on-prem, etc), del mismo modo que los agentes virtuales en entornos VMware, usados para extraer métricas de las instancias, pero en el caso de SSM la consola de gestión es remota, o lo que es lo mismo, se encuentra dividida en diferentes end-points. Es por ello por lo que el agente debe comunicarse con el servicio de SSM a través de red. Los equipos que quieran ser gestionados, deberán tener no sólo el agente instalado sino también conectividad de red para llegar a los endpoints de AWS SSM.
En este artículo hemos usado un par de instancias EC2 , una Linux y otra Windows:
Para la Linux hemos usado una AMI de RedHat, y en el caso del equipo Windows, se trata de la versión 2019.
Role para SSM
Para que el equipo pueda comunicarse con SSM, es necesario disponer de un role. Por ello vamos a generar un “service role” nuevo, accediendo al apartado IAM y seleccionado la opción “Roles” y clicando en el botón “Create role”:
Seleccionamos como “Trusted entity” el “AWS Service”, y abajo en el apartado “Use case”, el servicio EC2. Seleccionamos siguiente y añadimos las políticas que son necesarias:
Para ello introducir en la casilla de búsqueda el nombre “ssm”, y escoger entre las opciones que aparecen la “AmazonSSMManagedInstanceCore”
Asignamos el nombre que deseemos y nos aseguramos de que en el apartado de “trusted entities”, el valor de “principal” seleccionado es el servicio “ec2.amazonaws.com”, servicio con el que se va a invocar este role y al que estamos dando permiso:
El siguiente paso será añadir este role a las instancias. El modo más sencillo será marcar desde el panel la instancia a modificar, tal como se muestra en la imagen.
En el desplegable asignarle el role que acabamos de crear.
Instancias EC2 / managed nodes
En nuestro caso, hemos desplegado un equipo RedHat para la variedad Linux por un motivo: Las AMI’s oficiales distribuidas por RedHat no llevan incorporado el agente, así como sí lo llevan las AMI’s de Windows distribuidas por Microsoft, o las AMI’s de Amazon Linux.
En caso de que nuestra distribución no tenga agente, se puede instalar manualmente. Revisar el enlace siguiente para ver qué distribuciones están soportadas:
https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html
En el caso de RedHat procederemos a instalarlo con un comando como el siguiente:
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
Hay también disponibles binarios para la instalación de los agentes para entornos Windows o MacOS.
Fleet Manager
Ahora que ya tenemos los equipos con el agente de SSM instalado y con el “service role” asociado, podríamos acceder al apartado de “fleet manager”, lugar donde se visualiza a modo de registro los equipos gestionados con SSM, tanto equipos EC2, como equipos on-prem, etc. Esta herramienta está dentro de las opciones de SSM:
Los equipos gestionados a través de SSM, reciben el nombre de nodos, es por ello por lo que, en la vista de este servicio, los equipos registrados se identifican en la columna de “Node Id”:
Los equipos que aparecen son los que están registrados en la región actual. Tener en cuenta que AWS SSM es un servicio regional, eso quiere decir que si tenemos una cuenta en varias regiones, será necesario repetir el proceso descrito en este artículo para cada región de manera independiente.
Como todo software, el agente de SSM recibe constantes mejoras. Es por ello recomendable habilitar en el apartado “settings”, la actualización automática:
Baselines
Las “baselines” son manifiestos que definen un determinado nivel de cumplimiento con una política de seguridad. En el servicio de “patch manager” existen diferentes “baselines”, pero es muy recomendable crear propia una con las configuraciones que nos interese. Es un proceso realmente sencillo.
Para acceder al apartado de las “baselines”, ir a “Node Management” y seleccionar la opción “Patch Manager”:
Y en la pantalla que aparece acceder al botón “View predifined baselines”
En la vista de “baselines”, aparecen muchísimas, cada una para un sistema operativo diferente. Es en este momento cuando vamos a crear una personalizada. Para ello clicar sobre el botón “Create patch baseline”
En el nuevo apartado, seleccionar un nombre y una familia de SO que va a estar asociada a la “baseline”:
Definir la versión del SO, así como otros aspectos que definirán el nivel de cumplimiento:
Hay opciones como el “auto approval”, que permiten aprobar la instalación de una determinada actualización, al cabo de unos días de su publicación, o a partir de una determinada fecha, evitando así que parches día 0, no muy testeados, pudieran romper la estabilidad de los equipos. Incluso esto permitiría tener equipos de PRE o TEST donde instalar parches días antes que en los equipos de producción a modo de “canary testing”.
Igual de importante es el apartado de excepciones de paquetes. Con ello se evita la instalación de determinados paquetes que pueden romper el servicio (sistemas con kernels compilados a mano, paquetes Windows que no se llevan bien con algún otro programa de terceros, etc).
Para añadir excepciones debe usarse el siguiente formato:
En este momento ya tenemos una “baseline” propia. Cuando las “baselines” son propias, para encontrarlas luego, hay que especificar que el propietario somos nosotros. Para ello en el buscador de baselines, especificar “Owner: Self” tal como se muestra a continuación:
De lo contrario la vista por defecto sólo muestra “baselines” estándar provisionadas por AWS.
Patch groups
Una vez tenemos definidas las “baselines”, vamos a definir los “patch groups”. Un “patch group” establece la relación entre las “baselines” y los equipos sobre los que se van a aplicar, en función del valor de un tag que especificaremos más tarde en los equipos.
Para crear un “patch group”, es muy sencillo, sólo tenemos que seleccionar la “baseline” que acabamos de crear, desplegamos el menú “Actions” y seleccionamos la opción “Modify patch groups”
Se abrirá un apartado para generar los patch groups, introduciendo un nombre. En nuestro caso “Windows_Production”
Una vez introducido el nombre, fijándonos en respetar la nomenclatura, clicamos en el botón “Add” y cerramos el asistente.
Tags
Los tags son metadatos que nos ayudan a identificar a quien pertenece un recurso, una unidad de imputación de costes, etc. En este caso, con los tags también podemos asociar los nodos a los “patch groups” correspondientes. Para ello se usa siempre el mismo valor de tag “Patch Group”. Ojo! Es “case sensitive”
Vamos al apartado de las instancias, seleccionamos una de ellas, y editamos el apartado de tags para añadir el de “Patch Group”:
Si al introducir el tag, nos encontráramos con un error de tipo “’Patch Group’ is not a valid tag key.”
Es necesario deshabilitar la check box de metadata tagging en la configuración de la instancia:
Dejar la casilla siguiente deseleccionada y volver a probar a añadir el tag en el equipo.
Maintainance Windows
Recapitulemos. En este momento ya tenemos la instancia con el agente de SSM instalado y el role para interactuar con el servicio. Hemos creado una “baseline” propia, y luego la hemos asignado a unos “patch groups”. Finalmente hemos “tageado” las instancias con un tag que apunta directamente al “pach group” que nos interesa.
Las ventanas de mantenimiento son un apartado importante porque no sólo contiene la calendarización de las actualizaciones, sino también el listado de ejecuciones.
Vamos a proceder creando una ventana de mantenimiento a través del siguiente apartado:
Debemos introducir el nombre para la ventana, y fijar el cron. Se pueden establecer expresiones de cron con la nomenclatura típica o bien seleccionando las preestablecidas de cada hora o cada día.
Los valores de “Duration” y “Stop initiating task”, son obligatorios, y es recomendable dejarlos con unos valores como los siguientes:
Finalmente escoger zona horaria para hacer coincidir los horarios de la ventana con la que nos interese.
Al terminar tendremos un listado de las ventanas programadas, y datos interesantes como su próxima ejecución:
Configuración del parcheado
En este momento vamos a realizar el proceso que aglutina todos los pasos anteriores, y que capacita a “patch manager” para realizar las actualizaciones de los sistemas. Para ello acceder al apartado de “Patch Manager” y clicar en “Configure Patching”
Escoger los “patch groups” que se quieran actualizar:
Escoger la ventana de mantenimiento que se ha creado en el paso anterior:
Y dejar la operación que más se ajuste a lo que queremos hacer. En este caso vamos a escoger “Scan and Install”
En este momento, en el “dashboard” de de “Patch Manager”, deberíamos tener una vista de equipos pendientes de actualizar. Los valores en este apartado irán cambiando en función de si hay paquetes pendientes, fallos en las actualizaciones, etc.
Para poder realizar un seguimiento de las acciones realizadas, las podemos consultar en el “Run Command”
En este apartado hay dos pestañas. Una con los comandos en ejecución en este momento, que saldrán con un reloj al lado:
Y otra pestaña con el histórico de acciones:
Si en el proceso de instalación de actualizaciones, hay algún paquete marcado como reinicio necesario, el equipo se reiniciará inmediatamente. Tener esto en cuenta para establecer las ventanas de acuerdo con las necesidades del negocio:
Tras la instalación de los parches, y los reinicios en caso de haberlos, en el “dashboard” de “Patch Manager” saldrán ahora las instancias como conformes de acuerdo a las “baselines” establecidas:
Cloudwatch
En la consola del histórico de comandos, podemos ver las tareas ejecutadas, como en este caso. Si clicamos sobre el id de la tarea, podemos acceder a su detalle:
Dentro podemos ver los equipos sobre los que se ha ejecutado la acción, y podemos , seleccionando uno de esos equipos, ver el detalle de las operaciones. Para ello seleccionar y clicar sobre el botón “View output”
Las operaciones van probando todas las plataformas, por ello primero intentarán ejecutar el parcheado sobre un Windows, luego sobre un Linux y finalmente sobre un MacOS. Por ello para ver el estado de las actualizaciones, escogemos la plataforma del equipo que estamos consultando.
En la ventana “Output” veremos el registro, pero a menudo este se trunca por ser excesivamente largo:
Si queremos consultar esos datos podemos enviarlo a un “log group” de Cloudwatch. Para ello, primero vamos a CloudWatch y creamos un “log group”:
Ponemos un nombre y especificamos el periodo de retención.
El segundo paso es modificar el role de la máquina para que tenga permisos para escribir en Cloudwatch, por ello habrá que añadir una “in-line policy” como esta:
Le ponemos un nombre a esta “policy” y la guardamos:
Quedando el role del equipo como:
Volvemos a system manager, apartado “Mantainance Window” y dentro de las tareas (marco la tarea y selecciono edit):
Y en el apartado “Output Options” , escribir el nombre del log group a donde lo vamos a enviar:
Guardamos los cambios, y a partir de ahora al seleccionar el output de las tareas, veremos que nos aparece un enlace hacia Cloudwatch:
Y si consultamos ese enlace, nos llevará a la información de salida, pero ya sin truncar:
Desde Geko Consultoría Cloud, esperamos que este post te haya gustado y sobre todo que te resulte útil.
Te invitamos a que si necesitas información sobre el mundo Cloud y DevOps, nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles.
