KernelCare ePortal für größere Hosting-Infrastrukturen

KernelCare ePortal im Flottenbetrieb einordnen

KernelCare ePortal ist die selbst betriebene Management- und Verteilkomponente für KernelCare-Agenten in größeren Linux-Umgebungen. Sie bündelt Patchsets, Feeds und Registrierungsschlüssel an einer kontrollierten Stelle. Damit entscheidet der Betreiber nicht nur, ob Hosts Patches beziehen, sondern auch, aus welcher lokalen Quelle und nach welcher Freigabelogik dies geschieht.

Ohne ePortal kontaktieren die Agenten die TuxCare-Infrastruktur direkt. Das ist für kleine, weitgehend einheitliche und internetfähige Serverbestände meist der einfachere Weg: Es gibt keine zusätzliche zentrale Plattform zu aktualisieren, abzusichern und zu überwachen. Mit wachsender Zahl an Systemen wird diese Einfachheit jedoch zum Nachteil, wenn nachvollziehbare Freigaben oder begrenzte Netzausgänge verlangt werden.

In einer Hosting-Flotte treffen oft Webserver, Datenbankserver, Virtualisierungshosts und Management-Systeme mit unterschiedlichen Distributionen und Kernelreihen zusammen. Ein zentraler Patchbezug erlaubt, diese technischen Gruppen gezielt mit passenden Feeds und Schlüsseln zu versorgen. ePortal ist damit keine Alternative zum KernelCare-Agenten, sondern erweitert dessen Bezug von Patchsets um lokale Steuerung und Verteilung.

Der Nutzen entsteht folglich nicht allein durch die Zahl der Server. Ausschlaggebend sind verbindliche Patch-Ringe, Prüf- und Nachweispflichten, Netzwerkvorgaben sowie die Frage, ob ein zentraler Dienst selbst zuverlässig betrieben werden kann. Diese Anforderungen bestimmen auch, ob lokale Spiegelung, Cache oder direkter Bezug die angemessene Architektur ist.

Live-Patching, KernelCare und LibCare abgrenzen

Beim Live-Patching prüft der KernelCare-Agent regelmäßig, ob passende Patchsets verfügbar sind. Er lädt diese herunter, verifiziert sie und installiert sie in den laufenden Kernel. Sicherheitskorrekturen können dadurch aktiv werden, ohne dass für diesen Schritt ein Kernel-Neustart erforderlich ist. Welche Patchsets anwendbar sind, hängt dabei vom installierten Kernel und der unterstützten Distribution ab.

KernelCare bezeichnet das Angebot für Live-Kernel-Patches. LibCare ist davon zu trennen: Es ist ein optionales Zusatzprodukt für bestimmte Userspace-Komponenten und kein anderer Name für Kernel-Patching. ePortal wiederum patcht keinen Kernel selbst, sondern verwaltet Patchsets, Feeds und die Registrierung der KernelCare-Agenten in einer lokalen Enterprise-Installation.

Die frühere Bezeichnung KernelCare Plus sollte nur bei der Einordnung älterer Dokumentationen auftauchen. Der Hersteller hat dieses Produkt seit März 2023 abgekündigt und durch KernelCare ersetzt. Für Bestandsaufnahmen ist daher wichtig, installierte Agenten, Verträge und Dokumentation nicht anhand historischer Produktnamen mit aktuellen Komponenten oder Funktionsumfängen gleichzusetzen.

Live-Patching ersetzt keinen vollständigen Wartungsprozess. Geplante Reboots bleiben etwa für reguläre Kernelwechsel, Hardware- und Firmware-Updates, Treiberänderungen, Konfigurationsarbeiten oder Fehlerbilder nötig, die sich nicht live beheben lassen. Ein Betriebskonzept sollte deshalb die verkürzte Exposition durch Patchsets mit weiterhin geplanten Neustartfenstern verbinden, statt diese ersatzlos zu streichen.

Wann zentrale Patchsteuerung wirtschaftlich passt

