Zbadanie (brakującego) bezpieczeństwa typowych instalacji Docker i Kubernetes

Pracuję w IT od ponad 20 lat, ale jakoś nigdy nie zajmowałem się kontenerami. W teorii rozumiałem, jak są zbudowane i jak działają. Ale ponieważ nigdy nie miałem z nimi do czynienia w praktyce — nie byłem pewien, jak dokładnie działają ich mechanizmy pod maską.

Ponadto nie miałem pojęcia, jak wygląda kwestia bezpieczeństwa. Ale znów, teoria brzmi pięknie, a stara piosenka „wraz ze wzrostem bezpieczeństwa spada wygoda użytkowania” wciąż siedziała mi w głowie. Pomyślałem więc, że skoro wszystko jest takie łatwe do zrobienia z kontenerami, to bezpieczeństwo tam jest na bardzo niskim poziomie. Okazało się, że miałem rację.

Aby szybko zacząć, zapisałem się na kursy Black Hat w 2020 roku pod tytułem „Z błota w księstwa: penetracja i zabezpieczenie środowisk Docker Swarm i Kubernetes».

Kurs, który prowadzili Sheila A. Berta i Sol Ozzan, od razu rozpoczął się od opisu, jak działają kontenery Docker oraz jak przebiega ich proces wdrażania w Kubernetes. Było to całkowicie praktyczne zajęcia — studenci musieli przed zajęciami zainstalować Docker i microk8s na swoich maszynach — świetny sposób, aby zobaczyć interakcję narzędzi ze sobą, znaleźć słabe punkty i, co najważniejsze, spróbować je zablokować.

Niestety, chociaż kursy obiecywały, że stanę się „księciem” w ciągu dwóch dni, czułem, że to dopiero początek, i jeszcze wiele muszę się nauczyć.

Zanim zanurkuję w moje głębokie obserwacje, ważne jest, aby wyjaśnić, czym jest kontener. W świecie programowania sytuacja, w której kod napisany na twojej osobistej maszynie działa idealnie, ale przy próbie uruchomienia go na serwerze — po prostu nie działa, jest uznawana za normę. Kontenery próbują przezwyciężyć ten problem, zapewniając autonomiczne maszyny, które można łatwo przenosić z jednego serwera na inny, wiedząc, że zawsze będą działać. Jak wskazuje nazwa, zawierają one kod, biblioteki i inne oprogramowanie potrzebne do działania. Kubernetes, z drugiej strony, jest platformą orkiestracyjną dla kontenerów. W zasadzie z jego pomocą można bezproblemowo zarządzać setkami lub tysiącami różnych kontenerów.

Poniżej przedstawiam kilka moich wniosków z perspektywy czerwonej i niebieskiej drużyny.

Czerwona drużyna

Większość zawartości kontenerów działa z uprawnieniami roota: oznacza to, że jeśli kontener zostanie skompromitowany, uzyskasz pełny dostęp do kontenera. Ułatwia to następne kroki.

Montaż docker.sock wewnątrz kontenera jest niebezpieczny: jeśli uzyskałeś dostęp do roota w kontenerze, a także zainstalowałeś Docker wewnątrz kontenera z soketem Docker (⁄var⁄run⁄docker.sock), masz potencjalną możliwość eksploracji całego klastra, w tym dostęp do dowolnego innego kontenera. Taki dostęp jest niemożliwy do zapobieżenia ani przez izolację sieciową, ani w żaden inny sposób.

Zmienne środowiskowe często zawierają poufne dane: w większości przypadków ludzie przesyłają hasła do kontenera przy użyciu standardowych zmiennych środowiskowych. Więc jeśli masz dostęp do konta, możesz podejrzeć te zmienne środowiskowe, aby później rozszerzyć swoje uprawnienia.

Docker API może ujawnić wiele informacji: Docker API, przy ustawieniach domyślnych, działa bez autoryzacji i może ujawnić wiele informacji. Używając Shodan, można łatwo znaleźć listę otwartych portów, a następnie uzyskać szczegółowe informacje o klastrze – i przejść do jego pełnego przejęcia. TrendMicro napisał na ten temat interesujący artykuł.

Zespół niebieski

Nie uruchamiaj zawartości kontenerów pod roota: mimo że uruchamianie pod rootem jest prostsze, nie powinieneś tego robić. Zamiast tego uruchamiaj aplikacje z zredukowanymi uprawnieniami, ustalając uid albo za pomocą parametru —user podczas pracy z CLI, albo określając USER w Dockerfile.

Nie zezwalaj na instalację programów w kontenerach: prawie każdy atak zaczyna się od instalacji czegokolwiek. Od nmap po ifconfig i samego Dockera (wewnątrz kontenera), instalacja czegokolwiek w kontenerze była powszechną praktyką. Z tego powodu zawsze należy blokować wszystkie nieużywane porty. Pomaga to również zapobiec przesyłaniu komend kontrolnych w przypadku infekcji twojej maszyny. Oprócz zapobiegania instalacji aplikacji, warto upewnić się, że w samym kontenerze zainstalowana jest minimalna liczba aplikacji niezbędnych do wykonania zadania.

Chroń docker.sock: należy go chronić, ponieważ przez ten soket odbywa się komunikacja między kontenerem a klastrami. Ponieważ nie chcę wgłębiać się w szczegóły w tym artykule, przeczytaj notatkę od Docker, co może się zdarzyć i jak to wszystko zablokować.

Użyj sekretów Dockera zamiast zmiennych środowiskowych: Sekrety są od około 2017 roku. Choć nie jest to bezpieczne, jest to wciąż lepsze niż zmienne środowiskowe do przesyłania tajnych danych do kontenera.

Jeśli artykuł wzbudził twoje zainteresowanie kontenerami — można łatwo zainstalować Dockera lub microk8s (mała wersja Kubernetes). Tutaj są instrukcje dotyczące instalacji Dockera dla systemów Linux i MacOS, a tutaj — instrukcje dotyczące instalacji microk8s dla Windows, Linux i MacOS.

Po instalacji możesz przejść do tego przewodnika po szybkim starcie od Dockera, podobna wersja jest oferowana i dla microk8s.

Jeśli masz ochotę lub potrzebę przejść kompleksowy kurs dotyczący Dockera, w którym praktycy omawiają wszystkie jego narzędzia: od podstawowych abstrakcji po parametry sieci, niuanse pracy z różnymi systemami operacyjnymi i językami programowania, spróbuj "Kurs wideo po Dockerze". Poznasz technologię i zrozumiesz, gdzie i jak najlepiej wykorzystać Dockera. Od razu otrzymasz również przypadki najlepszych praktyk — lepiej uczyć się w bezpieczny sposób i z pomocą praktyków na historiach o błędach, niż na własnych błędach z kolczastymi uchwytami.

Źródło: habr.com