Fin de la vida útil de RHEL 8: fechas, riesgos y próximos pasos

Principales conclusiones

• RHEL 8 llegará al final de su ciclo de vida el 31 de mayo de 2029. A partir de esa fecha, Red Hat dejará de proporcionar parches de seguridad o correcciones de errores a menos que se adquiera un complemento de soporte ampliado de pago.
• Si sigues utilizando este sistema operativo más allá de 2029 sin un plan, dejarás de cumplir con las normas PCI DSS, HIPAA, SOC 2 y la mayoría de los demás marcos normativos que exigen la aplicación oportuna de parches.
• Las principales opciones son actualizar a RHEL 9, cambiar a una distribución compatible como AlmaLinux o Rocky, o adquirir soporte de ciclo de vida ampliado para ganar tiempo para la migración.
• El soporte ampliado de terceros —como el ELS de TuxCare — te permite mantener RHEL 8 actualizado con los parches necesarios tras el fin de su vida útil (EOL) sin necesidad de realizar una migración de emergencia, y cubre paquetes clave como el núcleo de Linux, OpenJDK, OpenSSL, Python y muchos más.

Si estás utilizando RHEL 8 en entorno de producción, ya has superado un hito: el soporte completo finalizó en mayo de 2024. Eso significa que ahora te encuentras en la fase de soporte de mantenimiento, que es más tranquila pero también más limitada: Red Hat corrige las vulnerabilidades CVE graves, pero no lleva a cabo ningún trabajo de desarrollo nuevo en la plataforma. La siguiente fecha importante es el 31 de mayo de 2029, cuando RHEL 8 llegue al final de su vida útil y los parches dejen de publicarse por completo.

Este artículo aborda lo que cada fase del ciclo de vida supone realmente para sus sistemas, a qué renuncia en cada transición, los riesgos reales de dejar que el año 2029 le pille desprevenido y las opciones disponibles, incluidas aquellas que no requieren una actualización radical para la que no ha previsto presupuesto.

¿Qué significa el fin del ciclo de vida de RHEL 8?

En el universo de Red Hat, el «fin de vida útil» no es una advertencia suave ni una sugerencia cortés para que te plantees actualizar. Es el momento en el que Red Hat deja de ofrecer novedades para esa versión principal. No hay parches para CVE, ni correcciones de errores, ni respuestas a los tickets de soporte. La versión pasa a lo que Red Hat denomina oficialmente la «fase de vida útil extendida», en la que aún se puede consultar la documentación y descargar los paquetes existentes, pero no se desarrolla nada nuevo.

Vale la pena ser precisos en cuanto a lo que ofrece realmente cada fase, ya que las diferencias son significativas:

• Fase de soporte completo: Red Hat ofrece todo: errata de seguridad, correcciones de errores urgentes y de alta prioridad, compatibilidad con nuevo hardware y mejoras de software seleccionadas en versiones menores. RHEL 8 se encontraba en esta fase desde mayo de 2019 hasta mayo de 2024.
• Fase de soporte técnico: Solo se publican avisos de seguridad críticos e importantes (RHSA) y correcciones urgentes de errores (RHBA). No hay soporte para nuevo hardware. No hay desarrollo de nuevas funciones. RHEL 8 estará disponible hasta el 31 de mayo de 2029.
• Fase de vida útil prolongada: Prácticamente obsoleta desde el punto de vista de las actualizaciones. Puedes consultar la documentación y acceder a los paquetes existentes, pero no recibirás nada nuevo a menos que hayas pagado por el complemento de soporte de ciclo de vida ampliado.

La consecuencia práctica: para cuando RHEL 8 llegue al final de su vida útil (EOL) en 2029, su kernel ya tendrá una década de antigüedad desde el punto de vista del desarrollo y no habrá recibido ninguna funcionalidad nueva desde 2024. Es mucho tiempo para que el panorama de amenazas evolucione mientras se interrumpen las actualizaciones.

Calendario del ciclo de vida del soporte técnico de RHEL 8

A continuación se muestra una comparación del ciclo de vida de RHEL 8 con el de otras versiones de Red Hat. El periodo de 10 años es el mismo para todas las versiones modernas de RHEL; lo que cambia es en qué punto de ese periodo te encuentras actualmente.

