KernelCare ePortal voor grotere hostinginfrastructuren

KernelCare ePortal integreren in het wagenparkbeheer

KernelCare ePortal is de zelfbeheerde beheer- en distributiecomponent voor KernelCare-agenten in grotere Linux-omgevingen. Deze bundelt patchsets, feeds en registratiesleutels op één gecontroleerde locatie. Hiermee bepaalt de beheerder niet alleen of hosts patches ontvangen, maar ook vanuit welke lokale bron en volgens welke vrijgavelogica dit gebeurt.

Zonder ePortal nemen de agenten rechtstreeks contact op met de TuxCare-infrastructuur. Voor kleine, grotendeels uniforme en internetgeschikte serverparken is dit meestal de eenvoudigste manier: er is geen extra centraal platform dat moet worden bijgewerkt, beveiligd en bewaakt. Naarmate het aantal systemen toeneemt, wordt deze eenvoud echter een nadeel wanneer traceerbare vrijgaven of beperkte netwerkuitgangen vereist zijn.

In een hostingpark komen vaak webservers, databaseservers, virtualisatiehosts en beheersystemen met verschillende distributies en kernelversies samen. Een centraal Aankoop van patches maakt het mogelijk om deze technische groepen gericht te voorzien van passende feeds en sleutels. ePortal is daarmee geen alternatief voor de KernelCare-agent, maar breidt de ophaling van patchesets uit met lokale aansturing en distributie.

Het nut vloeit dus niet alleen voort uit het aantal servers. Bepalend zijn bindende patchcycli, controle- en rapportageverplichtingen, netwerkvoorschriften en de vraag of een centrale dienst zelf betrouwbaar kan worden geëxploiteerd. Deze eisen bepalen ook of lokale mirroring, caching of directe opvraging de meest geschikte architectuur is.

Het onderscheid tussen Live-Patching, KernelCare en LibCare

Op Live patchen De KernelCare-agent controleert regelmatig of er geschikte patchesets beschikbaar zijn. Hij downloadt deze, controleert ze en installeert ze in de actieve kernel. Beveiligingscorrecties kunnen hierdoor worden geactiveerd zonder dat hiervoor een herstart van de kernel nodig is. Welke patchesets van toepassing zijn, hangt af van de geïnstalleerde kernel en de ondersteunde distributie.

KernelCare verwijst naar het aanbod van live kernel-patches. LibCare staat hier los van: het is een optioneel aanvullend product voor bepaalde userspace-componenten en geen andere benaming voor kernel-patching. ePortal daarentegen patcht zelf geen kernel, maar beheert patchesets, feeds en de registratie van de KernelCare-agenten in een lokale bedrijfsinstallatie.

De vroegere benaming KernelCare Plus zou alleen nog mogen voorkomen bij het ordenen van oudere documentatie. De fabrikant heeft dit product sinds maart 2023 uit de handel genomen en vervangen door KernelCare. Voor inventarisaties is het daarom belangrijk om geïnstalleerde agents, contracten en documentatie niet op basis van historische productnamen gelijk te stellen aan huidige componenten of functionaliteiten.

Live-patching is geen vervanging voor een volledig onderhoudsproces. Geplande Reboots blijven bijvoorbeeld nodig voor reguliere kernelwisselingen, hardware- en firmware-updates, wijzigingen in stuurprogramma’s, configuratiewerkzaamheden of foutmeldingen die niet live kunnen worden verholpen. Een bedrijfsconcept moet daarom de kortere blootstellingsduur door middel van patchsets combineren met de reeds geplande herstartvensters, in plaats van deze zonder vervanging te schrappen.

Wanneer is centrale patchbeheer economisch gezien een goede keuze?

ePortal is geschikt wanneer de organisatie patches niet alleen snel moet distribueren, maar ook de implementatie ervan op een bindende manier moet beheren. Dit betreft bijvoorbeeld afzonderlijke goedkeuringsgroepen voor Canary-hosts, staging en productie, restrictieve uitgaande firewallregels of bewijsstukken over welke host aan welke feed was toegewezen. Ook veel systemen met verschillende platforms profiteren van een centraal beheerde distributie-instantie.

