Testa KernelCare Live Patching på ett framgångsrikt sätt: bästa praxis för administratörer

Att placera KernelCare Livepatch på rätt plats

KernelCare är TuxCares agent för Live-uppdatering av kärnan på Linux-system som stöds. Den inför tillgängliga säkerhetskorrigeringar i den aktiva kärnan utan att servern behöver startas om omedelbart. Huruvida en patch kan tillämpas beror på den specifika kombinationen av kärnbyggnad, distribution och arkitektur; det faktum att ett agentpaket finns tillgängligt innebär inte i sig att detta stöd finns.

Ur ett tekniskt perspektiv beskriver Upstream Linux Livepatch-ramverket en konsistensövergång där berörda uppgifter på ett säkert sätt övergår till den ändrade koden. Denna dokumentation förklarar det allmänna kärnramverket, men inte nödvändigtvis implementeringssättet för varje KernelCare-variant. För produktspecifika funktioner och driftsbeslut gäller därför fortfarande uppgifterna från TuxCare avgörande.

En nedladdad eller som tillämpad rapporterad patch bevisar inledningsvis att patchkedjan fungerar. Den bevisar inte att databasanslutningar, lagringsåtkomst, nätverksvägar, batchjobb och affärstransaktioner förblir felfria under verklig belastning. En tillförlitlig test utvärderar därför både patchstatus, systemmetriker och applikationsresultat tillsammans.

Vanliga Kärnuppdateringar är fortfarande nödvändiga. Live-patchar ändrar inte det installerade kärnpaketet och täcker inte automatiskt hårdvarustöd, funktionsändringar eller alla drivrutinsanpassningar i en ny kärna. TuxCare tillhandahåller dessutom endast patchar för en enskild kärna så länge dess tillverkare publicerar säkerhetsuppdateringar för den aktuella serien.

KernelCare påverkar dessutom kärnan och ska hållas åtskilt från patchning i användarutrymmet. Ett lyckat test bevisar varken att LibCare-patchningen är uppdaterad eller att alla sårbarheter på värddatorn har åtgärdats fullständigt. Live-patching kompletterar därmed pakethantering och förändringshantering: den kan snabbare sätta brådskande kärnkorrigeringar i verket, medan regelbundna paketuppdateringar och planerade omstarter fortfarande ingår i underhållsstrategin.

Komponenter, plattformar och tydliga avgränsningar

Innan testet måste TuxCare-arkitekturen separeras ordentligt. KernelCare-agenten körs på målvärden, hämtar patchuppsättningar och tillämpar dem på den aktiva kärnan. ePortal är däremot en valfri, egendriven komponent för central styrning av patchkällor och utrullningar, till exempel i kontrollerade eller isolerade nät. De båda komponenterna fyller olika funktioner och är inte utbytbara.

Dessutom finns LibCare som ett tillägg för komponenter i användarutrymmet, såsom glibc eller OpenSSL. Ett godkänt KernelCare-test kontrollerar varken installationen eller patchstatusen för LibCare. Testprotokoll bör därför redovisa dessa nivåer separat: kärnans patchnivå, central distribution och patching av användarutrymmet kräver var och en egna bevis, godkännanden och, i förekommande fall, egna staging-system.

Den första praktiska uppgiften är att skapa en tillförlitlig inventering. Man ska registrera distribution och version, den kärna som faktiskt startats, arkitektur, virtualiseringstyp, aktiverade säkerhetsmekanismer och installerade kärnmoduler. Lika viktiga är lagrings- och nätverksdrivrutiner samt säkerhets-, säkerhetskopierings- och övervakningsagenter. Dessa egenskaper avgör om en staging-värd på ett realistiskt sätt återspeglar den framtida produktionsgruppen och om den föreslagna korrigeringen passar kernelbyggnaden.

Det är inte en allmän distributionslista som ensam avgör om stöd ska ges. Kontrollera den specifika kombinationen av distribution, kärnversion och arkitektur i TuxCares kompatibilitets- och patchdatabas. Det är först denna kontroll som skiljer en agent som går att installera från en kärna som faktiskt stöds. Den bör dokumenteras före varje utrullningsplanering och utföras på nytt vid ett kärnbyte.

