Maciej[cc] » Linux

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!

Co zrobić gdy nie mamy w kontenerze roota i trzeba debugować sieć

maciej — Wed, 27 Dec 2023 08:24:13 +0000

Często debugowanie kontenerów w kubernetesie wymaga przeanalizowania ruchu, jaki wchodzi lub wychodzi do systemu. Nie ma z tym problemu jeśli mamy dostęp do konta administratora u możemy uruchomić netstat lub tcpdump aby popatrzeć w pakiety. Co jeśli nie ma do tego dostępu?

Znajdź proces

Na początek zacznijmy od znalezienia procesu, który obsługuje ruch na porcie 80:

$ ps
bash: ps: command not found

Będzie trudniej… przejdźmy to katalogu /proc. Część z podkatalogów odpowiada procesom. Zwykle w kontenerach oraz w Linuksie proces z PID o numerze 1 odpowiada pierwszemu procesowi w systemie/kontenerze (np. /bin/init). Mamy zatem sporo różnych wpisów w proc:

$ ls -l /proc
total 0
dr-xr-xr-x 9 root root 0 Dec 19 11:59 1
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 29
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 30
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 31
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 32
dr-xr-xr-x 9 root root 0 Dec 27 08:05 33
dr-xr-xr-x 9 root root 0 Dec 27 08:06 55
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 56
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 63
drwxrwxrwt 2 root root 40 Dec 19 11:59 acpi
dr-xr-xr-x 13 root root 0 Dec 19 11:59 asound
...

Każdy z nich odpowiada osobnemu procesowi. Po nazwie właściciela można stwierdzić co to za proces, ale aby upewnić się, sprawdźmy wpis exe w takim katalogu:

$ ls -lh /proc/29/exe
lrwxrwxrwx 1 nginx nginx 0 Dec 27 08:10 /proc/29/exe -> /usr/sbin/nginx

exe to link symboliczny do pliku wykonywalnego w systemie plików. Mamy zatem ustalonego podejrzanego oraz jego proces.

Jakie porty są otwarte przez proces

Aby sprawdzić z czego korzysta dany proces zwykle można urzyć lsof lub netstat. W dobrze zabezpieczonych systemach nie mamy takiej możliwości. Zamiast tego możemy podglądnąć listę otwartych prze nginx plików:

$ ls -lh /proc/29/fd/
total 0
lrwx------ 1 nginx nginx 64 Dec 27 08:13 0 -> /dev/null
l-wx------ 1 nginx nginx 64 Dec 27 08:13 1 -> 'pipe:[37844]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 10 -> 'anon_inode:[eventfd]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 11 -> 'anon_inode:[eventfd]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 12 -> 'socket:[40105]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 13 -> 'socket:[40107]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 2 -> 'pipe:[37845]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 3 -> 'socket:[40103]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 4 -> 'pipe:[37845]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 5 -> 'pipe:[37844]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 6 -> 'socket:[40099]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 7 -> 'socket:[40100]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 8 -> 'socket:[40102]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 9 -> 'anon_inode:[eventpoll]'

Pliki z numerami (dokładniej deskryptorami, możliwe, że kojarzysz to z funkcji open w C) 0 i 1 to standardowe wejście i wyjście. Za ich pomocą program komunikuje się z użytkownikiem w konsoli. Tutaj jest wejście jest ustawione na /dev/null a wyjście przekierowane do pipe. To, co nas interesuje, to pliki opisane jako socket:[numer]. Są to połączenia sieciowe. Nazwa symlinka to deskryptor pliku/socketu widziany po stronie aplikacji. Numer widoczny po socket:… to identyfikator obiektu po stronie jądra systemu, tzw. inode.

Jak sprawdzić który inode odpowiada socketowi, nasłuchującemu na porcie 80? Popatrzmy w plik /proc/net/tcp:

$ cat /proc/net/tcp
 sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 
 0: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 40099 1 0000000000000000 100 0 0 10 0

Pokazuje on otwarte połączenia sieciowe. Ostatnia kolumna to inode połączenia (socketu). Jeśli poszukasz jej w /proc/29/fd, to znajdziesz podobny wpis, dla deskryptora pliku nr 6. Teraz wystarczy popatrzeć na local_address i zamienić numer portu 0050 na wartość dziesiętną i wyjdzie port 80, na którym słucha nasza aplikacja.

Wszystko to używając jedynie ls oraz cat z konta zwykłego użytkownika, które zwykle nie są usuwane podczas zabezpieczania kontenerów

Debugowanie kontenerów w chmurze

maciej — Fri, 24 Sep 2021 08:29:21 +0000

Czasami coś nie działa i przyczyna tego za diabła nie chce dać się znaleźć. Poniżej kilka pomocnych rad w debugowaniu w środowisku chmury i kontenerów, czyli “u mnie działa, a na cudzym komputerze nie”

Problem

Moja strona nie działa, a devops skomplikował sprawę. Na wejściu do naszego serwisu stoi ELB, ALB lub inny load balancer, który przekierowuje ruch do kontenera zarządzanego przez ECS lub kubernetes. Żeby było trudniej, nie mamy dostępu do czeluści load balancera i wejście na noda klastra też jest ograniczone. Możemy jedynie dostać się do kontenera.

Porblem pojawia się gdy frontend (UI) wysyła żądanie do backendu. Nie dostajemy poprawnej odpowiedzi, a jedynie błąd 503 Service Unavailable.

Rozwiązanie

Znajdź problem i napraw :)

Rozwiązanie 2

Zanim zaczniesz grzebać, upewnij się, że zepsucie danego kontenera nie pociągnie za sobą negatywnych konsekwencji. W przypadku Kubernetesa, ECS lub innych orchestratorów (jakkolwiek to się tłumaczy) usunięcie zepsutego kontenera powinno spowodować automatyczne utworzenie nowego, takiego samego. Oprócz tego dobrą rzeczą będzie kawałek papieru lub gedit do notowania co robimy, aby łatwo dało się zrobić rollback zmian, które są trwałe lub odtworzyć całą ścieżkę.

Ponadto pomyśl czy żądanie/request, które będziemy naprawiać nie niszczy czegoś po stronie backendu. Jeśli problem sprawia guzik “skasuj konto” to dwukrotne debugowanie tego samego requestu będzie problematyczne…

Sprawdź co nie bangla

Na początek znajdź z użyciem developer tools jakie żądanie sprawia problem. Otwórz developer tools w przeglądarce i popatrz co się dzieje gdy strona wysyła do backendu request. W dalszej części bardzo pomocne będzie skopiowanie polecenia cURL z dokładnymi parametrami żądania, które wysyła przeglądarka. W zakładce z listą połączeń sieciowych z developer tools możesz wybrać skopiowanie requestu m.in. jako polecenie programu cURL.

Ponadto, w ulubionym edytorze tekstu, jakim jest oczywiście pico albo gedit, zapisz powyższe polecenie. Często bedzie ono zawierało całą masę nagłówków, id sesji, ciasteczek i innych rzeczy, które weryfikuje backend w celu uwierzytelnienia człowieka. Jako użyteczny dodatek możesz zamienić w takim poleceniu nagłówek User Agent na własny string. W większości logów user agent pojawia się w każdej linijce logowanego requestu i dzięki temu będzie nam łatwiej przeszukać logi tylko z naszego curla.

Mając powyższe sprawdź czy curl dostaje tak samo niepoprawną odpowiedź od serwera. Możliwe że już na tym etapie otrzymasz komunikat z błędem i dalsze debugowanie stanie się zbędne.

Logi

Chyba podstawowa rzecz, dużo grepa, a jeśli to AWS to dużo scrollowania i szukania w cloudwatch. Jeśli nie ma w logach aplikacji z backendu, to możliwe że jest w logach load balancera. Jeśli nie, to…

Czas na grubszy kaliber

Czasami błąd jest tak uciążliwy, że ani w logach ani w odpowiedzi backendu nie da się znaleźć jego przyczyny. Pozostaje więc kilka cięższych dział:

Wewnątrz kontenera – netstat

Odpal netstat z pakietu net-tools w Ubuntu/Debianie. Polecenie netstat -ntap powinno wypisać wszystkie nawiązane połączenia i otwarte porty. Sprawdź czy wszystko jest tak jak powinno, tj. czy serwer nasłuchuje na odpowiednim porcie, czy widać połączenie z bazą etc.

Jeśli wszystko jest ok, to spróbuj wykonać to samo podczas wykonywania żądania przez cURL. Jeśli takie żądanie wykonuje się za szybko i nie nadążasz klikać, to wrzuć gdzieś sleep 10, tylko nie zapomnij go usunąć :) Ponieważ często po zmodyfikowaniu kodu potrzebny jest restart serwisu, a ubicie głównego procesu spowoduje restart kontenera, spróbuj kill -HUP [proces]. Dawno dawno temu, gdy komputery obsługiwało się bez myszki (i nie przez touch screen) zdarzało się, że coś zerwało połączenie z terminalem, na którym mieliśmy uruchomiony interaktywny proces. Przez SIGHUP można było poinformować taką odłączoną aplikacje, że straciliśmy z nią połączenie i chcemy aby się zakończyła. Serwery zwykle nie reagowały na to, jednak przez lata SIGHUP stał się sygnałem do reloadu konfiguracji i często również skryptów, które są wykonywane przez serwer. Dzięki temu prawdopodobnie nie zrestartujesz kontenera, w którym pracujesz.

Wracając do tematu – mając już wrzuconego gdzieś sleep 10 spróbuj netstat ponownie i zobacz czy nic nie wygląda podejrzanie

cURL do kontenera

Kolejnym punktem do odhaczenia jest wysłanie żądania przez cURL bezpośrenio z kontenera do niego samego. Możemy wykorzystać wcześniejsze polecenie cURL. Możemy też dodać opcje wymuszającą na cURL’u wyświetlenie nagłówków. Jeśli się powiedzie, to problem prawdopodobnie pojawia się gdzieś wcześniej, np. między load balancerem a kontenerem. Jeśli masz taką możliwość, wykonaj to samo z load balancera.

nc do innych usług

Jeśli to zadziała, dobrze jest sprawdzić połączenie z bazą lub innymi wymaganymi serwisami bezpośrednio z kontenera: nc nazwa_hosta port ( apt install netcat). W przypadku bazy można doinstalować jej klienta i spróbować się połączyć, przy okazji wykonując jakiś prosty select na tabelach, do których aplikacja ma mieć dostęp.

Udawanie innych serwisów

Kolejnym trikiem, który może się przydać jest odpalenie czegoś, co udaje bazę lub inny serwis. Pozwoli to poznać nam jakie żądania są wysyłane do sąsiednich usług. Może to być przydatne gdy nie mamy możliwości zainstalowania tcpdump lub jest to zabronione.

Jak to zrobić aby stało się to tylko lokalnie, bez psucia całej infrastruktury? Sprawdź jaki host jest ustawiony jako np. mikroserwis, który chcesz podsłuchać (jeśli używasz po IP, to sorry…). Następnie wpisz w /etc/hosts nowy wpis: 127.0.0.1 [nazwa hosta] i odpal w kontenerze nc -l [port usługi]. W Linuksie pierwszeństwo w ustalaniu adresów przypisanych do hostów ma plik /etc/hosts, dzięki czemu dodając do niego nowy wpis wymusimy aby nasz kontener połączył się z localhost zamiast właściwego hosta. Uruchomiony program nc pozwoli wypisać to, co miało zostać wysłane przez aplikację z naszego kontenera do serwisu. Pamiętaj, aby usunąć później wpis z /etc/hosts :)

Podglądnięcie zmiennych środowiskowych

Często zanim połączymy się z bazą lub podglądniemy ruch sieciowy do danego hosta warto sprawdzić jakie zmienne znają aplikacje, które są już uruchomione w kontenerze. Czasami przez błąd w konfiguracji aplikacja może nie mieć możliwości uzyskania tych zmiennych, bo np. zabrakło uprawnienia IAM do odpytania Secret Parameter Store. Może też to wynikać ze zmienionego API lub biblioteki – zamiast jednego requestu o listę wszystkich parametrów odpytuje o każdy z osobna, do czego IAM już nie uprawnia.

Wykonaj ps aux. Zwykle pierwszy proces będzie znał tylko te parametry, które są przekazywane bezpośrednio przez dockera. Wszelkie inne, uzyskiwane z chmury są znane późniejszym procesom, po pełnej inicjalizacji środowiska. Możesz podglądnąć jeden z wyższych PID’ów (ale nie z naszej sesji!) przez wpis w /proc/[pid]/environ:

sudo cat /proc/123/environ | tr ‘\0’ ‘\n’

Poszczególne zmienne są rozdzielone zerami (znakami o kodzie zero), stąd tr, który zmieni zera na nowe linie. Jeśli wygląda ok, to pijemy kolejną kawę i szukamy dalej

Ponownie netstat, lsof

Sprawdź ulimit i porównaj z ilością połączeń i otwartych plików w kontenerze. W zależności od konfiguracji ten parametr przy dużej ilości połączeń może stwarzać problemy

Podglądanie z czym się łączy aplikacja

Sprawdzisz to przez tcpdump udp port 53. W trakcie działania sniffera możesz wykonać żądanie przez cURL i sprawdzić co się dzieje i z czym się łączy aplikacja. Jeśli używasz IP, to zapytanie tcpdump będzie trochę inne.

strace do czytania logów

Jeśli cloudwatch szczególnie uwiera tu i ówdzie, przez co nie możesz znaleźć logów, warto sprawdzić co aplikacja wypisuje na standardowe wyjście. Nightmare w kontenerze? Nie :) Spróbuj:
strace --attach=[pid serwera] -e write=1,2
Powyższe podłączy “debuger” strace do procesu i będzie wyłapywało jedynie wywołania systemowe funkcji write do plików o fd=1 i 2. Oznaczają one odpowiednio stdout i stderr.

Nie jest to najwygodniejsza metoda oglądania logów, ale pozwala użyć ukochanego grepa i awk’a, co w przypadku cloudwatch nie zawsze jest najwygodniejsze i najszybsze.

Dla przykładowego ls wykonanego przez ssh:

otrzymamy wynik ze strace:

Nie jest to najczytelniejsze, ale odpowiednio okraszając to grep’em i wycinając wszystkie znaki sterowania terminalem (kolory, znaki specjalne etc.) możemy uzyskać dość czytelny wgląd w to, co się dzieje. Powyższa metoda zadziała też na połączeniach sieciowych, w tym na tych, któ©e są już odszyfrowane i idą np. do fcgi po systemowym sockecie.

Na koniec

Jeśli nie udało się nic znaleźć, a aplikacja dalej się sypie, to pozostaje stara dobra metoda… wyłącz i włącz kontener, później instancje, a na koniec pogadaj z frontendowcami i backendowcami którzy muszą wysyłać to problematyczne żądanie. Chociaż pogadać i zrozumieć jest dobrze przed całym powyższym szukaniem dziury w całym ;)

Szyfrowany dysk sieciowy dla potrzeb serwerowych

maciej — Mon, 26 Oct 2020 07:05:44 +0000

Poniżej przedstawiam kilka sposobów na wykorzystanie przestrzeni dyskowej zdalnej maszyny w sposób zabezpieczający w pełni nasze dane. Założenie konfiguracji jest jedno – maszyna udostępniająca swój dysk nie może mieć wglądu w nasze dane, które przechowujemy ani w klucze, którymi dane są szyfrowane. Całość komunikacji ma być w pełni bezpieczna, a jedyny dostęp do danych ma być możliwy jedynie po ich odszyfrowaniu w locie, już na komputerze klienta.

Dzięki temu przejęcie docelowej maszyny nie będzie oznaczało od razu wycieku naszych danych. Ma to być zapewnione począwszy od dostępu do samego jej dysku, aż po grzebanie w RAM’ie, gdzie mogą być przechowywane klucze szyfrujące, gdyby szyfrowanie odbywało się po zdalnej stronie. Kolejnym wymogiem jest aby sposób przechowywania danych był możliwy w środowisku serwerowym, gdzie chcemy zautomatyzować cały proces montowania i dostępu do danych, a więc bez żadnych UI oraz webowych interfejsów.

Duplicity

Najprostszym i zarazem najmniej funkcjonalnym na codzień rozwiązaniem jest zaprzęgnięcie narzędzia do backupów duplicity. Instalujemy go za pomocą:

sudo apt install duplicity

i od razu możemy korzystać. Jest to jeden z wygodniejszych sposobów na tworzenie backupów:

export PASSPHRASE="ala ma kota"
duplicity full /home/shrek rsync://shrek@remote-host//backups/shrek

Plusy:

Wsparcie dla przeróżnych backendów, od ssh, S3 aż po różne egzotyczne chmury
Pozwala tworzyć pełne kopie jak również przyrostowe, co może ograniczyć ilość używanego miejsca

Wady:

Działa jedynie jako backup na żądanie, nie da się wykorzystywać do bieżących operacji, tak jak system plików
Potrafi się wysypać przy dużych ilościach plików

Ecryptfs po NFS

Kolejnym, trochę wygodniejszym do codziennego użytku narzędziem jest połączenie NFS i ecryptfs. Z racji, że jest to połączenie dwóch różnych systemów plików, potrafi sprawiać problemy podczas usypiania komputera lub gdy wystąpią problemy z siecią.

Instalacja i uruchomienie po stronie klienta (zakładam, że gdzieś stoi serwer NFS):

sudo apt install ecryptfs-utils nfs-utils

mkdir /.backup
mkdir /backup

sudo mount -t nfs zdalny_host:/zasob_nfs /.backup
sudo mount -t ecryptfs /.backup /backup
# Tutaj ecryptfs poprosi o podanie nowego hasła, metody szyfrowania i kilku innych detali

Korzystając z takiego połączenia systemów plików nasz lokalny komputer pokaże w katalogu /backup odszyfrowaną zawartość katalogu /.backup. Każdy plik lub katalog w /backup odpowiada w ten sposób zaszyfrowanemu plikowi lub katalogowi w /.backup. Dzięki zastosowaniu NFS wszelkie dane, które zapisujemy w /backup są w formie zaszyfrowanej przesyłane przez sieć do hosta, który udostępnia swój katalog przez NFS.

Plusy:

Działa na żywo, jak zwykły system plików
Szyfrowanie jest wykonywane w całości po stronie klienta
Nie angażuje sterownika plików, dzięki czemu trudniej o uszkodzenie plików na poziomie systemu plików
Łatwe wykonywanie bezpiecznego backupu zaszyfrowanych danych – wystarczy rsync

Wady:

Czasami potrafi mocno zwolnić, zwłaszcza gdy mamy duży ping lub powolne łącze
Zawieszenie się lub zerwanie połączenia NFS skutecznie blokuje szyfrowany system plików, przez co procesy utykają na dostępie do plików w przypadku problemów sieciowych

NBD i LUKS

Ostatnim rozwiązaniem jest wykorzystanie serwera Network Block Device, który udostępni przez sieć całe urządzenie blokowe oraz systemu LUKS, który potrafi szyfrować całe urządzenia blokowe, ponad systemem plików. Dla zestawienia powyższych narzędzi nasz serwer będzie jedynie udostępniać pojedynczą partycję przez NBD, a my jako klient wykorzystamy mapowanie i odszyfrowanie jej przez driver LUKS, a następnie zamontujemy tak odszyfrowane urządzenie jako partycję ext4.

Instalacja po stronie klienta:

sudo apt install cryptsetup nbd-client

Instalacja po stronie serwera:

sudo apt install nbd-server

Następnie trzeba dodać plik eksportujący urządzenie (np. partycja /dev/sda4) do pliku /etc/nbd-server/conf.d/backup:

[backup]
 exportname = /dev/sda4

Pierwsze montowanie i formatowanie partycji po stronie klienta:

sudo nbd-client -N backup 10.11.22.33 /dev/nbd0

# Sformatowanie dysku do luks i odszyfrowanie go. Po obu poleceniach cryptsetup zapyta o hasło
sudo cryptsetup luksFormat /dev/nbd0
sudo cryptsetup luksOpen /dev/nbd0 backup

# cryptsetup stworzy plik backup, który reprezentuje odszyfrowane urządzenie /dev/nbd0:
sudo mkfs.ext4 /dev/mapper/backup

# Na koniec stwórzmy katalog, gdzie będziemy montować naszą partycję
mkdir /backup

sudo cryptsetup luksClose backup

Montowanie i odszyfrowanie za każdym kolejnym razem:

sudo nbd-client -N backup 10.11.22.33 /dev/nbd0
sudo cryptsetup luksOpen /dev/nbd0 backup
sudo mount /dev/mapper/backup /backup

i gotowe!

Zalety:

W mojej opini najszybsze i najbardziej odporne na problemy sieciowe rozwiązanie
Pozwala w pełni wykorzystać dowolny system plików
W razie problemów dane można również odszyfrować na hoście lub dowolnym innym komputerze

Wady:

Duże ryzyko uszkodzenia systemu plików w razie problemu z siecią
Utrudniony backup całego dysku

Podsumowanie

Kombinacji i różnych narzędzi umożliwiających podobne zabezpieczenie jest cała masa, zwłaszcza, jeśli nie ograniczymy się do tych typowo konsolowych. Powyższe jednak pozwolą w miarę dobrze zabezpieczyć się na wypadek przejęcia maszyny hostującej nasze dane i to w sposób dość “paranoiczny”. Zarówno dane jak i klucze deszyfrujące nie są znane po stronie serwera. Może to być zetem sposób na ochronę nawet w najbardziej ekstremalnych przypadkach – zapobiega wyciągnięciu kluczy np. z pamięci wirtualnej maszyny po uśpieniu jej. Natomiast z racji tego, że nasz klient nie posiada samych zaszyfrowanych danych bezpośrednio u siebie, to w przypadku przejęcia fizycznej maszyny, która te dane przetwarza pozostają one dalej bezpieczne, w formie zaszyfrowanej.

Do przechowywania dużych ilości danych można w tym przypadku wykorzystać na przykład tanie serwery z oferty kimsufi (nie, nie płacą mi za to :), z dyskami do 2TB w parze z raspberry pi hostowanym u siebie pod biurkiem lub wirtualną maszyną w innej chmurze.

Kubernetes – jak działa cluster IP

maciej — Sun, 29 Dec 2019 13:27:08 +0000

Niedawno pisałem o implementacji sieci opartej o Flannel. Zabrakło tam jednak jednej istotnej rzeczy – clusterIP. W tym poście przeczytasz jak dokładnie jest to zaimplementowane.

Jeśli patrzyłeś na organizację interfejsów, adresów itd., to pewnie rzuciło Ci się w oczy, że nigdzie nie było routingu ani żadnego innego śladu po adresach IP przydzielonych do serwisów. Jeśli korzystasz z domyślnej konfiguracji, jaką Kubernetes daje, to jest to pula 10.96.0.0/16. Z niej można wybrać dowolny adres IP który będzie dostępny w całym klastrze Kubernetesa i routowany do konkretnego serwisu:

apiVersion: v1
kind: Service
metadata:
 name: dinemic-io
 labels:
 app: dinemic-io
spec:
 ports:
 - port: 80
 selector:
 app: mnabozny-pl
 clusterIP: 10.96.0.123

Serwis za pomocą definicji z pola selector wyszukuje odpowiednie aplikacje, do których będzie przekierowany ruch na port 80. Będąc w dowolnym miejscu klastra (node lub K8s master) zawsze będziemy mogli połączyć się z tym adresem, na port 80. Patrząc natomaist w tablicę routingu, nie znajdziemy ani jednego wpisu wskazującego na taką pulę adresów:

maciek> ip route show
default via 192.168.1.1 dev eth0 onlink 
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
...

Pula adresów 10.0.0.0/24 to fizyczna sieć klastra, w którym działa Kubernetes. 10.244.X.0/24 to pula adresów, które Kubernetes przydziela poszczególnym podom na nodach (gdzie X odpowiada nodowi, a konkretny numerek podowi).

Traceroute do adresu powyższego serwisu wychodzi zawsze poza moją sieć, zgodnie z tym, co mówi tablica routingu. Wget na http://10.96.0.123:80 zawsze magicznie dociera do celu. Gdzie więc czai się ta magia?

Iptables dla clusterIP

Popatrzmy w ipsables. Za pomocą sudo iptables-save można wylistować wszystkie regułki, które są aktualnie załadowane do jądra. Jest tego dość sporo, dla tego można wspomóc się grepem:

maciek> sudo iptables-save | grep 10.96.0.123
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-SVC-AA7UXNSLITSSEFAY

Do łańcucha KUBE-SERVICES jest przekierowywany cały ruch z łańcucha INPUT. Pierwsza z powyższych reułek oznacza pakiety, które mają być oznaczone do MASQUERADE. Druga natomiast przekazuje je do konkretnego łańcucha – KUBE-SVC-AA7UXNSLITSSEFAY. Obie reguły działają dla docelowego adresu 10.96.0.123, na docelowym porcie 80.

Łańcuch dla konkretnego serwisu

W powyższym outpucie z iptables-save można zobaczyć, że druga regułka przekierowuje druch do konkretnego łańcucha, odpowiadającego serwisowi – KUBE-SVC-AA7UXNSLITSSEFAY. Przyjżyjmy się mu bliżej:

maciek> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0

Powyższy serwis przekierowuje cały ruch (100%) do łańcucha odpowiadającemu konkretnemu podowi, na port 80, robiąc przy okazji DNAT:

maciek> sudo iptables -nL KUBE-SEP-Q3TQA7ZS25JCTF3F -t nat
Chain KUBE-SEP-Q3TQA7ZS25JCTF3F (1 references)
target prot opt source destination 
KUBE-MARK-MASQ all -- 10.244.3.115 0.0.0.0/0 
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.3.115:80

Czyli, podsumowując, dowolny pakiet wchodzący do noda (INPUT) lub wychodzący z niego (OUTPUT) jest procesowany przez łańcuch KUBE-SERVICES. W nim natomiast K8S dodaje pojedyncze regułki, które wyłapują ruch kierowany do poszczególnych clusterIP przydzielonych do serwisów. Każdy serwis i clusterIP posiada swój osobny łańcuch KUBE-SVC-…, w którym jest rozdzielany ruch do poszczególnych podów i ich łańcuchów, w których jest realizowany DNAT.

Serwis dla wielu podów

Powyższy przykład pokazywał wpisy dla serwisu, który przekazuje ruch do jednego poda. Co jeśli przeskalujemy go do dwóch instancji? Szybkie kubectl apply -k . i po chwili mamy kilka zmian! Chwila oznacza dokładnie tyle, ile trzeba aby nowy pod się uruchomił i zaczął działać. Popatrzmy jeszcze raz w całe iptables. KUBE-SYSTEM pozostaje bez zmian, dalej kieruje ruch dla clusterIP 10.96.0.123 do naszego serwisu, w łańcuchu KUBE-SVC-AA7UXNSLITSSEFAY.

Natomiast sam łańcuch KUBE-SVC-AA7UXNSLITSSEFAY ma już nowe wpisy:

> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000
KUBE-SEP-OCALVIKCSC2PZKNJ all -- 0.0.0.0/0 0.0.0.0/0

Dodana została na początku nowa regułka kierująca 50% ruchu (popatrz na komentarz – statistic mode, z probability 0.5) do nowego poda, którego ruch jest kształtowany przez łancuch KUBE-SEP-Q3TQA7ZS25JCTF3F. Pozostałe 50% ruchu wpada w ostatnią regułkę, która jest tam od początku. Jeśli przeskalujemy nasz deployment do większej ilości podów, to udział procentowy odpowiednio spadnie do 100/N.

Skalowalność samego cluster IP

Można mieć wrażenie, że każdy pod w klastrze K8S jest w pewnym stopniu single point of failure i jest to prawdą. Natomiast dołożenie nad podami i naszymi aplikacjami abstrakcyjnej warstwy serwisów, które są czymś w rodzaju load balancera, pozwala bardzo łatwo ograniczyć ten słaby punkt. Jeśli nasze pody z aplikacją będą odpowiednio rozproszone po klastrze, w dużej ilości instancji, to awaria dowolnego poda nie wpłynie na dostępność naszego serwisu.

A co z samym clusterIP? Zauważ, że to konkretne IP, na które tu patrzyliśmy nie jest nigdzie “fizycznie” widoczne. Każdy host w klastrze K8S posiada swój własny zestaw regułek, zwykle spójny z innymi, przynajmniej pod kątem clusterIP. Próbując dostać się do konkretnego serwisu, właśnie przez clusterIP tak na prawdę iptables losuje nam IP poda, na który będziemy przekierowani i DNAT’owani.

Również dzięki temu można przekierować/przeroutować ruch np. z VPN lub zewnętrznej sieci do dowolnego noda, który stanie się wtedy gateway’em. Taki node po otrzymaniu pakietu do jednego z clusterIP przekieruje takie zapytanie dalej, do odpowiedniego poda.

Troubleshooting

A wszystko to, bo ostatnio pomieszałem labelki w selektorze aplikacji www i mysql’a :) około połowa połączeń była odrzucana, przez co strona częściej nie działała niż działała. Jeśli doświadczasz losowego connection refused, to prawdopodobnie właśnie przy load balancingu/losowaniu poda K8S przekierowuje Twoje zapytanie do innego poda, który w danej chwili ma uruchomioną inną usługę. Po sprawdzeniu, zmianie labelek i przeładowaniu całego serwisu wszystko zaczyna działać.

Kubernetes – co w sieci piszczy

maciej — Sun, 24 Nov 2019 10:44:57 +0000

Zróbmy wycieczkę pakietem od poda, aż po default gateway całego klastra Kubernetesa. Post ma na celu ułatwienie debugowania ewentualych problemów sieciowych Kubernetesa z Flannelem.

Skoro to czytasz, to zakładam, że masz jako takie pojęcie czym się je Kubernetesa, czym są pody i interfejsy sieciowe. Dobrze, gdybyś też wiedział conieco o kontenerach Dockera. Na tapetę weźmiemy (nie)działającą instalację, która składa się z kilku kontenerów i sieci obsługiwanej przez Flannel. Zaczynajmy!

Wejdźmy do poda

A zanim wejdziemy, zobaczmy jakie mamy pody:

master# kubectl get pods -n cloudover
NAME READY STATUS RESTARTS AGE
cloudover-io-8xxxyyy886-6c86k 1/1 Running 2 10d
cloudover-io-8xxxyyy886-jx479 1/1 Running 2 10d
cloudover-org-xxxyyyc48-4j4j4 1/1 Running 2 10d
cloudover-org-xxxyyyc48-jv59p 1/1 Running 2 10d
dinemic-io-599xxxyyy8-86d49 1/1 Running 2 20d
dinemic-io-599xxxyyy8-t4pq6 1/1 Running 2 20d
dinemic-io-backup-15xxxyyy20-4t2xr 0/1 Completed 0 2d17h
dinemic-io-backup-15xxxyyy20-2x7pp 0/1 Completed 0 41h
dinemic-io-backup-15xxxyyy20-7k8zs 0/1 Completed 0 17h
dinemic-io-mysql-79yyyxxx6d-wfdrh 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-p9jp2 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-plzfq 1/1 Running 2 20d
mnabozny-pl-backup-157xxxyyy0-q76s7 0/1 Completed 0 125m
mnabozny-pl-backup-157xxxyyy0-vrzgt 0/1 Completed 0 65m
mnabozny-pl-backup-157xxxyyy0-nt5mm 0/1 Completed 0 5m20s
mnabozny-pl-mysql-86xxxyyy55-q7nhn 1/1 Running 2 20d
pkg-cloudover-org-84xxxyyy78-dxzxr 1/1 Running 2 10d
pkg-cloudover-org-84xxxyyy78-tqb7w 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-2729k 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-4vjsq 1/1 Running 2 10d

Mamy więc kilka podów z różnych moich serwisów oraz zakończone cron joby backupu danych (Completed). Weźmy na warsztat poda pkg-dinemic-io-xxxyyyfc77-2729k, który sprawia problemy i zobaczmy jak wygląda jego sieć. Żeby było czym popatrzeć, musimy doinstalować potrzebne narzędzia (polecenie ip). Domyślnie, obraz dockera, z którego odpalony jest ten serwis, jest dość mocno okrojony:

master# kubectl exec -n cloudover -it pkg-dinemic-io-... bash
apt update
apt install -yqq iproute2 traceroute

Kolejną rzeczą jest sprawdzenie na którym nodzie uruchomiony jest pod, który chcemy zbadać i doinstalowanie tcpdumpa.

Mając (prawie) wszystko co potrzeba, możemy zobaczyć jak połączone są interfejsy poda i noda. Linux (docker i cała masa innych narzędzi) wykorzystuje mechanizm veth oraz sieciowe namespace (przestrzenie nazw), netns do oddzielania od siebie ruchu sieciowego kontenerów, wirtualnych maszyn itd. Namespace to grupa procesów (dotyczy to też dowolnego innego zasobu), która współdzieli te same interfejsy, tablice routingu, firewall i trochę innych rzeczy. Działa to prawie tak, jak osobny host w sieci lub wirtualna maszyna, z tą różnicą, że mamy doczynienia z jednym systemem operacyjnym. Jądro Linuksa odseparowuje te zasoby, aby można było używać np. nachodzących na siebie adresacji lub regułek iptables bez żadnych dodatkowych komplikacji.

Druga z przydatnych rzeczy, o której wspomniałem to interfejs typu veth. Najprościej jest porównać je do wirtualnego kabelka ethernetowego, który spina dwa interfejsy. Jeśli pakiet pojawi się na jego jednym końcu, to jest widoczny również na drugim (peer interface). Sparowane interfejsy veth można przekładać pomiędzy różnymi namespaces i przy nieco bardziej zaawansowanej konfiguracji, kształtować ruch sieciowy pomiędzy nimi. Korzysta z tego m.in. openstackowy neuron, flannel, corecluster i prawdopodobnie sporo innych narzędzi.

# dodaj nowa namespace
ip netns add test-ns

# dodaj pare interfejsow veth - veth1 i veth1p, ktore sa wzajemnie sparowane
ip link add veth1 type veth peer name veth1p

# ustaw namespace interfejsu peer na nasza nowa namespace
ip link set veth1p netns test-ns

Powyższy przykład tworzy nazwaną namespace, którą możemy zobaczyć przez ip netns show i usunąć przez ip netns del test-ns.

My za pomocą polecenia ip chcemy zobaczyć jak poukładane są interfejsy sieciowe na nodzie, gdzie jest uruchomiony pod. Sprawdźmy najpierw w samym podzie jakie mamy interfejsy:

pod# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
 link/ether a2:62:74:d8:6e:1c brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet 10.244.1.80/24 scope global eth0
 valid_lft forever preferred_lft forever

Jak zawsze lo, które jest po prostu lo. Eth0 za to prezentuje się nieco inaczej niż na “zwykłym” systemie. Po nazwie eth0 widzimy @if12. Dwunastka po małpie oznacza id interfejsu peer, który jest sparowany z naszym eth0. Eth0 w tym przypadku veth w przestrzeni namespace, której tutaj nie widzimy, z netnsid 0.

Patrząc po drugiej stronie, czyli na nodzie mamy taką listę interfejsów:

node# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Ostatni z nich to dźwięcznie brzmiący veth7b2f355b z dopiskiem @if3 Patrząc na pierwszy listing, który zrobiliśmy w podzie, z eth0@if12 widać, że eth0 poda miało id 3. Wszystko wię zatem zgadza. Ostatnią rzeczą, na którą warto rzucić okiem to parametr link-netnsid oznaczający ID namespace, do którego przypisany jest peerowany interfejs. Tak więc, w ip link show bezpośrednio z noda widzimy, że interfejs veth7b2f355b jest speerowany (sparowany? może pożeniony? :) z interfejsem o id 3 z namespace o id 5. W ip link show uruchomionym na podzie, widzimy, że interfejs eth0 jest speerowany z interfejsem o id 12, z namespace 0.

Wszystko się zgadza. Żeby sprawdzić możemy puścić pinga lub traceroute z poda i nasłuchiwać na odpowiadającym mu interfejsie sieciowym, na nodzie. Pakiety powinny się pojawić.

Dalej, w świat po opuszczeniu poda

Pakiety wychodzące z poda są adresowane przez “system operacyjny” poda z adresu interfejsu eth0 (src):

pod# ip route show
default via 10.244.1.1 dev eth0 
10.244.0.0/16 via 10.244.1.1 dev eth0 
10.244.1.0/24 dev eth0 proto kernel scope link src 10.244.1.80

W tym przypadku będzie to 10.244.x.y/24, który skonfigurował automatycznie Kubernetes. Po stworzeniu takiego pakietu i zaadresowaniu, jego warstwa IP nie powinna się zmieniać (chyba, że przejdzie przez magiczne regułki iptables, o czym będzie później). Zatem sam pod odpowiada za przygotowanie naszego pakietu w warstwie trzeciej.

Po przejściu na drugą stronę, czyli do “systemu” noda, pakiet taki pojawia się na interfejsie speerowanym z podem. Patrząc na adresacje tego interfejsu po stronie noda, nie zobaczymy już na nim adresu IP:

node# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether b8:27:eb:46:06:69 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.103/24 brd 10.0.0.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::ba27:ebff:fe46:669/64 scope link 
 valid_lft forever preferred_lft forever
...
5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
 link/ether 9e:2b:2b:16:e2:73 brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.0/32 scope global flannel.1
 valid_lft forever preferred_lft forever
 inet6 fe80::9c2b:2bff:fe16:e273/64 scope link 
 valid_lft forever preferred_lft forever
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.1/24 scope global cni0
 valid_lft forever preferred_lft forever
 inet6 fe80::58a8:5dff:fe84:d7ee/64 scope link 
 valid_lft forever preferred_lft forever
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5
 inet6 fe80::9004:f7ff:fea2:90f0/64 scope link 
 valid_lft forever preferred_lft forever

W zasadzie żaden z interfejsów speerowanych z podami nie ma przypisanego adresu. Jak jest zatem organizowany routing i przekazywanie pakietów? Tu zaczyna się nieco trudniejsza zabawa.

Każdy z interfejsów przyłączonych do podów jest zmostkowany z cni0 (żeby wyświetlić, doinstaluj pakiet br-utils):

node# brctl show
bridge name	bridge id		STP enabled	interfaces
cni0		8000.5aa85d84d7ee	no		veth67f9f314
							veth7b2f355b
							veth96d5a04b
							vethe25b43a7
							vethed432234
docker0		8000.02421143bd1a	no

Nasz interfejs veth7b2f355b również tam jest. Zatem pakiety, o ile nie zostaną wycięte przez iptables, są przekazywane przez mostek pomiędzy interfejsami z tego samego noda. Jeśli nie możesz sobie tego wyobrazić, to pomyśl, że cni0 jest switchem, a każdy zmostkowany interfejs jest kabelkiem (veth) prowadzącym do innego komputera (tutaj to namespace).

Dokładnie to samo można sprawdzić przez polecenie ip z pakietu iproute:

node# ip link show
...
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
7: veth67f9f314@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether ce:53:d6:38:84:5c brd ff:ff:ff:ff:ff:ff link-netnsid 0
8: vethe25b43a7@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether a6:16:c1:f9:ae:02 brd ff:ff:ff:ff:ff:ff link-netnsid 1
10: vethed432234@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 82:a5:3c:69:61:39 brd ff:ff:ff:ff:ff:ff link-netnsid 3
11: veth96d5a04b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 7e:af:3a:8a:29:91 brd ff:ff:ff:ff:ff:ff link-netnsid 4
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Każdy z interfejsów zmostkowanych z cni0 (lub innym mostkiem) ma parametr master cni0, który odpowiada za “bycie w bridgu” z cni0.

Ok, mamy zatem interfejsy, które są ze sobą połączone warstwą drugą, natomiast nie mamy jeszcze interfejsu, który odpowiadałby za wypchnięcie pakietu z noda lub przekazanie do innego poda. O ile w podzie wszystko jest jasne i routing mówi: wszystko co nie do mnie, idzie przez default gw, to na nodzie tak różowo nie jest.

Pakiety w obrębie jednego noda są routowane pomiędzy nimi, przez cni0 – każdy pod na nodzie ma swój IP z sieci przypisanej do noda – w tym przypadku 10.244.1.0/24. Jeśli pakiet ma być dostarczony do innego noda, to zaczynają się schodki.

Tablica rouringu noda wygląda następująco:

node# ip route show
default via 10.0.0.1 dev eth0 onlink 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.103 
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink 
10.244.6.0/24 via 10.244.6.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Cała sieć 10.244.1.0/24 jest routowana do naszego noda przez cni0. Natomiast sieci z innych nodów (10.244.2-6.0/24) są przesyłane przez interfejs flannel.1. Dopisek onlink mówi kernelowi, aby przesyłał ruch do tych sieci, nawet nie mając na tym interfejsie przypisanego adresu ip (inaczej musiałby mieć trasę przez konkretny host).

Interfejs flannel.1 jest tunelem vxlan (ip -d link show pokaże przy nim ID vlanu 1, mówi o tym też dopisek .1 w nazwie). Zatem adresując pakiet z naszego poda z adresem 10.244.1.68, przechodzi on przez interfejsy veth do domyślnego namespace, i pojawia się jako pakiet przychodzący przez port cni0 (łapie się na regułki z łancucha FORWARD z iptables), ale nie adresowany do naszego noda (zatem nie będzie to iptables INPUT). Ponieważ kernel w domyślnym namespace zna regułki mówiące o tym jak dostać się do innych sieci na innych nodach, przesyła taki pakiet przez interfejs flannel.1. Tam już na podstawie zapytań arp odnajnowany jest host z sieci innego noda, obsługującego danego poda, np. 10.244.6.0/32:

node# arp -an | grep flannel.1
? (10.244.4.0) at 2e:ed:ad:yy:aa:xx [ether] PERM on flannel.1
? (10.244.0.0) at d2:79:b7:yy:aa:xx [ether] PERM on flannel.1
? (10.244.3.0) at 1e:42:c2:yy:aa:xx [ether] PERM on flannel.1
? (10.244.6.0) at 5a:2d:9a:yy:aa:xx [ether] PERM on flannel.1
? (10.244.2.0) at c6:52:d3:yy:aa:xx [ether] PERM on flannel.1
? (10.244.5.0) at ce:ec:b4:yy:aa:xx [ether] PERM on flannel.1

Sieć stworzona z interfejsów flannel.1 różnych nodów można znowu wyobrazić sobie jako switcha spinającego po jednym kabelku z różnych nodów. Jednak zamiast par veth mamy tutaj tunele VXLAN, które tworzą wirtualną warstwę 2, niezależną od fizycznej sieci. W powyższym przypadku vxlan stworzony przez flannel.1 jest wypuszczany do fizycznej sieci przez eth0 noda. W vxlanie node za pomocą pakietów ARP poznaje inne hosty w sieci i na ich podstawie jest w stanie poprawnie zaadresować mac adres karty odpowiadającej docelowej sieci, w której będzie pod. Flaga onlink w tablicy routingu trochę to zadanie ułatwia, gdyż normalnie kernel musiałby mieć podanego hosta we wspólnej sieci, łączącej wszystkie nody. Tutaj ten etap jest pominięty i przeniesiony na vxlan i odkrywanie hostów poniekąd przez arp.

Po osiągnięciu docelowego hosta przez vxlan, pakiet przebywa analogiczną drogę do poda.

iptables

Po wpisaniu iptables-save dostajemy całkiem sporo regułek i łańcuchów, które odpowiadają za filtrowanie ruchu i natowanie go. Z ważniejszych rzeczy, na które warto zwrócić uwagę, to na wszystkich nodach mamy mimo wszystko ustawioną politykę FORWARD na DROP z dopuszczeniem przekazywania pakietów z sieci flanella:

:FORWARD DROP [0:0]
...
-A FORWARD -s 10.244.0.0/16 -j ACCEPT
-A FORWARD -d 10.244.0.0/16 -j ACCEPT

Do debugowania ruchu może też się przydać poniższy zestaw regułek:

-A POSTROUTING -s 10.244.0.0/16 -d 10.244.0.0/16 -j RETURN
-A POSTROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.1.0/24 -j RETURN
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.0.0/16 -j MASQUERADE --random-fully

Określa on skąd i gdzie pakiety mają być natowane oraz jaki ruch powinien zostać zablokowany.

Dodatkowo w dumpie z iptables-save znajdziemy też całą listę (dość długą) reguł, określających dostęp do klastra k8s, jego serwisów i dns’a.

Uff…

Podsumowując, inżynierowie integrujący flanella zrobili kawał dobrej roboty, który niekoniecznie dobrze się debuguje w razie problemów :) Natomiast ostatnie kilka lub kilkanaście lat pracy nad wirtualizacją i kontenerami daje coraz lepsze narzędzia pozwalające coraz lepiej kontrolować ruch sieciowy w tak zagmatwanych środowiskach jakim jest na przykład kubernetes.

Dlaczego zawód informatyka zawsze będzie potrzebny?

maciej — Sun, 08 Sep 2019 17:55:27 +0000

Kilka lat temu usłyszałem ciekawe stwierdzenie. Jakieś 40 lat temu wszyscy szewcy chórem mówili, że ich zawód nigdy nie wymrze, ponieważ ludzie zawsze będą potrzebowali butów, a ktoś będzie musiał je przecież naprawiać. Jak wyszło? Masz dziurę w bucie, to idziesz po nową parę. Niecałe trzydzieści lat temu (tak, to już lata 90-te) tą samą pewność siebie mieli elektronicy. Coraz więcej sprzętu elektronicznego, w każdym sklepie z elektroniką części zapasowe, ktoś to przecież musiał naprawiać.

Około 10 – 15 lat temu to samo myślałem o informatykach i adminach. Coraz więcej serwerów, ktoś to musi ogarniać. Nowe instalacje Apache + PHP + MySQL, nowe aktulizacje Linuksa, ktoś to musi ogarniać. Do tego wykuty prawie na pamięć config Apache, jakieś fajne zmiany w configu i… Dzisiaj okazało się, że taki admin potrafiący zainstalować LAMP to w sumie przeżytek. Admina zastąpiło

docker run --name moja_piekna_strona -p 80:80 \
	-v /home/maciej/nicciekawego:/srv \
	-d wordpress:latest

Przepraszam. To było 5 lat temu. 4 lata temu ewoluowało do docker-compose:

version: '3.3'

services:
 db:
 image: mysql:5.7
 volumes:
 - db_data:/var/lib/mysql
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: somewordpress
 MYSQL_DATABASE: wordpress
 MYSQL_USER: wordpress
 MYSQL_PASSWORD: wordpress

 wordpress:
 depends_on:
 - db
 image: wordpress:latest
 ports:
 - "8000:80"
 restart: always
 environment:
 WORDPRESS_DB_HOST: db:3306
 WORDPRESS_DB_USER: wordpress
 WORDPRESS_DB_PASSWORD: wordpress
 WORDPRESS_DB_NAME: wordpress
volumes:
 db_data: {}

i sieciowca można w sumie zwolnić. A trzy lata temu przeobraziło się w CloudFormation lub, u bardziej ambitnych, w Kubernetes:

apiVersion: v1
kind: Service
metadata:
 name: wordpress-mysql
 labels:
 app: wordpress
spec:
 ports:
 - port: 3306
 selector:
 app: wordpress
 tier: mysql
 clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mysql-pv-claim
 labels:
 app: wordpress
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
 name: wordpress-mysql
 labels:
 app: wordpress
spec:
 selector:
 matchLabels:
 app: wordpress
 tier: mysql
 strategy:
 type: Recreate
 template:
 metadata:
 labels:
 app: wordpress
 tier: mysql
 spec:
 containers:
 - image: mysql:5.6
 name: mysql
 env:
 - name: MYSQL_ROOT_PASSWORD
 valueFrom:
 secretKeyRef:
 name: mysql-pass
 key: password
 ports:
 - containerPort: 3306
 name: mysql
 volumeMounts:
 - name: mysql-persistent-storage
 mountPath: /var/lib/mysql
 volumes:
 - name: mysql-persistent-storage
 persistentVolumeClaim:
 claimName: mysql-pv-claim

Możliwe, że nawet ciut wcześniej. Firmy, które były trochę bardziej do przodu z technologią, po drodze zaadaptowały jeszcze prawdopodobnie Puppet, Ansible lub inne.

Obecnie, aby postawić wordpressa, wystarczy średnioogarnięty devops, który pozmienia w powyższym pliku co ważniejsze parametry i doczyta jak to wgrać w klaster. Zastąpi on admina od baz danych, systemu, LAMPA, sieciowca i po części programistę. Znajomości Apache nikt nie potrzebuje, bo wszystko ogarnia dość dobrze prekonfigurowany Nginx lub load balancer w chmurze, a baza danych w małych instalacjach daje radę. Jeszcze pozostaje kwestia tego, co zrobić z pomieszczeniem po starym WC i zaadaptowanym kiedyś na serwerownie. Jest dobra klima i media, więc możnaby zrobić relax room lub spa. Wróć, spa w biurze średnio pasuje. Więc relax room. A z piwnicy, w której kiedyś trzymało się admina można zrobić garaż dla rowerów.

Wszystko to tylko dla tego, że całą serwerownie i obowiązki admina zastąpiła chmura AWS lub GC ze swoimi usługami baz danych, load balancera, API gateway’ów i całej masy innego fajnego bajeru, który da się prawieże wyklikać. Do tego jeszcze był devops, który spisał to kiedyś w formie Infrastructure As A Code. Już nie pracuje dla nas, ale yaml po nim został :)

Co z tym programistą?

Tak, z programistą pewnie będzie podobnie, ale jeszcze nie tak szybko. Co chwilę gdzieś można usłyszeć, że zawód informatyka nigdy nie wyginie, bo kto będzie pisał te aplikacje, strony, bugi i pił kawę w kuchni. Czy na pewno? Można popatrzeć na ostatnie 10 lat rozwoju oprogramowania, na przykładzie Pythona. W 2009 roku dla tego języka było niewiele ORM’ów dla baz danych, kilka fajnych frameworków pozwalających postawić stronę i dość sporo systemowych bibliotek do wszystkiego. Patrząc na to jak rozwinęło się Django, programista dostaje prawie gotowe klocki, z których musi poukładać logiczną strukturę strony, a nie mozolnie pisać logikę, konfigurować renderowanie stron HTML i łączyć wszystko ze sobą. Najpopularniejsze zadania zostały tak zautomatyzowane, żeby programiście pozostało właśnie tylko układanie klocków. No czasami może integracja z czymś innym.

Składając to z zewnętrznymi narzędziami, lub całymi serwisami oferującymi swoje funkcjonalności, programista nie musi nawet konfigurować mailerki do rozsyłania spamu ze swojego serwisu. Maile wyśle za niego sendgrid. Dużo maili wyśle sendgrid za odpowiednią opłatą.

Patrząc na to jak rozwija się świat IT oraz dostępne narzędzia, programistów powoli zastąpią osoby pokroju DevOps, które będą potrafiły szybko poskładać gotowe klocki w całość. Na studiach uczyłem się, że architekt dostarcza UML programistom, z których oni mają wyczytać to, co ma robić aplikacja. Dzisiaj to programista dostaje opis aplikacji, sugeruje klientowi co może być lepiej zaimplementowane i to po prostu robi.

Nie jest to oczywiście reguła, ponieważ jest cała pula aplikacji, które wymagają indywidualnego podejścia, porządnego zaprojektowania i implementacji nieszablonowej logoki. Natomiast ilość aplikacji, które wymagają Javascriptowego frontendu (np. reacta), REST API i bazy danych w chmurze systematycznie rośnie.

Czy zatem programiści to gatunek na wymarciu? Pewnie jeszcze długo nie, tak samo długo jak “zwykli” admini znający system do spodu będą potrzebni. Natomiast same narzędzia, które stają się coraz lepsze i prostsze sprawiają, że coraz mniej aplikacji wymaga programisty z krwi i kości, a coraz więcej akcji dzieje się magicznie i może być mocno uproszczonych. Sukcesywnie dąży się do tego, że opis aplikacji, który kiedyś tworzyło się w UML’u dzisiaj zastępuje dokument lub seria calli z klientem, na podstawie których wiadomo z czego poskładać daną aplikację. Na pewno jest to dość duże uproszczenie i spłycenie tego, co aktualnie robią programiści, natomiast koniec końców ktoś zawsze będzie musiał przetłumaczyć klientowe “ja chcę to” na coś bardziej formalnego i dopytać tego klienta o całą masę szczegółów. Czy sztuczna inteligencja? Myślę, że jeszcze nie prędko

Na co dzień na raspberry

maciej — Fri, 02 Aug 2019 19:39:16 +0000

Raspberry PI jako desktop sprawdzało się do tej pory średnio – I/O dysku na poziomie 30MB/s bez perspektywy poprawienia jakimikolwiek rozszerzeniami przekreślała. Kilka tygodni temu sytuacja się zmieniła i mamy PI 4. Jak się na nim pracuje?

Od kilku tygodni jestem szczęśliwym posiadaczem dwóch malin w wersji 4. Pierwsza, z 1GB ramu sprawuje się bardzo dobrze hostując storage m.in. tego bloga. W zestawie z kilkoma innymi Raspberry PI 3, dedykowanym zasilaczem usb 40W od Tp-linka i dyskiem 2 TB daje sobie radę dość dobrze. Albo po prostu mi nie przeszkadza trochę dłuższe ładowanie strony :) Udało się na to wepchnąć kilka wordpressów, NAS, build server i jeszcze pare innych rzeczy.

Drugie PI4 czekało na lepsze czasy. Miało posłużyć jako hosting do bardziej wymagających stron, jednak między czasie plan się zmienił i stronki czekają na lepsze czasy. Pozostało zatem skorzystać z okazji i podpiąć je w miejsce starego, popsutego już macbooka i zobaczyć czy da się na tym pracować.

Da się :)

Oprócz kilku drobnych problemów, m.in. ze starą wersją firefoxa, brakiem ładnego środowiskai brakiem niektórych sterowników, m.in. do drukarki, RPI4 jako desktop sprawuje się całkiem znośnie. Dobra, może ktoś lubi MATE lub Xfce4, wtedy ma jeden problem mniej.

Bardzo duży zysk na wydajności daje włożenie dysku SSD. O ile w RPI 3 nie miało to większego sensu (bo USB 2.0 i tak obcinało transfer do 30MB/s), to malina w wersji 4 daje radę wyciągać 200-330MB/s. Do tego dochodzi płynnie działająca sieć, która nie współdzieli transferu z dyskiem i mamy całkiem przyjemnie pracujący desktop. Uruchomienie SSD wymagało co prawda dopisanie następującego stringa w /boot/cmdline.txt:

usb-storage.quirks=125f:a68a:u

i zabawę w kopiowanie systemu plików z karty SD na dysk, ale zwróciło się szybko w wydajności. Co więcej, karty SD nie dają takich transferów, więc zainwestowanie w dysk SSD dla maliny jest moim zdaniem dobrym krokiem.

A po instalacji…

Po zainstalowaniu Raspbiana Buster pozostaje doinstalować dosłownie kilka niezbędnych programów, m.in. ssh, openvpn, git, gcc, make, cmake, qtcreator, mate-desktop, mate-desktop-environment, libreoffice-writer, chromium-browser, mate-terminal, whois, imagemagick, htop, screen, nmap, tcpdump, fish oraz skonfigurować wifi w /etc/wpa_supplicant i /etc/network/interfaces aby cieszyć się gołym desktopem. Aby cieszyć się jeszcze bardziej i poczuć jak na początku tego tysiąclecia, wypadało jeszcze pobrać z mate-look.org kilka zestawów ikon oraz theme dla środowiska Mate. Następnie rozpakować je, do odpowiednio: /usr/share/icons i /usr/share/themes.

Wisienką na torcie jest oczywiście wywalenie z /etc/passwd domyślnego basha, wsadzenie tam fisha dla swojego konta (no tak, jeszcze konto pi trzeba usunąć i dodać swoje) i skonfigurowanie mate-terma ze swoimi ulubionymi skrótami.

Uf. Jak 15 lat temu, pół dnia roboty i desktop wygląda, nie wstyd się zalogować przy znajomych.

Wydajność

Jak wspomniałem, SSD daje kopa wydajności jeśli chodzi o dostęp do plików, uruchamianie programów itd. w stosunku do RPi 3. Natomiast po chwili użytkowania zaczynają wkurzać niewielkie lagi przy zmianach i włączaniu aplikacji, które trwają ok. pół sekundy, czasami ciut dłużej. Nie ma tego na zwykłym desktopie, nawet z włączonymi efektami pulpitu. Skąd tu się bierze – nie wiem. Może to brak cache w cpu, a może brak wsparcia grafiki w wyświetlaniu okienek?

Koniec końców da się jednak żyć z tym komuterkiem, jeśli tylko małę lagowanie i brak aktualnych wersji niektórych programów nie przeszkadza. Co więcej, kompilacja frameworka dinemic i innych aplikacji, nad którymi ostatnio pracuję przebiega tu dość sprawnie, nawet szybciej niż na moim zwykłym desktopie. Oczywiście kompilator wypluwa binarki w wersji ARM, ale to już inna bajka. Nie przeszkadza to również w normalnej pracy w przeglądarce i oglądaniu głupich obrazków, gdy kompilator zjada 400% CPU.

Podsumowując, jeśli ktoś nie ma wymagań co do grania i oglądania wideo (od biedy też się da), to idzie przeżyć z samym RPi 4. Jeśli chodzi o hosting, to jest znacznie lepiej i daje nieporównywalnego kopa w stosunku do RPi 3 zarówno jako sam hosting dynamicznych stron jak i NAS.

Na koniec dorzućmy UPS’a

Wspomniany na początku klaster RPi zastąpił starego dobrego HP G6, który robił za build server, hosting i całą resztę rzeczy na potrzeby projektów z cloudover. Po drodze przyplętał się UPS, 1500VA / 900W, który mógł podtrzymać serwer HP przez około 50 minut. Po wymianie na kilka raspberry PI i przekonfigurowaniu całego środowiska testowania i budowania czas wydłużył się… do 15 godzin :)

Jak trzymać hasła w pamięci i dlaczego cstringi są czasem lepsze od std::stringów?

maciej — Sat, 16 Feb 2019 08:32:37 +0000

“Poznaj sekret cstringów. Std::stringi ich za to nienawidzą”! A na serio, nie zgapiając od pomponików, będzie trochę na temat trzymania wrażliwych danych w pamięci RAM i o zapobieganiu ich zapisowi na dysk.

Na początek krótkie ćwiczenie: napisałeś program do przechowywania haseł. Taki keepass w wersji DIY. Po uruchomieniu wczytuje zaszyfrowany plik do pamięci, pyta Cię o hasło, odszyfrowuje i pokazuje wybrane hasło. Działa dopóki go nie zamkniesz, na wszelki wypadek, jakbyś potrzebował jeszcze innego hasła. Niby bezpieczne, bo zaszyfrowane, na hasło… ale nie do końca.

Co może pójść nie tak?

Trzymasz odszyfrowany pęk kluczy w pamięci – to pierwszy problem. Dowolne nadpisanie/odczytanie takiej pamięci, np. przez /dev/mem albo /proc/X/mem może skompromitować wszystkie hasła z Twojego pęku – dowolna osoba z uprawnieniami root’a będzie mogła wczytać treść z Twojej pamięci. To może odszyfrowywać tylko gdy tego potrzebujemy? Ok, wtedy trzymamy w pamięci jedynie nasze główne hasło i zaszyfrowane przez prawie cały czas dane.

Osoba atakująca będzie mogła wtedy dość łatwo poznać hasło, którego możesz też przecież używać gdzieś indziej (tak, są tacy ludzie i jest ich dość dużo :) ). Popatrzmy na inny przykład: Linux Kernel posiada wbudowany system szyfrowania dysków – LUKS. Do odszyfrowania jednego dysku można przypisać kilka różnych haseł dla różnych osób. Dzięki temu można uniknąć przekazywania ich i zapisywania na karteczkach. Każdy może użyć wtedy swojego ulubionego hasła :) Jeśli natomiast je zgubi, można zmienić tylko to jedno hasło do dysku, bez zmiany innych haseł. Co więcej zmiana dowolnego hasła nie wymusza re-szyfrowania całego dysku. Jak to działa? Nie ma za tym jakiejś specjalnej magii i matematyki. Każdy z użytkowników, którzy mają swoje hasła tak na prawdę deszyfruje główny klucz do dysku. Dopiero za pomocą tego klucza jest przeprowadzane pełne (de)szyfrowanie.

Podobny mechanizm możesz też zastosować w Twoim pęku kluczy lub podobnej aplikacji. Za pomocą hasła użytkownik może odszyfrować tak na prawdę klucz symetryczny, który posłuży do odczytania pozostałej części danych. Przechowywanie go w pamięci, jeśli to konieczne, jest wtedy nieco bardziej bezpiecznym rozwiązaniem niż ciągłe przechowywanie hasła, lub co gorsze pełnego pęku kluczy.

Gdzie zapisać tymczasowe hasło?

Mimo wszystko Twoje hasło lub klucz deszyfrujący musi być tak czy tak chociaż na chwilę wczytane do pamięci. Jak zabezpieczyć się przed jego wyciekiem? Oprócz możliwości odczytania hasła bezpośrednio z pamięci jest jeszcze jedna możliwość. Atakujący może zaalokować tak dużo pamięci w systemie, że w końcu Twój DIY Keepass zostanie przeniesiony do swapu. A stąd już prosta droga do wyciągnięcia i przeanalizowania danych. Jeśli nie jako dump pamięci z poziomu roota, to śrubokrętem, przenosząc dysk do innego komputera lub bootując komputer z live cd.

Jak się przed tym obronić? Linux posiada trzy funkcje pozwalające Twojej aplikacji określić jak ma się zachowywać jej wirtualna pamięć. Pierwsza z nich to mprotect. Podając adres pamięci (np. blok zwrócony przez malloc) możesz sprawić, że dany obszar będzie dostępny tylko do odczytu, do zapisu lub w cale. Flaga PROT_WRITE jest zwykle stosowana do zabezpieczenia obszaru pamięci, w którym znajduje się Twój plik wykonywalny, aby przypadkowe (lub złośliwe) nadpisanie kodu instrukcji Twojej aplikacji nie było możliwe. PROT_EXEC jest natomiast stosowane do zabezpieczenia pamięci przed wykonywaniem jej kodu, np. w obszarach pamięci przechwujących zmienne. Zapobiega do przypadkowemu uruchomieniu takiego kodu. Wbrew pozorom bardzo użyteczną flagą może być PROT_NONE. Takiego obszaru nie da się ani odczytać, ani zmodyfikować ani wykonać. Jedną stronę takiej pamięci możemy ustawić np. za obszarem, do którego będą zapisywane dane od użytkownika, o nieznanym rozmiarze. Jeśli nasze programowe zabezpieczenia zawiodą i na przykład zaczniemy zapisywać do takiej tablicy bez opamiętania (bez if’a :) to finalnie program spróbuje zapisać coś na stronie pamięci oznaczonym PROT_NONE. W takiej sytuacji zadziała już sprzętowe zabezpieczenie i nasza aplikacja otrzyma stosowny, zwykle bolesny sygnał od systemu operacyjnego.

Drugą funkcją służącą do modyfikowania zachowania pamięci jest madvise. Podobnie jak mprotect przyjmuje ona adres i rozmiar obszaru pamięci, który chcemy zmodyfikować. Za jej pomocą możemy powiedzieć systemowi (doradzić) jak będziemy korzystać z tego obszaru. Czy na przykład będą to losowe odczyty i cache’owanie na wyrost nie ma sensu, czy też podczas forka procesu ten obszar pamięci ma pozostać nieskopiowany. Flag jest sporo, warto przeglądnąć je w przyjaznym manualu.

Ostatnia funkcja, warta wspomnienia to mlock. Ponownie, przyjmuje jako pierwsze parametry adres i rozmiar obszaru pamięci. Zapobiega ona przenoszeniu stron pamięci na swap. Oznaczając w ten sposób obszar gdzie trzymamy klucz deszyfrujący oraz sam keychain, możemy zabezpieczyć się przed wspomnianym wcześniej wymuszeniem zrzutu pamięci na swap.

Korzystając z wszystkich trzech powyższych funkcji możemy wymusić na systemie operacyjnym nieco lepsze potraktowanie naszych danych przesiadujących w pamięci. Za pomocą mprotect możemy przez większość czasu zapobiegać dostępowi do pamięci, ustawiając jej flagę PROT_NONE, i “odbezpieczając” tylko gdy użytkownik potrzebuje hasła. Za pomocą madvise mona zapobiec skopiowaniu tej pamięci przez fork (i prawdopodobnie zabezpieczyć się też na kilka innych okoliczności), a z mlock zapobiegniemy wyrzuceniu na swap.

Cstring vs. std::string

Przy okazji wychodzi czemu czasami zarządzanie pamięcią przez malloc i standardowe stringi z C są bardziej użyteczne. Korzystając z std::string nie mamy tak dokładnej kontroli nad tym, gdzie będą trzymane dane ze stringa, jak również nie mamy gwarancji że po dopisaniu kolejnych znaków nie zostanie on w całości przeniesiony w inne miejsce. Trudniejsze staje się też zabezpieczenie strony tuż za stringiem. Nie jest to jednak niemożliwe, jednak wymaga dodatkowej pracy i dogłębnej wiedzy jak jest alokowana w tym przypadku pamięć. Dodatkowo, gdy std::string zwalnia pamięć, musimy też ręcznie posprzątać po nim, aby inny obiekt nie dostał obszaru z PROT_NONE.

W przypadku c stringów, wszystkie operacje przenoszenia, zabezpieczania i odbezpieczania musimy zrobić tak czy tak ręcznie, jednak z punktu widzenia czytelności kodu i jego obsługi jest to znacznie czytelniejsze.

Swap też jest szyfrowany

Tak, od jakiegoś czasu dystrybucje wspierają to domyślnie. Strony pamięci zrzucane do swapu są w locie szyfrowane, także odczytanie ich po wyłaczeniu komputera nieco się komplikuje. Przykładowy wpis z Arch wiki:

swap /dev/sdX# /dev/urandom swap,cipher=aes-xts-plain64,size=256

Przy każdym starcie system generuje losowy klucz do zaszyfrowania swapu z /dev/urandom. Nawet jeśli coś się na swapie pojawi, to będą to tylko losowe znaki dla osoby, która nie zna klucza. Problem pojawia się jednak przy wsparciu dla disk suspend – uśpienia komputera i zrzucenia stanu pamięci na dysk. W tym przypadku sprawy się nieco komplikują, ale to historia na inny wpis.

Wirtualne maszyny

O ile wszystkie powyższe sposoby mają się całkiem dobrze na “gołym” PC, to już korzystając z wirtualizacji nie mamy gwarancji, że ktoś nie zrobi zrzutu pamięci oraz dysku w locie i nie będzie próbował analizować tego offline. W takim wypadku jedynym rozwiązaniem minimalizującym ryzyko przechwycenia cennych danych jest tylko chwilowe odszyfrowywanie ich. Nie gwarantuje to jednak pełnego bezpieczeństwa. Na własnych systemach można zapobiegać temu odpowiednimi opcjami dla wirtualnych maszyn, dzięki którym gospodarz nie będzie przenosił ich stron na swap. Służy do tego m.in. opcja locked w libvircie. Jednak w publicznych chmurach nie mamy takiej gwarancji.

Bezpieczeństwo różnych algorytmów

Na koniec warto wspomnieć o bezpieczeństwie samych algorytmów szyfrujących. Co, jeśli któryś okaże się podatny na ataki? Często aplikacje oferujące szyfrowanie pozwalają na złożenie kilku algorytmów na raz. O ile Twoje hasło pozostaje prawdopodobnie najsłabszym punktem, to szansa na skompromitowanie dwóch algorytmów szyfrujących na raz znacznie spada. Pomyśl, że lata temu używałeś MD5 do potwierdzania integralności plików. Algorytm się “zepsuł”. Wykonanie SHA1(MD5(…)) nieco ratuje sprawę. W ten sposób zabezpieczają się np. adresy portfeli z Ethereum. Skompromitowanie jednego algorytmu (co powodowałoby że łatwo wygenerować inny portfel z tym samym adresem) znacznie maleje.

Pobieranie czegokolwiek z youtuba w fullhd z konsoli

maciej — Mon, 11 Feb 2019 22:41:12 +0000

Niektórzy lubią filmy, inni muzykę, a jeszcze inni po prostu potrzebują zapisać na dysk filmiki z kotami. Powód wymyślcie sobie sami :)

Od niedawna wszelkiego rodzaju pobieraczki youtubowe przestały oferować jakość full HD z dźwiękiem. No cóż, trzeba sobie radzić inaczej. Za pomocą youtube-dl można pobrać osobno dowolną ścieżkę audio z youtube oraz dowolną ścieżkę video, o wybranym bitrate, codecu oraz rozdzielczości.

Co będzie potrzebne?

Potrzeba nam dwóch narzędzi. A w zasadzie trzech – pipem pobierzemy downloader:

sudo apt install ffmpeg python3-pip
sudo pip3 install youtube_dl

Pakiet pip będzie nam służył do pobrania właściwego narzędzia w pythonie – youtube-dl. Za jego pomocą można zobaczyć co dany film oferuje do pobrania – wszystkie wersje audio i video oraz umożliwia pobranie ich. Ffmpeg posłuży do połączenia osobnych ścieżek audio oraz video w jeden plik.

Pobranie audio i video

Po pierwsze wybierzmy jakieś interesujące video. Na przykład to: https://www.youtube.com/watch?v=G1IbRujko-A.

Za pomocą youtube-dl można wyświetlić listę dostępnych ścieżek audio i video:

~> youtube-dl -F 'https://www.youtube.com/watch?v=G1IbRujko-A'
[youtube] G1IbRujko-A: Downloading webpage
[youtube] G1IbRujko-A: Downloading video info webpage
[youtube] G1IbRujko-A: Downloading js player vflYv1bWD
[info] Available formats for G1IbRujko-A:
format code extension resolution note
249 webm audio only DASH audio 117k , opus @ 50k, 272.51MiB
250 webm audio only DASH audio 136k , opus @ 70k, 351.10MiB
140 m4a audio only DASH audio 162k , m4a_dash container, mp4a.40.2@128k, 545.84MiB
171 webm audio only DASH audio 191k , vorbis@128k, 577.59MiB
251 webm audio only DASH audio 207k , opus @160k, 667.00MiB
160 mp4 256x144 144p 170k , avc1.4d400c, 24fps, video only, 205.76MiB
133 mp4 426x240 240p 237k , avc1.4d4015, 24fps, video only, 543.85MiB
278 webm 256x144 144p 281k , webm container, vp9, 24fps, video only, 401.04MiB
242 webm 426x240 240p 302k , vp9, 24fps, video only, 467.08MiB
134 mp4 640x360 360p 338k , avc1.4d401e, 24fps, video only, 968.71MiB
243 webm 640x360 360p 528k , vp9, 24fps, video only, 1.41GiB
135 mp4 854x480 480p 690k , avc1.4d401e, 24fps, video only, 2.24GiB
244 webm 854x480 480p 739k , vp9, 24fps, video only, 2.37GiB
247 webm 1280x720 720p 1090k , vp9, 24fps, video only, 3.61GiB
136 mp4 1280x720 720p 1154k , avc1.4d401f, 24fps, video only, 4.41GiB
137 mp4 1920x1080 1080p 2373k , avc1.640028, 24fps, video only, 9.32GiB
248 webm 1920x1080 1080p 2647k , vp9, 24fps, video only, 5.18GiB
43 webm 640x360 medium , vp8.0, vorbis@128k, 3.06GiB
18 mp4 640x360 medium 485k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 2.04GiB
22 mp4 1280x720 hd720 1179k , avc1.64001F, mp4a.40.2@192k (44100Hz) (best

W tym przypadku można pobrać gotowy plik – ścieżkę 22. W niektórych filmach, np. w teledyskach nie ma połączonej wersji audio + video i jest możliwość pobrania tylko osobnego audio i osobnego video. Zróbmy więc tak:

youtube-dl --format 171 'https://www.youtube.com/watch?v=G1IbRujko-A'
youtube-dl --format 136 'https://www.youtube.com/watch?v=G1IbRujko-A'

Ścieżka o id formatu 171 to audio w kontenerze webm, z kodekiem vorbis i bitrate 191k (powyższa tabelka). Ścieżka 136 to video 1280x720 mp4. W bieżącym katalogu powinieneś widzieć dwa nowe pliki – jeden z rozszerzeniem webm, a drugi mp4. Po otworzeniu w dowolnym odtwarzaczu pierwszy z nich będzie grał, a drugi wyglądał.

Łączenie w całość

Na koniec pozostaje połączyć jedno i drugie w jeden plik MP4:

ffmpeg -i [plik].webm -i [plik].mp4 -acodec copy -vcodec copy plik-calosc.mp4

Powyższe polecenie przekopiuje ścieżkę audio (-acodec copy) oraz ścieżkę video (-vcodec copy) bez ponownej kompresji. Obie ścieżki zostaną zapisane w pliku plik-calosc.mp4. I to wszystko.