Skuteczne testowanie funkcji KernelCare Live Patching: najlepsze praktyki dla administratorów

Jak właściwie klasyfikować program KernelCare Livepatch

KernelCare jest przedstawicielem firmy TuxCare w zakresie Aktualizacja jądra w trybie online na obsługiwanych systemach Linux. Wprowadza on udostępnione poprawki zabezpieczeń do uruchomionego jądra bez konieczności natychmiastowego ponownego uruchamiania serwera. To, czy dana poprawka ma zastosowanie, zależy od konkretnej kombinacji kompilacji jądra, dystrybucji i architektury; sama dostępność pakietu agenta nie gwarantuje jeszcze tej obsługi.

Z technicznego punktu widzenia framework Upstream Linux Livepatch opisuje proces przejścia zapewniający spójność, w ramach którego zadania, których to dotyczy, bezpiecznie przechodzą na zmodyfikowany kod. Niniejsza dokumentacja wyjaśnia ogólną strukturę jądra, ale niekoniecznie sposób implementacji każdej wersji KernelCare. W przypadku funkcji specyficznych dla produktu oraz decyzji operacyjnych należy zatem kierować się informacjami zawartymi w TuxCare ma decydujące znaczenie.

Pobrana lub zgłoszona jako zastosowana poprawka potwierdza przede wszystkim poprawność działania łańcucha poprawek. Nie gwarantuje ona jednak, że połączenia z bazą danych, dostęp do pamięci masowej, ścieżki sieciowe, zadania wsadowe i transakcje biznesowe będą działać bezbłędnie pod rzeczywistym obciążeniem. Dlatego też rzetelny test ocenia łącznie status poprawki, wskaźniki systemowe oraz wyniki działania aplikacji.

Standardowe Aktualizacje jądra są nadal niezbędne. Poprawki typu „livepatch” nie zmieniają zainstalowanego pakietu jądra i nie obejmują automatycznie obsługi sprzętu, zmian funkcjonalnych ani wszystkich dostosowań sterowników w nowym jądrze. Ponadto firma TuxCare udostępnia poprawki dla konkretnego jądra tylko tak długo, jak długo jego producent publikuje aktualizacje zabezpieczeń dla danej serii.

KernelCare dotyczy ponadto jądra i należy go odróżnić od łatania w przestrzeni użytkownika. Pomyślny wynik testu nie potwierdza ani aktualności łat LibCare, ani całkowitego usunięcia wszystkich luk w zabezpieczeniach hosta. W ten sposób łatki na żywo uzupełniają zarządzanie pakietami i zarządzanie zmianami: umożliwiają one wcześniejsze wprowadzenie pilnych poprawek jądra, podczas gdy regularne aktualizacje pakietów i zaplanowane restarty nadal stanowią część koncepcji konserwacji.

Komponenty, platformy i jasne rozgraniczenia

Przed rozpoczęciem testu należy dokładnie oddzielić architekturę TuxCare. Agent KernelCare działa na hoście docelowym, pobiera zestawy poprawek i stosuje je do uruchomionego jądra. ePortal jest natomiast opcjonalnym, samodzielnie działającym komponentem służącym do centralnego sterowania źródłami poprawek i wdrażaniem aktualizacji, na przykład w sieciach kontrolowanych lub izolowanych. Oba komponenty pełnią różne zadania i nie są zamienne.

Osobno dostępny jest LibCare jako dodatek do komponentów przestrzeni użytkownika, takich jak glibc czy OpenSSL. Pomyślny wynik testu KernelCare nie sprawdza ani instalacji, ani stanu poprawek LibCare. Protokoły testowe powinny zatem rejestrować te poziomy oddzielnie: stan poprawek jądra, centralna dystrybucja oraz aktualizacje przestrzeni użytkownika wymagają odpowiednio własnych dowodów, zatwierdzeń i, w razie potrzeby, własnych systemów stagingowych.

Pierwszym praktycznym zadaniem jest stworzenie rzetelnego spisu zasobów. Należy uwzględnić wersję dystrybucji i wydania, faktycznie uruchomiony jądro, architekturę, rodzaj wirtualizacji, aktywowane mechanizmy bezpieczeństwa oraz zainstalowane moduły jądra. Równie ważne są sterowniki pamięci masowej i sieciowe, a także agenci bezpieczeństwa, tworzenia kopii zapasowych i monitorowania. Cechy te decydują o tym, czy host testowy realistycznie odzwierciedla późniejszą grupę produkcyjną oraz czy oferowana poprawka jest zgodna z kompilacją jądra.

O przyznaniu wsparcia nie decyduje wyłącznie ogólna lista dystrybucyjna. Należy sprawdzić konkretną kombinację dystrybucji, wersji jądra i architektury w bazie danych zgodności i poprawek TuxCare. Dopiero ta weryfikacja pozwala odróżnić agenta, który można zainstalować, od jądra faktycznie obsługiwanej. Należy ją udokumentować przed każdym planowaniem wdrożenia i powtórzyć w przypadku zmiany jądra.

Secure Boot stanowi odrębną klasę platformy. Agent wymaga odpowiedniego łańcucha zaufania dla swoich modułów jądra. TuxCare określa minimalną wersję agenta 3.0-2 dla zautomatyzowanej procedury Secure Boot na obsługiwanych systemach RPM; informacja ta nie stanowi ogólnej minimalnej wersji dla KernelCare i nie dotyczy ręcznej rejestracji MOK. Zautomatyzowany proces wymaga między innymi rozruchu EFI, modułu shim oraz włączonej funkcji Secure Boot i nie jest przeznaczony dla systemów Debian ani Ubuntu. W związku z tym w celu walidacji tej konfiguracji konieczne jest zaplanowane ponowne uruchomienie systemu.

Przed instalacją należy ponadto sprawdzić, czy nie działają już jakieś usługi typu „live patching”. Według TuxCare usługa KernelCare nie może działać równolegle z usługą Canonical Livepatch. Równoległa eksploatacja nie stanowi sensownego testu kompatybilności, lecz stanowi kryterium wykluczające: najpierw należy usunąć istniejącą usługę zgodnie z zatwierdzoną procedurą operacyjną lub odłączyć platformę testową. Przegląd różnych procedur przedstawia wewnętrzne porównanie z KernelCare, Ksplice, kpatch i kGraft.

Co musi wykazać test o wysokiej wiarygodności

Rzetelny test zaczyna się od mierzalnych celów, a nie od ogólnikowego komunikatu „poprawka zainstalowana“. Należy wykazać, że jądro systemu jest obsługiwane i działa, źródło poprawki jest dostępne i autoryzowane, a także że zastosowano aktualny zestaw poprawek. Ponadto zespół musi zarejestrować efektywną wersję bezpieczeństwa zgłoszoną przez KernelCare. Dowody te potwierdzają poprawność łańcucha dostaw technicznego, ale nie potwierdzają jeszcze działania aplikacji.

Drugim poziomem kontroli jest Zdrowie związane z używaniem aplikacji. Usługi muszą pozostać dostępne, kluczowe transakcje muszą być poprawnie realizowane, a interfejsy muszą dostarczać oczekiwanych wyników. W przypadku systemów baz danych decydujące znaczenie mogą mieć replikacja i zapytania; w przypadku usług internetowych zakres testów obejmuje na przykład uwierzytelnianie, zadania wykonywane w tle oraz integracje zewnętrzne.

W zakresie monitorowania zapewnia kcarectl --status kody wyjścia odczytywane maszynowo. TuxCare przypisuje wartość 0 najnowszemu poziomowi poprawek, 1 – braku zastosowanych poprawek, 2 – nowym, jeszcze niezastosowanym poprawkom, a 3 – jądru, które nie jest obsługiwane. Stany te nadają się do stosowania w regułach alarmowych, jednak należy je analizować w połączeniu z logami jądra, metrykami usług oraz weryfikacjami merytorycznymi.

Należy również rozróżnić wersję uruchomioną od wersji efektywnej. uname -r wyświetla uruchomiony jądro, podczas gdy kcarectl --uname wyświetla wersję jądra uznaną przez TuxCare za bezpieczną. Jeśli informacje te nie zostaną odpowiednio uwzględnione w skanerze i bazie danych CMDB, skuteczna poprawka typu „livepatch” może zostać uznana za brakującą aktualizację.

Zatwierdzenie wymaga przedstawienia pełnej dokumentacji technicznej, pozytywnego wyniku testów aplikacyjnych oraz przeprowadzenia reprezentatywnego cyklu obciążenia. Może to być okno przetwarzania wsadowego, typowe obciążenie szczytowe lub zaplanowane przełączenie awaryjne. W przypadku nieobsługiwanego jądra, rosnącej liczby błędów lub nieudanych testów funkcjonalnych rozszerzenie zostanie wstrzymane, a wynik zostanie zbadany; pozytywny status agenta nie ma pierwszeństwa przed takimi sygnałami.

Stworzenie punktu odniesienia dla środowiska testowego zbliżonego do produkcyjnego

Rzetelny test zaczyna się od hosta testowego, który jak najdokładniej odzwierciedla docelową grupę użytkowników. Należy uwzględnić dystrybucję, uruchomiony jądro, architekturę, rodzaj wirtualizacji oraz aktywowane mechanizmy bezpieczeństwa. W wykazie należy również uwzględnić załadowane lub krytyczne dla działania moduły jądra, ścieżki pamięci masowej i sieciowe, agenty bezpieczeństwa i monitorowania, a także główne komponenty aplikacji. Zgodność należy zawsze sprawdzać pod kątem faktycznie uruchomionego jądra, a nie tylko dystrybucji.

Przed rozpoczęciem ingerencji należy również udokumentować stan aplikacji: pomyślnie zakończone transakcje biznesowe, wskaźniki błędów, czasy odpowiedzi, zadania w tle oraz, w razie potrzeby, przynależność do klastra lub status replikacji. Te Linia bazowa umożliwia prześledzenie późniejszych zmian. Sprawdź również, czy dostępna jest kopia zapasowa lub migawka odpowiednia dla danej aplikacji oraz w jaki sposób w praktyce przebiega proces jej przywracania; migawka maszyny wirtualnej nie zastępuje jednak spójnej kopii zapasowej bazy danych.

Usprawniona maszyna wirtualna testowa jest przydatna do sprawdzenia instalacji, rejestracji i dostępności źródła poprawek. Nie dostarcza ona jednak wiarygodnych informacji na temat sterowników stosowanych w środowisku produkcyjnym, specjalnych modułów ani wzorców obciążenia. Framework Upstream Linux Livepatch klasyfikuje aktywacje pod względem technicznym za pomocą przejścia spójnościowego; nie można jednak na tej podstawie wywnioskować konkretnego mechanizmu KernelCare. Niezależnie od tego, rzeczywiste profile pracy i dodatkowe komponenty operacyjne powinny zostać uwzględnione w reprezentatywnym teście stagingowym.

Nie należy ustalać czasu trwania obserwacji w sposób ogólny. W przypadku usługi z nocnymi importami test musi obejmować co najmniej jeden taki import; w przypadku klastra o wysokiej dostępności istotne znaczenie może mieć kontrolowane przełączenie awaryjne. Z góry określ wartości docelowe i kryteria przerwania testu. W przypadku pojawienia się nowych komunikatów jądra systemu, powtarzających się błędów agentów lub odchyleń merytorycznych test nie zostanie zatwierdzony, a wyniki zostaną zbadane przed kolejną falą.

Prawidłowa ocena stanu poprawki za pomocą polecenia kcarectl

Zarejestruj stan przed i po zatwierdzonej operacji instalowania poprawek za pomocą tych samych poleceń. Pozwoli to ustalić, które jądro zostało uruchomione, jaką wersję agenta wykorzystuje host oraz czy zestaw poprawek jest faktycznie aktywny. Wyniki należy umieścić w protokole zmian lub protokole testowym wraz z sygnaturą czasową, identyfikatorem hosta oraz wersją testowanej aplikacji. Sam komunikat o pomyślnym zakończeniu instalacji nie stanowi wystarczającego dowodu.

Poniższe zapytania mają charakter odczytowy i nadają się do sporządzenia stanu aktualnego. Należy je wykonać w środowisku docelowym, korzystając z uprawnień przewidzianych w tym środowisku. Dopiero późniejsza, świadomie zaplanowana operacja aktualizacji zmienia stan poprawek; dlatego też wynik tych poleceń stanowi podstawę do porównania i monitorowania, a nie sama operacja instalowania poprawek.

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

Szczególnie ważne jest rozróżnienie między systemem uruchomionym a wersja jądra. Skaner podatności, który tylko uname -r może to sprawiać wrażenie, że oprogramowanie nie jest aktualne, mimo że poprawka jest dostępna w postaci aktualizacji na żywo. Dlatego należy uzgodnić stan inwentarza i zasady zgodności z danymi udostępnionymi przez TuxCare, takimi jak aktualna wersja oraz lokalna lista CVE dostępna pod adresem /proc/kcare/cvelist.

Do powiadamiania nadaje się kcarectl --status jest lepsze niż zwykłe wyszukiwanie tekstowe w wynikach konsoli, ponieważ kody wyjścia można analizować automatycznie. Na przykład kod 2 wymaga podjęcia decyzji, czy nowy zestaw poprawek powinien zostać wdrożony w przewidzianym terminie; kod 3 oznacza problem z kompatybilnością lub stanem zasobów. Żaden z tych kodów nie zastępuje analizy logów jądra, wskaźników usług i transakcji biznesowych.

Stopniowe wdrażanie w środowiskach QA, Canary i produkcyjnym

Kontrolowane wdrażanie rozpoczyna się w dedykowanym środowisku kontroli jakości (QA), następnie przechodzi przez małą, reprezentatywną grupę testową typu „canary” i jest rozszerzane dopiero po uzyskaniu udokumentowanych, stabilnych wyników. Każda fala przechodzi te same testy stanu i testy aplikacji. Okres obserwacji zależy od cyklu obciążenia: w przypadku systemów wsadowych liczy się pełny przebieg przetwarzania, natomiast w przypadku klastrów może on obejmować replikację i kontrolowane przełączenie awaryjne.

W trakcie monitorowania sprawdzasz wskaźniki błędów, opóźnienia, komunikaty jądra i agentów, a także – w razie potrzeby – kworum i replikację. Dopiero po spełnieniu kryteriów zatwierdzenia przechodzi się do następnej grupy. Dalsze podstawowe informacje dotyczące wdrażania w trakcie bieżącej eksploatacji wyjaśniono w wewnętrznym artykule KernelCare Enterprise: aktualizacje na żywo bez okien serwisowych.

Opóźnienia w przekazywaniu danych oraz UPDATE_DELAY rozwiązują podobne zadania na różnych poziomach. Kanał jest udostępniany za pośrednictwem PREFIX wybrano jako źródło patcha ze stałym opóźnieniem. UPDATE_DELAY Natomiast zestawy poprawek są wstrzymywane poprzez konfigurację klienta do momentu osiągnięcia określonego minimalnego wieku. STICKY_PATCHSET ogranicza klienta do określonego maksymalnego poziomu zestawu poprawek.

Ręczne kcarectl --update pobiera najnowszy zestaw poprawek i stosuje go do uruchomionego jądra. Polecenie to należy stosować wyłącznie na zatwierdzonych systemach testowych lub w wyznaczonym oknie serwisowym. Przed wykonaniem tej czynności należy zapisać wartości bazowe, a zaraz po jej zakończeniu przeprowadzić kontrole techniczne i merytoryczne.

ePortal umożliwia scentralizowane zarządzanie zestawami poprawek i ich dystrybucją. Według TuxCare, gdy włączone są automatyczne aktualizacje, klienci sprawdzają dostępność zestawów poprawek co cztery godziny. Nie oznacza to jednak gwarantowanego czasu wykonania: w każdej fali należy monitorować dostępność, rejestrację, zasady oraz zgodność jądra.

W każdej fali należy odnotować stan poprawek, wybrane hosty, okno obserwacyjne, wyniki kontroli oraz osobę odpowiedzialną za zatwierdzenie. W przypadku odchyleń proces wdrażania zostaje wstrzymany. Te Zatwierdzenie Canary ogranicza zakres nieoczekiwanych skutków, ale nie zastępuje ani testu zgodności, ani zaplanowanego cyklu ponownego uruchamiania.

Testowanie funkcji Secure Boot i krytycznych przypadków szczególnych

Serwer z Bezpieczny rozruch należą do osobnej grupy testowej. Agent wymaga dla swoich modułów jądra działającego łańcucha zaufania; pomyślny przebieg instalacji jeszcze tego nie potwierdza. TuxCare określa minimalną wersję agenta 3.0-2 dla zautomatyzowanej procedury Secure Boot na obsługiwanych systemach RPM. Informacja ta nie stanowi ogólnej minimalnej wersji dla KernelCare ani nie dotyczy ręcznej rejestracji MOK.

Aby skorzystać z trybu automatycznego, muszą być między innymi dostępne: EFI-Boot, shim oraz włączona funkcja Secure Boot. Według TuxCare procedura ta nie jest przeznaczona dla systemów Debian i Ubuntu. Dlatego przed rozpoczęciem testu należy odnotować dystrybucję, tryb rozruchu oraz wersję agenta, a platformę odbiegającą od standardu traktować nie jako zwykłą odmianę konfiguracyjną, lecz jako odrębną ścieżkę, którą należy ocenić ręcznie.

Test kończy się dopiero po zaplanowanym ponownym uruchomieniu systemu. Następnie sprawdź to za pomocą narzędzia opisanego przez TuxCare mokutil lub na podstawie odpowiednich komunikatów jądra systemu, czy certyfikat jest rzeczywiście dostępny w łańcuchu zaufania. Dopiero potem na tym hoście następuje kontrolowane pobranie aktualizacji Livepatch z tymi samymi weryfikacjami merytorycznymi i technicznymi, co w pozostałej części cyklu kontroli jakości.

Również systemy z zastrzeżonymi sterownikami, modułami pamięci masowej lub sieciowymi, programami eBPF, oprogramowaniem zabezpieczającym i agentami monitorującymi wymagają własnego, reprezentatywnego zakresu testów. Nie jest to ogólne stwierdzenie dotyczące niezgodności. Z technicznego punktu widzenia framework Upstream Linux Livepatch opisuje przejścia spójności dla odpowiednich zadań; nie dowodzi to jednak, że KernelCare stosuje ten sam mechanizm na każdej obsługiwanej platformie.

Dlatego należy odzwierciedlić kombinacje, które faktycznie występują podczas pracy: na przykład pamięć typu multipath pod obciążeniem, szyfrowane połączenia sieciowe, agenci bezpieczeństwa oraz rola przełączania awaryjnego węzła klastra. Należy udokumentować załadowane moduły, komunikaty jądra oraz stan aplikacji i klastra przed i po zastosowaniu poprawki. Uproszczona maszyna wirtualna testowa pozbawiona tych komponentów może potwierdzić instalację agenta, ale nie dostarczy wiarygodnych informacji na temat tej klasy systemów.

Monitorowanie, analiza błędów i bezpieczna eskalacja

Monitoruj wprowadzanie poprawek na żywo na dwóch poziomach: plik w formacie nadającym się do odczytu maszynowego Stan aktualizacji pokazuje stan agenta, podczas gdy logi jądra, wskaźniki błędów, opóźnienia i stan klastra odzwierciedlają działanie aplikacji. Aktualny stan aktualizacji nie wyklucza jednoczesnego wystąpienia awarii aplikacji lub odchylenia merytorycznego. System alarmowania i zatwierdzania musi zatem łączyć oba poziomy i oddzielnie badać przyczynę odchylenia.

W zakresie automatycznej selekcji pacjentów zapewnia kcarectl --status Zdefiniowane kody wyjścia: 0 oznacza najnowszy poziom poprawek, 1 – brak zastosowanych poprawek, 2 – dostępne, ale jeszcze niezastosowane poprawki, a 3 – nieobsługiwane jądro. Kod 3 wymaga najpierw sprawdzenia zgodności; kod 2 nie jest błędem aplikacji, ale należy go ocenić pod kątem planowanej polityki wdrażania i aktualizacji.

W przypadku odchyleń należy najpierw zebrać dane, które można skorelować czasowo: informacje o stanie i aktualizacjach, komunikaty agentów, dziennik jądra, moment wywołania, obciążenia, których to dotyczy, oraz zmiany w modułach lub infrastrukturze. W przypadku węzłów klastra należy uwzględnić przynależność do klastra, stan replikacji oraz zdarzenia związane z przełączeniem awaryjnym. Dane te pozwalają odróżnić stan aktualizacji od wystąpienia w tym samym czasie awarii aplikacji lub sieci oraz zapewniają przejrzystość zgłoszenia do pomocy technicznej.

TuxCare dokumentuje kcarectl --force jako opcja wraz z aktualizacją, która wymusza zastosowanie poprawki, jeśli niektórych wątków nie da się zawiesić. Dokumentacja głównego gałęzia Linuksa ostrzega przed możliwymi uszkodzeniami związanymi z własnym mechanizmem wymuszania, wymaga następnie zaplanowanego restartu i odradza stosowanie kolejnych poprawek na żywo. Nie potwierdza jednak, że kcarectl --force wewnętrznie wykorzystuje tę samą semantykę. Decydujące znaczenie mają zatem instrukcje pomocy technicznej TuxCare dotyczące konkretnego produktu oraz diagnoza danego hosta; opcja ta nie nadaje się do stosowania jako standardowe działanie w ramach wdrażania lub usuwania usterek.

Zaplanowanie strategii ponownego uruchomienia i udokumentowanego zatwierdzenia

Funkcja „Live Patching” skraca czas potrzebny na załatanie obsługiwanych luk w zabezpieczeniach jądra, ale nie zmienia zainstalowanego pakietu jądra. Nowe pakiety jądra, obsługa sprzętu, zmiany w sterownikach lub oprogramowaniu układowym oraz ulepszenia funkcjonalne jądra nadal wymagają regularnego zarządzania pakietami i zaplanowanych ponownych uruchomień.

W związku z tym należy ustalić częstotliwość ponownego uruchamiania dla każdej klasy platformy. KernelCare udostępnia poprawki dla konkretnego jądra tylko tak długo, jak długo jego producent dostarcza aktualizacje zabezpieczeń dla danej serii. Okno konserwacyjne pozwala ponadto przywrócić zgodność między uruchomionym jądrem, załadowanymi sterownikami oraz udokumentowanym stanem docelowym.

TuxCare dokumentuje kcarectl --unload do pobierania poprawek KernelCare. Nie oznacza to jednak ogólnej gwarancji pełnego przywrócenia stanu poprzedniego. Dokumentacja źródłowa wskazuje, że w przypadku funkcji Atomic Replace i skumulowanych poprawek Livepatches zmiany stanu mogą utrudniać powrót do poprzedniego stanu; nie opisuje ona jednak automatycznie konkretnej implementacji każdej wersji KernelCare.

Przed usunięciem oprogramowania sprawdź zatem dokumentację dotyczącą zainstalowanej wersji agenta i w razie potrzeby uzgodnij działania naprawcze z firmą TuxCare. Niezawodny Punkt powrotu Pozostaje zdefiniowane, przetestowane jądro rozruchowe z zaplanowanym ponownym uruchomieniem oraz, w razie potrzeby, kontrolą spójności lub przywróceniem aplikacji.

Zatwierdzenie fali wdrożeniowej zawiera informacje o obsługiwanym jądrze, statusie poprawek, przeprowadzonych testach aplikacji, odpowiednich cyklach obciążenia, logach, osobach odpowiedzialnych oraz kryteriach przerwania. Nie stanowi to ogólnej gwarancji dotyczącej przyszłych zestawów poprawek. Zmiany w jądrze, modułach lub aplikacji mogą wymagać ponownego przeprowadzenia testów kontroli jakości (QA) i testów typu „canary”.

• Należy udokumentować obsługiwane jądro, źródło poprawki oraz aktualny stan poprawek.
• Wykazać, że testy aplikacji, cykl obciążenia, logi jądra i stan klastra nie wykazują żadnych niewyjaśnionych odchyleń.
• Określić etap wdrożenia, osoby odpowiedzialne, ścieżki alarmowe oraz kryteria przerwania procesu.
• Zaplanować kolejną aktualizację jądra wraz z oknem serwisowym, jądrem rozruchowym i testem ponownego uruchomienia.

W związku z tym decyzja operacyjna pozostaje jednoznaczna: udana aktualizacja na żywo pozwala na kontrolowane kontynuowanie danej fali. Natomiast niejasne sygnały techniczne lub merytoryczne prowadzą do wstrzymania, analizy lub planowanego ponownego uruchomienia. Planowanie ponownego uruchomienia stanowi część koncepcji bezpieczeństwa i przywracania sprawności, a nie przyznanie się do niepowodzenia aktualizacji na żywo.