ePortal passt, wenn der Betrieb Patches nicht lediglich schnell verteilen, sondern ihre Bereitstellung verbindlich steuern muss. Das betrifft beispielsweise getrennte Freigabegruppen für Canary-Hosts, Staging und Produktion, restriktive ausgehende Firewall-Regeln oder Nachweise darüber, welcher Host welchem Feed zugeordnet war. Auch viele Systeme mit verschiedenen Plattformen profitieren von einer zentral gepflegten Verteilinstanz.

Der zusätzliche Nutzen muss den Aufwand rechtfertigen. Eine ePortal-Instanz benötigt Kapazität, Updates, Backups, Zugriffsschutz und Monitoring; bei hoher Verfügbarkeit kommen Replikation und Netzarchitektur hinzu. Für wenige gleichartige Server mit erlaubtem Internetzugang bleibt der Direktbezug über die TuxCare-Infrastruktur daher oft einfacher. Weniger Komponenten bedeuten dort eine kleinere eigene Betriebsfläche.

Wirtschaftlich wird zentrale Steuerung besonders dort, wo ungeplante Gleichzeitigkeit teuer wäre: etwa bei vielen Kunden-Webservern, Datenbankclustern oder Virtualisierungshosts. Ein Freigabeprozess kann dann technische Ähnlichkeit und Geschäftsrisiko gemeinsam abbilden. Gruppen sollten nicht nur nach Standort entstehen, sondern auch Distribution, Kernelreihe, Hypervisor, Control Panel, Hardware und Kundenprofil berücksichtigen.

Die Sicherheitsabdeckung darf dabei nicht überschätzt werden. KernelCare stellt Live-Patches für einen Kernel grundsätzlich nur bereit, solange dessen Distribution-Anbieter Sicherheitsupdates für die betreffende Kernelserie veröffentlicht. Zudem ist Live-Patching kein pauschaler Nachweis für die Behebung aller Schwachstellen. Patchstatus, Distribution-Support und reguläre Wartung bleiben getrennt zu prüfen.

Die Betriebsentscheidung lautet daher nicht pauschal „zentral ist besser“. ePortal ist sinnvoll, wenn lokale Kontrolle, abgestufte Verteilung und belastbare Nachvollziehbarkeit konkrete Anforderungen erfüllen. Fehlen diese Anforderungen, kann der bewusst einfache Direktbezug robuster sein. Im nächsten Schritt entscheidet das gewünschte Bereitstellungsmodell über Speicherbedarf und externe Abhängigkeiten.

Spiegelung und Cache passend auswählen

Die Wahl des Verteilmodells bestimmt, wie unabhängig eine Hosting-Flotte beim Patchabruf ist und wie viel Infrastruktur sie dafür betreiben muss. Beim Direktbezug laden KernelCare-Agenten Patchsets über die TuxCare-Infrastruktur. ePortal verlagert dagegen Freigabe, lokale Vorhaltung und Verteilung in eine eigene Instanz; sie kann Patchsets als vollständiges oder gefiltertes Archiv spiegeln oder bedarfsorientiert zwischenspeichern.

Eine Vollspiegelung ist sinnvoll, wenn bereits übernommene Patchsets auch bei einer unterbrochenen externen Verbindung lokal verfügbar bleiben müssen oder verbindliche interne Freigaben dies verlangen. Eine gefilterte Spiegelung begrenzt Archivgröße und Datenverkehr auf tatsächlich eingesetzte Distributionen. Dafür muss die Inventarisierung zuverlässig erfassen, welche Kernelreihen und Architekturen die Flotte verwendet; sonst fehlt genau dann ein Archiv, wenn ein Host es benötigt.

Der Cache-Modus spart Speicher, ist aber kein Synonym für einen vollständig isolierten Betrieb. ePortal lädt Metadaten und beschafft Patch-Binärdaten bei Bedarf von der Quelle; heruntergeladene Binärdaten verbleiben laut Dokumentation zwei Wochen im lokalen Cache. Für abgeschottete Agentennetze kann das genügen, solange ePortal den erlaubten Upstream-Pfad nutzen darf.

