Fin de vie de RHEL 8 : dates, risques et mesures à prendre

Principaux enseignements

• RHEL 8 arrivera en fin de vie le 31 mai 2029. Après cette date, Red Hat ne fournira plus de correctifs de sécurité ni de corrections de bogues sans un module d'extension de support payant.
• Si vous continuez à utiliser ce système d'exploitation au-delà de 2029 sans plan de transition, vous ne serez plus en conformité avec les normes PCI DSS, HIPAA, SOC 2 et la plupart des autres référentiels qui exigent l'application de correctifs en temps opportun.
• Vos principales options consistent à passer à RHEL 9, à opter pour une distribution compatible telle qu'AlmaLinux ou Rocky, ou à souscrire à un support à cycle de vie prolongé afin de gagner du temps pour la migration.
• Une assistance étendue fournie par un tiers – telle que l'ELS de TuxCare – vous permet de continuer à recevoir les correctifs pour RHEL 8 après la fin de vie (EOL) sans avoir à procéder à une migration d'urgence, et couvre des paquets essentiels tels que le noyau Linux, OpenJDK, OpenSSL, Python et bien d'autres encore.

Si vous utilisez RHEL 8 en production, vous avez déjà franchi une étape importante : le support complet a pris fin en mai 2024. Cela signifie que vous bénéficiez désormais d'un support de maintenance, plus discret mais moins complet : Red Hat corrige les failles de sécurité graves (CVE), mais ne réalise plus aucun travail de développement sur la plateforme. La prochaine date importante est le 31 mai 2029, date à laquelle RHEL 8 arrivera en fin de vie et les correctifs cesseront complètement.

Cet article explique ce que chaque phase du cycle de vie implique concrètement pour vos systèmes, ce à quoi vous renoncez à chaque transition, les risques réels liés au fait de laisser l'année 2029 vous prendre par surprise, ainsi que les options qui s'offrent à vous – y compris celles qui ne nécessitent pas de refonte complète pour laquelle vous n'avez pas prévu de budget.

Que signifie la fin de vie de RHEL 8 ?

Dans l'univers Red Hat, la « fin de vie » (End of Life) n'est pas un simple avertissement ou une suggestion polie d'envisager une mise à niveau. C'est le moment où Red Hat cesse de publier toute nouvelle mise à jour pour cette version majeure. Plus de correctifs CVE, plus de corrections de bogues, plus de réponses aux tickets d'assistance. La version entre alors dans ce que Red Hat appelle officiellement la « phase de vie prolongée » (Extended Life Phase) : vous pouvez toujours consulter la documentation et télécharger les paquets existants, mais aucune nouvelle version n'est développée.

Il est important de bien préciser ce que chaque phase apporte concrètement, car les différences sont notables :

• Phase de support complet : Red Hat fournit tout : errata de sécurité, corrections de bogues urgentes et hautement prioritaires, prise en charge de nouveaux matériels et améliorations logicielles sélectionnées dans les versions mineures. RHEL 8 s'est trouvé dans cette phase de mai 2019 à mai 2024.
• Phase de support technique : Seuls les avis de sécurité critiques et importants (RHSA) et les correctifs urgents (RHBA) sont fournis. Aucune prise en charge de nouveau matériel. Aucun développement de fonctionnalités. RHEL 8 est disponible jusqu'au 31 mai 2029.
• Phase de cycle de vie prolongé : Pratiquement obsolète en termes de mises à jour. Vous pouvez consulter la documentation et accéder aux paquets existants, mais aucune nouveauté n'est disponible à moins que vous n'ayez souscrit à l'option de support de cycle de vie prolongé.

En pratique : lorsque RHEL 8 arrivera en fin de vie (EOL) en 2029, votre noyau aura déjà dix ans du point de vue du développement et n'aura reçu aucune nouvelle fonctionnalité depuis 2024. C'est une longue période pendant laquelle le paysage des menaces évoluera alors que vous ne recevrez plus de correctifs.

Calendrier du cycle de vie du support de RHEL 8

Voici comment le cycle de vie de RHEL 8 se compare à celui des versions précédentes dans l'historique des versions de Red Hat. La période de 10 ans est la même pour toutes les versions récentes de RHEL ; ce qui change, c'est la position où vous vous situez actuellement dans ce cycle.