Secure Boot utgör en egen plattformsklass. Agenten behöver en lämplig förtroendekedja för sina kärnmoduler. TuxCare anger att den automatiserade Secure Boot-processen på stödda RPM-system kräver minst version 3.0-2 av agenten; denna uppgift är inte en allmän minimiversion för KernelCare och gäller inte den manuella MOK-registreringen. Den automatiserade processen förutsätter bland annat EFI-Boot, shim och aktiverad Secure Boot och är inte avsedd för Debian eller Ubuntu. Därför ingår en planerad omstart för att validera denna konfiguration.

Innan installationen bör man dessutom söka efter befintliga Live-Patching-tjänster. Enligt TuxCare får KernelCare inte köras parallellt med Canonical Livepatch. Parallell drift är inte ett meningsfullt kompatibilitetstest, utan ett uteslutningskriterium: Först måste den befintliga tjänsten avinstalleras enligt den godkända driftsproceduren eller så måste testplattformen kopplas bort. En översikt över olika metoder ges i den interna jämförelsen med KernelCare, Ksplice, kpatch och kGraft.

Vad ett tillförlitligt test måste visa

En tillförlitlig testning börjar med verifierbara mål istället för det allmänna meddelandet „Patch installerad“. Det måste kunna bevisas att en stödd, aktiv kärna används, att det finns en tillgänglig och auktoriserad källa för patchar samt att den senaste patchnivån har tillämpats. Dessutom måste teamet registrera den effektiva säkerhetsversionen som rapporterats av KernelCare. Dessa bevis bekräftar den tekniska leveranskedjan, men ännu inte applikationens funktion.

Den andra kontrollnivån är Användarhälsa. Tjänsterna måste förbli tillgängliga, centrala transaktioner måste slutföras korrekt och gränssnitten måste leverera de förväntade resultaten. När det gäller databassystem kan replikering och sökningar vara avgörande; för webbtjänster ingår exempelvis autentisering, bakgrundsjobb och externa integrationer i testomfånget.

För övervakningen tillhandahåller kcarectl --status maskinläsbara exit-koder. TuxCare tilldelar 0 till den senaste patchnivån, 1 till inga tillämpade patchar, 2 till nya patchar som ännu inte tillämpats och 3 till en kärna som inte stöds. Dessa tillstånd lämpar sig för varningsregler, men måste utvärderas tillsammans med kärnloggar, tjänstemetriker och tekniska kontroller.

Skillnaden mellan den startade och den faktiska versionen. uname -r visar den startade kärnan, medan kcarectl --uname som anger den säkra kärnversion som TuxCare har identifierat. Om denna information inte beaktas på rätt sätt i skannern och CMDB kan en fungerande Livepatch framstå som en saknad uppdatering.

Ett godkännande förutsätter fullständiga tekniska bevis, godkända tillämpningstester och en representativ belastningscykel. Det kan vara ett batchfönster, en typisk toppbelastning eller en planerad failover. Vid en icke-stödd kärna, ökande fel eller misslyckade fackprov stoppas utvidgningen och resultatet undersöks; en positiv agentstatus åsidosätter inte sådana signaler.

Upprätta en produktionsnära staging-baseline

Ett tillförlitligt test börjar med en staging-värd som så exakt som möjligt återspeglar den framtida målgruppen. Registrera distribution, startad kärna, arkitektur, virtualiseringstyp och aktiverade säkerhetsmekanismer. Likaså ingår laddade eller verksamhetskritiska kärnmoduler, lagrings- och nätverksvägar, säkerhets- och övervakningsagenter samt de centrala applikationskomponenterna i inventeringen. Kompatibiliteten ska alltid kontrolleras för den faktiskt körda kärnan och inte bara för distributionen.