Ein vollständig luftgetrennt betriebener ePortal-Server ist davon getrennt zu beurteilen. Neue Patcharchive müssen dann über einen separat geplanten manuellen Transfer eingebracht werden. Definiere dafür Quellenprüfung, Integritäts- und Signaturkontrolle, Medien- oder Netzwerkfreigabe, Importreihenfolge und Verantwortlichkeiten. Weder gefilterte noch vollständige Spiegelung erzeugen diesen Prozess automatisch; sie bestimmen nur, welche Archive ePortal lokal vorhält.

Die Speicherplanung sollte nicht bei der Größe des aktuellen Archivs enden. TuxCare nennt für ePortal SSD-Speicher mit mindestens 100 IOPS sowie ein Wachstum von etwa 4 bis 5 GiB pro Monat als Orientierung. Diese Herstellerangaben ersetzen keine Kapazitätsplanung: Recovery-Ziele, parallele Rollouts, Netzwerklatenzen, Anzahl der Kernelvarianten und Monitoring-Anforderungen können die Architektur stärker prägen als freie Plattenkapazität.

Patch-Ringe für Hosting-Flotten aufbauen

Patch-Ringe machen aus einem zentral verfügbaren Patchset einen kontrollierten Rollout. Ein kleiner Canary-Kreis erhält die Freigabe zuerst, danach folgen Staging, eine begrenzte Produktionsgruppe und schließlich die breite Produktion. Jeder Ring braucht vorab definierte Beobachtungen und eine verantwortliche Stelle; ohne diese Kriterien verschiebt eine Verzögerung lediglich das Risiko, statt es zu bewerten.

Für die Produktionsringe ist Stable der vorgesehene Kanal. Testing eignet sich für einen separaten, bewusst kontrollierten Evaluierungsprozess, weil dieser Kanal alle verfügbaren Patchsets einbezieht und damit zusätzliche Patchsets enthalten kann, die noch nicht für Stable markiert sind. Unstable ist laut Dokumentation ein Early-Access-Kanal und nicht empfohlen. Testing und Unstable sind daher nicht als allgemeiner Produktionsnachweis zu behandeln.

Ringe sollten nach technischer Ähnlichkeit statt nur nach Rechenzentrumsstandort zusammengesetzt sein. Relevant sind Distribution und Kernelreihe, Hardwareplattform, Virtualisierung, Control Panel, Webserver-Stack und Kundenprofil. Ein Canary-Host mit anderer Kernelserie oder anderer Virtualisierung deckt das Verhalten eines produktiven Zielsystems nur eingeschränkt ab. Bei Shared Hosting gehören Ressourcenprofile und Konfigurationen des CloudLinux LVE Managers in diese Bewertung, weil sie Last- und Fehlerbilder beeinflussen können.

Besondere Vorsicht gilt neuen ePortal-Instanzen. ePortal prüft nach Herstellerangabe alle zehn Minuten auf neue Patchsets und lädt sie herunter, stellt sie aber nicht automatisch jedem Feed bereit. Werden Archive erstmals geladen, erhalten die enthaltenen Patchsets denselben Erscheinungszeitpunkt. Eine bereits konfigurierte Verzögerung kann deshalb dazu führen, dass der gesamte Erstbestand nach ihrem Ablauf in einen automatisch aktualisierten Feed gelangt.

Halte während der initialen Synchronisation daher die automatische Aktualisierung produktiver Feeds und deren produktive Schlüsselzuordnung zurück. Lade den Erstbestand vollständig, prüfe ihn sowie die Feed-Konfiguration und ordne Schlüssel erst danach kontrolliert den vorgesehenen Ringen zu oder aktiviere deren automatische Aktualisierung. Die Verzögerungslogik dient anschließend für neu eintreffende Patchsets; sie trennt den historischen Erstbestand einer neuen Instanz nicht zuverlässig.

Feeds, Schlüssel und Mandanten trennen

Feeds bilden die technische Seite der Rollout-Ringe ab: Sie verbinden Patchkanal und Verzögerungslogik mit einer Gruppe von Systemen. Registrierungsschlüssel lassen sich an Feeds binden und mit Serverlimits versehen. Dadurch kann ein Betreiber etwa interne Plattformen, Managed-Server-Angebote und getrennte Kundenumgebungen mit unterschiedlichen Freigabepfaden versorgen, ohne die Agentenkonfiguration auf jedem Host einzeln ändern zu müssen.

