NeuVector to narzędzie, które wychodzi daleko poza standardowe funkcje oferowane przez Kubernetes w zakresie bezpieczeństwa i monitorowania sieci. Dzięki zaawansowanemu firewallowi, kompleksowemu monitorowaniu połączeń oraz wykrywaniu zagrożeń w czasie rzeczywistym, NeuVector zapewnia pełną kontrolę nad infrastrukturą kontenerową. W tym artykule przyjrzymy się mu bliżej i sprawdzimy, jak to narzędzie pomaga w zarządzaniu regułami sieciowymi, skanowaniu obrazów kontenerowych i monitorowaniu zgodności z branżowymi standardami, a także jak wpływa na bezpieczeństwo aplikacji w dynamicznych środowiskach CI/CD. Poznaj funkcje, które gwarantują pełną ochronę twoich aplikacji, niezależnie od ich skali.
Kilka lat temu, podczas jednej z luźnych rozmów w kuluarach mojej firmy, temat dyskusji zszedł na tory szeroko pojętej konteneryzacji. Wówczas jeden z kolegów zadał pytanie: jak to właściwie jest z tym Kubernetesem od strony bezpieczeństwa w porównaniu do klasycznych rozwiązań, gdzie mamy typowy serwer z Linuksem i uruchomioną na nim aplikację? Zacząłem się zastanawiać, w jaki sposób można wyjaśnić problemy bezpieczeństwa aplikacji oraz środowisk kontenerowych.
Czym właściwie są kontenery?
Sprawa pozornie może wydawać się prosta. Kontenery rozumiemy jako niezależne jednostki, które zawierają dedykowane środowisko operacyjne, skonfigurowane pod konkretną aplikację. Tworzą one część większego ekosystemu, który sam w sobie jest odrębną całością infrastruktury. Kubernetes, będący środowiskiem kontenerowym, działa więc w izolacji od innych systemów informatycznych firmy. Dzięki tej izolacji można uznać go za stosunkowo dobrze chronione i bezpieczne rozwiązanie. Jednak gdy zastanowimy się, z czego tak naprawdę składa się Kubernetes i ile elementów składowych musimy wziąć pod uwagę, aby naszą aplikację uruchomić, okazuje się, że sprawa staje się mocno skomplikowana.
Po wymianie kilku zdań wspomniana dyskusja skierowała się w zupełnie innym kierunku i więcej już do tematu nie wracaliśmy. Natomiast przygotowując się do napisania tego artykułu, przypomniałem ją sobie. Zacząłem się zastanawiać, w jaki sposób można by ją poprowadzić, mając za słuchaczy osoby obeznane z tematyką kontenerową i świadome zagrożeń bezpieczeństwa. Nie zawsze bowiem zdajemy sobie sprawę, jak wiele, z pozoru błahych czynników, może mieć znaczenie dla bezpieczeństwa tak skomplikowanego strukturalnie środowiska, jakim jest orkiestrator w postaci Kubernetesa czy jego implementacji, takich jak Rancher, czy OpenShift.
Narzędzia podstawą analizy podatności serwerów
Zacznijmy od obrazu bazowego z doinstalowanymi i skonfigurowanymi elementami, które stanowią nasz kontener wraz z podłączonymi do niego dodatkowymi obiektami (jak pamięć dyskowa), poprzez routowalną sieć, na nodach w postaci fizycznych lub wirtualnych maszyn, na których rozłożony jest nasz klaster kończąc. Powiedzmy sobie wprost: działy bezpieczeństwa w firmach ściśle współpracujące z administratorami systemów zazwyczaj działają dosyć sprawnie. Jednak nawet najlepszy specjalista bez odpowiednich narzędzi nie będzie w stanie zbyt wiele zrobić. Analiza podatności serwerów i ich zgodność z normami czy analiza ruchu sieciowego przy pomocy specjalistycznych programów narzędziowych, to kluczowe działania, które działy bezpieczeństwa skutecznie podejmują.
Jednak co w przypadku kontenerów, które są bytami w pewnym sensie efemerycznymi, bez możliwości instalowania agentów czy dokonywania zmian bezpośrednio w systemie? Dodając do tego pewną specyficzną rolę, jaką pełnią w Kubernetesie serwery oraz stopień skomplikowania połączeń sieciowych pomiędzy aplikacjami tworzonymi najczęściej w postaci wielu działających równolegle mikroserwisów (problemem mogą być chociażby dynamiczne adresy IP), rysuje się nam obraz środowiska o dosyć dużym stopniu skomplikowania.
Zatem jak sobie z tym poradzić? Tak jak wspomniałem, specjalistyczne oprogramowanie narzędziowe wykorzystywane przez specjalistów z zakresu bezpieczeństwa w większości przypadków jest dosyć skuteczne. Stosując oddzielnie analizatory podatności czy skanery sieci będziemy w stanie wykryć większość zagrożeń, jakie na nas czekają. Jednak pewne elementy środowiska, takie jak wspomniane kontenery czy inne obiekty typowo kubernetesowe, są praktycznie bezbronne. Dodatkowo często stosowane są procesy CI/CD czy repozytoria kodu, które stanowią elementy na tyle specyficzne, że trudno dokonać jakiejkolwiek analizy bez specjalistycznego oprogramowania przeznaczonego właśnie do tego celu.
Co z Kubernetesem?
Dochodzi do tego jeszcze Kubernetes sam w sobie. Co prawda składa się on z wielu pomniejszych elementów, ale w gruncie rzeczy jest kompletnym ekosystemem skonfigurowanym w ściśle określony sposób. Również tutaj możemy natrafić na problemy, których w żaden inny sposób – niż tylko specjalistycznym, przeznaczonym do pracy w środowisku kontenerowym narzędziem – nie będziemy mogli wykryć. Kubernetes jest typowym programem składającym się z wielu modułów, z których każdy stanowi niejako odrębną i kompletną całość, ale połączonych i ściśle ze sobą współpracujących. Z jednej strony każdy element może być całkowicie pewny i bezpieczny, z drugiej kluczowy jest właśnie sposób połączenia elementów w jedną całość.
Przykładem może być chociażby certyfikat TLS, który umożliwia bezpieczne przesyłanie informacji pomiędzy modułami. Brak cyklicznej wymiany certyfikatu zwiększa ryzyko związane z wyciekiem informacji. Jest to element, który niejako zapewnia system nadrzędny, łącząc elementy składowe ze sobą. To i wiele innych zagrożeń, o których wspomnimy wielokrotnie w tym artykule, można zniwelować praktycznie do zera przy pomocy specjalistycznego programu narzędziowego przeznaczonego do pracy w środowisku kontenerowym. Takim programem jest tytułowy NeuVector, który omówimy w tym artykule szerzej.
Czym jest NeuVector?
NeuVector jest natywną dla Kubernetesa platformą zapewniającą między innymi ochronę przed lukami w zabezpieczeniach. Umożliwia także skanowanie w czasie rzeczywistym aktywności kontenerów czy hostów, monitoring zgodności środowiska ze standardami oraz ochronę procesu CI/CD od momentu budowania aplikacji do jej uruchomienia wraz z wymuszeniem zastosowania pewnych zasad przed wykonaniem wdrożenia. Jedną z kluczowych funkcji NeuVectora jest również ciągła analiza i monitoring ruchu sieciowego wraz z opcją aktywnej zapory ogniowej.
Wszystkie działania, jakie podejmuje Kubernetes lub jakie my (jako administratorzy) możemy za jego pośrednictwem podjąć, wykonuje, patrząc przez pryzmat działających kontenerów. Traktuje je oraz pody jako wierzchołek góry lodowej, wewnątrz której znajdują się wszystkie elementy składowe Kubernetesa pozwalające na uruchomienie aplikacji, a u podstawy której są nody z zainstalowanym niezależnie systemem operacyjnym. NeuVector pokazuje nam stan wszystkich tych elementów mogących mieć wpływ na bezpieczeństwo systemu. Począwszy od zgodności z normami, zainstalowanych pakietów, uruchomionych procesów czy połączeń sieciowych, traktując jednocześnie każdy z tych elementów całkowicie indywidualnie.
NeuVector a inne platformy
NeuVector działa jako natywna aplikacja Kubernetesa. Jest to o tyle ważne, iż może on być z powodzeniem używany zarówno w środowisku Rancher, jak i OpenShift, ale w dalszym ciągu pozostaje aplikacją kubernetesową. Oznacza to, że pewne obiekty typowe dla wspomnianych wyżej środowisk, jak chociażby projekty w Rancherze, dzięki którym możemy zarówno organizować, jak i zarządzać dostępem do namespace’ów na tejże platformie, będą dla NeuVectora niewidoczne. Nie oznacza to, że działanie na platformach innych niż klasyczny Kubernetes jest ograniczone – wręcz przeciwnie.
Narzędzie doskonale integruje się z każdą platformą, na której działa. Dodatkowo przy pomocy chociażby rozszerzenia NeuVector UI możemy uzyskać dostęp do narzędzia z poziomu konsoli platformy Rancher, wykorzystując między innymi dobrodziejstwa pojedynczego logowania (SSO). Współpraca z platformą Rancher nie powinna dziwić, gdyż NeuVector pochodzi od firmy SUSE, która jest również producentem Ranchera. Możemy się więc spodziewać, że wraz z rozwojem obydwu systemów, będzie ona coraz lepsza.
NeuVector jako typowa aplikacja kontenerowa zbudowana i instalowana jest najczęściej przy pomocy Helm Chartu jako zestaw komponentów, uruchamiając mikroserwisy, takie jak Kontrolery, Egzekutory, Menedżery i Skanery oraz CronJob, z których każdy ma swoje ściśle określone zadania, jak skanowanie, wymuszanie polityk czy aktualizacja bazy CVE.
Mikroserwisy aplikacji NeuVector
Zarządzanie klastrami
Po zainstalowaniu i uruchomieniu system zgłasza nam się jako praktycznie gotowa do pracy aplikacja. Po kilku zabiegach konfiguracyjnych, takich jak dodanie klastra czy stworzenie użytkowników lub podłączenie do kontrolera domeny i przyznanie wymaganych dostępów, możemy zabrać się za analizę. Jedną z ciekawszych funkcji NeuVectora jest to, że posiadając kilka klastrów kubernetesowych możemy podłączyć każdy z nich do jednej działającej instancji. Dzięki temu z jednej konsoli administracyjnej mamy dostęp do każdego z nich. W takiej sytuacji jeden pełni rolę klastra głównego, a pozostałe są zarządzalne.
Jest to dosyć ciekawe rozwiązanie, gdyż pozwala nam na globalne stosowanie pewnych reguł. Na przykład dotyczących ruchu sieciowego, działania procesów czy dostępu do plików, do wszystkich podłączonych do NeuVectora klastrów. Jest to wygodne w sytuacji, gdy mamy bardzo podobne do siebie środowiska i zależy nam na tym, aby raz skonfigurowane reguły móc zastosować na pozostałych klastrach. Warunkiem jest oczywiście posiadanie odpowiednich uprawnień w każdym klastrze.
Zarządzanie klastrami
Polityki federacyjne
Wiele predefiniowanych reguł jest dodawanych do listy polityk federacyjnych przez samego NeuVectora już na etapie konfiguracji klastra.
Polityki federacyjne
NeuVector – strona główna
NeuVector po wykonaniu kilku zabiegów konfiguracyjnych przywita nas stroną główną, prezentującą nam ogólny obraz naszego klastra: od informacji ogólnych, poprzez bardziej szczegółowe, dotyczące poszczególnych elementów systemu, na statystykach kończąc.
Strona główna
Analiza systemu zaczyna się w menu „Assets”, które, podzielone na kategorie jak przestrzenie nazw, węzły czy kontenery, pozwala nam monitorować, dodawać i częściowo także zarządzać integralnymi elementami składowymi klastra. Umożliwia także zarządzanie dodatkowymi komponentami wchodzącymi w skład procesów CI/CD jak rejestry obrazów wraz z weryfikacją podpisów cyfrowych.
Tryby pracy NeuVectora
Tryb Discover
Podstawowym i domyślnym sposobem działania NeuVectora jest tryb „Discover”. Jest to swoisty tryb uczenia, w którym analizowane jest wszystko to, co dzieje się w środowisku. Po wykonanym skanowaniu i na podstawie zbieranych w czasie rzeczywistym informacji budowana jest baza danych o kontenerach, procesach czy połączeniach sieciowych. Korelacja poszczególnych komponentów jest tutaj bardzo ważna, gdyż mamy hosty pełniące rolę węzłów Kubernetesa z uruchomionymi na nich podami. Na nich z kolei znajdują się kontenery, dzięki czemu każdy element jest traktowany jako oddzielny byt, a jednocześnie jako element składowy większej całości.
Zwracam na to uwagę w kontekście tego, o czym pisałem wcześniej. Istnieje wiele programów narzędziowych pozwalających na skanowanie serwerów pod kątem luk, podatności czy zgodności ze standardami. Jednak w oderwaniu od funkcji, jakie dane serwery pełnią, raport uzyskany w ten sposób będzie co najmniej niepełny. Dodając do tego efemeryczność kontenerów, które w naturalnym stanie (nie mówimy o maszynach wirtualnych opartych na kontenerach, pomimo że w ostatnim czasie technologia ta staje się coraz popularniejsza) nie mogą być traktowane jak virtualki i skanowane z użyciem standardowych narzędzi, dochodzimy do momentu, w którym tylko specjalistyczne narzędzia, takie jak NeuVector dają nam możliwość wykrywania zagrożeń.
Lista zagrożeń
NeuVector traktuje jednak kontenery trochę jak virtualki. Skanuje je i prezentuje nam listę podatności wraz z opisem oraz odnośnikiem do strony zawierającej opis danego problemu, niezgodności ze standardami, którymi możemy do pewnego stopnia zarządzać, czy w końcu pokazując listę procesów uruchomionych na każdym kontenerze.
Tryb „Discover” pozwala na nauczenie NeuVectora zachowań systemu z punktu widzenia działających procesów czy połączeń sieciowych. Opowiemy o nim szerzej w dalszej części materiału, tworząc bazę reguł na podstawie normalnej pracy kontenerów i pracujących w nich aplikacji.
Tryb Monitor
Tryb „Monitor” działa nieco inaczej. Tutaj nic nie jest wykrywane, a wszystkie reguły, których system nie został wcześniej nauczony, są traktowane jako potencjalnie niebezpieczne. W tym trybie nic nie jest blokowane. Jednak każde odstępstwo od reguł powoduje wpis do dziennika zdarzeń.
Tryb Protect
Ostatnim trybem jest „Protect” będący swego rodzaju rozszerzeniem trybu „Monitor”. W tym wypadku każde odstępstwo od nauczonych reguł powoduje zablokowanie możliwości uruchomienia procesu na kontenerze czy połączenia sieciowego, które nie spełnia określonych zasad.
Procesy
Oczywiście tryb uczenia nie jest jedyną metodą na tworzenie reguł. Mamy tutaj możliwość modyfikacji czy nawet tworzenia własnych.
Grupy
Aby stworzyć lub zmodyfikować regułę, musimy powiedzieć nieco więcej o grupach. Grupą, która jest podstawową jednostką, jaką posługuje się NeuVector w zakresie polityk bezpieczeństwa, mogą być hosty, kontenery czy nawet wykryte podczas połączeń sieciowych jednostki zewnętrzne. Najczęściej jednak jako grupę traktujemy podstawowe kontrolery Kubernetesa, poprzez które realizujemy wdrożenia, tj. Deployments, StatefulSets, and DaemonSets wraz z podami, których uruchomienie jest jednym z efektów ich wykonania. Grupy wykrywane są automatycznie, ale nic nie stoi na przeszkodzie, aby stworzyć własne według zadanych kryteriów.
Grupy
Tryb pracy NeuVectora możemy ustawić oddzielnie dla danej grupy. Jest to szczególnie ważne w przypadku środowisk testowych i przedprodukcyjnych. Dzięki temu w przypadku nowych wdrożeń bądź konieczności przetestowania lub weryfikacji istniejących, nie musimy zmieniać trybu dla całego klastra. Co więcej, mamy również funkcję eksportu i importu polityk bezpieczeństwa, przez co możemy w szybki i pewny sposób skonfigurować środowisko produkcyjne bez narażania go na niepotrzebne niebezpieczeństwo związane ze zmianą trybu działania. Zalecanym trybem działania dla środowisk produkcyjnych jest bowiem wyłącznie trybu „Protect”.
Reguły sieciowe
Reguły sieciowe wykrywane są w trybie „Discover” analogicznie do procesów. Tutaj też mamy możliwość tworzenia własnych. Jedną z różnic w stosunku do procesów jest to, że dotyczą one nie tylko kontenerów, ale całego klastra, włączając w to nody, przez które i za pośrednictwem których odbywa się ruch. Dotyczy to zarówno sieci overlay, z której korzystają kontenery, jak i sieci routowalnej. Analizy ruchu sieciowego możemy dokonać także przy pomocy narzędzia „Network Activity”, stanowiącego graficzną reprezentację wykrytych i utworzonych reguł.
Aktywność sieciowa
W trybach „Monitor” i „Protect” zachowanie systemu jest nieco inne. Jak wspomniałem wcześniej, każda aktywność, która nie została wcześniej wykryta, jest uznawana jako niebezpieczna i odnotowywana w dzienniku zdarzeń. Z tego też miejsca mamy możliwość dodania każdej z wykrytych nieprawidłowości do listy akceptowanych, biorąc niejako odpowiedzialność za to – reguła taka będzie widoczna w systemie jako „User created”.
Zdarzenia bezpieczeństwa
Reguły użytkownika
Reguły sieciowe w Kubernetes – Network Policies
Mówiąc o regułach sieciowych, musimy wziąć pod uwagę, jak bardzo skomplikowany jest to temat w Kubernetesie. Zaczynając od połączeń między podami w ramach jednego czy też wielu namespaceów, na udostępnianiu usług poza kontener kończąc. Nie znaczy to, że Kubernetes jest całkowicie bezbronny w tym temacie. Oferuje chociażby narzędzie Network Policies umożliwiające definiowanie reguł, zgodnie z którymi nasze połączenia będą realizowane.
Jest to narzędzie dobre i jak najbardziej może i nawet powinno być wykorzystywane. Jednak jego przeznaczenie jest nieco inne. Tworząc reguły sieciowe na poziomie samego Kubernetesa korzystamy bowiem najczęściej z etykiet (czy to na poziomie aplikacji, czy namespace’ów), zakładając, iż są one poprawnie skonfigurowane i niezmienne. Nie mamy tutaj możliwości śledzenia ruchu (poza oczywiście analizą logów) czy jego graficznej prezentacji. W przypadku niewielkiej liczby kontenerów umieszczonych w nielicznych tylko namespace’ach i w sytuacji, gdy mamy relatywnie dużą pewność niezmienności naszego środowiska, takie rozwiązanie jest wystarczające.
Reguły sieciowe w NeuVector
Natomiast NeuVector daje nam narzędzia i możliwości w znaczny sposób wykraczające poza to, co oferuje Kubernetes. Dodatkowo bardzo mocno zwiększają one możliwości analizy, a co za tym idzie – bezpieczeństwa. Można powiedzieć, że mamy tutaj do czynienia z typowym firewallem blokującym niechciany ruch. Z tą różnicą w stosunku do klasycznych rozwiązań, że każde połączenie jest analizowane pod kątem wszystkich elementów w nim pośredniczących – zaczynając od kontenera, poprzez ingresy, serwery dns i inne, typowe dla Kubernetesa elementy, na obiektach zewnętrznych, leżących niejako poza naszą jurysdykcją kończąc.
Pracując w trybie odkrywania, zauważymy, że próba wykonania połączenia w kierunku kontenera czy też z niego samego na zewnątrz, spowoduje wykrycie kilku reguł zamiast jednej. Na stronie „Network Activity” pojawią się nowe, niewykryte wcześniej, bo nieużywane do tej pory elementy.
Reguły sieciowe
Nadmienić należy też, że każdą regułę, nawet jeżeli należy ona do tego samego połączenia, możemy zablokować, nawet bez widocznej straty dla samego połączenia. Czasami sam Kubernetes sięga do dodatkowych obiektów jak serwery DNS czy monitoring, których użycie jest jak najbardziej uzasadnione i potrzebne, ale z punktu widzenia sieci nie zawsze rozpoznawalne. Dlatego też mamy możliwość zablokowania takich połączeń i bardzo dokładnej ich analizy.
Network Activity
Narzędzie Network Activity, o którym w kontekście trybów pracy już trochę powiedzieliśmy, daje nam właśnie te możliwości, których brakuje w Network Policies. Mam tu na myśli graficzne przedstawienie całej, związanej z naszym klastrem sieci. Próbując narysować siatkę połączeń pomiędzy wszystkimi komponentami, otrzymamy pajęczynę, która praktycznie uniemożliwia jakąkolwiek analizę. Daje nam jednak obraz systemu i dostarcza wiedzę na temat jego skomplikowana. Duże znaczenie ma tutaj dokładne określenie, które elementy tak naprawdę nas interesują. Możemy to zrobić przy pomocy przestrzeni nazw czy grup, o których powiedzieliśmy sobie, omawiając temat podatności.
Aktywność sieciowa – widok nodów
Funkcje NeuVectora w dużym stopniu pokrywają się z tymi, które oferują nam programy wykorzystywane przez działy bezpieczeństwa czy sieci, służące do analizy ruchu lub wykrywania zagrożeń. Czy to znaczy, że stoją z tymi programami w sprzeczności i ich używanie stanowi jakąś przeszkodę w postaci dublowania funkcji? I tak i nie. Odpowiedź na to pytanie zależy od ilości i stopnia wykorzystania oprogramowania, jakie posiadamy. NeuVector oferuje możliwości, których poprzez swoje ukierunkowanie na technologie kontenerowe oraz ogólną wszechstronność i kompleksowość platformy trudno szukać gdzie indziej.
Monitorowanie środowiska
Poza zarządzaniem podatnościami i ruchem sieciowym (w tym funkcje zaawansowanego firewalla, które pozwalają nam zapanować nad pajęczyną kontenerów bez względu na rozmiar i stopień skomplikowania naszego klastra), mamy do dyspozycji również funkcje skanowania środowiska pod kątem niezgodności i odstępstw od przepisów, regulacji czy przyjętych standardów. Znajdziemy wśród nich takie regulacje jak PCI DSS (określające standardy ochrony kart płatniczych), HIPAA (regulujące ochronę prywatności i bezpieczeństwa danych medycznych), ochronę danych osobowych GDPR czy standardy bezpieczeństwa informacji i zarządzania ryzykiem NIST. To, które z nich będziemy wykorzystywać, zależy w głównej mierze od profilu działalności naszej firmy i standardów, jakie powinniśmy stosować. NeuVector daje nam możliwość ciągłego monitorowania naszych klastrów w poszukiwaniu odstępstw od standardów, w odniesieniu do takich obiektów jak obrazy, węzły czy kontenery wraz z możliwością szczegółowej konfiguracji.
Konfiguracja standardów i regulacji
Wzorce standardów i regulacji
W przypadku monitorowania zgodności nie mamy odnośników do konkretnych regulacji. Są one dobrze opisane i stanowią pewien standard, znany doskonale działom bezpieczeństwa. Niemniej jednak każda wykryta nieprawidłowość jest szczegółowo opisana wraz z podaniem obiektów, których dotyczy.
Monitorowanie zgodności
Nie zapominajmy, że NeuVector jest narzędziem stricte kontenerowym. W związku z tym, poza nieprawidłowościami kontenerowymi, wszystkie te, które dotyczą nodów, czyli bądź co bądź fizycznych lub wirtualnych serwerów, są pokazane przez pryzmat funkcji, jakie pełnią.
Wsparcie NeuVector w procesach CI/CD
Powiedzieliśmy sobie dużo o funkcjach NeuVectora związanych z monitorowaniem działającego środowiska. Wśród zalet programu, jakie wymieniłem na początku, znalazła się wzmianka o wsparciu procesów CI/CD. Co NeuVector może nam zaoferować w tym temacie?
Akronim CI/CD jeszcze do niedawna był dosyć dużą nowością. Można go było zdefiniować jako najczęściej automatyczny proces budowania, testowania i wdrażania aplikacji przy użyciu jednego lub kilku połączonych ze sobą w jeden ciąg przyczynowo-skutkowy programów. Definicja naturalnie dalej funkcjonuje, ale odnoszę wrażenie, że podobnie jak wiele innych określeń, które na stałe weszły do słownika branżowego IT, z czasem stała się zbyt ogólna. Dobrym przykładem jest chociażby słowo DevOps, które jeszcze do niedawna dało się doskonale zdefiniować, a dzisiaj już nawet trudno powiedzieć, czym osoba określająca się tym mianem miałaby się zajmować. Znaczenie DevOps jest tak szerokie, że wydaje się prawie niemożliwe do zdefiniowania.
Wbrew pozorom zjawiska, o których wspomniałem, są dobre, ponieważ świadczą o tym, że branża informatyczna żyje i rozwija się. Nowe pomysły, nawet te na pierwszy rzut oka niezbyt trafione, są wdrażane w życie i stają się integralną częścią naszej branży. Ale jak to wygląda w praktyce i czy sam proces CI/CD może być potencjalnie niebezpieczny? Zadajmy sobie jedno fundamentalne pytanie: co jest na wejściu i na wyjściu każdego takiego procesu? W klasycznym i najprostszym z możliwych procesów CI/CD budujemy obraz na podstawie jakiegoś obrazu bazowego. No właśnie – jakiegoś. Zdarzają się sytuacje, gdy mamy do dyspozycji jedynie konkretne, przeskanowane i bezpieczne obrazy bazowe, ale nawet wtedy nie mamy pewności, czy w momencie budowania są one nadal bezpieczne. Dodając do tego proces instalacji i konfiguracji dodatkowego oprogramowania, a o to przecież chodzi w tym procesie, otrzymujemy produkt, co do którego nie możemy być pewni.
Co w przypadku, gdy nie mamy kontroli nad budowaniem?
Oczywiście wyżej opisałem sytuację, w której budowanie jest po naszej stronie lub gdy mamy pełną kontrolę nad tym procesem. Natomiast ogrom oprogramowania, jakie wdrażamy, jest tworzony przez firmy trzecie, a w tej sytuacji często nie mamy zbyt wiele do powiedzenia. Zawsze jednak otrzymujemy produkt końcowy w postaci gotowego obrazu kontenerowego. No dobrze, ale właściwie gdzie leży problem? Przecież skoro mamy narzędzia skanowania i analizy kontenerów w czasie rzeczywistym, to czy jest potrzeba używania kolejnego? Co prawda monitoring w czasie rzeczywistym pozwala nam wykryć anomalie i nieprawidłowości, ale zgodnie z zasadą, że lepiej jest zapobiegać niż leczyć, warto zwrócić uwagę, co tak naprawdę wdrażamy.
Zauważmy też, że sam proces skanowania odbywa się co prawda w czasie rzeczywistym, ale naprawa wykrytych już po wdrożeniu problemów taka prosta i szybka nie jest. Oczywiście bardzo dużo zależy od specyfiki samej firmy i funkcjonujących w niej procesów czy chociażby liczby środowisk testowych. Jednak bez względu na to, jak szybko zareagujemy i naprawimy dany problem, to pewnych ryzyk i przestojów nie unikniemy.
NeuVector – skanowanie obrazów kontenerowych
Jedną z ciekawszych funkcji NeuVectora jest możliwość skanowania obrazów kontenerowych, zanim jeszcze te do nas trafią pod kątem luk w zabezpieczeniach i podatności, jak również zgodności ze standardami. NeuVector pozwala na podłączenie najpopularniejszych rejestrów obrazów kontenerowych, takich jak JFrog Artifactory, Docker Registry, Gitlab czy Harbor (ta opcja dostępna jest po zainstalowaniu odpowiedniego modułu) oraz wiele innych, a także skanowanie każdego nowego obrazu, który się w danym repozytorium pojawia. Oczywiście nic nie stoi na przeszkodzie, aby cyklicznemu skanowaniu poddawać nie tylko nowe, ale również istniejące obrazy. Działanie takie możemy skonfigurować również po każdorazowej aktualizacji bazy podatności.
Skanowanie rejestru
Raport zgodności
Wynikiem skanowania jest raport zgodności ze standardami oraz podatności dla każdego modu, a także, w przypadku gdy podczas konfiguracji została zaznaczona odpowiednia funkcja, w podziale na warstwy obrazu. W sytuacji, gdy mamy pod kontrolą cały proces CI/CD, włączając w to budowanie obrazu i gdy nasze obrazy zmieniają się stosunkowo często, opcja ta jest niezwykle przydatna. Raport zresztą do złudzenia przypomina ten, który mieliśmy okazję omawiać dla węzłów czy kontenerów. Z tą różnicą, że nie działamy na uruchomionym kontenerze, ale na obrazie, który, jak już pisałem wcześniej, jest dla nas potencjalną kopalnią problemów, a które możemy niejako zdusić już w zarodku, zanim dopuścimy go do użycia w naszym systemie.
Skanowanie obrazu
Dlaczego w ogóle powinniśmy się tym martwić i jak to się ma do omawianego wcześniej skanowania uruchomionego kontenera? Zauważmy, że obraz jest pewnego rodzaju bazą, na której stawiamy nasz kontener. To tak, jakbyśmy skanowali system operacyjny wraz z konfiguracją jeszcze przed jego zainstalowaniem. Analogia może niezbyt dobra pomimo oczywistych podobieństw, ale faktycznie tak jest. Obrazy kontenerowe są oparte na obrazie bazowym, który nawet jeśli jest stuprocentowo bezpieczny, po modyfikacjach wykonanych przez dewelopera zazwyczaj bezpieczny nie jest. Dodając do tego fakt dezaktualizacji pakietów, zdarza się, że w celu przyspieszenia budowania obrazu, pomijana jest opcja update’u pakietów. Otrzymujemy wówczas pewnego rodzaju minę, która sama w sobie niebezpieczna nie jest, ale użyta w uruchomionym kontenerze, może narobić sporo szkód.
Podpisywanie obrazów
Dobrą praktyką w kontekście tworzenia obrazów kontenerowych, jest też ich podpisywanie z użyciem narzędzia Singstore/Cosign. Dzięki temu zwiększamy jeszcze bardziej pewność, że nasz obraz jest zweryfikowany i bezpieczny.
Weryfikacja podpisu
NeuVector daje nam możliwość weryfikacji, czy obraz, którego chcemy użyć, został podpisany odpowiednim kluczem lub tożsamością.
Podsumowanie
Można zauważyć, że NeuVector, pomimo swojej różnorodności i bogactwa funkcji, zaskakuje spójnością. Trudno oprzeć się wrażeniu, że celem nadrzędnym wszystkiego, co robimy, jest zapewnienie jak największego bezpieczeństwa kontenerom. Zaczynając od analizy samego środowiska, poprzez skanowanie i zabezpieczenie obrazu, na weryfikacji i ciągłym monitoringu uruchomionych kontenerów zarówno pod kątem podatności, jak i połączeń sieciowych kończąc.
Prześledźmy sobie raz jeszcze wszystkie elementy, które musimy wziąć pod uwagę, aby móc powiedzieć, że nasza aplikacja jest bezpieczna. Na samym początku mamy obraz kontenerowy, który musimy zbudować. Bez względu na to, czy dokonamy tego własnymi siłami, czy też otrzymamy gotowy, zbudowany obraz od zewnętrznego dostawcy, jest on źródłem potencjalnych problemów. Na przykład w postaci chociażby nieaktualnych pakietów czy też niezałatanych luk systemowych. Użycie obrazu bez podatności ochroni nas przed problemami, które mogą wynikać na przykład z braku aktualizacji, ale nie zapominajmy, że operację skanowania obrazu wykonujemy zazwyczaj tylko raz – w momencie umieszczenia jej w repozytorium.
Mamy oczywiście możliwość cyklicznego skanowania wszystkich obrazów i jest to funkcja bardzo przydatna, ale raczej mało wygodna w kontekście uchuchomionych kontenerów. Znacznie prościej i bezpieczniej jest trzymać rękę na pulsie poprzez ciągłe monitorowanie aplikacji już działających. To też jest kolejny element. Nie zapominajmy o uruchomionych procesach i połączeniach sieciowych. Tutaj NeuVector daje nam pokaz swojej siły, łącząc niejako funkcję zaawansowanego firewalla z monitoringiem wszystkich działających na danym kontenerze procesów.
Kontenery muszą gdzieś stać. W związku z tym kolejnym klockiem na naszej drodze są węzy w postaci hostów oraz Kubernetes sam w sobie (jako zbiór połączonych ze sobą i skonfigurowanych obiektów). Czy warto zatem zainwestować nieco środków, aby poznać wszystko to, co oferuje nam NeuVector? Zdecydowanie tak. Nawet jeżeli uznamy, że pewne jego funkcje dublują się z używanymi już programami, to myślę, że kompleksowość przedstawionego rozwiązania jest co najmniej warta uwagi.