Dokumentera dessutom applikationens tillstånd innan ingreppet: lyckade affärstransaktioner, felfrekvenser, svarstider, bakgrundsjobb och, vid behov, klustermedlemskap eller replikeringsstatus. Dessa Baslinje gör det möjligt att spåra senare avvikelser. Kontrollera också om det finns en säkerhetskopia eller en snapshot som är lämplig för applikationen och hur återställningen av denna ska genomföras i praktiken; en VM-snapshot ersätter inte en konsekvent databassäkerhetskopia.

En avskalad test-VM är lämplig för att kontrollera installation, registrering och tillgänglighet av patchkällan. Den ger dock inga tillförlitliga resultat när det gäller drivrutiner som efterliknar produktionsmiljön, speciella moduler eller belastningsmönster. Upstream Linux Livepatch-ramverket klassificerar aktiveringar tekniskt sett via en konsistensövergång; därifrån kan dock ingen specifik KernelCare-mekanism härledas. Oavsett detta hör verkliga arbetsprofiler och operativa tilläggskomponenter hemma i ett representativt staging-test.

Fastställ inte observationstiden generellt. För en tjänst med nattliga importer måste testet åtminstone omfatta en sådan import; vid ett kluster med hög tillgänglighet kan en kontrollerad failover vara relevant. Fastställ målvärden och avbrottskriterier i förväg. Om nya kärnmeddelanden, upprepade agentfel eller tekniska avvikelser uppstår, uteblir godkännandet och resultatet undersöks innan nästa omgång påbörjas.

Utvärdera patchstatus korrekt med kcarectl

Registrera tillståndet före och efter en godkänd patchning med samma kommandon. På så sätt går det att avgöra vilken kärna som startades, vilken agentversion värden använder och om en patchuppsättning faktiskt är aktiv. Resultaten ska inkluderas i ändrings- eller testprotokollet tillsammans med tidsstämpel, värd-ID och den testade applikationsversionen. En enskild meddelandetext om att installationen lyckades räcker inte som bevis.

Följande frågor är av läsande karaktär och lämpar sig för en lägesbedömning. Kör dem i målmiljön med de behörigheter som finns där. Det är först en senare, medvetet planerad uppdatering som ändrar patchstatusen; utdata från dessa kommandon utgör därför en grund för jämförelse och övervakning, inte själva patchprocessen.

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

Det är särskilt viktigt att skilja mellan uppstartade och effektiv kärnversion. En sårbarhetsskanner som endast uname -r om detta utvärderas kan det ge ett inaktuellt intryck, trots att en livepatch tillhandahåller den aktuella korrigeringen. Jämför därför inventeringen och efterlevnadsreglerna med de tillgängliga TuxCare-uppgifterna, till exempel den faktiska versionen samt den lokala CVE-listan under /proc/kcare/cvelist.

För larm är följande lämpligt kcarectl --status bättre än en ren textsökning i konsolutdata, eftersom avslutningskoderna kan analyseras automatiskt. En kod 2 kräver till exempel en bedömning av om en ny uppsättning korrigeringar ska rullas ut inom det avsedda tidsfönstret; kod 3 avser ett kompatibilitets- eller inventariefall. Ingen av dessa koder ersätter granskningen av kärnloggar, tjänstemetrik och affärstransaktioner.

Stegvis kontroll av QA, Canary och produktion

En kontrollerad lansering inleds i en särskild QA-miljö, fortsätter därefter till en liten, representativ Canary-grupp och utvidgas först när resultaten har visat sig vara stabila. Varje våg genomgår samma status- och tillämpningstester. Övervakningstiden bestäms av belastningscykeln: för batchsystem räknas en fullständig bearbetningsomgång, medan replikering och en kontrollerad failover kan ingå för kluster.

Under övervakningen kontrollerar du felfrekvenser, fördröjningar, meddelanden från kärnan och agenterna samt, i förekommande fall, kvorum och replikering. Först när godkännandekriterierna är uppfyllda går man vidare till nästa grupp. Ytterligare grundläggande information om användning under drift förklaras i det interna inlägget KernelCare Enterprise: Live-patching utan underhållsfönster.

Fördröjda flöden och UPDATE_DELAY löser liknande uppgifter på olika nivåer. Ett flöde sker via PREFIX vald som patchkälla med fast fördröjning. UPDATE_DELAY Patchset hålls däremot tillbaka via klientkonfigurationen fram till en angiven lägsta ålder. STICKY_PATCHSET begränsar klienten till en viss maximal patchset-nivå.

En manuell kcarectl --update laddar ner den senaste uppsättningen patchar och tillämpar den på den aktiva kärnan. Använd kommandot endast på godkända testsystem eller under ett fastställt underhållsfönster. Säkerhetskopiera basvärdena innan och utför därefter omedelbart de tekniska och fackmässiga kontrollerna.

ePortal kan hantera patchpaket och distribution centralt. När automatiska uppdateringar är aktiverade söker klienterna, enligt TuxCare, efter tillgängliga patchuppsättningar var fjärde timme. Detta innebär dock ingen garanterad genomförandetid: tillgänglighet, registrering, riktlinjer och kärnkompatibilitet måste övervakas för varje våg.

Registrera för varje våg patchstatus, utvalda värddatorer, övervakningsfönster, testresultat och ansvarig för godkännande. Vid avvikelser stoppas utvidgningen. Dessa Canary-frigivning begränsar omfattningen av oförutsedda effekter, men ersätter varken kompatibilitetskontrollen eller den planerade omstartscykeln.

Testa Secure Boot och kritiska specialfall

Server med Säker start hör hemma i en egen testgrupp. Agenten behöver en fungerande förtroendekedja för sina kärnmoduler; en lyckad installation är inte i sig ett bevis på detta. TuxCare anger att minimiversionen för den automatiserade Secure Boot-processen på stödda RPM-system är Agent 3.0-2. Denna uppgift gäller inte som en allmän minimiversion för KernelCare och inte heller för den manuella MOK-registreringen.

För den automatiserade metoden krävs bland annat EFI-Boot, shim och aktiverad Secure Boot. Enligt TuxCare är denna process inte avsedd för Debian och Ubuntu. Notera därför distribution, startläge och agentversion före testet och betrakta en avvikande plattform inte som en ren konfigurationsvariant, utan som en separat väg som måste utvärderas manuellt.

Kontrollen avslutas först efter en planerad omstart. Kontrollera därefter med det verktyg som beskrivs av TuxCare mokutil eller genom lämpliga kärnmeddelanden, om certifikatet verkligen finns tillgängligt i förtroendekedjan. Först därefter genomförs en kontrollerad hämtning av Livepatch på denna värd, med samma sakliga och tekniska kontroller som i övriga delar av QA-omgången.

Även system med proprietära drivrutiner, lagrings- eller nätverksmoduler, eBPF-program, säkerhetsprogramvara och övervakningsagenter kräver en egen representativ testomfattning. Detta är inte ett generellt påstående om inkompatibilitet. Ur ett tekniskt perspektiv beskriver Upstream Linux Livepatch-ramverket konsistensövergångar för berörda uppgifter; detta bevisar dock inte att KernelCare använder samma mekanism på alla plattformar som stöds.

Simulera därför de kombinationer som faktiskt förekommer i drift: till exempel multipath-lagring under belastning, krypterade nätverksanslutningar, säkerhetsagenter och en klusternods failover-roll. Dokumentera laddade moduler, kärnmeddelanden samt applikations- och klusterstatus före och efter patchen. En avskalad test-VM utan dessa komponenter kan bekräfta agentinstallationen, men ger ingen tillförlitlig information om denna systemklass.

Övervakning, felanalys och säker eskalering

Övervaka live-patching på två nivåer: Den maskinläsbara Patchstatus visar agentens status, medan kärnloggar, felfrekvenser, fördröjningar och klusterstatus ger en bild av applikationens drift. Att programvaran är uppdaterad utesluter inte att det samtidigt föreligger ett applikationsfel eller en teknisk avvikelse. Larmhantering och godkännande måste därför sammanföra båda nivåerna och undersöka orsaken till en avvikelse separat.

För automatiserad triagering tillhandahåller kcarectl --status Definierade avslutningskoder: 0 står för den senaste patchnivån, 1 för inga tillämpade patchar, 2 för tillgängliga men ännu inte tillämpade patchar och 3 för en kärna som inte stöds. Kod 3 kräver först en kompatibilitetskontroll; kod 2 är inget programfel, men måste utvärderas mot den planerade riktlinjen för utrullning och uppdatering.

Vid avvikelser ska du först samla in data som kan korreleras tidsmässigt: utdata av status- och patchinformation, agentmeddelanden, kärnlogg, tidpunkt för hämtningen, berörda arbetsbelastningar samt ändringar av moduler eller infrastruktur. För klusternoder ingår medlemskap, replikeringsstatus och failover-händelser. Dessa uppgifter skiljer ett patch-tillstånd från en applikations- eller nätverksstörning som inträffat samtidigt och gör det möjligt att spåra ett supportärende.

TuxCare dokumenterar kcarectl --force som ett alternativ tillsammans med en uppdatering som tvingar fram en patch om vissa trådar inte går att frysa. Dokumentationen från Linux-uppströmsvärlden varnar för eventuella skador i samband med sin egen tvångsmekanism, kräver därefter en planerad omstart och avråder från ytterligare livepatchar. Den ger dock inga belägg för att kcarectl --force använder samma semantik internt. Avgörande är därför de produktspecifika supportanvisningarna från TuxCare och diagnosen av den aktuella värden; alternativet lämpar sig inte som en vanlig utrullnings- eller felsökningsåtgärd.

Planera en omstartsstrategi och dokumenterad godkännandeprocess

Live Patching förkortar tiden det tar att åtgärda stödda sårbarheter i kärnan, men ändrar inte det installerade kärnpaketet. Nya kärnpaket, hårdvarustöd, ändringar av drivrutiner eller firmware samt funktionella förbättringar av kärnan kräver fortfarande vanlig pakethantering och planerade omstarter.

Fastställ därför en omstartscykel för varje plattformsklass. KernelCare tillhandahåller endast patchar för en enskild kärna så länge dess tillverkare förser den aktuella serien med säkerhetsuppdateringar. Ett underhållsfönster återför dessutom den uppstartade kärnan, de laddade drivrutinerna och det dokumenterade referensläget till harmoni.

TuxCare dokumenterar kcarectl --unload för nedladdning av KernelCare-patchar. Detta innebär inte någon allmän garanti för fullständig återställning. Upstream-dokumentationen visar för Atomic Replace och kumulativa Livepatches att tillståndsförändringar kan försvåra återställningen; den beskriver dock inte automatiskt den konkreta implementeringen av varje KernelCare-version.

Kontrollera därför dokumentationen för den installerade agentversionen innan du avinstallerar den och samordna vid behov åtgärder vid störningar med TuxCare. Den pålitliga Återvändningspunkt Då återstår en definierad, testad startkärna med planerad omstart samt, vid behov, en konsistenskontroll eller återställning av applikationen.

Godkännandet av en utrullningsvåg dokumenterar vilken kärna som stöds, patchstatus, utförda applikationstester, relevanta belastningscykler, loggar, ansvariga personer och avbrottskriterier. Det utgör inte ett generellt löfte om framtida patchuppsättningar. Ändringar av kärnan, moduler eller applikationen kan kräva nya QA- och Canary-tester.

• Dokumentera vilken kärna som stöds, källan till patchen och vilken patchversion som har använts.
• Verifiera att applikationskontroller, belastningscykler, kärnloggar och klusterstatus inte uppvisar några oförklarliga avvikelser.
• Fastställa implementeringsfas, ansvariga, larmvägar och avbrottskriterier.
• Planera nästa kärnuppdatering med underhållsfönster, startkärna och omstartskontroll.

Därmed är driftsbeslutet entydigt: En lyckad livepatch möjliggör en kontrollerad fortsättning av den aktuella vågen. Oklara tekniska eller fackmässiga signaler leder däremot till avbrott, analys eller planerad omstart. Planeringen av omstarten är en del av säkerhets- och återställningskonceptet, inte ett erkännande av att en livepatch har misslyckats.