Scenariusz: Yu Pengfei , Mah Chia Hui

Wstęp

Gwałtowny wzrost wykorzystania Kubernetes w ciągu ostatniej dekady był ogromnym spektaklem. Jednak Rzymu nie zbudowano od razu i podobnie jak w przypadku każdego innego głównego stosu technologii w użyciu, minęło kilka dziesięcioleci, zanim technologia konteneryzacji dojrzała, zanim Kubernetes przedstawił się jako najlepsza artykulacja na obecnym etapie.

Ponieważ coraz więcej aplikacji jest umieszczanych w kontenerach, silniki orkiestracji, takie jak Kubernetes, stały się niezwykle popularne. Jako silnik orkiestracji, Kubernetes pomaga zarządzać, skalować i wdrażać konteneryzowane aplikacje. To powiedziawszy, istnieje mnóstwo różnych silników orkiestracji (takich jak Docker Swarm) — dlaczego więc Kubernetes pozostaje tak popularny? Szybka odpowiedź polega na tym, że Kubernetes jest bogaty w funkcje i wyposażony w takie możliwości, jak samonaprawianie i automatyczne skalowanie. Ponadto Kubernetes jest wdrażany jako usługa zarządzana przez większość dostawców usług w chmurze (CSP). To umacnia jego pozycję jako „złotego standardu” dla silników orkiestracji. Adopcja Kubernetes wciąż rośnie, a 96% organizacji używa lub ocenia Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Problemy Mo'Hone Mo'

Biorąc pod uwagę powszechne wykorzystanie Kubernetes, nie jest zaskoczeniem, że jest to również cenna powierzchnia ataku, którą atakujący aktywnie próbują wywęszyć i wykorzystać. Wraz z jego nową dominacją programiści popełniają również błędy w jego implementacji, konfiguracji lub wdrożeniu.

Ten artykuł jest pierwszym z naszej serii dotyczącej bezpieczeństwa Kubernetes. Zawiera przegląd niektórych typowych ataków oraz podstawowe najlepsze praktyki bezpieczeństwa dla Kubernetes. W kolejnych artykułach zagłębimy się w bardziej złożone ataki, takie jak HostPath Mounting, kapsuły/węzły trampoliny itp., oraz ich środki zaradcze.

Aby zrozumieć ataki, musimy najpierw zrozumieć architekturę Kubernetes. Poniższy schemat wysokiego poziomu jest dobrym punktem wyjścia. Jeśli znasz już architekturę Kubernetes i jej podstawy, możesz przejść do sekcji „Metodologia ataku”.

Diagram architektury Kubernetes

Strąki

Kubernetes składa się z wielu ruchomych części, a jego najniższa jednostka robocza to POD . Pod może obsługiwać wiele różnych kontenerów i woluminów pamięci masowej. Każda kapsuła ma również swój unikalny adres IP. Jest również bardzo skalowalny, ponieważ opiera się na planach wdrożenia (plik yaml).

węzły

Aby wszystko było proste dla wszystkich, po prostu podzielimy typy węzłów na:

● Węzły robocze

● Węzeł główny

Zestaw węzłów tworzy klaster.

Węzły robocze:

Pody znajdują się w tych węzłach roboczych, które mogą być maszynami wirtualnymi lub fizycznymi. Możesz myśleć o nich jako o maszynach hosta dla strąków.

Węzeł główny:

Węzeł główny jest ostatecznym administratorem całego klastra. Kontroluje i zarządza wszystkimi węzłami roboczymi, które obejmują następujące komponenty: serwer Kube-API, Kube-Controller-Manager, Kube Scheduler itp.

Przestrzeń nazw

Przestrzeń nazw Kubernetes to mechanizm izolacji, który izoluje zasoby w klastrze, zwykle używany, gdy różne zespoły pracują nad tym samym klastrem. W kontekście cyberbezpieczeństwa każdy obiekt/zasób przestrzeni nazw jest unikalny dla przestrzeni nazw. Wywołanie obiektu/zasobu między przestrzeniami nazw jest niemożliwe, ponieważ te obiekty/zasoby są izolowane w swoich przestrzeniach nazw.

Teraz, mając całą tę nową wiedzę, powinieneś mieć podstawową wiedzę na temat środowiska Kubernetes. Przejdźmy do bardziej soczystej strony rzeczy, jak można zaatakować Kubernetesa?

Metodologia ataku

Wyrafinowaną metodologię atakującego można podzielić na trzy etapy.

Etap 1: Początkowy punkt oparcia

Podstawowym sposobem na zdobycie początkowej pozycji jest złamanie zabezpieczeń aplikacji internetowej lub mikrousługi hostowanej w klastrze. Celem atakującego jest uzyskanie zdalnego wykonania kodu w aplikacji poprzez wyliczenie aplikacji i zidentyfikowanie możliwych do wykorzystania luk (np. log4shell, apache struts).

Etap 2: Eskalacja uprawnień

Po zdobyciu przyczółka w klastrze Kubernetes osoba atakująca znajdowałaby się w kapsule, która, jak wyjaśniono, jest po prostu kontenerem dokującym. Atakujący może przeszukać kontener w poszukiwaniu poufnych danych, ale jest ograniczony do tego, co jest dostępne. . W związku z tym osoba atakująca będzie dążyć do eskalacji do poda z większymi uprawnieniami lub do węzła.

Oto kilka typowych technik, które może zastosować osoba atakująca:

• Wrażliwe pliki

Naprawa:

Oprócz standardowej praktyki polegającej na niezaszyfrowaniu poufnych poświadczeń w zasobniku, administrator Kubernetes powinien przestrzegać zasad najmniejszych uprawnień podczas nadawania uprawnień do tokena konta usługi.

• Osiągalne aplikacje

Naprawa:

Aby zarządzać, które pody, przestrzenie nazw, a nawet serwery zewnętrzne mogą uzyskać dostęp do określonego zasobu Kubernetes, administrator Kubernetes może użyć zasobu zasad sieciowych Kubernetes .

• Usługi metadanych w chmurze

Naprawa:

Administrator Kubernetes może wykorzystać wspomniany zasób polityki sieciowej Kubernetes, aby uniemożliwić atakującemu dostęp do interfejsu API metadanych w chmurze i innych aplikacji hostowanych w klastrze, które nie są wymagane do podstawowych funkcji biznesowych.

• Wybicie strąka

Naprawa:

Administrator Kubernetes może korzystać z zasobu kontrolera dostępu, zasobu Kubernetes, który weryfikuje każdy zasób tworzony w klastrze Kubernetes według zdefiniowanego zestawu reguł. Zasób, który nie jest zgodny ze zdefiniowanym zestawem reguł, nie zostałby utworzony, co spowodowałoby błąd.

Etap 3: Zdobycie klejnotów koronnych

W ekosystemie Kubernetes klejnoty koronne odnoszą się do węzła głównego. Osoba atakująca, która uzyskała pełny dostęp do węzła głównego, zasadniczo miałaby pełną kontrolę nad klastrem Kubernetes. Atakujący powtórzyłby techniki wyszczególnione w etapach 1 i 2, aby przejść poprzecznie z zainfekowanego poda do węzła bazowego, a następnie ostatecznie do węzła głównego. Aby zapobiec wystąpieniu tego najgorszego scenariusza, administrator Kubernetes musi upewnić się, że klaster jest bezpiecznie skonfigurowany z niektórymi z wyżej wymienionych środków zaradczych.

Czy to wszystko?

Aby uzyskać pełniejszy wgląd w stan zabezpieczeń Kubernetes w Twojej organizacji, zalecamy skorzystanie z macierzy ataków Kubernetes firmy Microsoft. Matryca obejmuje główne taktyki, które są istotne dla bezpieczeństwa Kubernetes. Każdy z nich zawiera kilka technik, które atakujący mogą wykorzystać do osiągnięcia różnych celów.

Wniosek

Ponieważ coraz więcej organizacji przyjmuje Kubernetes jako de facto narzędzie do zarządzania orkiestracją kontenerów, coraz więcej wrażliwych danych trafia do klastrów Kubernetes. Istnieje jeszcze większe zapotrzebowanie na administratorów systemów, którzy chcą skonfigurować swój klaster, aby zapewnić jego bezpieczną konfigurację. Atakujący z pełnym dostępem do głównego węzła klastra Kubernetes to ostatnia rzecz, jaką chciałby widzieć CISO.

Uważaj na nasze nadchodzące artykuły, w których będziemy dzielić się bardziej szczegółowymi i konkretnymi atakami, z którymi często spotykamy się dzisiaj w terenie.

Uważaj i złap się na FLIPPETY-FLIP.