KernelCare ePortal til større hosting-infrastrukturer

Integrering af KernelCare ePortal i flådedriften

KernelCare ePortal er den selvdrevne administrations- og distributionskomponent til KernelCare-agenter i større Linux-miljøer. Den samler patch-sæt, feeds og registreringsnøgler på ét kontrolleret sted. Dermed bestemmer operatøren ikke kun, om værter skal hente opdateringer, men også fra hvilken lokal kilde og efter hvilke godkendelsesregler dette skal ske.

Uden ePortal kontakter agenterne direkte TuxCare-infrastrukturen. For små, stort set ensartede og internetforbundne serverparker er dette som regel den nemmeste løsning: Der er ingen ekstra central platform, der skal opdateres, sikres og overvåges. Med et stigende antal systemer bliver denne enkelhed imidlertid en ulempe, når der kræves sporbare godkendelser eller begrænsede netværksudgange.

I en hostingflåde findes der ofte webservere, databaseservere, virtualiseringsværter og styringssystemer med forskellige distributioner og kernelserier. En central Patch-køb gør det muligt at forsyne disse tekniske grupper målrettet med passende feeds og nøgler. ePortal er dermed ikke et alternativ til KernelCare-agenten, men udvider dennes hentning af patch-sæt med lokal styring og distribution.

Fordelen skyldes altså ikke alene antallet af servere. Afgørende er bindende patch-cyklusser, kontrol- og dokumentationskrav, netværksspecifikationer samt spørgsmålet om, hvorvidt en central tjeneste selv kan drives pålideligt. Disse krav afgør også, om lokal spejling, cache eller direkte hentning er den mest hensigtsmæssige arkitektur.

Skelne mellem Live-Patching, KernelCare og LibCare

På Live-patching KernelCare-agenten kontrollerer regelmæssigt, om der er passende patch-sæt tilgængelige. Den henter dem, verificerer dem og installerer dem i den kørende kerne. Sikkerhedsrettelser kan dermed træde i kraft uden at det er nødvendigt at genstarte kernen. Hvilke patch-sæt der kan anvendes, afhænger af den installerede kerne og den understøttede distribution.

KernelCare betegner tilbuddet om live-kernel-patches. LibCare skal holdes adskilt herfra: Det er et valgfrit tillægsprodukt til bestemte userspace-komponenter og ikke et andet navn for kernel-patching. ePortal laver derimod ikke selv patches til kernen, men administrerer patch-sæt, feeds og registreringen af KernelCare-agenterne i en lokal virksomhedsinstallation.

Den tidligere betegnelse »KernelCare Plus« bør kun forekomme i forbindelse med klassificering af ældre dokumentation. Producenten har udfaset dette produkt siden marts 2023 og erstattet det med KernelCare. Ved opgørelser er det derfor vigtigt ikke at sidestille installerede agenter, kontrakter og dokumentation med aktuelle komponenter eller funktionsomfang på baggrund af historiske produktnavne.

Live-patching er ikke en erstatning for en fuldstændig vedligeholdelsesproces. Planlagt Genstart er stadig nødvendige, f.eks. i forbindelse med regelmæssige kerneudskiftninger, hardware- og firmwareopdateringer, driverændringer, konfigurationsarbejde eller fejlscenarier, der ikke kan løses i realtid. Et driftskoncept bør derfor kombinere den reducerede eksponering gennem patch-sæt med de fortsat planlagte genstartvinduer, i stedet for at fjerne disse helt.

Hvornår er central patch-styring økonomisk fordelagtig

ePortal er det rette valg, når virksomheden ikke blot skal distribuere patches hurtigt, men også skal styre udrulningen på en bindende måde. Det gælder for eksempel separate godkendelsesgrupper for Canary-hosts, staging og produktion, restriktive udgående firewall-regler eller dokumentation for, hvilken host der var tildelt hvilket feed. Også mange systemer med forskellige platforme drager fordel af en centralt vedligeholdt distributionsinstans.

Den ekstra fordel skal retfærdiggøre indsatsen. En ePortal-instans kræver kapacitet, opdateringer, sikkerhedskopier, adgangsbeskyttelse og overvågning; ved høj tilgængelighed kommer replikering og netværksarkitektur oveni. For få ensartede servere med tilladt internetadgang er det derfor ofte nemmere at benytte TuxCare-infrastrukturen direkte. Færre komponenter betyder i dette tilfælde et mindre eget driftsområde.

Fra et økonomisk synspunkt er central styring især fordelagtig dér, hvor uplanlagt samtidighed ville være dyr: for eksempel ved mange kundewebservere, databaseklynger eller virtualiseringsværter. En Udgivelsesproces kan dermed afspejle både tekniske ligheder og forretningsmæssige risici. Grupperne bør ikke kun dannes ud fra placering, men også tage højde for distribution, kernelserie, hypervisor, kontrolpanel, hardware og kundeprofil.

Sikkerhedsdækningen må dog ikke overvurderes. KernelCare stiller som udgangspunkt kun live-patches til rådighed for en kerne, så længe distributionens udbyder udgiver sikkerhedsopdateringer til den pågældende kerneserie. Desuden er live-patching ikke et generelt bevis på, at alle sårbarheder er blevet rettet. Patchstatus, distributionssupport og regelmæssig vedligeholdelse skal fortsat kontrolleres separat.

Driftsbeslutningen lyder derfor ikke generelt: „centralt er bedre“. ePortal er hensigtsmæssigt, når lokal kontrol, differentieret fordeling og pålidelig sporbarhed opfylder konkrete krav. Mangler disse krav, kan den bevidst enkle direkte indkøb være mere robust. I det næste trin er det den ønskede leveringsmodel, der afgør lagerbehovet og de eksterne afhængigheder.

Vælg den rigtige spejling og cache

Valget af distributionsmodel afgør, hvor uafhængig en hostingflåde er, når det gælder hentning af opdateringer, og hvor meget infrastruktur den skal drive til dette formål. Ved direkte hentning henter KernelCare-agenter patch-sæt via TuxCare-infrastrukturen. ePortal flytter derimod frigivelse, lokal opbevaring og distribution til en egen instans; den kan spejle patch-sæt som et komplet eller filtreret arkiv eller cache dem efter behov.

En fuld spejling er hensigtsmæssig, hvis allerede hentede patch-sæt skal forblive tilgængelige lokalt, selv når den eksterne forbindelse er afbrudt, eller hvis bindende interne godkendelser kræver dette. En filtreret spejling begrænser arkivstørrelsen og datatrafikken til de distributioner, der faktisk anvendes. Til dette formål skal inventariseringen pålideligt registrere, hvilke kernelserier og arkitekturer flåden anvender; ellers mangler der netop et arkiv, når en host har brug for det.

Der Cache-tilstand Det sparer lagerplads, men er ikke det samme som fuldstændig isoleret drift. ePortal indlæser metadata og henter patch-binærdata fra kilden efter behov; ifølge dokumentationen forbliver de downloadede binærdata i den lokale cache i to uger. For isolerede agentnetværk kan dette være tilstrækkeligt, så længe ePortal har tilladelse til at benytte den tilladte upstream-sti.

En ePortal-server, der drives fuldstændigt isoleret fra netværket, skal vurderes separat. Nye patcharkiver skal i så fald importeres via en separat planlagt manuel overførsel. Definer i den forbindelse kildekontrol, integritets- og signaturkontrol, medie- eller netværksgodkendelse, importrækkefølge og ansvarsfordeling. Hverken filtreret eller fuldstændig spejling genererer denne proces automatisk; de bestemmer kun, hvilke arkiver ePortal opbevarer lokalt.

Lagringsplanlægningen bør ikke begrænses til det nuværende arkivs størrelse. TuxCare angiver som retningslinje for ePortal SSD-lager med mindst 100 IOPS samt en vækst på ca. 4 til 5 GiB om måneden. Disse producentoplysninger erstatter ikke kapacitetsplanlægningen: Genopretningsmål, parallelle udrulninger, netværksforsinkelser, antallet af kernevarianter og overvågningskrav kan have større indflydelse på arkitekturen end ledig diskplads.

Oprettelse af patch-ringe til hostingflåder

Patch-ringe sikrer en kontrolleret udrulning ud fra et centralt tilgængeligt patch-sæt. En lille »Canary«-gruppe får først godkendelsen, derefter følger »Staging«, en begrænset produktionsgruppe og til sidst den brede produktion. Hver ring kræver på forhånd definerede overvågningsparametre og en ansvarlig instans; uden disse kriterier udskyder en forsinkelse blot risikoen i stedet for at vurdere den.

For produktionsringene gælder, at Stald den påtænkte kanal. Testing er velegnet til en separat, bevidst kontrolleret evalueringsproces, fordi denne kanal omfatter alle tilgængelige patchsæt og dermed kan indeholde yderligere patchsæt, der endnu ikke er markeret som Stable. Unstable er ifølge dokumentationen en Early-Access-kanal og anbefales ikke. Testing og Unstable skal derfor ikke betragtes som generel produktionsbevis.

Ringe bør sammensættes ud fra teknisk lighed i stedet for udelukkende ud fra datacentrets placering. Relevante faktorer er distribution og kernelserien, hardwareplatform, virtualisering, kontrolpanel, webserver-stack og kundeprofil. En Canary-host med en anden kernelserien eller en anden virtualisering dækker kun i begrænset omfang adfærden i et produktivt målsystem. Ved shared hosting omfatter ressourceprofiler og konfigurationer af CloudLinux LVE-administratorer i denne vurdering, da de kan påvirke belastnings- og fejlbilleder.

Der skal udvises særlig forsigtighed med nye ePortal-instanser. Ifølge producentens oplysninger tjekker ePortal hvert tiende minut, om der er nye patch-sæt, og henter dem, men stiller dem ikke automatisk til rådighed for alle feeds. Når arkiver hentes for første gang, tildeles de indeholdte patch-sæt samme udgivelsestidspunkt. En allerede konfigureret forsinkelse kan derfor medføre, at hele den oprindelige beholdning, når forsinkelsen er udløbet, overføres til et automatisk opdateret feed.

Undlad derfor under den indledende synkronisering at udføre automatisk opdatering af produktive feeds og deres produktive nøgletildeling. Indlæs den første datamængde fuldstændigt, kontroller den samt feedkonfigurationen, og tildel først derefter nøglerne kontrolleret til de påtænkte ringe, eller aktiver deres automatiske opdatering. Forsinkelseslogikken anvendes derefter til nye patch-sæt, der ankommer; den adskiller ikke pålideligt den historiske startdatasæt fra en ny instans.

Adskil feeds, nøgler og klienter

Feeds udgør den tekniske side af rollout-ringene: De forbinder patchkanalen og forsinkelseslogikken med en gruppe af systemer. Registreringsnøgler kan knyttes til feeds og forsynes med serverbegrænsninger. Dermed kan en operatør f.eks. forsyne interne platforme, managed server-tilbud og separate kundemiljøer med forskellige frigivelsesveje uden at skulle ændre agentkonfigurationen på hver enkelt host.

Denne indstilling udgør dog ikke en fuldstændig sikkerhedsgrænse. Den valgfri funktion Forretningsenheder Understøtter multi-tenancy i ePortal, men erstatter hverken netværkssegmentering, en adgangsretningsmodel eller adskilte administrative ansvarsområder. Også logføring, hemmelighedsstyring og kontrollen af, hvem der må oprette nøgler eller ændre feeds, skal planlægges og kontrolleres regelmæssigt uafhængigt af produktfunktionen.

I klientmiljøer er adskillelsen mellem patchstyring og den øvrige hosting-isolering særligt vigtig. En nøgle kan begrænse den tilsigtede feed-tildeling og antallet af servere, der kan registreres, men forhindrer ikke tværgående adgang til andre infrastrukturkomponenter. Proces- og filsystemisolering forbliver separate opgaver; dette suppleres af artiklen om CloudLinux SecureLVE på niveauet for konti og websteder.

Fra ePortal 2.14-1 kan API-nøgler til den offentlige API anvendes som alternativ til Basic Authentication. ePortal-administrationen tillader blandt andet, at API-nøgler kan tilbagekaldes enkeltvis, samt at der angives en valgfri udløbsdato. Dette letter oprettelsen af separate tilladelser til CMDB-integrationer eller konfigurationsautomatisering, forudsat at rettighederne for den tilhørende brugerkonto bevidst begrænses.

Gem tokens som hemmeligheder i et hemmelighedsstyringssystem, ikke i playbooks, images, shell-historikker eller tickets. Dette er en driftsmæssig sikkerhedsforanstaltning og ikke en egenskab, der automatisk håndhæves af ePortal. En praktisk proces tildeler hver nøgle en ejer, et formål, tilladte produkter, en servergrænse og en rotationsdato.

API-nøgler bør målrettet tilbagekaldes ved et systemsskifte, et rolleændring eller hvis adgangen til automatiseringen ikke længere er nødvendig. Registreringsnøgler skal du håndtere anderledes: Ifølge dokumentationen vil fjernelsen af en sådan nøgle også fjerne alle de servere, der er registreret under den, fra ePortal. Planlæg derfor inden sletningen overførslen til en ny nøgle eller omregistreringen af de berørte værter, og kontroller derefter deres feed-tildeling samt check-in-status.

Drift af replikering og TLS på en robust måde

For en distribution af opdateringer med høj tilgængelighed kombineres flere ePortal-noder på en sådan måde, at KernelCare-agenter henvender sig til et fælles cluster-DNS-navn eller en HTTP-load-balancer. Til administrative opgaver skal du derimod bruge et kontrolleret, knudespecifikt admin-endepunkt. Ifølge producenten må du ikke bruge det fælles cluster-endepunkt til operationer i ePortal-administrationsgrænsefladen.

Inden idriftsættelsen bør arkitekturen ikke kun tage højde for nedbrud på en ePortal-server. Også DNS-opløsning, load balancer, certifikater, lagerplads til patcharkiver, forbindelsen til patchkilden og tilgængeligheden fra hvert netværkssegment er relevante faktorer. En ekstra node uden koordineret netværks- og driftsovervågning forbedrer tilgængeligheden kun i begrænset omfang; i tilfælde af en fejl kan den endda skjule afvigende tilstande.

Knudepunkterne synkroniserer ændringer via replikering. Denne synkronisering er ikke nødvendigvis synlig med det samme. Især ved Round-Robin kan en agent, der netop er blevet registreret, først nå det første knudepunkt til registrering og umiddelbart derefter et knudepunkt, der endnu ikke er synkroniseret, til opdatering. Automatiseringer bør derfor indeholde et kort ventetidspunkt eller en gentagelseslogik med et begrænset antal gentagelser, i stedet for at behandle en umiddelbart efterfølgende hentning af en patch som en pålidelig slutstatus.

Også længerevarende afbrydelser indgår i fejlscenariet. Ifølge dokumentationen opbevares replikeringsprotokoller i syv dage; hvis en node forbliver afbrudt i længere tid, kan den gå glip af ændringer. Den Replikationsforsinkelse Det er altså en driftsstatus, ikke blot en diagnoseværdi. Efter netværksforstyrrelser skal du derfor kontrollere feed-tildelinger, nøglebeholdningen og patcharkivet på den genoprettede node, inden den igen behandler agentforespørgsler som normalt.

Replikeringen foregår via HTTP. Uden en passende TLS-sikring overføres replikeringsdataene derfor ukrypteret. Opdel denne datatrafik i mindst et pålideligt netværk, eller konfigurer TLS i overensstemmelse med arkitekturen. For agentendepunkter, der er tilgængelige eksternt eller på tværs af netværk, er en verificerbar certifikatkæde en vigtig del af TLS-afslutning; en deaktiveret certifikatkontrol er ikke en forsvarlig langsigtet løsning.

Hvis der er en reverse proxy foran ePortal, skal de tilladte værtsnavne konfigureres, så ePortal begrænser anmodninger om værtsheadere. Proxyen skal desuden videresende den oprindelige værtsheader samt X-Forwarded-Proto korrekt. Ellers kan der opstå forkerte eksterne URL'er, omdirigeringsproblemer eller en fejlagtig vurdering af det anvendte protokol. Denne header-konfiguration bør derfor være en del af enhver ændring af proxyen og godkendelsen heraf.

Indføre dokumentation, sikkerhedskopiering og overvågning

Kontrollerbar live-patching kræver løbende dokumentation, ikke blot en vellykket første installation. Registrer som minimum hver hosts feed-tildeling, den seneste agent-check-in, den rapporterede patch-status og status for registreringsnøglerne. Suppler disse data med oplysninger om de ansvarlige teams og en sporbar godkendelsesbeslutning. På den måde kan man ved en sikkerhedsmeddelelse målrettet fastslå, hvilken gruppe der bruger hvilken implementeringsvej.

Andre faste kontroller vedrører lagerpladsvækst, ledig plads til arkiver, replikeringsstatus samt rotation eller tilbagekaldelse af nøgler, der ikke længere er nødvendige. API-nøgler er bedre egnet til automatiserede forespørgsler end delte administratoradgangskoder, fordi de kan administreres individuelt, tilbagekaldes og eventuelt forsynes med en udløbsdato. Opbevar dem som en sikkerhedsforanstaltning i en hemmelighedsstyring, ikke i billeder, playbooks eller tickets.

For en eksisterende klynge er følgende, ikke-ændrende kontrolkald et velegnet element til overvågning eller en planlagt sundhedstjek. Det leverer en maskinlæsbar kortstatus, herunder replikeringsforsinkelse. I tilfælde af et problem afsluttes opkaldet med exit-kode 1; overvågningen bør udløse en alarm ved denne tilstand, men yderligere indsnævre årsagen på baggrund af node- og netværksdata.

kc.eportal replication --short-status

ePortal skelner mellem en arkiveringskørsel af en sikkerhedskopi og en ren sikkerhedskopi af databasen. Den fulde kommandosyntaks lyder kc.eportal backup <path_to_archive>; den opretter et sikkerhedskopieringsarkiv, der indeholder patchset-filerne. Med kc.eportal backup-db <path_to_backup> I stedet sikkerhedskopierer du kun databaserne uden patch-sæt-filer. Denne anden metode er velegnet til konfigurations- og serverdata, men ikke til lokal arkivering af patches.

Disse ePortal-sikkerhedskopier omfatter ikke automatisk hele miljøet. Operativsystemkonfiguration, reverse-proxy- og load-balancer-konfiguration, TLS-certifikater og private nøgler, DNS-indstillinger samt eksterne firewall- eller secret management-konfigurationer kræver egne sikkerheds- og gendannelsesregler. Definer for hver sikkerhedskopieringstype formål, opbevaringsperiode, lagringssted og den ansvarlige gendannelsesvej.

Ved en gendannelse skal ePortal-tjenesten stoppes. Planlæg denne afbrydelse af tjenesten, informer om nødvendigt de berørte driftshold, og kontroller derefter nøje datakonsistensen samt agenternes adgang. En sikkerhedskopiering gælder først efter en kontrolleret, planlagt Gendan som pålidelig. En test må ikke ved en fejltagelse ændre produktive feeds eller nøgletildelinger.

Vurdering af fejlmønstre og driftsbeslutninger

Hvis forventede patches udebliver, skal der først skelnes mellem manglende tilgængelighed, manglende hentning og manglende frigivelse. Kontroller den installerede agent- og ePortal-version, de tildelte nøgler og feeds, den relevante distribution samt kernelserien og forbindelsen til patchkilden. En patch kan desuden mangle, hvis den pågældende kernelserie ikke længere modtager sikkerhedsopdateringer fra distributionsudbyderen; live-patching ophæver ikke denne begrænsning.

Historiske producentmeddelelser vedrørende ældre komponentversioner må ikke opfattes som faste versionsangivelser. En meddelelse fra december 2025 vedrørte blandt andet KernelCare-Agent 3.x og ePortal 2.20 i forbindelse med et nyt signeret patch-format. Før du foretager opdateringer, skal du derfor kontrollere den aktuelle Kompatibilitetsmatrix, de faktisk installerede versioner og den internt godkendte rækkefølge for opdateringerne.

I cache-tilstand kan en cache-miss ved begrænset ekstern adgang forsinke hentningen af en patch, fordi den nødvendige binærfil endnu ikke findes lokalt. Dette er ikke et bevis på fuldstændig isoleret drift. Fastlæg for restriktive zoner, hvilke forbindelser der er tilladt, hvordan manglende arkiver overføres, og hvem der er ansvarlig for godkendelse, integritet og tidspunktet for denne overførsel.

Et andet fejlscenarie er en uventet bred udrulning efter den første download af patcharkiver til en ny instans. Da de arkiver, der downloades for første gang, samtidig fremstår som nye for forsinkelseslogikken, beskytter en tidligere indstillet forsinkelse ikke pålideligt mod en fælles udrulning. Udsæt automatiske feed-opdateringer og produktive nøgletildelinger under den indledende synkronisering, kontroller den indledende beholdning, og aktiver først derefter de produktive ringe på en kontrolleret måde.

Replikationshuller efter længerevarende afbrydelser i knudepunkterne og fejlbehæftede reverse-proxyer kræver forskellige foranstaltninger: Førstnævnte kræver en afstemning af knudepunktets tilstand, sidstnævnte en kontrol af TLS, tilladte værtsnavne samt videresendte headere. Begge tilfælde skal indgå i runbooks med klare eskaleringsprocedurer. En generel genstart løser hverken manglende data eller en forkert tillidsgrænse.

ePortal er især nyttigt, når der reelt er behov for patch-ringe, lokal distribution, kontrollerede netværksudgange eller verificerbare godkendelser. For en lille, homogen og internetkompatibel serverpark er det ofte nemmere at hente data direkte via TuxCare-infrastrukturen. Beslutningen bør derfor afveje den ekstra driftsindsats mod konkrete kontrol- og dokumentationskrav, ikke alene mod antallet af servere.