Diese Zuordnung ist jedoch keine vollständige Sicherheitsgrenze. Die optionale Funktion Business Units unterstützt Multi-Tenancy im ePortal, ersetzt aber weder Netzwerksegmentierung noch ein Berechtigungsmodell oder getrennte administrative Zuständigkeiten. Auch Protokollierung, Secret-Management und die Prüfung, wer Schlüssel erstellen oder Feeds ändern darf, müssen unabhängig von der Produktfunktion geplant und regelmäßig kontrolliert werden.

Für Mandantenumgebungen ist die Trennung von Patchsteuerung und übriger Hosting-Isolation besonders wichtig. Ein Schlüssel kann die beabsichtigte Feed-Zuordnung und die Zahl registrierbarer Server begrenzen, verhindert aber keine Querzugriffe in anderen Infrastrukturkomponenten. Prozess- und Dateisystemisolation bleiben eigene Aufgaben; dazu ergänzt der Beitrag über CloudLinux SecureLVE die Ebene von Accounts und Websites.

Ab ePortal 2.14-1 können API-Keys für die öffentliche API alternativ zur Basic Authentication verwendet werden. Die ePortal-Verwaltung erlaubt für API-Keys unter anderem einzeln widerrufbare Schlüssel sowie ein optionales Ablaufdatum. Das erleichtert getrennte Berechtigungen für CMDB-Anbindungen oder Konfigurationsautomatisierung, sofern die Rechte des zugehörigen Benutzerkontos bewusst begrenzt werden.

Lege Tokens als Secrets in einem Secret-Management-System ab, nicht in Playbooks, Images, Shell-Historien oder Tickets. Das ist eine betriebliche Schutzmaßnahme und keine durch ePortal automatisch erzwungene Eigenschaft. Ein praxistauglicher Prozess ordnet jedem Schlüssel einen Eigentümer, einen Zweck, zulässige Produkte, ein Serverlimit und ein Rotationsdatum zu.

API-Keys sollten bei einem Systemwechsel, einem Rollenwechsel oder einem nicht mehr benötigten Automatisierungszugang gezielt widerrufen werden. Registrierungsschlüssel behandelst du anders: Das Entfernen eines solchen Schlüssels entfernt laut Dokumentation auch alle darunter registrierten Server aus ePortal. Plane deshalb vor dem Löschen die Migration auf einen neuen Schlüssel oder die erneute Registrierung der betroffenen Hosts und prüfe anschließend deren Feed-Zuordnung sowie Check-in-Status.

Replikation und TLS belastbar betreiben

Für eine hochverfügbare Patch-Verteilung werden mehrere ePortal-Knoten so kombiniert, dass KernelCare-Agenten einen gemeinsamen Cluster-DNS-Namen oder einen HTTP-Load-Balancer ansprechen. Für administrative Arbeiten verwendest du dagegen einen kontrollierten, knotenspezifischen Admin-Endpunkt. Den gemeinsamen Cluster-Endpunkt darfst du laut Hersteller nicht für Operationen in der ePortal-Administrationsoberfläche einsetzen.

Vor der Produktivsetzung sollte die Architektur nicht nur den Ausfall eines ePortal-Servers betrachten. Relevant sind auch DNS-Auflösung, Load-Balancer, Zertifikate, Speicher für Patcharchive, die Verbindung zur Patchquelle und die Erreichbarkeit aus jedem Netzsegment. Ein zweiter Knoten ohne abgestimmte Netzwerk- und Betriebsüberwachung verbessert die Verfügbarkeit nur begrenzt; er kann im Fehlerfall sogar abweichende Zustände verdecken.

Die Knoten gleichen Änderungen per Replikation ab. Dieser Abgleich ist nicht zwingend sofort sichtbar. Besonders bei Round-Robin kann ein gerade registrierter Agent den ersten Knoten für die Registrierung und direkt danach einen noch nicht synchronisierten Knoten für die Aktualisierung erreichen. Automatisierungen sollten deshalb einen kurzen Wartepunkt oder eine Retry-Logik mit begrenzten Wiederholungen vorsehen, statt einen unmittelbar folgenden Patchabruf als verlässlichen Endzustand zu behandeln.

Auch längere Trennungen gehören in das Fehlerszenario. Replikationsprotokolle werden laut Dokumentation sieben Tage vorgehalten; bleibt ein Knoten länger getrennt, kann er Änderungen überspringen. Der Replikationsverzug ist damit ein operativer Status, nicht bloß ein Diagnosewert. Nach Netzwerkstörungen prüfst du daher Feed-Zuordnungen, Schlüsselbestand und Patcharchiv auf dem zurückkehrenden Knoten, bevor er wieder regulär Agentenanfragen bedient.

Die Replikation erfolgt über HTTP. Ohne eine geeignete TLS-Absicherung werden die Replikationsdaten daher unverschlüsselt übertragen. Segmentiere diesen Datenverkehr mindestens in ein vertrauenswürdiges Netz oder terminiere TLS passend zur Architektur. Für extern oder netzübergreifend erreichbare Agentenendpunkte ist eine überprüfbare Zertifikatskette wichtiger Bestandteil der TLS-Terminierung; eine deaktivierte Zertifikatsprüfung ist keine vertretbare Dauerlösung.

Steht ein Reverse Proxy vor ePortal, müssen erlaubte Hostnamen konfiguriert sein, damit ePortal Host-Header-Anfragen begrenzt. Der Proxy muss außerdem den ursprünglichen Host-Header sowie X-Forwarded-Proto korrekt weiterreichen. Andernfalls können falsche externe URLs, Weiterleitungsprobleme oder eine fehlerhafte Einschätzung des verwendeten Protokolls entstehen. Diese Header-Konfiguration sollte deshalb Teil jeder Proxy-Änderung und ihrer Abnahme sein.

Nachweise, Backups und Monitoring etablieren

Kontrollierbares Live-Patching braucht wiederkehrende Nachweise, nicht nur eine erfolgreiche Erstinstallation. Erfasse mindestens die Feed-Zuordnung jedes Hosts, den letzten Agenten-Check-in, den gemeldeten Patchstand und den Status der Registrierungsschlüssel. Ergänze diese Daten um verantwortliche Teams und eine nachvollziehbare Freigabeentscheidung. So lässt sich bei einer Sicherheitsmeldung gezielt feststellen, welche Gruppe welchen Bereitstellungsweg nutzt.

Weitere feste Kontrollen betreffen Speicherwachstum, freien Platz für Archive, den Replikationsstatus und die Rotation oder den Widerruf nicht mehr benötigter Schlüssel. API-Keys eignen sich für automatisierte Abfragen besser als geteilte Administratorkennwörter, weil sie einzeln verwaltet, widerrufen und optional mit einem Ablaufdatum versehen werden können. Lege sie als betriebliche Schutzmaßnahme in einer Secret-Verwaltung ab, nicht in Images, Playbooks oder Tickets.

Für einen vorhandenen Cluster ist der folgende, nicht verändernde Prüfaufruf ein geeigneter Baustein für Monitoring oder einen geplanten Health-Check. Er liefert einen maschinenlesbaren Kurzstatus einschließlich Replikationsverzug. Bei einem Problem beendet sich der Aufruf mit Exit-Code 1; das Monitoring sollte diesen Zustand alarmieren, aber die Ursache anhand von Knoten- und Netzwerkdaten weiter eingrenzen.

kc.eportal replication --short-status

ePortal unterscheidet einen Datenbackup-Archivlauf und ein reines Datenbankbackup. Die vollständige Befehlssyntax lautet kc.eportal backup <path_to_archive>; sie erstellt ein Backup-Archiv einschließlich der Patchset-Dateien. Mit kc.eportal backup-db <path_to_backup> sicherst du dagegen nur die Datenbanken ohne Patchset-Dateien. Dieser zweite Weg eignet sich für Konfigurations- und Serverdaten, nicht für die lokale Patcharchivierung.

Diese ePortal-Backups umfassen nicht automatisch die gesamte Umgebung. Betriebssystemkonfiguration, Reverse-Proxy- und Load-Balancer-Konfiguration, TLS-Zertifikate und private Schlüssel, DNS-Einstellungen sowie externe Firewall- oder Secret-Management-Konfigurationen brauchen eigene Sicherungs- und Wiederherstellungsregeln. Definiere je Sicherungsart Zweck, Aufbewahrung, Speicherort und den verantwortlichen Wiederherstellungsweg.

Bei einer Wiederherstellung muss der ePortal-Dienst gestoppt werden. Plane diese Dienstunterbrechung, informiere gegebenenfalls betroffene Betriebsteams und prüfe danach gezielt die Datenkonsistenz sowie die Erreichbarkeit für Agenten. Eine Sicherung gilt erst nach einer kontrolliert geplanten Rücksicherung als belastbar. Dabei darf ein Test nicht versehentlich produktive Feeds oder Schlüsselzuweisungen verändern.

Fehlerbilder und Betriebsentscheidung bewerten

Bleiben erwartete Patches aus, ist zunächst zwischen fehlender Verfügbarkeit, fehlendem Abruf und fehlender Freigabe zu unterscheiden. Prüfe installierte Agenten- und ePortal-Version, zugeordneten Schlüssel und Feed, die passende Distribution samt Kernelreihe sowie die Verbindung zur Patchquelle. Ein Patch kann außerdem fehlen, wenn die betreffende Kernelserie vom Distributionsanbieter keine Sicherheitsupdates mehr erhält; Live-Patching hebt diese Grenze nicht auf.

Historische Herstellerhinweise zu älteren Komponentenständen dürfen nicht als dauerhafte Versionsvorgabe gelesen werden. Ein Hinweis aus Dezember 2025 betraf unter anderem KernelCare-Agent 3.x und ePortal 2.20 im Kontext eines neuen signierten Patchformats. Vor Aktualisierungen prüfst du deshalb die aktuelle Kompatibilitätsmatrix, die tatsächlich installierten Versionen und die intern freigegebene Update-Reihenfolge.

Im Cache-Modus kann ein Cache-Miss bei eingeschränktem externem Zugang den Patchbezug verzögern, weil die benötigte Binärdatei noch nicht lokal liegt. Das ist kein Beleg für einen vollständig isolierten Betrieb. Lege für restriktive Zonen fest, welche Verbindungen zulässig sind, wie fehlende Archive transferiert werden und wer Freigabe, Integrität und Zeitpunkt dieses Transfers verantwortet.

Ein weiteres Fehlerbild ist ein unerwartet breiter Rollout nach dem ersten Download von Patcharchiven auf einer neuen Instanz. Da die erstmals geladenen Archive für die Verzögerungslogik gleichzeitig neu erscheinen, schützt eine zuvor gesetzte Verzögerung nicht zuverlässig vor einer gemeinsamen Bereitstellung. Halte automatische Feed-Aktualisierungen und produktive Schlüsselzuordnungen während der initialen Synchronisation zurück, prüfe den Erstbestand und aktiviere die produktiven Ringe erst danach kontrolliert.

Replikationslücken nach längerer Knotenunterbrechung und fehlerhafte Reverse-Proxies verlangen unterschiedliche Maßnahmen: Erstere erfordern einen Abgleich des Knotenzustands, letztere eine Prüfung von TLS, erlaubten Hostnamen sowie weitergereichten Headern. Beide Fälle gehören in Runbooks mit klarer Eskalation. Ein pauschaler Neustart behebt weder fehlende Daten noch eine unzutreffende Vertrauensgrenze.

ePortal ist vor allem sinnvoll, wenn Patch-Ringe, lokale Verteilung, kontrollierte Netzausgänge oder prüfbare Freigaben tatsächlich gefordert sind. Für einen kleinen, homogenen und internetfähigen Serverbestand bleibt der direkte Bezug über die TuxCare-Infrastruktur oft einfacher. Die Entscheidung sollte daher den zusätzlichen Betriebsaufwand gegen konkrete Steuerungs- und Nachweispflichten abwägen, nicht allein gegen die Zahl der Server.