Ende des Supports für RHEL 8: Termine, Risiken und nächste Schritte

Wichtigste Erkenntnisse

• RHEL 8 erreicht am 31. Mai 2029 das Ende seines Lebenszyklus. Nach diesem Datum stellt Red Hat ohne ein kostenpflichtiges Add-on für erweiterten Support keine Sicherheitspatches oder Fehlerbehebungen mehr bereit.
• Wenn Sie dieses Betriebssystem über das Jahr 2029 hinaus ohne entsprechenden Plan weiterbetreiben, verstoßen Sie gegen die Vorschriften von PCI DSS, HIPAA, SOC 2 und die meisten anderen Rahmenwerke, die eine zeitnahe Installation von Patches vorschreiben.
• Ihre wichtigsten Optionen sind ein Upgrade auf RHEL 9, der Wechsel zu einer kompatiblen Distribution wie AlmaLinux oder Rocky oder der Erwerb eines Support-Vertrags mit verlängertem Lebenszyklus, um Zeit für die Migration zu gewinnen.
• Durch erweiterten Support von Drittanbietern – wie beispielsweise TuxCares ELS – können Sie RHEL 8 auch nach Ablauf der Supportlaufzeit (EOL) ohne Notfallmigration auf dem neuesten Stand halten; dabei werden wichtige Pakete wie der Linux-Kernel, OpenJDK, OpenSSL, Python und weitere abgedeckt.

Wenn Sie RHEL 8 in der Produktion einsetzen, haben Sie bereits einen Meilenstein hinter sich: Der vollständige Support endete im Mai 2024. Das bedeutet, dass Sie sich nun im Wartungssupport befinden, der ruhiger, aber auch eingeschränkter ist – Red Hat behebt zwar schwerwiegende Sicherheitslücken (CVEs), führt jedoch keine neuen Entwicklungsarbeiten an der Plattform mehr durch. Das nächste wichtige Datum ist der 31. Mai 2029, wenn RHEL 8 das Ende seiner Lebensdauer erreicht und die Patches vollständig eingestellt werden.

Dieser Artikel erläutert, was die einzelnen Phasen des Lebenszyklus konkret für Ihre Systeme bedeuten, welche Kompromisse Sie bei jedem Übergang eingehen müssen, welche konkreten Risiken damit verbunden sind, wenn Sie sich nicht rechtzeitig auf das Jahr 2029 vorbereiten, und welche Optionen Ihnen zur Verfügung stehen – darunter auch solche, die keine umfassende Umstellung erfordern, für die Sie kein Budget eingeplant haben.

Was bedeutet das Ende des Lebenszyklus von RHEL 8?

Das Ende des Lebenszyklus in der Red Hat-Welt ist keine sanfte Warnung oder höfliche Aufforderung, ein Upgrade in Betracht zu ziehen. Es ist der Zeitpunkt, an dem Red Hat keine neuen Releases mehr für diese Hauptversion bereitstellt. Keine CVE-Patches, keine Fehlerbehebungen, keine Antworten auf Support-Tickets. Die Version wechselt in die von Red Hat offiziell als „Extended Life Phase“ bezeichnete Phase, in der Sie zwar weiterhin die Dokumentation einsehen und vorhandene Pakete abrufen können, aber nichts Neues mehr entwickelt wird.

Es lohnt sich, genau zu beschreiben, was jede Phase tatsächlich leistet, denn die Unterschiede sind erheblich:

• Vollständige Support-Phase: Red Hat stellt alles bereit: Sicherheits-Errata, dringende und hochprioritäre Fehlerbehebungen, Unterstützung für neue Hardware sowie ausgewählte Softwareverbesserungen in Minor-Releases. RHEL 8 befand sich von Mai 2019 bis Mai 2024 in dieser Phase.
• Wartungs- und Supportphase: Es werden nur kritische und wichtige Sicherheitshinweise (RHSAs) sowie dringende Fehlerbehebungen (RHBAs) bereitgestellt. Kein Support für neue Hardware. Keine Entwicklung neuer Funktionen. RHEL 8 ist bis zum 31. Mai 2029 verfügbar.
• Verlängerte Lebensdauerphase: Aus Sicht der Patches praktisch tot. Sie können die Dokumentation lesen und auf vorhandene Pakete zugreifen, aber es gibt keine neuen Updates, es sei denn, Sie haben für das Add-on „Extended Life Cycle Support“ bezahlt.

Die praktische Konsequenz: Wenn RHEL 8 im Jahr 2029 das Ende der Lebensdauer (EOL) erreicht, wird Ihr Kernel aus Entwicklungssicht bereits ein Jahrzehnt alt sein und seit 2024 keine neuen Funktionen mehr erhalten haben. Das ist eine lange Zeit, in der sich die Bedrohungslage weiterentwickelt, während Sie keine Patches mehr erhalten.

Zeitplan für den Support-Lebenszyklus von RHEL 8

Hier sehen Sie, wie sich der Lebenszyklus von RHEL 8 im Vergleich zu den anderen Versionen in der Release-Historie von Red Hat darstellt. Der Zeithorizont von 10 Jahren ist bei allen aktuellen RHEL-Versionen gleich; was sich ändert, ist der Punkt, an dem Sie sich gerade innerhalb dieses Zeitraums befinden.

Wenn Sie RHEL 7 lange genug genutzt haben, um den Druck der Frist im Jahr 2024 zu spüren, wird Ihnen der Stichtag 2029 bei RHEL 8 bekannt vorkommen – derselbe Migrationsdruck, nur um fünf Jahre verschoben. Der Unterschied besteht diesmal darin, dass RHEL 9 bereits seit 2022 allgemein verfügbar ist, sodass das Upgrade-Ziel stabil und gut getestet ist. Die meisten Teams hatten jahrelange Vorlaufzeit. Die Lücke zwischen dem Ende des Wartungssupports und dem Ende der ELS-Abdeckung. Die Lücke zwischen dem Ende der aktiven Wartung und dem Ende des erweiterten Supports lässt sich leicht falsch interpretieren – aber egal, wie man es betrachtet: 2029 kommt, unabhängig davon, ob das Migrationsprojekt einen Projektmanager hat oder nicht.

Warum RHEL-Versionen aus dem Verkehr gezogen werden

Es ist hilfreich, die geschäftlichen Gründe für EOL-Entscheidungen zu verstehen, wenn man versucht, den Beteiligten die Dringlichkeit zu verdeutlichen, die angesichts der Frist im Jahr 2029 davon ausgehen, dass noch Zeit bleibt.

Die technische Bandbreite hat ihre Grenzen

Red Hat betreut jede aktive Hauptversion mit einem eigenen Team aus Kernel-Betreuern, Sicherheitsanalysten, Qualitätssicherungsprozessen und Support-Technikern. Jede weitere unterstützte Version vervielfacht diesen Aufwand. Irgendwann übersteigen die Kosten für die Pflege einer zehn Jahre alten Codebase, die gegen moderne Bedrohungen gepatcht werden muss, die durch die Abonnement-Einnahmen dieser Version erzielten Erlöse. Die Rechnung geht irgendwann nicht mehr auf, und Red Hat zieht einen Schlussstrich.

Sicherheitsmodelle entwickeln sich weiter

Die Bedrohungslage im Jahr 2019 unterscheidet sich grundlegend von derjenigen, die uns bis zum Jahr 2029 bevorsteht. Sicherheitsmaßnahmen wie eine strengere Kernel-Absicherung, aktualisierte kryptografische Standardeinstellungen und eine verbesserte SELinux-Richtlinienerstellung werden in neuere Versionen integriert und lassen sich oft nicht sauber auf eine ältere Kernel-Basis zurückportieren. Letztendlich wird das Patchen alter Versionen zur Erfüllung aktueller Compliance-Anforderungen zu einem aussichtslosen Unterfangen, unabhängig vom technischen Aufwand.

In unserer Übersicht über die Sicherheitslebenszyklen von Red Hat erfahren Sie mehr darüber, wie sich die Weiterentwicklung der Plattform auf Ihre Sicherheitslage auswirkt.

Moderne Workloads erfordern moderne Toolchains

Neuere Sprach-Runtimes, Container-Tools und Cloud-native Frameworks setzen zunehmend eine aktuellere Version von glibc, des Kernels und von systemd voraus. RHEL 8 wird mit glibc 2.28 und Kernel 4.18 ausgeliefert – diese sind zwar für viele Anwendungsfälle noch brauchbar, schränken Sie jedoch erheblich ein, wenn Sie mit eBPF, modernen Container-Runtimes oder aktuellen Kubernetes-Versionen arbeiten. Auch Compliance-Frameworks und Audit-Tools setzen bei der Bewertung Ihrer Umgebung in der Regel eine aktuelle Plattformunterstützung voraus.

Risiken eines Weiterbetriebs von RHEL 8 nach Ablauf der Supportdauer

Nicht behobene CVEs häufen sich schnell an

Sobald Red Hat keine RHSAs mehr für RHEL 8 herausgibt, stellt jede bekannt gewordene CVE auf Kernel-Ebene oder in Kernpaketen eine dauerhafte Sicherheitslücke auf Ihren Systemen dar. Es ist kein Upstream-Fix in Aussicht. Die Zeit nach dem EOL von RHEL 7 ist ein guter Anhaltspunkt: Innerhalb weniger Monate nach dem EOL standen Systeme, die nicht migriert hatten oder keinen erweiterten Support erworben hatten, auf einer immer länger werdenden Liste bekannter ausnutzbarer Schwachstellen, für die es keine Abhilfemaßnahmen gab. Schwachstellenscanner werden diese sofort aufdecken, und es wird keine Lösung dafür verfügbar sein. Auditoren werden dies bemerken, bevor Ihr Team es tut.

Laut dem „2025 Enterprise Linux & Open-Source Landscape Report“ von TuxCare waren 40 % der befragten Unternehmen in den letzten 12 Monaten von einem Cybersicherheitsvorfall betroffen, wobei 60 % dieser Vorfälle auf nicht installierte Sicherheitspatches zurückzuführen waren.

Die Konformitätsbescheinigungen werden zunehmend ungültig

PCI DSS, HIPAA, SOC 2 Typ II, ISO 27001, FedRAMP – alle diese Standards erfordern den Einsatz von Software, für die zeitnah Sicherheitspatches bereitgestellt werden. Sobald RHEL 8 das Ende der Lebensdauer (EOL) erreicht, ohne dass eine Vereinbarung über erweiterten Support besteht, verstoßen Sie technisch gesehen gegen die Vorschriften. Das ist kein theoretisches Problem: Ein SaaS-Unternehmen mit 40 Mitarbeitern, das versucht, einen SOC-2-Bericht mit nicht mehr unterstützten Betriebssystemversionen im Umfang zu erneuern, wird viel Zeit damit verbringen, Ausgleichskontrollen zu erstellen, die Auditoren in der Regel nicht als adäquaten Ersatz für tatsächliche Patches akzeptieren werden.

Der Hersteller-Support für Ihre gesamte Infrastruktur lässt nach

Unabhängige Softwareanbieter – Datenbankanbieter, Middleware-Anbieter und Anbieter von Sicherheitstools – richten ihre Support-Matrizen nach dem Lebenszyklus des zugrunde liegenden Betriebssystems aus. Wenn RHEL 8 aus der Liste der von Red Hat unterstützten Betriebssysteme gestrichen wird, werden viele dieser Anbieter diesem Beispiel folgen. Ein Produktionsausfall bei einer Oracle-Datenbank oder einer SAP-Instanz, die auf einem nicht mehr unterstützten Betriebssystem läuft, ist ein besonders ungünstiger Zeitpunkt, um festzustellen, dass Ihr Supportvertrag nicht mehr gültig ist.

Cyberversicherungen werden kompliziert

Die Versicherer sind in dieser Hinsicht mittlerweile viel versierter. In Anträgen auf Cyber-Versicherungsschutz wird mittlerweile routinemäßig nach EOL-Software in Ihrer Umgebung gefragt, und die Policen enthalten zunehmend Klauseln, die Ansprüche für Sicherheitsverletzungen ausschließen, die auf bekannte, nicht gepatchte Schwachstellen zurückzuführen sind. Der Einsatz veralteter Software, von der Sie wussten, dass sie das EOL erreicht hat, stellt ein nachweisbares Haftungsrisiko dar, das die Versicherer mittlerweile entsprechend in ihren Prämien berücksichtigen oder zu einer Ablehnung der Police führen.

Je länger du wartest, desto schwieriger wird das Upgrade

Diesem Aspekt wird nicht genügend Beachtung geschenkt. Mit jedem Monat, den Sie nach Ablauf der EOL-Frist weiterhin auf RHEL 8 bleiben, wird die spätere Migration teurer. Neue Mitarbeiter sind mit veralteten Tools weniger vertraut. Die Konfigurationsverwaltung weicht von allem ab, was dokumentiert oder testbar ist. Bei der Hardware-Erneuerung stößt man auf Kompatibilitätsprobleme mit Treibern, wenn neuere Firmware für Netzwerkkarten oder Speichercontroller keine zertifizierte Unterstützung für RHEL 8 bietet. Das System wird gleichzeitig schwieriger zu besetzen, schwieriger zu betreiben und schwieriger zu migrieren.

Optionen nach Ablauf der Lebensdauer von RHEL 8

Welcher Weg der richtige ist, hängt davon ab, wie viel Arbeit auf Anwendungsebene ein Upgrade mit sich bringt, wie viel Ausfallzeit Sie in Kauf nehmen können und ob Ihr Team derzeit über die personellen Ressourcen verfügt, um ein Migrationsprojekt zu übernehmen. Es gibt keine allgemeingültige Antwort, aber eine Reihe realistischer Optionen.

Option 1: TuxCare Endless Lifecycle Support (ELS)

Der „Endless Lifecycle Support“ (ELS) von TuxCare ist eine Überlegung wert, falls eine reibungslose Migration bis Mai 2029 nicht sicher ist. TuxCare bietet bereits ELS für RHEL 7 an und liefert auch nach Ablauf des Wartungssupports von Red Hat weiterhin Patches für Sicherheitslücken. Es wird erwartet, dass dieser Service auch auf RHEL 8 ausgeweitet wird, sobald dessen Lebenszyklus endet. Der Service ist unabhängig vom Red Hat-Abonnementmodell, was bedeutet, dass Sie kritische RHEL 8-Workloads gepatcht und auditfähig halten können, während Ihr Migrationsprojekt in einem vernünftigen Tempo voranschreitet, anstatt in einem erzwungenen Sprint durchgeführt zu werden.

Es ist wichtig zu wissen, was die RHEL-ELS von TuxCare auf Paketebene tatsächlich abdeckt. Die ELS auf Betriebssystemebene umfasst nicht nur den Kernel, sondern auch häufig verwendete Pakete wie OpenJDK, Python, httpd, OpenSSL und OpenSSH, sodass die Kernkomponenten Ihres Stacks im Rahmen desselben Abonnements abgedeckt sind.

Option 2: In-Place-Upgrade auf RHEL 9 mit Leapp

Das Leapp-Dienstprogramm von Red Hat ermöglicht In-Place-Upgrades von RHEL 8 auf RHEL 9 und funktioniert auf einem sauberen, gut gewarteten System einwandfrei. Auf einem System, das seit 2019 läuft und auf dem sich Anpassungen, Repos von Drittanbietern und Kernel-Module angesammelt haben, die niemand vollständig dokumentiert hat, funktioniert es weniger gut.

Der richtige Ansatz ist, Folgendes auszuführen: leapp preupgrade Erstens: Es deckt Hindernisse auf, bevor Sie sich zu etwas verpflichten. Planen Sie ausreichend Zeit ein, um die aufgezeigten Hindernisse zu überwinden, denn es wird einige geben.

Profi-Tipp: Bevor Sie „leapp upgrade“ ausführen, überprüfen Sie die /var/log/leapp/leapp-report.txt danach leapp preupgrade – Achte nicht nur auf „Hindernisse“. Auch die Probleme mit dem Schweregrad „hoch“, die keine Hindernisse darstellen, können dir nach dem Upgrade noch Probleme bereiten, insbesondere bei Kernel-Modulen von Drittanbietern und benutzerdefinierten PAM-Konfigurationen. Behebe diese Probleme, bevor du den Commit durchführst.

Option 3: Komplette Neuinstallation unter RHEL 9 oder RHEL 10

Bei Workloads, die sich für Container eignen oder über Infrastructure-as-Code verwaltet werden, ist eine parallele Neuinstallation oft sauberer als ein Upgrade vor Ort. Sie erhalten eine neue Basis, keine Upgrade-Artefakte und eine natürliche Gelegenheit, technische Schulden abzubauen, die sich seit 2019 angesammelt haben. Langsamer pro Host, aber zuverlässiger bei Skalierung.

Option 4: Wechseln Sie zu einer RHEL-kompatiblen Distribution

AlmaLinux, Rocky Linux und Oracle Linux sind binärkompatible Alternativen, auf denen dieselben Pakete laufen und die für fast dieselben Anwendungsfälle zertifiziert sind. AlmaLinux und Rocky sind kostenlos; Oracle bietet einen kostenpflichtigen Support an. Dieser Ansatz eignet sich gut, wenn Ihre Tools das Betriebssystem als Standardprodukt behandeln und Sie keine Red-Hat-spezifischen Anforderungen an Supportverträge haben. Überprüfen Sie vor der Entscheidung die ISV-Zertifizierungen – nicht jeder Anbieter unterstützt die Alternativen offiziell, und einige verlangen ausdrücklich RHEL.

Option 5: Das ELS-Add-on von Red Hat

Red Hat bietet ein Zusatzmodul für erweiterten Lebenszyklus-Support an, das den begrenzten Sicherheitsschutz über den Stichtag im Mai 2029 hinaus bis Mai 2032 verlängert. Dies ist die naheliegende Wahl, wenn Sie im Red-Hat-Ökosystem bleiben möchten und über das entsprechende Budget verfügen. Der Umfang ist deutlich geringer als beim Wartungs-Support – weniger Pakete, nur CVEs mit höchster Schweregradstufe –, sodass es sich um eine Überbrückungslösung handelt und nicht um einen langfristigen Ersatz für ein Upgrade.

So wählen Sie aus:

• Wenn Ihre Anwendungen bereits für RHEL 9 zertifiziert sind und Sie über die entsprechenden technischen Ressourcen verfügen, nutzen Sie einfach Leapp und bringen Sie die Sache hinter sich. Das ist die richtige Lösung für die meisten unkomplizierten Umgebungen.
• Wenn Sie anbietergebundene Lösungen einsetzen – Oracle DB, SAP, ältere Middleware, die noch nicht für RHEL 9 zertifiziert ist –, sollten Sie sich frühzeitig ein realistisches Bild von den Zeitplänen machen. Zertifizierungszyklen für Unternehmenssoftware verlaufen nicht schnell, und eine Migration, die auf dem Papier einfach aussieht, kann sich in die Länge ziehen, wenn man die Freigaben durch den Anbieter, Tests und Änderungsgenehmigungsverfahren mit einbezieht. Der erweiterte Lebenszyklus-Support ist genau für dieses Szenario gedacht: Er gibt Ihnen den nötigen Spielraum, um die Migration ordnungsgemäß und ohne Zeitdruck durchzuführen.
• Wenn Sie auf die Kosten achten und keinen Red-Hat-Supportvertrag benötigen, sind AlmaLinux oder Rocky wirklich gute Optionen. Das ist kein Kompromiss – es handelt sich um solide Distributionen, die sowohl von der Community als auch von kommerziellen Anbietern unterstützt werden.

Vorausplanen: Ein realistischer Zeitplan

EOL-Fristen scheinen noch in weiter Ferne zu liegen – bis sie plötzlich vor der Tür stehen. Teams, die Anfang 2024 mit der Migration von RHEL 7 begonnen hatten, konnten die Frist im Juni 2024 meist nicht einhalten – Migrationsprojekte dauern fast immer länger als ursprünglich veranschlagt, insbesondere wenn Zertifizierungen von Drittanbieteranwendungen erforderlich sind.

Die Teams, die ihre Fristen einhalten, behandeln die Migration wie ein richtiges Projekt – mit einem Projektleiter, einem Backlog und jemandem, dessen Aufgabe es ist, alle zwei Wochen den Stand der ISV-Zertifizierung zu überprüfen. Die Teams, die ihre Fristen verpassen, sind diejenigen, die die Aufgabe einem leitenden Ingenieur übertragen haben, „wenn er Zeit hat“. Dieser Ingenieur hat keine Zeit. Sie haben nie Zeit. Und plötzlich ist es März 2029 und jemand liest die EOL-Mitteilung von Red Hat zum ersten Mal, als wäre es eine Eilmeldung.

Ein praktikabler Ansatz für RHEL 8 könnte etwa so aussehen:

• In mehr als 24 Monaten: Erfassen Sie alle RHEL 8-Hosts, Anwendungen und ISV-Abhängigkeiten. Ermitteln Sie, welche Anwendungen bereits für RHEL 9 zertifiziert sind und welche als Hindernisse gelten.
• Noch 18 Monate: Testen Sie RHEL 9 (oder eine Alternative Ihrer Wahl) mit Workloads außerhalb der Produktionsumgebung. Führen Sie leapp preupgrade an repräsentativen Systemen und dokumentieren die Hemmfaktoren.
• 12 Monate vor dem Termin: Beginnen Sie mit der schrittweisen Migration der Produktion, beginnend mit den Workloads mit dem geringsten Risiko. Legen Sie fest, welche Systeme auf RHEL 8 mit erweitertem Support verbleiben sollen, und planen Sie das Budget entsprechend.
• 6 Monate vor Ablauf: Schließen Sie erweiterte Supportverträge für alle noch verbleibenden Kunden ab. Klären Sie die Compliance-Dokumentation mit Ihren Wirtschaftsprüfern ab, damit es keine Überraschungen gibt.
• Vor dem EOL: Jedes System wird entweder migriert oder durch erweiterten Support abgedeckt. Nichts bleibt ungepatcht.

Wenn Ihre Umgebung aus mehr als nur einer Handvoll Hosts besteht, werden Sie mit ziemlicher Sicherheit auf eine betriebliche Komplexität stoßen, die einfache Upgrades zu einem mehrmonatigen Unterfangen macht. Je früher Sie die Verantwortung für das Projekt übernehmen, desto weniger störend wirkt sich diese Komplexität aus.

Mit ELS von TuxCare auf der sicheren Seite

In den meisten RHEL 8-Produktionsumgebungen sieht die Realität meist so aus: Man beginnt pünktlich mit der Migration, stößt dann auf eine herstellergebundene Anwendung, die noch nicht für RHEL 9 zertifiziert ist, und benötigt mehr Zeit, als im ursprünglichen Plan vorgesehen war. An diesem Punkt ist der erweiterte Sicherheitssupport keine Option mehr.

TuxCare sorgt dafür, dass Ihre Systeme auch nach dem Ende des Supportzyklus für RHEL 8 im Mai 2029 vor Sicherheitslücken geschützt bleiben – dank unserer Erfahrung mit CentOS, RHEL 7 und einer Reihe weiterer Linux-Distributionen, deren Supportzyklus bereits abgelaufen ist. So haben Sie genügend Zeit für eine ordnungsgemäße Migration, ohne in der Produktion mit ungepatchten Systemen arbeiten zu müssen – und ohne in letzter Minute in Panik ein verlängertes Red Hat-Abonnement abschließen zu müssen.

In Umgebungen, in denen ein Neustart mit erheblichen Beeinträchtigungen verbunden ist, lohnt es sich, KernelCare gesondert in Betracht zu ziehen – es patcht den laufenden Kernel, ohne dass Ausfallzeiten entstehen. Es handelt sich um ein von ELS unabhängiges Produkt, das separat erworben wird, doch beide können zusammen verwendet werden.

Zusammenfassung

Artikel Name

Ende des Supports für RHEL 8: Termine, Risiken und nächste Schritte

Beschreibung

Erfahren Sie, wann der Support für RHEL 8 endet, welche Risiken der Betrieb nicht mehr unterstützter Systeme mit sich bringt und welche Möglichkeiten es gibt, um nach dem EOL weiterhin sicher und konform zu bleiben.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers