systemd 261: qué cambia para DevOps, seguridad y cloud en Linux

Introducción

Hasta ahora, los equipos de DevOps y SRE que gestionaban instancias en la nube dependían de herramientas externas —como cloud-init o scripts personalizados— para extraer metadatos de la plataforma (como el ID de instancia en AWS EC2 o el instance profile en Azure). Con systemd 261, lanzado en junio de 2025, esto cambia: ahora el init system incluye un subsistema nativo de metadatos en la nube integrado directamente en el daemon de systemd.

Pero no solo eso. La versión 261 también introduce un TPM virtual para sistemas sin hardware dedicado, un instalador de sistema basado en texto (reemplazando herramientas gráficas), y mejoras en el manejo de estado durante reinicios con kexec. Para equipos que operan flotas de servidores Linux —desde entornos bare metal hasta cloud—, estas novedades pueden simplificar flujos de trabajo, reducir dependencias externas y hasta mejorar la postura de seguridad.

En este artículo, desglosamos:

• Qué funciones nuevas trae systemd 261 y por qué importan a DevOps y seguridad.
• Cómo afectan a entornos cloud específicos (AWS, Azure, GCP, etc.).
• Pasos concretos para adoptar estos cambios sin romper pipelines existentes.

Qué ocurrió

El release systemd 261 (publicado el 17 de junio de 2025) es una versión de «integración y consolidación», según el anuncio oficial. No es un parche de seguridad crítico, pero introduce cambios arquitectónicos que impactan en:

1. Gestión de metadatos en la nube: Un nuevo daemon, systemd-imdsd, expone una API local (Varlink) para que los servicios consuman datos de instancias (como el instance ID o availability zone).
2. Soporte para kexec con preservación de estado: Los servicios pueden mantener sus file descriptors y configuraciones entre reinicios con kexec, útil para actualizaciones sin downtime.
3. TPM virtual: Un servicio llamado systemd-tpm2-swtpm.service permite emular un TPM 2.0 usando la herramienta swtpm de IBM, evitando depender de hardware físico.
4. Instalador de sistema basado en texto: systemd-sysinstall reemplaza herramientas como Calamares o Anaconda en distribuciones minimalistas, utilizando llamadas Varlink a systemd-repart, bootctl y systemd-creds.

Además, se removió soporte para la versión 0 de la base de datos de udev, lo que obliga a actualizar desde sistemas con systemd anteriores a v247 (lanzado en 2022). También se renombró la opción --user= de systemd-nspawn a --uid= para alinearse con estándares POSIX.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

Antes, los equipos debían instalar paquetes como aws-cli o usar scripts con curl para obtener datos de metadatos de instancias. Con systemd-imdsd, ahora pueden consumir estos datos directamente desde un endpoint local /run/systemd/imds.sock via Varlink. Por ejemplo:

$ systemd-imds get instance-id
i-0abcdef123456789

Los clouds soportados incluyen AWS EC2, Microsoft Azure, Google Compute Engine, Hetzner, Oracle Cloud, Scaleway, Tencent Cloud, Alibaba ECS y Vultr. La lista se define en un archivo JSON dentro del paquete (/usr/lib/systemd/imds/clouds.json), que mapea SMBIOS a endpoints de metadatos.

El soporte para FileDescriptorStorePreserve=yes en servicios permite que unidades de systemd retengan sus file descriptors (como sockets Unix o pipes) durante un reinicio con kexec. Esto es clave para:

• Actualizaciones hot-reload de servicios sin perder conexiones activas.
• Contenedores systemd-nspawn que necesitan mantener estado entre sesiones.

Reemplaza herramientas gráficas por un instalador de línea de comandos que usa Varlink para interactuar con:

• systemd-repart (gestión de particiones).
• bootctl (gestión de bootloaders).
• systemd-creds (gestión de credenciales en tiempo de arranque).

Para equipos de Seguridad

El servicio systemd-tpm2-swtpm.service lanza un TPM 2.0 emulado usando swtpm (IBM), útil para:

• Sistemas en cloud que no exponen un TPM físico (ej: instancias de AWS EC2 Gen1).
• Entornos de desarrollo o CI/CD donde no se quiere depender de hardware.

La opción ConditionSecurity=measured-os verifica si el sistema arrancó con measured boot (medición de arranque), integrándose con TPM 2.0 para almacenar hashes de componentes en el PCR (Platform Configuration Register).

• Reduce costos al eliminar la necesidad de TPM físico en entornos no críticos.
• Permite implementar measured boot en sistemas cloud donde antes era imposible. Según IBM, swtpm tiene un 0.1% de overhead en rendimiento vs. un TPM físico (fuente).

• Recuperación de contraseñas de disco cifrado (LUKS).
• Escenarios de rollback a kernels anteriores.

Detalles técnicos

Subsistema de metadatos cloud (systemd-imds)

• systemd-imdsd: Daemon que expone una API Varlink en /run/systemd/imds.sock.
• systemd-imds: Cliente CLI para consultar metadatos.
• Archivo de configuración /usr/lib/systemd/imds/clouds.json que mapea SMBIOS a endpoints:

  {
    "aws": {
      "smbios": ["Amazon EC2", "amazon"],
      "endpoint": "http://169.254.169.254/latest/meta-data/"
    },
    "azure": {
      "smbios": ["Microsoft Corporation", "Virtual Machine"],
      "endpoint": "http://169.254.169.254/metadata/instance"
    }
  }
  

• El daemon systemd-imdsd solo acepta conexiones locales por defecto. Para restringir aún más, se puede compilar con --disable-imds-network y usar un firewall (ej: nftables):

  nft add rule ip filter INPUT iif lo accept
  nft add rule ip filter INPUT tcp dport 5355 drop
  

• Los metadatos importados se miden (hash SHA-256) antes de almacenarse en variables de entorno o credenciales de systemd.

• Afecta a sistemas con systemd >= 261 y kernels >= 5.15 (necesario para soporte de Varlink en el espacio de usuario).
• Distribuciones como Ubuntu 24.04 LTS, Fedora 40, y RHEL 10 (en desarrollo) incluirán este paquete en sus repositorios oficiales.

Soporte para kexec y preservación de estado

• El kernel debe soportar Live Update Orchestration (LSM en kernels >= 5.19) y Kexec Handover (documentado en kernel.org).
• Los servicios deben configurar FileDescriptorStorePreserve=yes en su unidad:

  [Service]
  FileDescriptorStorePreserve=yes
  ExecStart=/usr/bin/my-service
  

1. Un servicio abre un socket Unix:

   int sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
   bind(sockfd, "/run/my-service/socket");
   

1. Al reiniciar con kexec, el descriptor sockfd se preserva y el servicio lo recupera automáticamente.

• Solo funciona con file descriptors soportados por el kernel (sockets, pipes, pero no archivos regulares).
• Requiere que el initramfs incluya systemd (caso típico en distribuciones modernas).

TPM virtual (systemd-tpm2-swtpm)

• swtpm >= 0.8.0 (versión mínima para soporte de TPM 2.0).
• Kernel con soporte para tpm y tpm_tis (habilitado por defecto en kernels >= 5.10).
• Opción de kernel systemd.tpm2-swtpm=1 para habilitar el servicio.

# /etc/systemd/system/systemd-tpm2-swtpm.service.d/override.conf
[Service]
ExecStart=/usr/bin/swtpm socket \
  --tpm2 \
  --server type=tcp,port=2321 \
  --ctrl type=tcp,port=2322 \
  --flags not-need-init

• El TPM virtual no reemplaza un TPM físico en entornos de alta seguridad (ej: HSM para firmas digitales).
• Para sistemas en cloud, se recomienda usar el TPM físico del proveedor (ej: AWS Nitro Enclaves o Azure Confidential VMs).

Instalador textual (systemd-sysinstall)

• Basado en Varlink para comunicarse con:

– bootctl: Configuración de bootloaders (GRUB, systemd-boot).

– systemd-creds: Almacenamiento seguro de credenciales (usando forward-secure sealing).

# Instalar Fedora en /dev/nvme0n1
systemd-sysinstall \
  --disk /dev/nvme0n1 \
  --partition esp:/boot/efi:size=512M \
  --partition root:/:fstype=btrfs \
  --user alice \
  --password-file /etc/secret/password.txt

• Fedora 41 (planificado para Q4 2025).
• Debian Testing (en evaluación).

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar systemd (pero con precaución)

1. Verificar la versión actual:

   systemd --version | head -n1
   # systemd 255 (255.4-1.fc40)
   

1. Actualizar según la distribución:

     apt update && apt install -t bookworm-backports systemd=261-*
     

– RHEL/Fedora:

     dnf upgrade systemd
     

1. Verificar compatibilidad con udev:

     dnf upgrade udev systemd --releasever=9  # En RHEL, migrar a RHEL 9+
     

2. Habilitar metadatos cloud (opcional pero recomendado)

1. Instalar el paquete systemd-imds:

   apt install systemd-imds  # Debian/Ubuntu
   dnf install systemd-imds  # RHEL/Fedora
   

1. Probar el endpoint local:

   systemd-imds get instance-id
   # i-0abcdef123456789
   

1. Restringir acceso:

   # Solo permitir conexiones locales
   nft add table inet imds_filter
   nft add chain inet imds_filter input { type filter hook input priority 0 \; }
   nft add rule inet imds_filter input iif lo accept
   nft add rule inet imds_filter input tcp dport {5355, 5356} drop
   

• El endpoint local ya está disponible en 169.254.169.254/metadata/instance, pero systemd-imds normaliza la respuesta:

  systemd-imds get placement/group-name
  # my-cluster-group
  

3. Probar kexec con preservación de estado

1. Instalar kexec-tools:

   apt install kexec-tools  # Debian/Ubuntu
   

1. Crear un servicio de prueba con FileDescriptorStorePreserve=yes:

   # /etc/systemd/system/test-preserve.service
   [Service]
   Type=simple
   ExecStart=/usr/bin/socat UNIX-LISTEN:/tmp/test.sock,fork EXEC:"/bin/cat"
   FileDescriptorStorePreserve=yes
   

1. Ejecutar kexec:

   kexec -l /boot/vmlinuz-$(uname -r) --initrd=/boot/initrd.img-$(uname -r) --append="console=ttyS0"
   systemctl kexec
   

1. Verificar que el socket persiste:

   ls -l /proc/$(pidof socat)/fd/
   

4. Evaluar TPM virtual (solo para entornos no críticos)

1. Instalar swtpm:

   apt install swtpm  # Debian/Ubuntu
   dnf install swtpm  # RHEL/Fedora
   

1. Habilitar el servicio:

   systemctl enable --now systemd-tpm2-swtpm.service
   

1. Verificar con tpm2-tools:

   tpm2_getrandom 8 > /dev/null
   tpm2_pcrread sha256:0
   

• No uses este TPM virtual para almacenar claves de cifrado en producción.
• Para sistemas en cloud, prioriza el TPM del proveedor (ej: AWS Nitro o Azure vTPM).

5. Migrar a systemd-sysinstall (si aplica)

1. Descargar la imagen ISO con soporte para systemd-sysinstall (ej: Fedora 41+).
2. Ejecutar el instalador:

   sudo systemd-sysinstall \
     --disk /dev/vda \
     --partition boot:/boot/efi:size=1G \
     --partition root:/:fstype=btrfs \
     --user admin \
     --password-file /root/password.txt
   

1. Verificar particiones:

   bootctl list
   lsblk -f
   

Conclusión

systemd 261 no es un release menor: introduce cambios arquitectónicos que pueden simplificar flujos de trabajo en DevOps, mejorar la seguridad con medición de arranque y TPM virtual, y reducir dependencias en herramientas externas. Para equipos que gestionan infraestructura Linux en cloud o bare metal, las novedades más valiosas son:

1. Metadatos cloud nativos: Elimina la necesidad de aws-cli o scripts personalizados para obtener datos de instancias, exponiendo una API local segura.
2. Preservación de estado con kexec: Ideal para actualizaciones sin downtime en clusters Kubernetes o servidores con alta disponibilidad.
3. TPM virtual: Útil para entornos donde no hay TPM físico, pero no para casos de alta seguridad.
4. Instalador textual: Simplifica instalaciones headless en servidores remotos.

• Actualicen a systemd 261 solo después de probar en un entorno de staging, especialmente si usan RHEL 8 o Ubuntu 22.04 (riesgo por remoción de soporte para udev v0).
• Para entornos cloud, evalúen migrar a systemd-imds para centralizar la gestión de metadatos.
• Si usan TPM, prioricen el hardware del proveedor (AWS Nitro, Azure vTPM) sobre la solución virtual, salvo que sea para desarrollo o entornos no críticos.

Fuentes

• Help Net Security: systemd 261 released
• Red Hat Security Updates
• OMG Ubuntu: systemd 261
• IBM swtpm GitHub
• Kernel.org: Kexec Handover
• systemd.io: systemd-imds