Si vous avez utilisé RHEL 7 suffisamment longtemps pour ressentir la pression de son échéance de 2024, la date butoir de 2029 pour RHEL 8 vous semblera familière : le même dilemme de migration, simplement repoussé de cinq ans. La différence cette fois-ci est que RHEL 9 est disponible au grand public depuis 2022 ; la version vers laquelle migrer est donc stable et a fait ses preuves. La plupart des équipes ont bénéficié de plusieurs années de délai. L'écart entre la fin du support de maintenance et la fin de la couverture ELS. L'écart entre la fin de la maintenance active et la fin du support étendu est facile à mal interpréter – mais quelle que soit la façon dont on présente les choses, 2029 arrivera, que le projet de migration ait ou non un chef de projet.

Pourquoi les versions de RHEL sont-elles retirées ?

Il est utile de comprendre la logique métier qui sous-tend les décisions relatives à la fin de vie d'un produit lorsque l'on cherche à expliquer l'urgence de la situation aux parties prenantes qui, voyant l'échéance de 2029, pensent qu'il reste encore du temps.

La bande passante technique a ses limites

Red Hat assure la maintenance de chaque version majeure active grâce à sa propre équipe composée de responsables du noyau, d'analystes en sécurité, de processus d'assurance qualité et d'ingénieurs du support. Chaque version supplémentaire prise en charge vient alourdir cette charge de travail. À un certain stade, le coût de la mise à jour d'une base de code vieille de dix ans pour la protéger contre les menaces actuelles dépasse les revenus générés par les abonnements à cette version. Le calcul finit par ne plus tenir la route, et Red Hat décide alors de mettre un terme à cette situation.

Les modèles de sécurité évoluent

Le paysage des menaces en 2019 n'a rien à voir avec celui qui se profile à l'horizon 2029. Les mesures de protection, telles que le renforcement accru du noyau, la mise à jour des paramètres cryptographiques par défaut et l'amélioration de la génération des politiques SELinux, sont intégrées dans les nouvelles versions et ne peuvent souvent pas être rétroportées proprement vers une base de noyau plus ancienne. À terme, l'application de correctifs aux anciennes versions pour respecter les normes de conformité actuelles devient une entreprise vouée à l'échec, quel que soit l'effort technique déployé.

Pour en savoir plus sur l'impact de l'évolution des plateformes sur votre niveau de vulnérabilité, consultez notre présentation des cycles de vie de sécurité Red Hat.

Les charges de travail modernes nécessitent des chaînes d'outils modernes

Les nouveaux environnements d'exécution de langages, les outils de conteneurs et les frameworks natifs du cloud requièrent de plus en plus souvent des versions plus récentes de glibc, du noyau et de systemd. RHEL 8 est livrée avec glibc 2.28 et le noyau 4.18 – des versions qui restent utilisables pour de nombreuses charges de travail, mais qui constituent une véritable limite si vous travaillez avec eBPF, des environnements d'exécution de conteneurs modernes ou des versions récentes de Kubernetes. Les frameworks de conformité et les outils d'audit ont également tendance à exiger une prise en charge actuelle de la plateforme lors de l'évaluation de votre environnement.

Risques liés au maintien de RHEL 8 après la fin de son cycle de vie

Les vulnérabilités CVE non corrigées s'accumulent rapidement

Une fois que Red Hat aura cessé de publier des RHSAs pour RHEL 8, chaque CVE touchant le noyau ou les paquets de base qui sera divulgué constituera une faille permanente sur vos systèmes. Aucun correctif en amont n'est prévu. La période post-fin de vie (EOL) de RHEL 7 constitue un bon indicateur : dans les mois qui ont suivi la fin de vie, les systèmes qui n'avaient pas migré ou souscrit à un support étendu se sont retrouvés confrontés à une liste croissante de vulnérabilités exploitables connues, sans aucune solution de correction. Les scanners de vulnérabilité les détecteront immédiatement, et aucun correctif ne sera disponible. Les auditeurs le remarqueront avant votre équipe.

Selon le rapport « Enterprise Linux & Open-Source Landscape Report 2025 » de TuxCare, 40 % des entreprises interrogées ont été victimes d'un incident de cybersécurité au cours des 12 derniers mois, et 60 % de ces incidents étaient liés à des correctifs de sécurité non installés.

Les certifications de conformité commencent à être refusées

PCI DSS, HIPAA, SOC 2 Type II, ISO 27001, FedRAMP: toutes ces normes exigent l'utilisation de logiciels bénéficiant de correctifs de sécurité réguliers. Dès que RHEL 8 atteindra sa fin de vie (EOL) sans qu'un contrat de support prolongé ne soit en place, vous serez techniquement en situation de non-conformité. Ce n'est pas un problème théorique : une entreprise SaaS de 40 personnes qui tente de renouveler un rapport SOC 2 avec des versions de système d'exploitation non prises en charge dans son périmètre passera beaucoup de temps à rédiger des contrôles compensatoires que les auditeurs n'acceptent généralement pas comme substituts adéquats aux correctifs réels.

Le soutien des fournisseurs pour l'ensemble de votre infrastructure s'affaiblit

Les éditeurs de logiciels indépendants (ISV) – fournisseurs de bases de données, de middleware ou d’outils de sécurité – alignent leurs tableaux de prise en charge sur le cycle de vie du système d’exploitation sous-jacent. Lorsque RHEL 8 ne figurera plus sur la liste des versions prises en charge par Red Hat, bon nombre de ces fournisseurs feront de même. Il n’y a pas pire moment pour découvrir que votre contrat de support n’est plus valable que lors d’un incident de production sur une base de données Oracle ou une instance SAP fonctionnant sur un système d’exploitation qui n’est plus pris en charge.

L'assurance cyber devient complexe

Les assureurs ont désormais une approche plus rigoureuse à cet égard. Les formulaires de souscription d'assurance cyber demandent désormais systématiquement si votre environnement contient des logiciels en fin de cycle de vie (EOL), et les polices prévoient de plus en plus souvent des clauses qui excluent les sinistres liés à des failles attribuables à des vulnérabilités connues et non corrigées. L'utilisation de logiciels obsolètes dont vous saviez qu'ils étaient en fin de cycle de vie constitue un risque de responsabilité civil avéré, que les assureurs ont commencé à répercuter sur les tarifs ou à refuser de couvrir en conséquence.

Plus on attend, plus la mise à niveau devient difficile

On ne souligne pas assez ce problème. Chaque mois où vous continuez à utiliser RHEL 8 après sa fin de vie (EOL), la migration finale devient plus coûteuse. Les nouveaux employés sont moins familiarisés avec des outils vieillissants. La gestion des configurations s'éloigne de tout ce qui est documenté ou vérifiable. Les renouvellements de matériel se heurtent à des problèmes de compatibilité des pilotes lorsque les nouveaux micrologiciels des cartes réseau ou des contrôleurs de stockage ne sont pas certifiés pour RHEL 8. Le système devient plus difficile à gérer en termes de personnel, plus difficile à exploiter et plus difficile à migrer – tout cela simultanément.

Options après la fin de vie de RHEL 8

Le choix de la bonne approche dépend de l'ampleur des modifications à apporter au niveau de la couche applicative, du temps d'indisponibilité que vous pouvez tolérer et de la capacité de votre équipe à prendre en charge un projet de migration dès maintenant. Il n'y a pas de réponse universelle, mais il existe un éventail d'options réalistes.

Option 1 : le support à vie (ELS) de TuxCare

Il est utile de se renseigner sur le service « Endless Lifecycle Support » (ELS) de TuxCare si une migration sans heurts d'ici mai 2029 n'est pas garantie. TuxCare propose déjà l'ELS pour RHEL 7, fournissant des correctifs de vulnérabilité en continu après la fin du support de maintenance de Red Hat, et cette même couverture devrait s'étendre à RHEL 8 lorsque celui-ci arrivera en fin de vie (EOL). Ce service est indépendant du modèle d'abonnement Red Hat, ce qui signifie que vous pouvez maintenir les charges de travail RHEL 8 critiques à jour et prêtes pour les audits, tandis que votre projet de migration se déroule à un rythme raisonnable plutôt que dans une course effrénée.

Il est utile de savoir ce que couvre exactement l'ELS RHEL de TuxCare au niveau des paquets. L'ELS au niveau du système d'exploitation ne se limite pas au noyau : il inclut des paquets couramment utilisés tels que OpenJDK, Python, httpd, OpenSSL et OpenSSH. Ainsi, les composants essentiels de votre pile sont couverts par le même abonnement.

Option 2 : Mise à niveau sur place vers RHEL 9 à l'aide de Leapp

L'utilitaire Leapp de Red Hat permet d'effectuer des mises à niveau sur place de RHEL 8 vers RHEL 9, et sur un système propre et bien entretenu, cela fonctionne bien. Sur un système en service depuis 2019, avec des personnalisations accumulées, des dépôts tiers et des modules du noyau dont personne n'a fourni de documentation complète, c'est une autre histoire.

La bonne approche consiste à exécuter leapp preupgrade Tout d'abord, il met en évidence les obstacles avant que vous ne vous engagiez dans quoi que ce soit. Prévoyez du temps pour surmonter les obstacles qu'il identifie, car il y en aura forcément.

Conseil de pro : Avant d'exécuter la commande « leapp upgrade », vérifiez le /var/log/leapp/leapp-report.txt après leapp preupgrade – Ne vous contentez pas de rechercher les « inhibiteurs ». Les éléments classés comme « graves » qui ne sont pas des inhibiteurs peuvent tout de même vous poser des problèmes après la mise à niveau, notamment en ce qui concerne les modules de noyau tiers et les configurations PAM personnalisées. Corrigez-les avant de valider.

Option 3 : Réinstallation complète sur RHEL 9 ou RHEL 10

Pour les charges de travail compatibles avec les conteneurs ou gérées via une infrastructure en tant que code, une reconstruction parallèle s'avère souvent plus propre qu'une mise à niveau sur place. Vous obtenez ainsi une base de référence vierge, sans artefacts de mise à niveau, et une occasion idéale de résorber la dette technique qui s'accumule depuis 2019. Le processus est plus lent par hôte, mais plus fiable à grande échelle.

Option 4 : Passer à une distribution compatible avec RHEL

AlmaLinux, Rocky Linux et Oracle Linux sont des alternatives compatibles au niveau binaire qui exécutent les mêmes paquets et sont certifiées pour la plupart des mêmes charges de travail. AlmaLinux et Rocky sont gratuits ; Oracle propose un niveau de support payant. Cette solution est tout à fait adaptée si vos outils considèrent le système d'exploitation comme un produit standard et si vous n'avez pas besoin d'un contrat de support spécifique à Red Hat. Vérifiez les certifications des éditeurs de logiciels avant de vous engager : tous les fournisseurs ne prennent pas officiellement en charge ces alternatives, et certains exigent spécifiquement RHEL.

Option 5 : le module complémentaire ELS de Red Hat

Red Hat propose une option de support à cycle de vie prolongé qui étend la couverture de sécurité limitée au-delà de la date butoir de mai 2029 jusqu'en mai 2032. C'est le choix qui s'impose si vous souhaitez rester dans l'écosystème Red Hat et que vous en avez les moyens. La couverture est nettement plus restreinte que celle du support de maintenance – moins de paquets, uniquement les CVE présentant le niveau de gravité le plus élevé – ; il s'agit donc d'une solution transitoire, et non d'un substitut à long terme à la mise à niveau.

Comment choisir :

• Si vos applications sont déjà certifiées sur RHEL 9 et que vous disposez des ressources techniques nécessaires, utilisez simplement Leapp pour mener à bien cette tâche. C'est la solution idéale pour la plupart des environnements simples.
• Si vous utilisez des solutions verrouillées par un fournisseur – base de données Oracle, SAP, middleware plus ancien qui n’a pas encore été certifié sur RHEL 9 –, il vaut mieux être réaliste dès le départ quant aux délais. Les cycles de certification des logiciels d'entreprise ne sont pas rapides, et une migration qui semble simple sur le papier a tendance à s'étaler dans le temps une fois que l'on tient compte des processus de validation par le fournisseur, de test et d'approbation des changements. Le support à cycle de vie prolongé existe précisément pour ce type de scénario : il vous donne le temps nécessaire pour mener à bien cette migration correctement, plutôt que sous la pression.
• Si vous êtes soucieux des coûts et que vous n'avez pas besoin d'un contrat d'assistance Red Hat, AlmaLinux ou Rocky constituent de véritables alternatives intéressantes. Il ne s'agit pas d'un compromis : ce sont des distributions fiables qui bénéficient d'un véritable soutien tant de la part de la communauté que du monde commercial.

Planifier à l'avance : un calendrier réaliste

Les dates limites de fin de vie semblent bien lointaines… jusqu’à ce qu’elles soient soudainement à nos portes. La plupart des équipes qui ont entamé leur migration vers RHEL 7 début 2024 n’ont pas respecté la date butoir de juin 2024 : les projets de migration prennent presque toujours plus de temps que prévu initialement, surtout lorsqu’il faut certifier des applications tierces.

Les équipes qui respectent les délais traitent la migration comme un véritable projet : avec un chef de projet, un backlog et une personne chargée de suivre l'état d'avancement de la certification ISV toutes les deux semaines. Les équipes qui ne respectent pas les délais sont celles qui ont confié cette tâche à un ingénieur senior « quand il aura le temps ». Cet ingénieur n'a pas le temps. Il n'a jamais le temps. Et soudain, nous sommes en mars 2029 et quelqu'un lit l'avis de fin de vie (EOL) de Red Hat pour la première fois, comme s'il s'agissait d'une nouvelle de dernière minute.

Une approche viable pour RHEL 8 pourrait ressembler à ceci :

• À plus de 24 mois : Répertoriez tous les hôtes RHEL 8, les applications et les dépendances ISV. Identifiez les applications déjà certifiées sur RHEL 9 et celles qui constituent des obstacles.
• Dans 18 mois : Testez RHEL 9 (ou la solution de votre choix) sur des charges de travail hors production. Exécutez leapp preupgrade sur des systèmes représentatifs et répertorier les facteurs limitants.
• Dans 12 mois : Commencez les migrations de production par vagues, en commençant par les charges de travail présentant le moins de risques. Déterminez quels systèmes resteront sous RHEL 8 avec support étendu et prévoyez le budget correspondant.
• Dans 6 mois : Finalisez les contrats de support prolongé pour les derniers récalcitrants. Vérifiez la documentation de conformité avec vos auditeurs afin d'éviter toute mauvaise surprise.
• Avant la fin de vie (EOL) : Tous les systèmes sont soit migrés, soit couverts par une assistance prolongée. Aucun système ne reste sans correctif.

Si votre environnement compte plus d'une poignée de serveurs, vous serez très certainement confronté à une complexité opérationnelle telle que de simples mises à jour se transformeront en projets s'étalant sur plusieurs trimestres. Plus tôt vous prendrez les rênes du projet, moins cette complexité sera source de perturbations.

Restez en sécurité avec l'ELS de TuxCare

Dans la plupart des environnements RHEL 8 en production, le scénario le plus réaliste se présente ainsi : vous lancez la migration dans les délais, vous vous heurtez à une application dépendante d’un fournisseur qui n’est pas encore certifiée pour RHEL 9, et vous avez besoin d’un délai supplémentaire par rapport à ce que prévoyait le plan initial. C’est là que le support de sécurité prolongé cesse d’être une option.

TuxCare assure la mise à jour de vos systèmes contre les vulnérabilités après la date de fin de vie de RHEL 8, prévue en mai 2029, grâce à son expérience dans la prise en charge de CentOS, de RHEL 7 et de nombreuses autres distributions Linux en fin de vie. Vous disposez ainsi du temps nécessaire pour effectuer une migration en toute sécurité, sans vous retrouver avec des systèmes non mis à jour en production – et sans devoir acheter à la dernière minute, dans la précipitation, un abonnement prolongé Red Hat.

Dans les environnements où les redémarrages sont problématiques, KernelCare mérite qu'on s'y intéresse de près : il applique des correctifs au noyau en cours d'exécution sans nécessiter d'interruption de service. Il s'agit d'un produit distinct d'ELS, vendu séparément, mais les deux peuvent être utilisés conjointement.

Résumé

Nom de l'article

Fin de vie de RHEL 8 : dates, risques et mesures à prendre

Description

Découvrez la date de fin de prise en charge de RHEL 8, les risques liés à l'utilisation de systèmes non pris en charge, ainsi que les meilleures solutions pour garantir la sécurité et la conformité après la fin de vie du produit.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur