KernelCare ePortal för större webbhotellsinfrastrukturer

Integrera KernelCare ePortal i vagnparksdriften

KernelCare ePortal är den egenutvecklade hanterings- och distributionskomponenten för KernelCare-agenter i större Linux-miljöer. Den samlar patchuppsättningar, flöden och registreringsnycklar på en kontrollerad plats. På så sätt bestämmer operatören inte bara om värddatorer ska hämta patchar, utan också från vilken lokal källa och enligt vilken godkännandeprocess detta ska ske.

Utan ePortal ansluter agenterna direkt till TuxCare-infrastrukturen. Detta är oftast det enklaste alternativet för små, i stort sett enhetliga och internetanslutna serverparker: det finns ingen ytterligare central plattform som behöver uppdateras, säkras och övervakas. När antalet system ökar blir denna enkelhet dock en nackdel om spårbara godkännanden eller begränsade nätverksutgångar krävs.

I en hostingflotta förekommer ofta webbservrar, databasservrar, virtualiseringsvärdar och hanteringssystem med olika distributioner och kernelserier. En central Patchbeställning gör det möjligt att på ett målinriktat sätt förse dessa tekniska grupper med lämpliga flöden och nycklar. ePortal är därmed inte ett alternativ till KernelCare-agenten, utan utökar dess hämtning av patchuppsättningar med lokal styrning och distribution.

Nyttan beror alltså inte enbart på antalet servrar. Avgörande faktorer är bindande patch-cykler, kontroll- och dokumentationskrav, nätverksspecifikationer samt frågan om en central tjänst i sig kan drivas på ett tillförlitligt sätt. Dessa krav avgör också om lokal spegling, cache eller direkt hämtning är den lämpliga arkitekturen.

Skillnaden mellan Live-Patching, KernelCare och LibCare

På Live-patchning KernelCare-agenten kontrollerar regelbundet om lämpliga patchuppsättningar finns tillgängliga. Den hämtar dessa, verifierar dem och installerar dem i den aktiva kärnan. På så sätt kan säkerhetskorrigeringar träda i kraft utan att det krävs en omstart av kärnan för detta steg. Vilka patchuppsättningar som är tillämpliga beror på den installerade kärnan och den distribution som stöds.

KernelCare avser tjänsten för live-kärnkorrigeringar. LibCare ska inte förväxlas med detta: det är en valfri tilläggsprodukt för vissa användarutrymmeskomponenter och inte ett annat namn för kärnkorrigeringar. ePortal å sin sida patchar inte själva kärnan, utan hanterar patchuppsättningar, flöden och registreringen av KernelCare-agenterna i en lokal företagsinstallation.

Den tidigare benämningen KernelCare Plus bör endast förekomma vid klassificering av äldre dokumentation. Tillverkaren har avslutat försäljningen av denna produkt sedan mars 2023 och ersatt den med KernelCare. Vid inventeringar är det därför viktigt att inte likställa installerade agenter, avtal och dokumentation med aktuella komponenter eller funktionsomfång utifrån historiska produktnamn.

Live-patching ersätter inte en fullständig underhållsprocess. Planerad Nystarter är fortfarande nödvändiga för exempelvis regelbundna kärnbyten, uppdateringar av hårdvara och firmware, drivrutinsändringar, konfigurationsarbete eller felbilder som inte kan åtgärdas i realtid. Ett driftskoncept bör därför kombinera den förkortade exponeringstiden genom patchuppsättningar med fortsatt planerade omstartsfönster, istället för att helt stryka dessa.

När centraliserad patch-hantering är ekonomiskt lönsam

ePortal är lämpligt när verksamheten inte bara behöver distribuera patchar snabbt, utan också måste styra deras distribution på ett bindande sätt. Detta gäller till exempel separata godkännandegrupper för Canary-värdar, staging och produktion, restriktiva utgående brandväggsregler eller dokumentation över vilken värd som tillhörde vilken feed. Även många system med olika plattformar drar nytta av en centralt underhållen distributionsinstans.

Mervärdet måste motivera insatsen. En ePortal-instans kräver kapacitet, uppdateringar, säkerhetskopiering, åtkomstskydd och övervakning; vid hög tillgänglighet tillkommer dessutom replikering och nätverksarkitektur. För ett fåtal likartade servrar med tillåten internetåtkomst är det därför ofta enklare att ansluta direkt via TuxCare-infrastrukturen. Färre komponenter innebär där en mindre egen driftsyta.

Ur ekonomisk synvinkel är central styrning särskilt viktig där oplanerad samtidighet skulle bli kostsam: till exempel vid många kundwebbservrar, databaskluster eller virtualiseringsvärdar. En Process för frisläppande kan då på ett samlat sätt återspegla både tekniska likheter och affärsrisker. Grupperna bör inte bara bildas utifrån plats, utan även ta hänsyn till distribution, kärnserie, hypervisor, kontrollpanel, hårdvara och kundprofil.

Säkerhetsskyddet får dock inte överskattas. KernelCare tillhandahåller i princip endast live-patchar för en kärna så länge som distributionens leverantör publicerar säkerhetsuppdateringar för den aktuella kärnserien. Dessutom är live-patchning inte ett generellt bevis på att alla sårbarheter har åtgärdats. Patchstatus, distributionsstöd och regelbunden underhåll måste fortfarande kontrolleras separat.

Driftsbeslutet innebär därför inte generellt att „centralt är bättre“. ePortal är lämpligt när lokal kontroll, differentierad fördelning och tillförlitlig spårbarhet uppfyller konkreta krav. Om dessa krav saknas kan den medvetet enkla direktanslutningen vara mer robust. I nästa steg avgör den önskade tillhandahållandemodellen lagringsbehovet och externa beroenden.

Välj rätt spegling och cache

Valet av distributionsmodell avgör hur oberoende en hostingflotta är när det gäller hämtning av patchar och hur mycket infrastruktur den måste driva för detta. Vid direktnedladdning hämtar KernelCare-agenter patchuppsättningar via TuxCare-infrastrukturen. ePortal flyttar däremot godkännande, lokal lagring och distribution till en egen instans; den kan spegla patchuppsättningar som ett komplett eller filtrerat arkiv eller cachelagra dem efter behov.

En fullständig spegling är lämplig om redan hämtade patchuppsättningar måste förbli tillgängliga lokalt även vid en avbruten extern anslutning, eller om bindande interna godkännanden kräver detta. En filtrerad spegling begränsar arkivstorleken och datatrafiken till de distributioner som faktiskt används. För detta måste inventeringen på ett tillförlitligt sätt registrera vilka kernelserier och arkitekturer som används i maskinparken; annars saknas just det arkivet när en värd behöver det.

Der Cache-läge sparar lagringsutrymme, men är inte synonymt med en helt isolerad drift. ePortal laddar ner metadata och hämtar binärdata för uppdateringar från källan vid behov; enligt dokumentationen lagras nedladdade binärdata i den lokala cachen i två veckor. För isolerade agentnätverk kan detta räcka, så länge ePortal får använda den tillåtna uppströmsvägen.

En ePortal-server som drivs helt i en isolerad miljö ska bedömas separat. Nya patcharkiv måste då införas via en separat planerad manuell överföring. Definiera därför källkontroll, integritets- och signaturkontroll, media- eller nätverksgodkännande, importordning och ansvarsområden. Varken filtrerad eller fullständig spegling genererar denna process automatiskt; de avgör endast vilka arkiv som ePortal lagrar lokalt.

Lagringsplaneringen bör inte begränsas till storleken på det aktuella arkivet. TuxCare anger som riktlinje för ePortal SSD-lagring med minst 100 IOPS samt en tillväxt på cirka 4 till 5 GiB per månad. Dessa tillverkaruppgifter ersätter inte kapacitetsplaneringen: återställningsmål, parallella driftsättningar, nätverksfördröjningar, antalet kärnvarianter och övervakningskrav kan påverka arkitekturen i högre grad än ledig diskkapacitet.

Skapa patch-ringar för värdflottor

Patch-ringar omvandlar en centralt tillgänglig patchuppsättning till en kontrollerad utrullning. En liten ”canary”-grupp får godkännandet först, därefter följer staging, en begränsad produktionsgrupp och slutligen den breda produktionen. Varje ring kräver i förväg definierade övervakningsmått och en ansvarig instans; utan dessa kriterier innebär en försening endast att risken skjuts upp istället för att utvärderas.

För produktionsringarna gäller att Stall den avsedda kanalen. Testing lämpar sig för en separat, medvetet kontrollerad utvärderingsprocess, eftersom denna kanal omfattar alla tillgängliga patchuppsättningar och därmed kan innehålla ytterligare patchuppsättningar som ännu inte har markerats för Stable. Enligt dokumentationen är Unstable en kanal för tidig åtkomst och rekommenderas inte. Testing och Unstable ska därför inte betraktas som allmänna produktionsversioner.