De meerwaarde moet de inspanning rechtvaardigen. Een ePortal-instantie vereist capaciteit, updates, back-ups, toegangsbeveiliging en monitoring; bij hoge beschikbaarheid komen daar replicatie en netwerkarchitectuur bij. Voor een klein aantal vergelijkbare servers met toegestane internettoegang blijft directe aansluiting via de TuxCare-infrastructuur daarom vaak eenvoudiger. Minder componenten betekenen daar een kleinere eigen bedrijfsomgeving.

Centrale aansturing is vooral economisch gezien zinvol wanneer onvoorziene gelijktijdigheid hoge kosten met zich mee zou brengen: bijvoorbeeld bij een groot aantal webservers voor klanten, databaseclusters of virtualisatiehosts. Een Vrijgaveproces kan dan zowel technische overeenkomsten als bedrijfsrisico’s in kaart brengen. Groepen moeten niet alleen op basis van locatie worden samengesteld, maar moeten ook rekening houden met distributie, kernelversie, hypervisor, configuratiescherm, hardware en klantprofiel.

De veiligheidswaarde hiervan mag niet worden overschat. KernelCare stelt in principe alleen live-patches voor een kernel beschikbaar zolang de distributeur van die kernel beveiligingsupdates voor de betreffende kernelserie publiceert. Bovendien is live-patching geen algemeen bewijs dat alle kwetsbaarheden zijn verholpen. De patchstatus, distributieondersteuning en regulier onderhoud moeten afzonderlijk worden gecontroleerd.

De operationele beslissing luidt daarom niet zonder meer: „centraal is beter“. ePortal is zinvol wanneer lokale controle, gefaseerde distributie en betrouwbare traceerbaarheid aan concrete eisen voldoen. Als deze eisen ontbreken, kan de bewust eenvoudige directe inkoop robuuster zijn. In de volgende stap bepaalt het gewenste leveringsmodel de opslagbehoefte en externe afhankelijkheden.

De juiste spiegeling en cache kiezen

De keuze van het distributiemodel bepaalt in hoeverre een hostingpark onafhankelijk is bij het ophalen van patches en hoeveel infrastructuur het daarvoor moet beheren. Bij directe ophaling laden KernelCare-agenten patchesets via de TuxCare-infrastructuur. ePortal daarentegen verplaatst de vrijgave, lokale opslag en distributie naar een eigen instantie; deze kan patchesets als volledig of gefilterd archief spiegelen of op basis van behoefte tijdelijk opslaan.

Een volledige mirroring is zinvol wanneer reeds gedownloade patchsets ook bij een onderbroken externe verbinding lokaal beschikbaar moeten blijven, of wanneer bindende interne goedkeuringen dit vereisen. Een gefilterde mirroring beperkt de archiefgrootte en het dataverkeer tot daadwerkelijk gebruikte distributies. Hiervoor moet de inventarisatie betrouwbaar vastleggen welke kernelreeksen en architecturen het park gebruikt; anders ontbreekt er juist dan een archief wanneer een host het nodig heeft.

De Cachemodus bespaart opslagruimte, maar is geen synoniem voor een volledig geïsoleerde werking. ePortal laadt metadata en haalt indien nodig patch-binaire gegevens op van de bron; gedownloade binaire gegevens blijven volgens de documentatie twee weken in de lokale cache staan. Voor afgeschermde agentnetwerken kan dat voldoende zijn, zolang ePortal het toegestane upstream-pad mag gebruiken.

Een volledig in een luchtgedichte omgeving werkende ePortal-server moet hierbuiten worden beoordeeld. Nieuwe patcharchieven moeten dan via een afzonderlijk geplande handmatige overdracht worden geïmporteerd. Definieer hiervoor broncontrole, integriteits- en handtekeningcontrole, media- of netwerktoegang, importvolgorde en verantwoordelijkheden. Noch gefilterde, noch volledige spiegeling genereert dit proces automatisch; ze bepalen alleen welke archieven ePortal lokaal bewaart.

De opslagplanning mag niet beperkt blijven tot de omvang van het huidige archief. TuxCare noemt voor ePortal SSD-opslag met minimaal 100 IOPS en een groei van ongeveer 4 tot 5 GiB per maand als richtlijn. Deze specificaties van de fabrikant zijn geen vervanging voor capaciteitsplanning: hersteldoelstellingen, gelijktijdige implementaties, netwerklatenties, het aantal kernelvarianten en monitoringvereisten kunnen de architectuur sterker beïnvloeden dan de beschikbare schijfcapaciteit.

Patchringen voor hostingvloten opzetten

Patchringen zorgen ervoor dat een centraal beschikbare patchset op een gecontroleerde manier wordt uitgerold. Eerst krijgt een kleine ‘canary’-groep de goedkeuring, daarna volgen de staging-omgeving, een beperkte productiegroep en ten slotte de brede productie. Elke ring vereist vooraf vastgestelde monitoringcriteria en een verantwoordelijke instantie; zonder deze criteria verschuift een vertraging het risico alleen maar, in plaats van het te beoordelen.

Voor de productieringen geldt dat Stable het beoogde kanaal. Testing is geschikt voor een afzonderlijk, bewust gecontroleerd evaluatieproces, omdat dit kanaal alle beschikbare patchsets omvat en dus extra patchsets kan bevatten die nog niet zijn gemarkeerd voor Stable. Unstable is volgens de documentatie een Early-Access-kanaal en wordt niet aanbevolen. Testing en Unstable mogen daarom niet worden beschouwd als algemene productiebewijzen.

Ringen moeten worden samengesteld op basis van technische gelijkenis in plaats van uitsluitend op basis van de locatie van het datacenter. Relevant zijn de distributie en kernelreeks, het hardwareplatform, de virtualisatie, het configuratiescherm, de webserverstack en het klantprofiel. Een Canary-host met een andere kernelreeks of andere virtualisatie geeft slechts in beperkte mate het gedrag van een productief doelsysteem weer. Bij shared hosting zijn resourceprofielen en configuraties van de CloudLinux LVE-beheerders in deze beoordeling, omdat ze invloed kunnen hebben op de belastings- en foutpatronen.

Wees vooral voorzichtig met nieuwe ePortal-instanties. Volgens de fabrikant controleert ePortal elke tien minuten of er nieuwe patchsets beschikbaar zijn en downloadt deze, maar stelt ze niet automatisch beschikbaar voor elke feed. Wanneer archieven voor het eerst worden geladen, krijgen de daarin opgenomen patchsets dezelfde publicatiedatum. Een reeds geconfigureerde vertraging kan er daarom toe leiden dat de volledige eerste set na het verstrijken van de vertraging in een automatisch bijgewerkte feed terechtkomt.

Schort daarom tijdens de eerste synchronisatie de automatische bijwerking van productieve feeds en de bijbehorende sleuteltoewijzing op. Laad de initiële dataset volledig, controleer deze en de feedconfiguratie, en wijs de sleutels pas daarna op gecontroleerde wijze toe aan de daarvoor bestemde ringen of activeer de automatische bijwerking ervan. De vertragingslogica is vervolgens bedoeld voor nieuw binnenkomende patchsets; deze scheidt de historische eerste set van een nieuwe instantie niet op betrouwbare wijze.

Feeds, sleutels en clients scheiden

Feeds geven de technische kant van de rollout-ringen weer: ze verbinden het patchkanaal en de vertragingslogica met een groep systemen. Registratiesleutels kunnen aan feeds worden gekoppeld en van serverlimieten worden voorzien. Hierdoor kan een beheerder bijvoorbeeld interne platforms, managed server-oplossingen en afzonderlijke klantomgevingen voorzien van verschillende vrijgavepaden, zonder de agentconfiguratie op elke host afzonderlijk te hoeven wijzigen.

