Slack recuerda su transición a la v2 de IMDS (servicio de metadatos de instancia), operado con la ayuda de herramientas de AWS… y tecnologías internas.
¿Quién no ha migrado todavía a IMDSv2? Durante el año pasado, las iniciativas se han acelerado en AWS para fomentar las actualizaciones de versiones. Slack es una de las empresas que ha finalizado el proceso. Su equipo de Cloud Foundations informó recientemente sobre esto sobre esto .
IMDS (Servicio de metadatos instantáneos) proporciona acceso a información de configuración estática y dinámica. Adjunto localmente a cada instancia, se expone a través de una dirección IP específica (169.254.169.254 o fd00:ec2::254).
La versión original de IMDS utiliza un método de solicitud/respuesta, sin ninguna autenticación o verificación especial. Por lo tanto, deja la puerta abierta, entre otras cosas, a ataques a través de aplicaciones vulnerables.
v2, lanzado en 2019, cierra la brecha utilizando un método orientado a sesiones (recuperación de un token mediante solicitud PUT, luego uso de este token en solicitudes GET).
Si IMDSv1 sigue siendo compatible, AWS impulsa v2. Amazon Linux 2023, por ejemplo, lo usa de forma predeterminada. Lo mismo durante varias semanas para todos los lanzamientos realizados en la consola con AMI de inicio rápido. En febrero de 2024, una función API debería permitir controlar el uso de la v1 a nivel de cuenta. Luego, a partir de mediados de 2024, los nuevos tipos de instancias solo admitirán IMDSv2 de forma predeterminada.
Herramientas hechas en AWS…
Para migrar, Slack utilizó algunas de las herramientas que AWS pone a disposición . Tiene tecnologías internas acopladas.
La empresa tiene cuentas de AWS por entorno ( sandbox , dev, prod) y por equipo… así como, en ocasiones, por aplicación. Todos son miembros de una organización raíz. Cuando crea uno, la información se escribe en una tabla de DynamoDB a la que puede acceder una API interna llamada Archipelago.
Antes de migrar, era necesario determinar cuántas instancias usaban IMDSv1. Aquí utilizamos el método recomendado: la métrica CloudWatch MetadataNoToken. Una aplicación interna (imds-cw-metric-collector) asocia estos elementos con ID de instancia, llama a servicios de aprovisionamiento para recopilar información como ID de propietario y roles de Chef (para instancias configuradas de esta manera) y luego envía todo a un panel de Prometheus . Sobre esta base los equipos están trabajando en la migración a IMDSv2.
Para comprender qué procesos dentro de las instancias realizaban llamadas IMDSv1, Slack utilizó ImdsPacketAnalyzer , una herramienta de registro de código abierto creada en AWS. Lo empaquetó en .deb y lo integró en su repositorio APT, para que sus equipos pudieran instalarlo bajo demanda (la mayoría de los casos usan Ubuntu o Amazon Linux).
Para los casos basados en una versión antigua de Ubuntu (18.04 en este caso), era necesario utilizar herramientas de terceros como lsof y netlogs.
…y desarrollos internos
Según lo recomendado por AWS, Slack primero actualizó sus scripts bash, CLI y SDK a versiones compatibles con IMDSv2.
Luego, la empresa recurrió a su principal herramienta de aprovisionamiento: Terraform. Para facilitar los cambios, sus equipos utilizan módulos compartidos. Problema: para la migración de IMDS, no queríamos aplicar los cambios a todas las cuentas al mismo tiempo. Solución adoptada: filtrado mediante un módulo anidado (accounts_using_imdsv1).
Para evitar que las instancias se inicien con IMDSv1, Slack ha actualizado sus SCP (políticas de control de servicios). Aquí también, filtrando con su módulo Terraform.
Sin embargo, los SCP no funcionaron en todas partes. En particular, no se aplicaban a la cuenta raíz. Tampoco a roles vinculados a un servicio (las VM que lanza el servicio de autoescalado escapan de los SCP por ejemplo).
Asimismo, Slack no pudo evitar que sus equipos crearan plantillas de lanzamiento que no obligaran al uso de IMDSv2.
Al no poder evitar al 100% el lanzamiento de instancias en v1, se implementó un sistema de notificación que utiliza EventBridge y Lambda. Una regla captura solicitudes a la API de EC2 ; el otro capta las respuestas. Los eventos correspondientes a IMDSv1 están centralizados en un bus y asociados a una función Lambda. Esto utiliza el ID de la cuenta y la API de Archipelago para enviar una notificación de Slack al equipo correspondiente. Existe un modelo similar para controlar la activación de IMDSv1 en instancias existentes.
Para eliminar IMDSv1 en instancias existentes, Slack implementó un servicio específico en EKS y lo asoció con una función con privilegios restringidos (los autenticadores se obtienen a través de un proveedor OIDC ). También utiliza Archipelago para analizar instancias y forzar la activación de IMDSv2 si es necesario. Edicion Silicon desde Francia; traducido.
Ilustración principal © metamorworks – Adobe Stock
Contacto