Ringarna bör sammansättas utifrån teknisk likhet istället för enbart datacentrets plats. Relevanta faktorer är distribution och kernelserien, hårdvaruplattform, virtualisering, kontrollpanel, webbserverstack och kundprofil. En Canary-värd med en annan kernelserien eller annan virtualisering täcker endast i begränsad utsträckning beteendet hos ett produktivt målsystem. Vid delad hosting gäller resursprofiler och konfigurationer av CloudLinux LVE-hanterare i denna utvärdering, eftersom de kan påverka belastnings- och felmönster.

Särskild försiktighet bör iakttas vid nya ePortal-instanser. Enligt tillverkarens uppgifter kontrollerar ePortal var tionde minut om det finns nya patchuppsättningar och laddar ner dem, men gör dem inte automatiskt tillgängliga för alla flöden. När arkiv laddas ner för första gången tilldelas de ingående patchuppsättningarna samma publiceringstidpunkt. En redan konfigurerad fördröjning kan därför leda till att hela det ursprungliga beståndet hamnar i ett automatiskt uppdaterat flöde när fördröjningen har löpt ut.

Avbryt därför den automatiska uppdateringen av produktiva flöden och deras produktiva nyckel tilldelning under den inledande synkroniseringen. Ladda in den initiala datamängden fullständigt, kontrollera den samt flödeskonfigurationen och tilldela därefter nycklarna på ett kontrollerat sätt till de avsedda ringarna eller aktivera deras automatiska uppdatering. Fördröjningslogiken används därefter för nyinkommande patchset; den skiljer inte på ett tillförlitligt sätt ut den historiska startdatauppsättningen för en ny instans.

Separera flöden, nycklar och klienter

Feeds återspeglar den tekniska sidan av utrullningsringarna: de kopplar samman patchkanalen och fördröjningslogiken med en grupp system. Registreringsnycklar kan kopplas till feeds och förses med serverbegränsningar. På så sätt kan en operatör till exempel förse interna plattformar, managed server-tjänster och separata kundmiljöer med olika godkännandevägar utan att behöva ändra agentkonfigurationen på varje värd separat.

Denna klassificering utgör dock inte en fullständig säkerhetsgräns. Den valfria funktionen Affärsenheter Stöder multitenancy i ePortal, men ersätter varken nätverkssegmentering, behörighetsmodell eller separata administrativa ansvarsområden. Även loggning, hantering av hemligheter och kontrollen av vem som får skapa nycklar eller ändra flöden måste planeras och regelbundet granskas oberoende av produktfunktionen.

I klientmiljöer är det särskilt viktigt att skilja mellan hanteringen av uppdateringar och övrig isolering av värdtjänster. En nyckel kan begränsa den avsedda tilldelningen av flöden och antalet registrerbara servrar, men förhindrar inte tvärgående åtkomst i andra infrastrukturkomponenter. Process- och filsystemisolering förblir separata uppgifter; detta kompletteras av artikeln om CloudLinux SecureLVE nivån för konton och webbplatser.

Från och med ePortal 2.14-1 kan API-nycklar användas för det offentliga API:et som ett alternativ till grundläggande autentisering. I ePortal-administrationen kan API-nycklar bland annat återkallas individuellt och förses med ett valfritt utgångsdatum. Detta underlättar separata behörigheter för CMDB-anslutningar eller konfigurationsautomatisering, förutsatt att behörigheterna för det tillhörande användarkontot medvetet begränsas.

Spara token som hemligheter i ett system för hantering av hemligheter, inte i playbooks, bilder, shell-historik eller ärenden. Detta är en operativ säkerhetsåtgärd och inte en egenskap som automatiskt tvingas fram av ePortal. En praktiskt tillämpbar process tilldelar varje nyckel en ägare, ett syfte, tillåtna produkter, en servergräns och ett rotationsdatum.

API-nycklar bör återkallas specifikt vid ett systembyte, ett rollbyte eller när åtkomst för automatisering inte längre behövs. Registreringsnycklar hanteras på ett annat sätt: enligt dokumentationen innebär borttagandet av en sådan nyckel att även alla servrar som är registrerade under den tas bort från ePortal. Planera därför innan du raderar att migrera till en ny nyckel eller att omregistrera de berörda värdarna och kontrollera därefter deras feed-tilldelning samt incheckningsstatus.

Att driva replikering och TLS på ett stabilt sätt

För en distribution av patchar med hög tillgänglighet Flera ePortal-noder kombineras så att KernelCare-agenter ansluter till ett gemensamt kluster-DNS-namn eller en HTTP-lastbalanserare. För administrativa uppgifter använder du däremot en kontrollerad, nodspecifik administratörsändpunkt. Enligt tillverkaren får du inte använda den gemensamma klusterändpunkten för åtgärder i ePortals administrationsgränssnitt.

Innan driftsättningen bör arkitekturen inte bara ta hänsyn till ett eventuellt fel på en ePortal-server. Även DNS-upplösning, lastbalanserare, certifikat, lagringsutrymme för patcharkiv, anslutningen till patchenkällan och tillgängligheten från varje nätverkssegment är relevanta faktorer. En andra nod utan samordnad nätverks- och driftsövervakning förbättrar tillgängligheten endast i begränsad utsträckning; vid ett fel kan den till och med dölja avvikande tillstånd.

Noderna synkroniserar ändringar genom replikering. Denna synkronisering syns inte nödvändigtvis omedelbart. Särskilt vid Round-Robin-metoden kan en agent som just har registrerats nå den första noden för registrering och direkt därefter en nod som ännu inte har synkroniserats för uppdatering. Automatiseringar bör därför inkludera en kort väntetid eller en logik för återförsök med ett begränsat antal försök, istället för att behandla en omedelbart efterföljande hämtning av en patch som ett tillförlitligt slutresultat.

Även längre avbrott ingår i felscenariot. Enligt dokumentationen sparas replikeringsprotokollen i sju dagar; om en nod förblir frånkopplad längre än så kan den missa ändringar. Den Replikationsfördröjning Det är alltså ett operativt tillstånd, inte bara ett diagnosvärde. Efter nätverksstörningar bör du därför kontrollera feed-tilldelningar, nyckelbeståndet och patcharkivet på den återanslutna noden innan den återgår till att hantera agentförfrågningar som vanligt.

Replikeringen sker via HTTP. Utan lämplig TLS-säkerhet överförs därför replikeringsdata okrypterat. Segmentera denna datatrafik åtminstone till ett betrott nätverk eller konfigurera TLS på ett sätt som passar arkitekturen. För agentändpunkter som är tillgängliga externt eller över nätverksgränserna är en verifierbar certifikatkedja en viktig del av TLS-avslutning; att inaktivera certifikatkontrollen är ingen acceptabel långsiktig lösning.

Om det finns en omvänd proxy framför ePortal måste tillåtna värdnamn konfigureras så att ePortal begränsar förfrågningar om värdheadern. Proxyn måste dessutom vidarebefordra den ursprungliga värdheadern samt X-Forwarded-Proto korrekt. I annat fall kan felaktiga externa URL:er, vidarebefordringsproblem eller en felaktig bedömning av vilket protokoll som används uppstå. Denna header-konfiguration bör därför ingå i varje proxyändring och dess godkännande.

Införa dokumentation, säkerhetskopiering och övervakning

För att kunna kontrollera live-patching krävs återkommande verifieringar, inte bara en lyckad första installation. Registrera åtminstone varje värds feed-tilldelning, den senaste agentincheckningen, den rapporterade patchstatusen och statusen för registreringsnycklarna. Komplettera dessa uppgifter med ansvariga team och ett spårbart godkännandebeslut. På så sätt går det att vid en säkerhetsrapportering specifikt fastställa vilken grupp som använder vilken distributionsväg.

Andra regelbundna kontroller avser lagringsutrymmets tillväxt, ledigt utrymme för arkiv, replikeringsstatus samt rotation eller återkallande av nycklar som inte längre behövs. API-nycklar är bättre lämpade för automatiserade förfrågningar än delade administratörslösenord, eftersom de kan hanteras och återkallas individuellt samt, om så önskas, förses med ett utgångsdatum. Förvara dem i en hemlighetshantering som en operativ säkerhetsåtgärd, inte i bilder, playbooks eller ärenden.

För ett befintligt kluster är följande, icke-förändrande kontrollanrop en lämplig komponent för övervakning eller en planerad hälsokontroll. Det ger en maskinläsbar kortstatus, inklusive replikeringsfördröjning. Vid ett problem avslutas anropet med exitkod 1; övervakningen bör larmas vid detta tillstånd, men orsaken bör avgränsas ytterligare utifrån nod- och nätverksdata.

kc.eportal replication --short-status

ePortal skiljer mellan en arkiveringskörning för säkerhetskopiering av data och en ren säkerhetskopiering av databasen. Den fullständiga kommandosyntaxen lyder kc.eportal backup <path_to_archive>; den skapar ett säkerhetskopieringsarkiv som innehåller patchset-filerna. Med kc.eportal backup-db <path_to_backup> I det här fallet säkerhetskopierar du endast databaserna utan patchset-filer. Denna andra metod lämpar sig för konfigurations- och serverdata, men inte för lokal arkivering av patchar.

Dessa ePortal-säkerhetskopior omfattar inte automatiskt hela miljön. Operativsystemskonfiguration, konfiguration av omvänd proxy och lastbalanserare, TLS-certifikat och privata nycklar, DNS-inställningar samt externa brandväggs- eller hemlighetshanteringskonfigurationer kräver egna regler för säkerhetskopiering och återställning. Definiera för varje säkerhetskopieringstyp syfte, lagringstid, lagringsplats och den ansvariga återställningsvägen.

Vid en återställning måste ePortal-tjänsten stängas av. Planera för detta avbrott, informera vid behov berörda driftsteam och kontrollera därefter noggrant datakonsistensen samt tillgängligheten för agenterna. En säkerhetskopiering anses giltig först efter en kontrollerad och planerad Återställ som tillförlitlig. En test får inte av misstag ändra produktiva flöden eller nyckeltilldelningar.

Utvärdera felbilder och driftsbeslut

Om förväntade patchar uteblir måste man först skilja mellan bristande tillgänglighet, bristande hämtning och bristande godkännande. Kontrollera versionen av den installerade agenten och ePortal, tilldelade nycklar och flöden, rätt distribution inklusive kernelserien samt anslutningen till patchkällan. En patch kan dessutom saknas om den aktuella kernelserien inte längre får säkerhetsuppdateringar från distributionsleverantören; live-patching upphäver inte denna begränsning.

Historiska anvisningar från tillverkaren om äldre komponentversioner får inte tolkas som permanenta versionskrav. En anvisning från december 2025 gällde bland annat KernelCare-Agent 3.x och ePortal 2.20 i samband med ett nytt signerat patchformat. Innan du uppdaterar bör du därför kontrollera den aktuella Kompatibilitetsmatris, de versioner som faktiskt har installerats och den uppdateringsordning som har godkänts internt.

I cache-läge kan en cache-miss vid begränsad extern åtkomst fördröja hämtningen av patchar, eftersom den nödvändiga binärfilen ännu inte finns lokalt. Detta är inte ett bevis på en helt isolerad drift. Fastställ för restriktiva zoner vilka anslutningar som är tillåtna, hur saknade arkiv ska överföras och vem som ansvarar för godkännande, integritet och tidpunkt för denna överföring.

Ett annat felmönster är en oväntat omfattande utrullning efter den första nedladdningen av patcharkiv till en ny instans. Eftersom de arkiv som laddas ner för första gången samtidigt uppfattas som nya av fördröjningslogiken, skyddar en tidigare inställd fördröjning inte tillförlitligt mot en gemensam distribution. Håll tillbaka automatiska feed-uppdateringar och produktiva nyckeltilldelningar under den inledande synkroniseringen, kontrollera det initiala beståndet och aktivera de produktiva ringarna först därefter på ett kontrollerat sätt.

Replikationsluckor efter ett längre avbrott i noden och felaktiga omvända proxyservrar kräver olika åtgärder: De förstnämnda kräver en synkronisering av nodens status, de sistnämnda en kontroll av TLS, tillåtna värdnamn samt vidarebefordrade rubriker. Båda fallen ska ingå i runbooks med tydliga eskaleringsrutiner. En generell omstart åtgärdar varken saknade data eller en felaktig förtroendegräns.

ePortal är framför allt lämpligt när patch-ringar, lokal distribution, kontrollerade nätverksutgångar eller verifierbara godkännanden faktiskt krävs. För en liten, homogen och internetansluten serverpark är det ofta enklare att ansluta direkt via TuxCare-infrastrukturen. Beslutet bör därför väga den extra driftskostnaden mot konkreta styrnings- och dokumentationskrav, inte enbart mot antalet servrar.