Debugowanie kontenerów w kubernetesie – część 2

maciej — Tue, 12 Mar 2024 10:02:11 +0000

Po poprzedniej części zapraszam na kolejną, pokazującą jak poradzić sobie z ograniczeniami które wprowadza Kubernetes podczas debugowania aplikacji sieciowych.

Wykonanie pojedynczego polecenia/shelll

kubectl -n my_namespace exec -it pod -- /bin/some_command

Gdzie zwykle /bin/some_command można zastąpić /bin/bash

Kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest /bin/bash

Powyższe spowoduje uruchomienie nowego kontenera w tym samym podzie. Dzięki temu możemy połączyć się do localhost (127.0.0.1) i sprawdzić jak działają nasze serwisy za pomocą curl/wget. W trybie debug mamy też dostęp do roota, dzięki czemu hardening właściwej aplikacji nie jest aż tak straszny i nie ogranicza nas, np. w zainstalowaniu nowych paczek. Taki kontener nie współdzieli też systemu plików z oryginalnymi kontenerami z poda, dzięki temu nie namieszamy zbyt dużo.

Lepszy kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest --share-processes -c container_name --copy-to=mg-debug

Jest to trochę bardziej rozbudowana wersja poprzedniego polecenia. Odpalając taki kontener do debugowania możemy wybrać jeden z istniejących kontenerów i kubectl skopiuje jego konfiguracje (zamontowane volumes, sieć i przestrzeń procesów). Zabawa w takim środowisku daje już dość duże możliwości interakcji z innymi kontenerami. Można wysłać przyjacieski sygnał -KILL do procesów, pogrzebać w podmontowanych wolumenach lub sprawdzić sieć, również bez ograniczeń hardeningu.

Shell noda

Link dla zdesperowanych: https://github.com/kvaps/kubectl-node-shell. Skrypt potrafi uruchomić shell na nodzie kubernetesa. Dzięki niemu możemy dostać się jako root na dowolnego noda z klastra jako root i wprost pogrzebać w systemie. Chyba najbardziej “wszechmocna” opcja do zabawy w szukanie dziury w całym.

Miłego debugowania!

Czego w dockerze nie zrobisz?

maciej — Tue, 02 Jan 2018 17:20:07 +0000

Lista jest pewnie dużo dłuższa, ale poniższe dały mi się we znaki:

Nie uruchomisz openvpn’a

Kontenery domyślnie nie pozwalają na ingerencje w sieci systemu operacyjnego. Przez to nie da się w łatwy sposób uruchomić np. OpenVPN, który potrzebuje stworzyć własny interfejs sieciowy tun/tap. Czasami uruchamiając kontenery w różnych miejscach świata i w różnych serwerowniach postawienie VPN’a spinającego je wszystkie ze sobą jest dość wygodnym rozwiązaniem, dodatkowo dającym bezpieczeństwo.

Aby podłączyć taką sieć do kontenera trzeba się albo pogimnastykować z routingiem w systemie gospodarza albo poczarować z uprawnieniami kontenera. Aby to zrobić trzeba uruchomić nowy obraz z parametrem --cap-add=NET_ADMIN, który zwiększa możliwości ingerencji w macierzysty system, a w szczególności w konfigurację jego sieci.

Nie poda piwa

z drugiej strony zwykły desktop też piwa nie poda. Ale chociaż potrzyma na tacce cd, a docker nie. Idźmy dalej.

Debugowanie programów

Kolejną rzeczą jest debugowanie kodu. Debugger (np. gdb) wymaga dość głębokiego integrowania się z inną aplikacją, które jest zwykle wykonywane przez funkcję ptrace. Funkcja ta pozwala pisać i czytać po pamięci innych programów, które chcemy badać. Dzięki ptrace debuger może zatrzymać wykonywanie programu w wybranym przez siebie miejscu, wykonywać go krok po kroku lub przechwytywać (i zmieniać) przerwania systemowe. Z systemowej funkcji ptrace korzysta też programik strace, pokazujący co program aktualnie robi, przechwytując jego przerwania oraz User Mode Linux, który podmienia przerwania systemowe na własne.

Aby umożliwić korzystanie z ptrace w kontenerze, musimy dodać mu flagę --cap-add SYS_PTRACE, która przez linux capabilities pozwoli na dostęp do tej funkcji.

Nici z network namespaces

Czasami potrzeba wykonać coś więcej, niż sam VPN i poczarować np. z przestrzeniami nazw aby uruchomić niektóre narzędzia (np. podczas pisania i testów CoreCluster). Podobnie jak przy konfiguracji VPN, tutaj też Docker ograniczy nam taką możliwość. Można to obejść podobnie, przez capabilities.

Czyli jak się da obejść to jednak nie ogranicza?

W sumie tak. Ale należy pamiętać, że dodając kontenerowi każdą taką flagę ryzykujemy, że kod uruchomiony w kontenerze będzie mógł w jakiś sposób przejść do systemu gospodarza. Idąc tą drogą możemy pozdejmować wszystkie ograniczenia Dockera (lub innego silnika kontenerów) i cieszyć się nieskrępowaną pracą w łatwo zarządzalnym chroot. W ten sposób dostajemy wtedy sam chroot, z którego prawdopodobnie będziemy mogli łatwo wyjść, podobnie jak potencjalny intruz, który mógłby być nieco lepiej powstrzymany przez ograniczonego dockera (w domyślnej konfiguracji). Z drugiej strony wszyscy więksi dostawcy usług, oferujący silnik kontenerów nigdy nie dają dockera bezpośrednio na swoim sprzęcie, a za pośrednictwem wirtualnych maszyn, które nie są współdzielone pomiędzy użytkownikami.

Podsumowując, Docker mimo swoich fajnych narzędzi pozostawia trochę ograniczeń na to, co możemy wykonać w kontenerze. Tyczy się to prawdopodobnie również innych silników. W takich przypadkach (których zapewne znajdzie się znacznie więcej) możemy posiłkować się starą, dobrą wirtualizacją, która daje w pełni funkcjonalny system. Wykorzystując obrazy Copy On Write i Kernel Same Page Mapping możemy znacznie ograniczyć użycie pamięci i przestrzeni dyskowej potrzebnej na wirtualne maszyny, zachowując pełną funkcjonalność.

Maciej[cc] » docker