Si has utilizado RHEL 7 el tiempo suficiente como para sentir la presión de su fecha límite de 2024, la fecha límite de 2029 de RHEL 8 te resultará familiar: la misma presión por la migración, solo que pospuesta cinco años. La diferencia esta vez es que RHEL 9 está disponible para el público general desde 2022, por lo que el objetivo de actualización es estable y ha sido sometido a pruebas exhaustivas. La mayoría de los equipos han tenido años de margen. La brecha entre el fin del soporte de mantenimiento y el fin de la cobertura ELS. La brecha entre el fin del mantenimiento activo y el fin del soporte extendido es fácil de malinterpretar, pero independientemente del enfoque que se utilice, 2029 llegará, tenga o no el proyecto de migración un gestor de proyectos.

Por qué se retiran las versiones de RHEL

Comprender la lógica empresarial que subyace a las decisiones sobre el fin de la vida útil resulta útil a la hora de explicar la urgencia a las partes interesadas que, al ver que el plazo vence en 2029, dan por sentado que aún queda tiempo.

El ancho de banda técnico tiene sus límites

Red Hat mantiene cada versión principal activa con su propio equipo de mantenedores del núcleo, analistas de seguridad, procesos de control de calidad e ingenieros de soporte. Cada versión adicional para la que se ofrece soporte multiplica esa carga de trabajo. Llega un momento en que mantener actualizada una base de código con una década de antigüedad frente a las amenazas modernas cuesta más de lo que justifican los ingresos por suscripción de esa versión. Las cuentas acaban por no cuadrar, y Red Hat pone punto y final.

Los modelos de seguridad evolucionan

El panorama de amenazas en 2019 no se parece en nada al que se avecina de cara a 2029. Las medidas de mitigación, como un refuerzo más estricto del núcleo, la actualización de los valores predeterminados de criptografía y la mejora en la generación de políticas de SELinux, se incorporan en las versiones más recientes y, a menudo, no pueden retroportarse correctamente a una base de núcleo más antigua. Con el tiempo, aplicar parches a las versiones antiguas para cumplir con los requisitos de cumplimiento actuales se convierte en una tarea infructuosa, independientemente del esfuerzo de ingeniería que se dedique a ello.

Puede obtener más información sobre cómo la evolución de las plataformas afecta a su situación de vulnerabilidad en nuestra descripción general de los ciclos de vida de seguridad de Red Hat.

Las cargas de trabajo modernas requieren cadenas de herramientas modernas

Los entornos de ejecución de lenguajes más recientes, las herramientas de contenedores y los marcos nativos de la nube requieren cada vez más versiones más recientes de glibc, el núcleo y systemd. RHEL 8 incluye glibc 2.28 y el núcleo 4.18, que siguen siendo válidos para muchas cargas de trabajo, pero que suponen una limitación real si se trabaja con eBPF, entornos de ejecución de contenedores modernos o versiones recientes de Kubernetes. Los marcos de cumplimiento normativo y las herramientas de auditoría también tienden a dar por sentado el soporte de la plataforma actual a la hora de evaluar su entorno.

Riesgos de seguir utilizando RHEL 8 tras el fin de su ciclo de vida

Las vulnerabilidades CVE sin parchear se acumulan rápidamente

Una vez que Red Hat deje de publicar RHSAs para RHEL 8, cada CVE a nivel del núcleo o de los paquetes básicos que se revele se convertirá en una vulnerabilidad permanente en sus sistemas. No habrá ninguna corrección por parte del desarrollador original. El periodo posterior al fin de vida útil (EOL) de RHEL 7 es un buen ejemplo: a los pocos meses del EOL, los sistemas que no habían migrado o adquirido soporte extendido se encontraban ante una lista cada vez mayor de vulnerabilidades explotables conocidas sin ninguna vía de corrección. Los escáneres de vulnerabilidades las detectarán de inmediato y no habrá ninguna corrección disponible. Los auditores se darán cuenta antes que su equipo.

Según el informe «2025 Enterprise Linux & Open-Source Landscape Report» de TuxCare, el 40 % de las organizaciones encuestadas sufrió un incidente de ciberseguridad en los últimos 12 meses, y el 60 % de ellos estaba relacionado con la falta de aplicación de parches de seguridad.

Las certificaciones de cumplimiento empiezan a caducar

PCI DSS, HIPAA, SOC 2 Tipo II, ISO 27001, FedRAMP: todas estas normas exigen utilizar software que reciba parches de seguridad puntuales. En el momento en que RHEL 8 llegue al final de su ciclo de vida (EOL) sin un acuerdo de soporte ampliado, técnicamente dejarás de cumplir con la normativa. No se trata de un problema teórico: una empresa de SaaS de 40 personas que intente renovar un informe SOC 2 con versiones de sistema operativo sin soporte técnico en su ámbito de aplicación dedicará mucho tiempo a redactar controles compensatorios que los auditores no suelen aceptar como sustitutos adecuados de los parches reales.

El soporte técnico del proveedor para todo tu entorno se va reduciendo

Los proveedores independientes de software (ISV) —proveedores de bases de datos, de middleware y de herramientas de seguridad— vinculan sus matrices de soporte al ciclo de vida del sistema operativo subyacente. Cuando RHEL 8 deje de figurar en la lista de sistemas operativos compatibles de Red Hat, muchos de esos proveedores harán lo mismo. Un incidente en producción en una base de datos Oracle o una instancia de SAP que se ejecute en un sistema operativo sin soporte es un momento especialmente inoportuno para descubrir que tu contrato de soporte ya no es válido.

Los seguros cibernéticos se complican

Las aseguradoras se han vuelto más exigentes en este aspecto. En las solicitudes de cobertura de seguros cibernéticos ahora se pregunta de forma habitual por el software al final de su ciclo de vida (EOL) presente en su entorno, y las pólizas incluyen cada vez más cláusulas que anulan las reclamaciones por brechas de seguridad atribuibles a vulnerabilidades conocidas y sin parchear. El uso de software obsoleto del que se sabía que había llegado al final de su ciclo de vida (EOL) supone un riesgo de responsabilidad civil demostrable que las aseguradoras han comenzado a valorar en las primas o a rechazar en consecuencia.

Cuanto más esperes, más difícil será la actualización

A este aspecto no se le presta la atención que merece. Cada mes que se sigue utilizando RHEL 8 tras su fin de vida útil, la migración final resulta más costosa. Los nuevos empleados están menos familiarizados con herramientas obsoletas. La gestión de la configuración se aleja de lo documentado o de lo que se puede probar. Las actualizaciones de hardware se topan con problemas de compatibilidad de controladores cuando el firmware de las tarjetas de red o los controladores de almacenamiento más recientes no cuenta con compatibilidad certificada para RHEL 8. El sistema se vuelve más difícil de gestionar, más difícil de operar y más difícil de migrar, todo al mismo tiempo.

Opciones tras el fin de la vida útil de RHEL 8

El camino a seguir depende del volumen de trabajo que implique la actualización en la capa de aplicación, del tiempo de inactividad que puedas tolerar y de si tu equipo cuenta con el personal necesario para encargarse de un proyecto de migración en este momento. No hay una respuesta única, pero sí hay un conjunto de opciones realistas.

Opción 1: El servicio de asistencia técnica de ciclo de vida ilimitado (ELS) de TuxCare

Vale la pena conocer el servicio Endless Lifecycle Support (ELS) de TuxCare si no hay certeza de que la migración se pueda llevar a cabo sin problemas antes de mayo de 2029. TuxCare ya ofrece ELS para RHEL 7, proporcionando parches de vulnerabilidad de forma continua tras el fin del soporte de mantenimiento de Red Hat, y se espera que esta misma cobertura se extienda a RHEL 8 cuando este alcance su fin de vida útil (EOL). El servicio es independiente del modelo de suscripción de Red Hat, lo que significa que puede mantener las cargas de trabajo críticas de RHEL 8 actualizadas y listas para auditorías mientras su proyecto de migración avanza a un ritmo razonable, en lugar de a un ritmo acelerado y forzado.

Vale la pena saber qué cubre realmente el servicio ELS de RHEL de TuxCare a nivel de paquetes. El servicio ELS a nivel del sistema operativo no se limita al núcleo, sino que incluye paquetes de uso común como OpenJDK, Python, httpd, OpenSSL y OpenSSH, por lo que los componentes básicos de tu pila están cubiertos por la misma suscripción.

Opción 2: Actualización in situ a RHEL 9 mediante Leapp

La utilidad Leapp de Red Hat permite realizar actualizaciones directas de RHEL 8 a RHEL 9, y en un sistema limpio y bien mantenido funciona bien. Sin embargo, en un sistema que lleva en funcionamiento desde 2019 y que acumula personalizaciones, repositorios de terceros y módulos del núcleo que nadie ha documentado por completo, el resultado es menos satisfactorio.

Lo correcto es ejecutar leapp preupgrade En primer lugar, detecta los obstáculos antes de que te comprometas a nada. Dedica tiempo para resolver los obstáculos que encuentre, porque seguro que habrá algunos.

Consejo de experto: Antes de ejecutar «leapp upgrade», comprueba el /var/log/leapp/leapp-report.txt después de leapp preupgrade – No te limites a buscar «inhibidores». Los elementos de «alta» gravedad que no son inhibidores también te pueden dar problemas tras la actualización, sobre todo en lo que respecta a los módulos del núcleo de terceros y las configuraciones PAM personalizadas. Soluciona esos problemas antes de confirmar los cambios.

Opción 3: Reinstalación completa en RHEL 9 o RHEL 10

En el caso de las cargas de trabajo compatibles con contenedores o gestionadas mediante infraestructura como código, una reconstrucción paralela suele ser más limpia que una actualización in situ. Se obtiene una base de referencia nueva, sin artefactos de actualización, y una oportunidad natural para eliminar la deuda técnica que se ha ido acumulando desde 2019. Es más lento por host, pero más fiable a gran escala.

Opción 4: Cambiar a una distribución compatible con RHEL

AlmaLinux, Rocky Linux y Oracle Linux son alternativas binariamente compatibles que ejecutan los mismos paquetes y están certificadas para la mayoría de las mismas cargas de trabajo. AlmaLinux y Rocky son gratuitas; Oracle ofrece un nivel de soporte de pago. Esta opción resulta adecuada si tus herramientas consideran el sistema operativo como un producto básico y no tienes requisitos específicos de contrato de soporte con Red Hat. Comprueba las certificaciones de los proveedores de software independientes (ISV) antes de tomar una decisión: no todos los proveedores admiten oficialmente las alternativas, y algunos exigen específicamente RHEL.

Opción 5: El complemento ELS de Red Hat

Red Hat ofrece un complemento de soporte de ciclo de vida ampliado que prolonga la cobertura de seguridad limitada más allá de la fecha límite de mayo de 2029 hasta mayo de 2032. Es la opción más obvia si necesitas permanecer dentro del ecosistema de Red Hat y dispones del presupuesto necesario. La cobertura es considerablemente más limitada que la del soporte de mantenimiento —menos paquetes y solo las vulnerabilidades CVE de mayor gravedad—, por lo que se trata de una solución provisional, no de un sustituto a largo plazo de la actualización.

Cómo elegir:

• Si tus aplicaciones ya están certificadas para RHEL 9 y dispones de los recursos técnicos necesarios, simplemente utiliza Leapp y ponlo en marcha. Esa es la solución más adecuada para los entornos más sencillos.
• Si utilizas algún sistema ligado a un proveedor concreto —como Oracle DB, SAP o middleware antiguo que aún no haya sido certificado para RHEL 9—, conviene ser realista desde el principio en cuanto a los plazos. Los ciclos de certificación del software empresarial no avanzan rápido, y una migración que parece sencilla sobre el papel tiende a alargarse una vez que se tienen en cuenta los procesos de aprobación del proveedor, las pruebas y la autorización de los cambios. El soporte de ciclo de vida extendido existe precisamente para este tipo de situaciones: te da el margen necesario para hacerlo bien, en lugar de hacerlo bajo presión.
• Si te preocupa el coste y no necesitas un contrato de soporte de Red Hat, AlmaLinux o Rocky son opciones realmente buenas. No se trata de un compromiso: son distribuciones sólidas que cuentan con un respaldo tanto comunitario como comercial.

Planificar con antelación: un calendario realista

Los plazos de fin de vida útil (EOL) parecen estar muy lejos hasta que ya no lo están. La mayoría de los equipos que iniciaron la migración de RHEL 7 a principios de 2024 no lograron cumplir el plazo de junio de 2024: los proyectos de migración casi siempre llevan más tiempo del estimado inicialmente, sobre todo cuando hay que certificar aplicaciones de terceros.

Los equipos que cumplen los plazos tratan la migración como un proyecto en toda regla: con un jefe de proyecto, una lista de tareas pendientes y alguien cuyo trabajo consiste en hacer un seguimiento del estado de la certificación del ISV cada dos semanas. Los equipos que no cumplen los plazos son aquellos que se lo han encargado a un ingeniero sénior «para cuando tenga tiempo». Ese ingeniero no tiene tiempo. Nunca tienen tiempo. Y de repente es marzo de 2029 y alguien está leyendo el aviso de fin de vida útil (EOL) de Red Hat por primera vez como si fuera una noticia de última hora.

Un enfoque viable para RHEL 8 podría ser algo así:

• A más de 24 meses vista: Realice un inventario de todos los hosts, aplicaciones y dependencias de ISV de RHEL 8. Identifique qué aplicaciones ya están certificadas para RHEL 9 y cuáles suponen un obstáculo.
• A 18 meses vista: Prueba RHEL 9 (o la alternativa que elijas) con cargas de trabajo que no sean de producción. Ejecuta leapp preupgrade en sistemas representativos y documentar los factores que lo impiden.
• A 12 meses vista: Comience las migraciones de producción por fases, empezando por las cargas de trabajo de menor riesgo. Decida qué sistemas permanecerán en RHEL 8 con soporte ampliado y elabore el presupuesto correspondiente.
• A seis meses vista: Cierre los contratos de soporte ampliado para cualquier caso pendiente. Confirme la documentación de cumplimiento con sus auditores para que no haya sorpresas.
• Antes del fin de la vida útil (EOL): Todos los sistemas se han migrado o cuentan con soporte ampliado. No hay ningún sistema sin parches.

Si tu entorno cuenta con más de unos pocos servidores, es casi seguro que te enfrentarás a una complejidad operativa tal que convertirá las simples actualizaciones en proyectos que se prolongarán durante varios trimestres. Cuanto antes te hagas cargo del proyecto, menos trastornos te causará esa complejidad.

Mantén la seguridad con el ELS de TuxCare

En la mayoría de los entornos de producción de RHEL 8, la realidad suele ser la siguiente: se inicia la migración a tiempo, se tropieza con una aplicación dependiente de un proveedor concreto que aún no está certificada para RHEL 9 y se necesita más tiempo del que preveía el plan original. Ahí es donde el soporte de seguridad ampliado deja de ser opcional.

TuxCare mantiene tus sistemas actualizados contra vulnerabilidades tras la fecha de fin de vida útil de RHEL 8 en mayo de 2029, gracias a su experiencia en el soporte técnico de CentOS, RHEL 7 y otras muchas distribuciones de Linux que han llegado al final de su ciclo de vida. Así dispones del tiempo necesario para realizar una migración adecuada, sin tener que operar en entorno de producción sin parches y sin tener que adquirir a toda prisa una suscripción ampliada de Red Hat en el último momento.

En entornos en los que los reinicios suponen un gran inconveniente, vale la pena considerar por separado KernelCare, ya que aplica parches al núcleo en ejecución sin necesidad de interrumpir el servicio. Se trata de un producto distinto de ELS, que se adquiere por separado, pero ambos pueden utilizarse conjuntamente.

Resumen

Nombre del artículo

Fin de la vida útil de RHEL 8: fechas, riesgos y próximos pasos

Descripción

Descubre cuándo finaliza el soporte técnico de RHEL 8, los riesgos que conlleva utilizar sistemas sin soporte técnico y las mejores opciones para mantener la seguridad y el cumplimiento normativo tras el fin de la vida útil del producto.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial