Test af KernelCare Live Patching med succes: Bedste praksis for administratorer

Hvordan man korrekt klassificerer KernelCare Livepatch

KernelCare er TuxCares agent for Live-opdatering af kernen på understøttede Linux-systemer. Den integrerer de udgivne sikkerhedsrettelser i den kørende kerne uden at serveren behøver at genstarte med det samme. Om en patch kan anvendes, afhænger af den konkrete kombination af kernebuild, distribution og arkitektur; det faktum, at der findes en agentpakke, er ikke i sig selv nok til at bekræfte denne understøttelse.

Fra et teknisk synspunkt beskriver Upstream Linux Livepatch-rammeværket en konsistensovergang, hvor de berørte opgaver sikkert skifter til den ændrede kode. Denne dokumentation forklarer det generelle kerne-rammeværk, men ikke nødvendigvis implementeringsmetoden for hver enkelt KernelCare-variant. For produktspecifikke funktioner og driftsbeslutninger gælder derfor fortsat oplysningerne fra TuxCare afgørende.

En patch, der er downloadet eller markeret som anvendt, beviser i første omgang, at patchkæden fungerer. Den beviser ikke, at databaseforbindelser, adgang til lagringsmedier, netværksstier, batch-job og forretningsmæssige transaktioner forbliver fejlfri under reel belastning. En pålidelig test vurderer derfor patchstatus, systemmetrikker og applikationsresultater samlet.

Almindelige Kernel-opdateringer er stadig nødvendige. Live-patches ændrer ikke den installerede kernepakke og dækker ikke automatisk hardwareunderstøttelse, funktionsændringer eller alle driverjusteringer i en ny kerne. TuxCare stiller desuden kun patches til rådighed for en bestemt kerne, så længe dens producent udgiver sikkerhedsopdateringer til den pågældende serie.

KernelCare vedrører desuden kernen og skal adskilles fra patching i brugerrummet. En vellykket test beviser hverken en LibCare-patchstatus eller, at alle sårbarheder på værten er fuldstændigt udbedret. Live-patching supplerer dermed pakkehåndtering og ændringsstyring: Det kan sætte presserende kernekorrektioner i kraft tidligere, mens regelmæssige pakkeopdateringer og planlagte genstarter fortsat er en del af vedligeholdelseskonceptet.

Komponenter, platforme og klare afgrænsninger

Før testen skal TuxCare-arkitekturen adskilles fuldstændigt. KernelCare-agenten kører på målværten, henter patch-sæt og anvender dem på den kørende kerne. ePortal er derimod en valgfri, selvstændigt drevet komponent til central styring af patchkilder og udrulninger, f.eks. i kontrollerede eller isolerede netværk. De to komponenter varetager forskellige opgaver og kan ikke udskiftes med hinanden.

Hertil kommer LibCare som et tillægsprogram til brugerrumskomponenter som glibc eller OpenSSL. En vellykket KernelCare-test kontrollerer hverken installationen eller patch-status for LibCare. Testprotokoller bør derfor registrere disse niveauer separat: Kernel-patchstatus, central distribution og patching af brugerrummet kræver hver især egne dokumentationer, godkendelser og eventuelt egne staging-systemer.

Den første praktiske opgave er at udarbejde en pålidelig oversigt. Her skal distribution og version, den faktisk opstartede kerne, arkitektur, virtualiseringstype, aktiverede sikkerhedsmekanismer og installerede kernemoduler registreres. Lige så vigtige er lager- og netværksdrivere samt sikkerheds-, backup- og overvågningsagenter. Disse egenskaber afgør, om en staging-host realistisk afspejler den senere produktionsgruppe, og om den tilbudte patch passer til kernel-buildet.

Den afgørende beslutning om support træffes ikke alene på baggrund af en generel distributionsliste. Kontroller den konkrete kombination af distribution, kerneversion og arkitektur i TuxCare-kompatibilitets- og patchdatabasen. Først denne kontrol skelner mellem en agent, der kan installeres, og en kerne, der faktisk understøttes. Den bør dokumenteres før enhver udrulningsplanlægning og gentages ved et kerneskift.

Secure Boot udgør en separat platformsklasse. Agenten har brug for en passende tillidskæde til sine kernemoduler. TuxCare angiver, at den automatiserede Secure Boot-procedure på understøttede RPM-systemer kræver mindst version 3.0-2 af agenten; denne angivelse er ikke en generel minimumsversion for KernelCare og vedrører ikke den manuelle MOK-registrering. Den automatiserede proces forudsætter blandt andet EFI-boot, shim og aktiveret Secure Boot og er ikke beregnet til Debian eller Ubuntu. Derfor indgår en planlagt genstart i valideringen af denne konfiguration.

Før installationen skal der desuden søges efter eksisterende Live-Patching-tjenester. Ifølge TuxCare må KernelCare ikke køre sideløbende med Canonical Livepatch. Paralleldrift er ikke en meningsfuld kompatibilitetstest, men et udelukkelseskriterium: Først skal den eksisterende tjeneste fjernes i henhold til den godkendte fremgangsmåde, eller testplatformen skal afbrydes. En oversigt over forskellige fremgangsmåder findes i den interne sammenligning med KernelCare, Ksplice, kpatch og kGraft.

Hvad en pålidelig test skal bevise

En pålidelig test starter med mål, der kan verificeres, i stedet for en generel melding om, at „patchen er installeret“. Der skal fremlægges dokumentation for en understøttet, kørende kerne, en tilgængelig og autoriseret patchkilde samt en anvendt, opdateret patchstatus. Derudover skal teamet registrere den effektive sikkerhedsversion, som KernelCare har rapporteret. Denne dokumentation bekræfter den tekniske leverandørkæde, men endnu ikke applikationens funktion.

Det andet kontrolniveau er Sundhed i forbindelse med anvendelsen. Tjenesterne skal forblive tilgængelige, centrale transaktioner skal gennemføres korrekt, og grænsefladerne skal levere de forventede resultater. For databasesystemer kan replikering og forespørgsler være afgørende; for webtjenester skal testomfanget f.eks. omfatte autentificering, baggrundsopgaver og eksterne integrationer.

Til overvågningen leverer kcarectl --status maskinlæsbare exit-koder. TuxCare tildeler 0 til det nyeste patch-niveau, 1 til ingen anvendte patches, 2 til nye patches, der endnu ikke er anvendt, og 3 til en kerne, der ikke understøttes. Disse tilstande er velegnede til alarmregler, men skal vurderes sammen med kernel-logfiler, servicemetrikker og tekniske kontroller.

Skel desuden mellem den indlæste og den effektive version. uname -r viser den opstartede kerne, mens kcarectl --uname der angiver den sikre kerneversion, som TuxCare har angivet. Hvis disse oplysninger ikke tages behørigt i betragtning i scanneren og CMDB’en, kan en effektiv livepatch fremstå som en manglende opdatering.

En godkendelse forudsætter fuldstændig teknisk dokumentation, beståede anvendelsestests og en repræsentativ belastningscyklus. Det kan være et batch-vindue, en typisk spidsbelastning eller en planlagt failover. I tilfælde af en ikke-understøttet kerne, stigende antal fejl eller mislykkede faglige test stoppes udvidelsen, og resultatet undersøges; en positiv agentstatus tilsidesætter ikke sådanne signaler.

Opbygge en produktionsnær staging-baseline

En robust test starter med en staging-host, der så nøjagtigt som muligt afspejler den senere målgruppe. Registrer distribution, den opstartede kerne, arkitektur, virtualiseringstype og aktiverede sikkerhedsmekanismer. Ladede eller driftskritiske kernemoduler, lager- og netværksstier, sikkerheds- og overvågningsagenter samt de centrale applikationskomponenter skal ligeledes indgå i oversigten. Kompatibiliteten skal altid kontrolleres for den faktisk kørende kerne og ikke kun for distributionen.

Dokumentér desuden applikationens tilstand inden indgrebet: vellykkede forretningstransaktioner, fejlprocenter, svartider, baggrundsopgaver og, hvis nødvendigt, klyngemedlemskab eller replikeringsstatus. Disse Baseline gør det muligt at spore senere afvigelser. Kontroller også, om der findes en backup eller et snapshot, der er egnet til formålet, og hvordan gendannelsen heraf skal foregå i praksis; et VM-snapshot kan dog ikke erstatte en konsistent databasesikkerhedskopi.

En slank test-VM er nyttig til at kontrollere installation, registrering og tilgængeligheden af patchkilden. Den giver dog ingen pålidelig information om drivere, der ligner dem i produktionsmiljøet, specielle moduler eller belastningsmønstre. Upstream Linux Livepatch-rammeværket klassificerer aktiveringer teknisk set via en konsistensovergang; heraf kan der dog ikke udledes en bestemt KernelCare-mekanisme. Uafhængigt heraf hører reelle arbejdsprofiler og driftsmæssige tillægskomponenter hjemme i en repræsentativ staging-test.

Fastlæg ikke observationstiden generelt. For en tjeneste med natlige importprocesser skal testen mindst omfatte en sådan import; i tilfælde af et højtilgængeligt cluster kan en kontrolleret failover være relevant. Fastlæg målværdier og afbrydelseskriterier på forhånd. Hvis der opstår nye kernelmeldinger, gentagne agentfejl eller faglige afvigelser, gives der ikke godkendelse, og resultaterne undersøges nærmere, inden der gennemføres en ny bølge.

Korrekt vurdering af patchstatus med kcarectl

Registrer tilstanden før og efter en godkendt patch-proces ved hjælp af de samme kommandoer. På den måde kan man se, hvilken kerne der blev startet, hvilken agentversion værten bruger, og om et patch-sæt rent faktisk er aktivt. Resultaterne skal indføres i ændrings- eller testprotokollen sammen med tidsstempel, værts-ID og den testede applikationsversion. En enkelt succesmeddelelse fra installationsprogrammet er ikke tilstrækkeligt bevis herfor.

Følgende forespørgsler er skrivebeskyttede og egner sig til statusopgørelse. Udfør dem i målmiljøet med de der tilgængelige rettigheder. Først en senere, bevidst planlagt opdateringsproces ændrer patch-status; udskriften af disse kommandoer udgør derfor et grundlag for sammenligning og overvågning, ikke selve patch-processen.

uname -r
kcarectl --version
kcarectl --info
kcarectl --patch-info
kcarectl --status
kcarectl --uname

Det er særligt vigtigt at skelne mellem opstartet og effektiv kernelversion. En sårbarhedsscanner, der kun uname -r kan give et forældet indtryk, selvom en livepatch indeholder den pågældende rettelse. Afstem derfor din oversigt og dine compliance-regler med de tilgængelige TuxCare-data, f.eks. den effektive version samt den lokale CVE-liste under /proc/kcare/cvelist.

Til alarmer er følgende egnet kcarectl --status bedre end en simpel tekstsøgning i konsoludskrifter, fordi exit-koderne kan analyseres automatisk. En kode 2 kræver for eksempel en vurdering af, om et nyt patch-sæt skal implementeres inden for det fastsatte tidsrum; kode 3 angiver et kompatibilitets- eller inventarproblem. Ingen af disse koder erstatter gennemgangen af kernel-logfiler, servicemetrikker og faglige transaktioner.

QA, Canary og produktion skal indfases gradvist

En kontrolleret udrulning starter i et dedikeret QA-miljø, fortsætter derefter gennem en lille, repræsentativ Canary-gruppe og udvides først, når der foreligger dokumenterede stabile resultater. Hver bølge gennemgår de samme status- og anvendelsestests. Overvågningsperioden afhænger af belastningscyklussen: For batch-systemer tæller en fuldstændig behandlingskørsel, mens replikering og en kontrolleret failover kan indgå for klynger.

Under overvågningen kontrollerer du fejlprocenter, ventetider, kernel- og agentmeddelelser samt, hvis relevant, kvorum og replikering. Først når godkendelseskriterierne er opfyldt, går man videre til den næste gruppe. Yderligere grundlæggende oplysninger om anvendelsen i den løbende drift findes i det interne indlæg KernelCare Enterprise: Live-patching uden vedligeholdelsesvindue.

Forsinkede feeds og UPDATE_DELAY løser lignende opgaver på forskellige niveauer. Et feed sendes via PREFIX valgt som patchkilde med fast forsinkelse. UPDATE_DELAY Patchsæt tilbageholdes derimod via klientkonfigurationen indtil en angivet minimumsalder. STICKY_PATCHSET begrænser klienten til en bestemt maksimal patchset-status.

En manuel kcarectl --update indlæser det nyeste patch-sæt og anvender det på den kørende kerne. Brug kun kommandoen på godkendte testsystemer eller inden for et fastlagt vedligeholdelsesvindue. Sørg for at gemme basisværdierne inden, og udfør straks de tekniske og faglige kontroller bagefter.

ePortal kan centralt styre patch-sæt og distribution. Når automatiske opdateringer er aktiveret, søger klienterne ifølge TuxCare efter tilgængelige patch-sæt hver fjerde time. Dette medfører dog ingen garanti for gennemførelsestidspunktet: Tilgængelighed, registrering, retningslinjer og kernekompatibilitet skal overvåges for hver bølge.

Registrer for hver bølge status for patch, udvalgte værter, overvågningsvindue, testresultater og den ansvarlige for godkendelsen. Ved afvigelser standses udbredelsen. Dette Canary-udgivelse begrænser omfanget af uventede effekter, men erstatter hverken kompatibilitetstesten eller den planlagte genstartscyklus.

Test af Secure Boot og kritiske særtilfælde

Server med Sikker opstart hører til i en separat testgruppe. Agenten har brug for en fungerende tillidskæde til sine kernemoduler; en vellykket installation er ikke i sig selv bevis på dette. TuxCare angiver agentversion 3.0-2 som minimumskrav for den automatiserede Secure Boot-procedure på understøttede RPM-systemer. Denne angivelse gælder ikke som generelt minimumskrav for KernelCare og heller ikke for den manuelle MOK-registrering.

For at kunne benytte den automatiserede metode skal der blandt andet være EFI-Boot, shim og aktiveret Secure Boot. Ifølge TuxCare er denne fremgangsmåde ikke beregnet til Debian og Ubuntu. Notér derfor distribution, boot-tilstand og agentversion inden testen, og betragt en afvigende platform ikke blot som en konfigurationsvariant, men som en separat vej, der skal vurderes manuelt.

Kontrollen afsluttes først efter en planlagt genstart. Kontroller derefter med det værktøj, der er beskrevet af TuxCare mokutil eller ved hjælp af relevante kernefejlmeddelelser, om certifikatet rent faktisk er tilgængeligt i tillidskæden. Først derefter foretages der på denne vært en kontrolleret hentning af Livepatch med de samme faglige og tekniske kontroller som i den øvrige QA-runde.

Også systemer med proprietære drivere, lagrings- eller netværksmoduler, eBPF-programmer, sikkerhedssoftware og overvågningsagenter kræver deres eget repræsentative testomfang. Dette er ikke en generel udtalelse om inkompatibilitet. Som en teknisk klassificering beskriver Upstream Linux Livepatch-frameworket konsistensovergange for berørte opgaver; dette beviser dog ikke, at KernelCare anvender den samme mekanisme på alle understøttede platforme.

Simuler derfor de kombinationer, der rent faktisk forekommer i drift: f.eks. multipath-lager under belastning, krypterede netværksforbindelser, sikkerhedsagenter og en klyngeknudens failover-rolle. Dokumenter indlæste moduler, kernebeskeder samt applikations- og klyngestatus før og efter patchen. En slank test-VM uden disse komponenter kan bekræfte agentinstallationen, men kan ikke levere en pålidelig vurdering af denne systemklasse.

Overvågning, fejlanalyse og sikker eskalering

Overvåg live-patching på to niveauer: Den maskinlæsbare Patchstatus viser agentens tilstand, mens kernel-logfiler, fejlrater, ventetider og klyngetilstand afspejler applikationens drift. Selv om patch-status er opdateret, kan der stadig forekomme en applikationsfejl eller en faglig afvigelse. Alarmering og godkendelse skal derfor samle begge niveauer og undersøge årsagen til en afvigelse separat.

Til automatiseret triage leverer kcarectl --status Definerede exit-koder: 0 angiver det nyeste patch-niveau, 1 angiver, at der ikke er installeret nogen patches, 2 angiver, at der er tilgængelige, men endnu ikke installerede patches, og 3 angiver en kerne, der ikke understøttes. Kode 3 kræver først en kompatibilitetskontrol; kode 2 er ikke en programfejl, men skal vurderes i forhold til den planlagte udrulnings- og opdateringspolitik.

Ved afvigelser skal du først indsamle data, der kan sammenholdes tidsmæssigt: Status- og patchoplysninger, agentmeddelelser, kernel-log, tidspunktet for hentningen, berørte arbejdsbelastninger samt ændringer i moduler eller infrastruktur. For klyngeknudepunkter omfatter dette medlemskab, replikeringsstatus og failover-hændelser. Disse data adskiller en patch-tilstand fra en applikations- eller netværksfejl, der er opstået samtidig, og gør en supportssag sporbar.

TuxCare dokumenterer kcarectl --force som en mulighed sammen med en opdatering, der tvinger anvendelsen af en patch, hvis nogle tråde ikke kan fryses. Upstream-Linux-dokumentationen advarer i forbindelse med sin egen tvangsmekanisme mod mulige skader, kræver derefter en planlagt genstart og fraråder yderligere live-patches. Den dokumenterer dog ikke, at kcarectl --force internt anvendes den samme semantik. Derfor er den produktspecifikke TuxCare-supportvejledning og diagnosen af den konkrete host afgørende; denne mulighed er ikke egnet som en almindelig udrulnings- eller fejlfindingsforanstaltning.

Planlægning af genstartstrategi og dokumenteret godkendelse

Live Patching forkorter tiden, det tager at lukke understøttede sårbarheder i kernen, men ændrer ikke den installerede kernepakke. Nye kerneltilbud, hardwarestøtte, ændringer af drivere eller firmware samt funktionelle forbedringer af kernen kræver fortsat den almindelige pakkehåndtering og planlagte genstarter.

Fastlæg derfor en genstartfrekvens for hver platformsklasse. KernelCare stiller kun patches til en bestemt kerne til rådighed, så længe dens producent leverer sikkerhedsopdateringer til den pågældende serie. Et vedligeholdelsesvindue sikrer desuden, at den opstartede kerne, de indlæste drivere og den dokumenterede måltilstand igen er i overensstemmelse med hinanden.

TuxCare dokumenterer kcarectl --unload til at downloade KernelCare-patches. Dette indebærer ikke nogen generel garanti for en fuldstændig gendannelse. Upstream-dokumentationen viser for Atomic Replace og kumulative Livepatches, at ændringer i systemtilstanden kan gøre det vanskeligt at vende tilbage til den tidligere tilstand; den beskriver dog ikke automatisk den konkrete implementering af hver enkelt KernelCare-version.

Kontroller derfor, inden du afinstallerer, dokumentationen for den installerede agentversion, og aftal om nødvendigt, hvilke foranstaltninger der skal træffes i tilfælde af fejl, med TuxCare. Den pålidelige Vendepunkt Der forbliver en defineret, testet boot-kerne med planlagt genstart samt eventuelt en konsistenskontrol eller gendannelse af applikationen.

Godkendelsen af en udrulningsbølge dokumenterer den understøttede kerne, patch-status, udførte applikationstests, relevante belastningscyklusser, logfiler, ansvarlige personer og afbrydelseskriterier. Den udgør ikke en generel tilsagn om senere patch-sæt. Ændringer af kernen, moduler eller applikationen kan gøre det nødvendigt at gennemføre en ny QA- og Canary-test.

• Dokumenter den understøttede kerne, patchkilden og den anvendte patchversion.
• Påvise, at der ikke er uafklarede afvigelser i applikationskontroller, belastningscyklus, kernel-logfiler og klyngestatus.
• Fastlægge implementeringsfase, ansvarlige, alarmprocedurer og afbrydelseskriterier.
• Planlæg den næste kerneopdatering med vedligeholdelsesvindue, opstartskerne og genstartskontrol.

Dermed er driftsbeslutningen entydig: En vellykket livepatch muliggør en kontrolleret fortsættelse af den pågældende bølge. Uafklarede tekniske eller faglige signaler fører derimod til standsning, analyse eller en planlagt genstart. Planlægningen af genstart er en del af sikkerheds- og genopretningskonceptet, ikke en indrømmelse af, at en livepatch er mislykket.