Deze toewijzing vormt echter geen volledige veiligheidsgrens. De optionele functie Bedrijfsonderdelen ondersteunt multi-tenancy in het ePortal, maar vervangt noch netwerksegmentatie, noch een autorisatiemodel, noch gescheiden administratieve verantwoordelijkheden. Ook logboekregistratie, geheimbeheer en de controle op wie sleutels mag aanmaken of feeds mag wijzigen, moeten onafhankelijk van de productfunctie worden gepland en regelmatig worden gecontroleerd.

Voor klantomgevingen is de scheiding tussen patchbeheer en de overige hostingisolatie bijzonder belangrijk. Een sleutel kan de beoogde feedtoewijzing en het aantal registreerbare servers beperken, maar voorkomt geen kruistoegang tot andere infrastructuurcomponenten. Proces- en bestandssysteemisolatie blijven aparte taken; hierover gaat het artikel over CloudLinux SecureLVE het niveau van accounts en websites.

Vanaf ePortal 2.14-1 kunnen API-sleutels voor de openbare API worden gebruikt als alternatief voor basisauthenticatie. Het ePortal-beheer biedt voor API-sleutels onder andere de mogelijkheid om sleutels afzonderlijk in te trekken en een optionele vervaldatum in te stellen. Dit vergemakkelijkt het toekennen van afzonderlijke machtigingen voor CMDB-koppelingen of configuratieautomatisering, mits de rechten van het bijbehorende gebruikersaccount bewust worden beperkt.

Sla tokens op als secrets in een secret-beheersysteem, niet in playbooks, images, shell-geschiedenis of tickets. Dit is een operationele beveiligingsmaatregel en geen eigenschap die automatisch door ePortal wordt afgedwongen. Een praktisch proces wijst aan elke sleutel een eigenaar, een doel, toegestane producten, een serverlimiet en een rotatiedatum toe.

API-sleutels moeten doelgericht worden ingetrokken bij een systeemwijziging, een rolwijziging of wanneer de toegang voor automatisering niet langer nodig is. Registratiesleutels behandel je anders: volgens de documentatie worden bij het verwijderen van een dergelijke sleutel ook alle daaronder geregistreerde servers uit ePortal verwijderd. Plan daarom vóór het verwijderen de migratie naar een nieuwe sleutel of de herregistratie van de betreffende hosts en controleer vervolgens hun feed-toewijzing en check-in-status.

Replicatie en TLS op een robuuste manier uitvoeren

Voor een patchdistributie met hoge beschikbaarheid worden meerdere ePortal-knooppunten zodanig gecombineerd dat KernelCare-agenten een gemeenschappelijke cluster-DNS-naam of een HTTP-load-balancer benaderen. Voor beheerwerkzaamheden gebruik je daarentegen een gecontroleerd, knooppunt-specifiek beheer-eindpunt. Volgens de fabrikant mag je het gemeenschappelijke cluster-eindpunt niet gebruiken voor bewerkingen in de ePortal-beheerinterface.

Vóór de ingebruikname moet de architectuur niet alleen rekening houden met het uitvallen van een ePortal-server. Ook DNS-resolutie, load balancers, certificaten, opslagruimte voor patcharchieven, de verbinding met de patchbron en de bereikbaarheid vanuit elk netwerksegment zijn van belang. Een tweede knooppunt zonder afgestemde netwerk- en bedrijfsmonitoring verbetert de beschikbaarheid slechts in beperkte mate; in geval van een storing kan het zelfs afwijkende toestanden verbergen.

De knooppunten synchroniseren wijzigingen via replicatie. Deze synchronisatie is niet per se onmiddellijk zichtbaar. Met name bij Round-Robin kan een zojuist geregistreerde agent eerst het eerste knooppunt bereiken voor de registratie en direct daarna een nog niet gesynchroniseerd knooppunt voor de update. Automatiseringen moeten daarom voorzien in een korte wachttijd of een herhalingslogica met een beperkt aantal pogingen, in plaats van een onmiddellijk daaropvolgende patch-opvraging te beschouwen als een betrouwbare eindtoestand.

Ook langdurige onderbrekingen maken deel uit van het storingsscenario. Volgens de documentatie worden replicatieprotocollen zeven dagen bewaard; als een knooppunt langer niet verbonden is, kan het wijzigingen overslaan. De Replicatievertraging Het gaat hier dus om een operationele status, niet louter om een diagnosewaarde. Na netwerkstoringen controleer je daarom de feed-toewijzingen, de sleutelvoorraad en het patcharchief op het terugkerende knooppunt, voordat dit weer normaal de verzoeken van agenten afhandelt.

De replicatie vindt plaats via HTTP. Zonder een geschikte TLS-beveiliging worden de replicatiegegevens daarom onversleuteld verzonden. Segmenteer dit dataverkeer ten minste naar een betrouwbaar netwerk of pas TLS aan in overeenstemming met de architectuur. Voor agent-eindpunten die extern of netwerkoverschrijdend bereikbaar zijn, vormt een verifieerbare certificaatketen een belangrijk onderdeel van de TLS-afsluiting; het uitschakelen van de certificaatcontrole is geen aanvaardbare permanente oplossing.

Als er een reverse proxy vóór ePortal staat, moeten toegestane hostnamen worden geconfigureerd, zodat ePortal het aantal hostheader-verzoeken beperkt. De proxy moet bovendien de oorspronkelijke hostheader en X-Forwarded-Proto correct doorgeven. Anders kunnen er onjuiste externe URL's, omleidingsproblemen of een verkeerde inschatting van het gebruikte protocol ontstaan. Deze headerconfiguratie moet daarom deel uitmaken van elke wijziging aan de proxy en de acceptatie daarvan.

Bewijsstukken, back-ups en monitoring opzetten

Voor controleerbare live-patching is periodieke verificatie nodig, niet alleen een succesvolle eerste installatie. Leg ten minste de feedtoewijzing van elke host vast, de laatste check-in van de agent, de gemelde patchstatus en de status van de registratiesleutels. Vul deze gegevens aan met de verantwoordelijke teams en een traceerbaar goedkeuringsbesluit. Zo kan bij een beveiligingsmelding gericht worden vastgesteld welke groep welk implementatiepad gebruikt.

Andere vaste controles hebben betrekking op de groei van de opslagruimte, de beschikbare ruimte voor archieven, de replicatiestatus en de rotatie of intrekking van sleutels die niet langer nodig zijn. API-sleutels zijn geschikter voor geautomatiseerde verzoeken dan gedeelde beheerderswachtwoorden, omdat ze afzonderlijk kunnen worden beheerd, ingetrokken en eventueel van een vervaldatum kunnen worden voorzien. Sla ze als operationele beveiligingsmaatregel op in een geheimenbeheersysteem, niet in images, playbooks of tickets.

Voor een bestaand cluster is de volgende, niet-veranderende controleaanroep een geschikt onderdeel voor monitoring of een geplande healthcheck. Deze levert een machinaal leesbare kortstatus op, inclusief replicatievertraging. Bij een probleem wordt de aanroep beëindigd met exitcode 1; de monitoring moet bij deze status een alarm genereren, maar de oorzaak verder inkaarten aan de hand van knooppunt- en netwerkgegevens.

kc.eportal replication --short-status

ePortal maakt onderscheid tussen een back-up van de gegevens en een back-up van alleen de database. De volledige syntaxis van het commando luidt kc.eportal backup <path_to_archive>; het maakt een back-uparchief aan, inclusief de patchsetbestanden. Met kc.eportal backup-db <path_to_backup> In dat geval maak je alleen een back-up van de databases zonder patchset-bestanden. Deze tweede methode is geschikt voor configuratie- en servergegevens, maar niet voor het lokaal archiveren van patches.

Deze ePortal-back-ups omvatten niet automatisch de gehele omgeving. De configuratie van het besturingssysteem, de configuratie van de reverse-proxy en de load balancer, TLS-certificaten en privésleutels, DNS-instellingen en externe firewall- of geheimbeheerconfiguraties vereisen eigen regels voor back-up en herstel. Definieer per back-uptype het doel, de bewaartermijn, de opslaglocatie en de verantwoordelijke herstelprocedure.

Bij een herstel moet de ePortal-service worden gestopt. Plan deze onderbreking van de dienst, breng indien nodig de betrokken operationele teams op de hoogte en controleer daarna gericht de consistentie van de gegevens en de bereikbaarheid voor agenten. Een back-up is pas geldig na een gecontroleerde, geplande Herstel als betrouwbaar. Daarbij mag een test niet per ongeluk productieve feeds of sleuteltoewijzingen wijzigen.

Foutbeelden en bedrijfsbeslissingen beoordelen

Als verwachte patches uitblijven, moet in eerste instantie onderscheid worden gemaakt tussen een gebrek aan beschikbaarheid, het niet ophalen ervan en het ontbreken van goedkeuring. Controleer de geïnstalleerde agent- en ePortal-versie, de toegewezen sleutel en feed, de juiste distributie inclusief kernelreeks en de verbinding met de patchbron. Een patch kan bovendien ontbreken als de betreffende kernelreeks geen beveiligingsupdates meer ontvangt van de distributieleverancier; live-patching heft deze beperking niet op.

Historische opmerkingen van de fabrikant over oudere componentversies mogen niet worden opgevat als een permanente versie-specificatie. Een opmerking uit december 2025 had onder andere betrekking op KernelCare-Agent 3.x en ePortal 2.20 in het kader van een nieuw, ondertekend patchformaat. Controleer daarom vóór het uitvoeren van updates de huidige Compatibiliteitsmatrix, de daadwerkelijk geïnstalleerde versies en de intern vastgestelde volgorde van de updates.

In de cachemodus kan een cache-miss bij beperkte externe toegang het ophalen van patches vertragen, omdat het benodigde binaire bestand nog niet lokaal aanwezig is. Dit is geen bewijs voor een volledig geïsoleerde werking. Bepaal voor restrictieve zones welke verbindingen zijn toegestaan, hoe ontbrekende archieven worden overgedragen en wie verantwoordelijk is voor de goedkeuring, de integriteit en het tijdstip van deze overdracht.

Een ander foutpatroon is een onverwacht brede uitrol na de eerste download van patcharchieven op een nieuwe instantie. Aangezien de voor het eerst gedownloade archieven voor de vertragingslogica tegelijkertijd als nieuw verschijnen, biedt een eerder ingestelde vertraging geen betrouwbare bescherming tegen een gelijktijdige uitrol. Stel automatische feed-updates en productieve sleuteltoewijzingen uit tijdens de eerste synchronisatie, controleer de initiële inventaris en activeer de productieve ringen pas daarna op een gecontroleerde manier.

Replicatiegaten na een langdurige onderbreking van een knooppunt en defecte reverse-proxies vereisen verschillende maatregelen: in het eerste geval moet de status van het knooppunt worden gesynchroniseerd, in het tweede geval moeten TLS, toegestane hostnamen en doorgestuurde headers worden gecontroleerd. Beide gevallen moeten worden opgenomen in runbooks met een duidelijke escalatieprocedure. Een algemene herstart lost noch ontbrekende gegevens, noch een onjuiste vertrouwensgrens op.

ePortal is vooral zinvol wanneer patchringen, lokale distributie, gecontroleerde netwerkuitgangen of controleerbare vrijgaven daadwerkelijk vereist zijn. Voor een klein, homogeen en internetgeschikt serverpark blijft de directe aansluiting via de TuxCare-infrastructuur vaak eenvoudiger. Bij de beslissing moet daarom de extra operationele inspanning worden afgewogen tegen concrete beheers- en rapportageverplichtingen, en niet alleen tegen het aantal servers.