Maciej[cc] » Cloud

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!

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 ;)

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.

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.

Krótki wstęp do AWS i boto3

maciej — Thu, 14 Feb 2019 16:59:45 +0000

Jest sporo poradników na temat tego jak korzystać z chmury AWS. Oto kolejny :)

Przygotowanie środowiska

Na początek zainstaluj potrzebne pakiety:

apt update
apt install ipython3 python3-boto3

i załóż konto na aws.amazon.com. Po zalogowaniu się do console.aws.amazon.com wpisz w polu do przeszukiwania serwisów AWS IAM. IAM to narzędzie do zarządzania kluczami dostępu – Identity and Access Manager. Służą one do przydzielania dostępu do Twoich zasobów w AWS skryptom. Dzięki temu nie musisz zapisywać hasła na przykład na serwerze, lecz tylko klucz i ID klucza.

Następnie kliknij users i wybierz lub stwórz nowego użytkownika. W detalach, wybierz zakładkę Security credentials. Powinna tam być sekcja Access keys. Kliknij Create access key. W okienku dialogowym pokaże się tabelka z ID klucza oraz sam klucz (widoczny po kliknięciu show).

Zapisz te wartości w pliku ~/.aws/credentials na Twoim komputerze. Boto3 oraz inne narzędzia AWS, z których możesz korzystać będą szukać właśnie tam domyślnych danych do logowania w AWS:

[default]
aws_access_key_id = ABCDEFGHIJKL
aws_secret_access_key = joJ/fw4tgp98sjoif34faCSDSv459...

Pierwsze kroki

Odpal konsolę ipython3, zaimportuj boto3 i połącz się z AWS:

# ipython3
import boto3

ec2 = boto3.resource('ec2', 'us-east-1')

Za pomocą obiektu ec2 będziemy mogli odpytać API AWS o dostępne zasoby i uruchomić nowe instancje w danym regionie.

Listowanie zasobów

Poniższy fragment wyświetli obrazy, których właścicielem jest Canonical (użytkownik o ID 099720109477):

for i in ec2.images.filter(Owners=['099720109477']):
 print(i)

ec2.images, podobnie jak instances, vpcs itd. posiada kilka metod służących do selektywnego listowania zasobów w AWS. Aby wyświetlić wszystkie zasoby, można wykorzystać ec2.images.all(), jednak nie polecam tego akurat na images – zbyt dużo wyników. Powyższa metoda filter pozwala przekazać kilka rodzajów kryteriów do wyświetlenia. Aby zobaczyć pełną dokumentację wpisz w konsoli ipython:

In [11]: ec2.images.filter?

i naciśnij enter. Powinna pokazać się pełna dokumentacja funkcji:

Signature: ec2.images.filter(**kwargs)
Docstring:
Creates an iterable of all Image resources in the collection filtered by kwargs passed to method.

See also: `AWS API Documentation <https://docs.aws.amazon.com/goto/WebAPI/ec2-2016-11-15/DescribeImages>`_


**Request Syntax**
::

 image_iterator = ec2.images.filter(
 ExecutableUsers=[
 'string',
 ],
 Filters=[
 {
 'Name': 'string',
 'Values': [
 'string',
 ]
 },
 ],
 ImageIds=[
 'string',
 ],
 Owners=[
 'string',
 ],
 DryRun=True|False
 )
...

Na kolejnych stronach dokumentacji

Tworzenie nowych obrazów

Użyj metody ec2.create_volume aby stworzyć nowy obraz dysku. Sprawdź jej parametry wywołując ją najpierw z pytajnikiem. Na początek możesz dodać parametr DryRun=True aby nie zaalokować niepotrzebnie zasobów:

v = ec2.create_volume(DryRun=True)

API boto3 w odpowiedzi powinno zwrócić wyjątek z informacją jakich parametrów brakuje. Pododawaj je aż uzyskasz prawidłową odpowiedź z API.

Jednym z parametrów, jaki będziesz musiał podać jest AvailabilityZone, która jest czymś dokładniejszym niż określenie samego regionu. Aby zobaczyć jakie są AvailabilityZones w Twoim regionie, będziemy potrzebowali kolejnego obiektu API – ec2.client. Za jego pomocą można zobaczyć nieco inne parametry niż z tego, co zwróciło nam poprzednio ec2.resource:

ec2client = boto3.client('ec2', 'us-east-1')
ec2client.describe_availability_zones()
Out[22]:
{'AvailabilityZones': [{'Messages': [],
 'RegionName': 'us-east-1',
 'State': 'available',
 'ZoneName': 'us-east-1xyz'
...
In [23]:

Wybierz jedną strefę i wróć do tworzenia obrazu. Finalnie powinieneś dostać taki komunikat z DryRun=True:

ClientError: An error occurred (DryRunOperation) when calling the CreateVolume operation: Request would have succeeded, but DryRun flag is set.

Oznacza to dokładnie tyle, że wszystkie checki przeszyły i pozostało tylko usunąć DryRun aby poprawnie wysłać żądanie do AWS. Sprawdź jeszcze tylko rozmiar tworzonego volumenu aby nie zjeść całej swojej quoty :)

Jeśli zapisałeś zwrócony wynik do zmiennej, to powinieneś móc odczytać ID obrazu:

print(v.id)

Jeśli nie, to prawdopodobnie dostałeś podobny do poniższego string:

Out[26]: ec2.Volume(id='vol-0348fjqpif...')

Możesz stworzyć nowy obiekt odpowiadający Twojemu obrazowi:

v2 = ec2.Volume(id='vol-0348fjqpif...')

Mając “w ręce” taki obiekt można sprawdzić też jaki obraz ma rozmiar (v2.size), jego status (v2.state) i podobne rzeczy. Jeśli chcesz zobaczyć w konsoli ipython wszystkie opcje, wpisz v2 i wciśnij tabulator:

In [31]: v2. [to wciśnij tabulator :) ]
 v.attach_to_instance v.create_time v.enable_io v.kms_key_id v.size v.volume_id
 v.attachments v.delete v.encrypted v.load v.snapshot_id v.volume_type
 v.availability_zone v.describe_attribute v.get_available_subresources v.meta v.snapshots
 v.create_snapshot v.describe_status v.id v.modify_attribute v.state
 v.create_tags v.detach_from_instance v.iops v.reload v.tags

Strzałkami w górę/dół można wybrać sobie funkcję. Ot taki feature dla leniwych :) Na koniec, żeby nie dostać po kieszeni można skasować wolumen:

v2.delete()

Tworzenie wirtualnej maszyny – EC2 instance

Przejdźmy przez dodanie wszystkich parametrów po kolei:

i = ec2.create_instances(DryDun=True, MinCount=1, MaxCount=1)

Funckja pozwala stworzyć wiele instancji na raz. Pierwszymi parametrami o jakie będzie krzyczyała są powyższe MinCount i MaxCount. Tutaj chcemy zrobić dokładnie jedną instancje, więc oba są równe 1.

Wybór obrazu
Drugi brakujący parametr to ImageId. Zmodyfikujmy nieco wcześniejszą pętle aby sprawdzić jakie są nazwy obrazów i ich ID:

for i in ec2.images.filter(Owners=['099720109477'], Filters=[{'Name': 'name', 'Values': ['*bionic*']}]):
 print(str(i.id) + ' - ' + str(i.name))

Dodatkowy parametr metody filter to Filter. Przyjmuje on listę filtrów opisanych słownikiem. Wymaganymi polami są Name, który określa nazwę pola, którego dotyczy dany filtr oraz Values który określa dopuszczalne wartości tego pola w dowolnym pasującym wpisie. W powyższym przykładzie filtrujemy po polu name i wymagamy, aby w nazwie obrazu pojawiło się słowo bionic w dowolnym otoczeniu (gwiazdki):

[
 {
 'Name': 'name',
 'Values': ['*bionic*']
 }
]

Można też dołożyć kolejne kryteria aby na przykład wylistować tylko publiczne obrazy:

[
 {
 'Name': 'name',
 'Values': ['*bionic*']
 },
 {
 'Name': 'is-public',
 'Values': ['true']
 }
]

i tak dalej… Wybierz swój ID obrazu z ubuntu i idźmy dalej. ami-0a313d6098716f372 to na przykład Ubuntu Bionic LTS w wersji server minimal.

Dodanie VPC i sieci

Kolejnym brakującym parametrem będzie VPC, o ile nie masz swojego. Stwórzmy nowe i dodajmy od razu do niego sieć. VPC to wirtualna prywatna sieć, w której można dodawać adresacje podsieci, routing i trochę innych fajnych rzeczy. To trochę tak jakbyś łączył kabelki do switcha, a później dodawał adresacje na serwerze dhcp jako subnet:

vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16')
subnet = vpc.create_subnet(CidrBlock='10.0.1.0/24')
iface = subnet.create_network_interface()

Cały subnet powinien mieścić się w adresacji jaką podałeś w create_vpc. Obiekt iface odpowiada podłączeniu do naszej nowej sieci. Coś w rodzaju ethernetowego kabelka z przypiętym adresem IP znajdującym się w danej sieci (subnet). Przypisany losowy adres możesz sprawdzić wpisując:

print(iface.private_ip_address)

Jeśli nie zapisałeś któregoś wyniku w zmiennej, w ipythonowej sesji, w każdej chwili możesz taki obiekt odtworzyć:

vpc.create_subnet(CidrBlock='10.0.1.0/24')
Out[32]: ec2.Subnet(id='subnet-12345...')

s = ec2.Subnet(id='subnet-12345...')

Stworzenie instancji – po raz ostateczny

Z tymi dwoma obiektami możemy wrócić do tworzenia instancji:

i = ec2.create_instances(MinCount=1, MaxCount=1, ImageId='ami-0a313d6098716f372', InstanceType='c4.xlarge', SubnetId=s.id)

Create_instances zwraca listę wyników – można ustawić większą ilość maszyn w MaxCount. Jeśli nie AWS’owi nie uda się stworzyć takiej ilości jak MaxCount będzie próbował aż do osiągnięcia MinCount. Jeśli nie będzie mógł stworzyć MinCount maszyn, to zwróci błąd, np. przez ograniczenia Twojego konta.

Jeśli zastanawiasz się po co nam był nowy interfejs – zgadza się, nie był potrzebny :) Można go skasować: iface.delete()

Aby sprawdzić w jakim stanie jest nasza wirtualna maszyna, możesz wpisać:

instance = i[0]
print(instance.state)

Za każdym razem w odpowiedzi dostaniesz “pending”. To przez fakt, że boto3 pamięta ostatnią odpowiedź API AWS. Aby odświeżyć stan instancji (to samo tyczy się obrazów, VPC itd.) wywołaj instance.reload().

Posprzątanie

Na koniec pozostaje posprzątanie wszystkiego:

inst.terminate()

# Reload subnet information to be able to release it. If there are ifaces attached, first remove them
subnet.reload()
subnet.delete()

vpc.delete()

No masters, no slaves, blockchain inside – pisanie zdecentralizowanych aplikacji

maciej — Fri, 14 Dec 2018 13:33:22 +0000

Blockchain idealnie wpisuje się w ostatni trend politycznej poprawności w świecie IT. Nie ma nodów master ani slave, wszyscy są równi niezależnie od ~~płci~~ miejsca w sieci. Framework Dinemic jest biblioteką, która pomaga tworzyć zdecentralizowane aplikacje w C++ oparte o technologię, która jest pochodną Blockchain, X509 oraz kilku innych technologi. Służy głównie do tworzenia programów, które mają działać na wielu maszynach równocześnie zapewniając przy tym wysoką wydajność i odporność na awarie.

Chociaż dinemic jest de facto ORM’em dla C++, to spróbujmy na początek inaczej. Wyobraź sobie repozytorium Git’a. Takie, w którym to nie developerzy robią commity, a poszczególne obiekty klas, a każdy commit jest informacją na temat zmiany stanu takiego obiektu (i bazy danych pod nim), podpisaną przez niego cyfrowo. Dodatkowo pomyśl, że nie mamy jednego centralnego serwera Git’a, ale każdy komputer w sieci jest za razem repozytorium lokalnym i remote’m dla innych repozytoriów. Jeszcze tylko dodać, że nieautoryzowane zmiany są odrzucane przez inne repa i mamy obraz framework’a dinemic. To tak w skrócie. Po nieco obszerniejszy opis zapraszam dalej.

Jak to zwykle działa

Zwykle aplikacje, nawet te obsługujące większe serwisy, mają następującą architekturę: program, na przykład w PHP, jest hostowany przez serwer www. Jego logika odpowiada on za przygotowanie i udostępnienie treści zapisanych w bazie danych. W ostatnim czasie, nawet jeśli jest to aplikacja desktopowa lub mobilna, to i tak jej backend jest obsługiwany przez serwis oparty o zapytania HTTP.

Jak przy każdym serwisie, podczas budowania takiej aplikacji powstaje cała masa pytań. Jedno z najczęściej spotykanych to jak autoryzować ich użytkowników? W najprostszej formie można to zrobić na poziomie bazy danych, nie komplikując zbytnio logiki swoich aplikacji. Jednak w miarę rozwoju lub chcąc integrować się z zewnętrznymi serwisami pozostaje przeniesienie całej autoryzacji użytkowników do zewnętrznego lub wydzielonego wewnętrznego (mikro)serwisu.

Na koniec pozostaje do rozwiązania problem dostępności takiej usługi, jej bezpieczeństwa i całej masy innych problemów, na które prawdopodobnie się napotka. Na przykład granulacji uprawnień: czy użytkownik może lub nie mieć dostępu do serwisu, czy też administrator może zdecydować do jakich jego części może mieć dostęp? Jeśli to drugie, to czy chcemy dawać dostęp do wszystkich funkcjonalności, czy mieć możliwość ich wyboru? I tak dalej…

Do tego może jeszcze dojść zewnętrzny system autoryzacji, np. przez google lub facebooka, i mamy gotowy projekt na długie miesiące służący jedynie do odpowiedniego “wpuszczenia” użytkownika do naszego systemu. Odpowiedniego, czyli takiego aby nie mógł za dużo nabroić i żeby nie był całkowicie sparaliżowany ograniczeniami. Do tego jeszcze należy pamiętać o zabezpieczeniu wszystkiego, odpowienio mocnych hashah haseł, sposobie hashowania, dedykowanym API… ech…

Architektura OpenStack Havana :) (tak, stare)

Jak to działa z dinemic

Wyobraź sobie następujący scenariusz z Git’a (chociaż dinemic nie ma z nim nic wspólnego). Każdy developer tworzy swoje zmiany we własnych gałęziach. Czasami te zmiany zachodzą na siebie tworząc konflikty, a czasami po prostu konieczne jest zmergowanie dwóch gałęzi w jedną tak, aby połączyć nowe fragmenty kodu z gałęzią stable. Wszystkie takie zmiany są uporządkowane w logiczny ciąg lub nawet graf określający ich kolejność.

Co się dzieje gdy dwóch developerów pisze w osobnych kopiach repozytorium? Zwykle nic. I jest to bardzo częste gdy wiele osób pracuje na własnych komputerach. Po połączeniu się z repozytorium ich zmiany są nakładane na siebie, a w przypadku konfliktów każdy z nich rozwiązuje je po swojemu.

Teraz wyobraź sobie bardzo podobny scenariusz, tylko zamiast programistów mamy obiekty klas w C++, których stan zmienia się co jakiś czas. Każda taka zmiana to nowa aktualizacja wpięta w łańcuch lub graf takich aktualizacji, podobnie jak commit w Git. Każda z tych zmian jest też na bieżąco rozsyłana po sieci klastra, w którym działają aplikacje oparte o framework dinemic. W Gicie programiści są identyfikowani kluczami SSH i mogą zmieniać dowolne gałęzie. W framerowku dinemic każdy obiekt klasy podczas jego tworzenia ma generowany zestaw kluczy kryptograficznych, którymi podpisuje się pod swoimi zmianami. Może to robić tylko sam w sobie lub w obiektach, które dodały jego publiczny klucz do listy autoryzowanych obiektów.

Oprócz tego wszystkie te zmiany są porządkowane w formie łańcuchów umożliwiających odtworzenie stanu klastra z dowolnego momentu i ewentualne połączenie (merge) po awarii klastra.

Bezpieczeństwo i uprawnienia

Każdy obiekt, jaki jest tworzony przez klasy dziedziczące po DModel automatycznie generuje i zapisuje parę kluczy kryptograficznych na hoście, na którym został utworzony. Za pomocą tych kluczy będą podpisane cyfrowo wszelkie zmiany w tym obiekcie, począwszy od informacji o jego stworzeniu, przez zmiany dowolnych pól aż po żądanie skasowania z wszystkich replik w klastrze. Sekretny, prywatny klucz jest tworzony tylko tam, gdzie został stworzony obiekt. Publiczna część klucza jest rozsyłana po całym klastrze wraz z informacją, że obiekt został utworzony w rozproszonej bazie. Na publicznej części klucza opierany też jest ID obiektu, tak więc nie ma możliwości (inaczej – jest to bardzo trudne) podrobienia obiektu o tym samym ID. Jeśli ktoś chciałby to zrobić musiałby złamać algorytmy, na których opiera się znaczna część komunikacji w Internecie.

#include <libdinemic/dmodel.h>;

class MyClass : public DModel
{
 void update_network();
public:
 /// Create new object
 MyClass(StoreInterface *store,
 SyncInterface *sync,
 const std::vector<std::string> &authorized_object_ids);
 /// Restore existing object
 MyClass(const std::string &db_id, StoreInterface *store, SyncInterface *sync, DModel *parent=NULL, DModel *caller=NULL);
 /// Create as child object
 MyClass(DModel *parent);

 ~MyClass();

 DField important_property_a;
 DField important_property_b;
 DList list_of_something;
 ...
};

W dowolnym miejscu w klastrze, a dokładniej w dowolnej jego aplikacji korzystającej z libdinemic można odtworzyć obiekt, który znajduje się w bazie danych i korzystać z niego

Ok, ale co po tym, że obiekt można zmienić tylko na hoście, gdzie został stworzony? Dinemic służy do budowania aplikacji, które będą działały na wielu hostach. Koniecznym zatem jest, aby inne hosty w sieci też mogły mieć możliwość odtworzenia takich samych obiektów oraz ich modyfikacji. Pierwsza kwestia jest dość naturalna – tworząc obiekt klasy w jednej aplikacji, nie pojawi się on automatycznie w żadnym innym miejscu. Dopiero chcąc wykorzystać jego dane lub dokonać zmian w tym obiekcie musimy sami, w kodzie aplikacji stworzyć taki obiekt (czyli de facto zmienną tego typu). Dinemic zatroszczy się o to, aby jego stan był zgodny ze stanem na innych nodach klastra:

MyClass my_object("here_comes_long_id", store, sync);
my_object.important_property_a = "abcd";

W dowolnym miejscu klastra możemy stworzyć zmienną, która zostanie odwzorowana przez ORM Dinemic w obiekt o podanym ID

Co do drugiej kwestii, czyli modyfikacji obiektów (również powyższy przykład), to Dinemic daje pełną elastyczność co do definiowania co kto może i jak to może. Po pierwsze przypomnijmy – wszystkie informacje na temat zmian obiektów są zawsze dokonywane przez kogoś. Jeśli nie definiujemy tego, to są one anonimowe, czyli bez podpisu. W przeciwnym wypadku będą one podpisane kluczem prywatnym obiektu autoryzowanego do dokonania zmian lub podpisane kluczem prywatnym innego, nieautoryzowanego obiektu. Listę takich obiektów można zdefiniować już w trakcie tworzenia pierwszej instancji obiektu w klastrze, przez parametr authorized_object_ids. Wszystkie zmiany dokonywane przez wymienione tam obiekty będą traktowane tak samo jakby były dokonywane przez ten sam obiekt.

Weźmy na przykład aplikację, która ma być rozproszonym kalendarzem. Każda osoba (obiekt klasy Person) ma listę swoich wydarzeń (obiekty klasy Event). Tworząc nowe wydarzenie możemy podać ID innych osób, które mają mieć możliwość zmian np. terminu. W ten sposób przypiszemy do naszego kalendarza nasze nowe wydarzenie. Nikt poza naszymi dwoma znajomymi nie będzie mógł zmienić tej daty:

class Person : DModel {
 ...
 DField first_name;
};

class Event : DModel {
 ...
 DField person_id;
 DField event_date;
 DField event_name;
};

// Map object related to my calendar to new object in code
Person me("my_id...", store, sync);

// Map John to another object
Person john("jobhn's_id...", store, sync)
...

// Create new event in database
vector<string> authorized_objects;
authorized_objects.push_back(me.get_db_id());
authorized_objects.push_back(john.get_db_id());
...
Event new_event(store, sync, authorized_objects);

W ten sposób John będzie mógł stworzyć taki sam obiekt wydarzenia i wszelkie jego zmiany w tym obiekcie będą traktowane na równi z naszymi:

Event received_event("event_id", store, sync);
received_event.event_date = "Tomorrow!";

Powyższa zmiana, wykonana już w aplikacji John’a jest automatycznie propagowana w całym klastrze i po chwili będzie również widoczna w naszym kalendarzu.

Nieautoryzowane i anonimowe zmiany

To nie wszystko. Dinemic pozwala zaaplikować dowolny zestaw listenerów, które będą automatycznie odfiltrowywać niepodpisane lub nieautoryzowane zmiany. Dzięki listenerom możemy również nasłuchiwać zmian, jakie są wykonywane w klastrze przez innych uczestników.

Poufne dane

Kolejną rzeczą, którą dostaje się gratis jest możliwość szyfrowania danych. Ponieważ dinemic bazuje na otwartej architekturze i domyślnie pozwala akceptować wszystkie zmiany z sieci, programista tworzący w nim aplikacje ma możliwość wykorzystania istniejących kluczy kryptograficznych i zaszyfrowania poszczególnych pól w klasach. Dzięki temu tylko autoryzowane do odczytu obiekty będą miały możliwość odszyfrowania danych zapisanych w bazie i mapowanych przez framework na obiekty C++. Z punktu widzenia programisty wystarczy jedynie zmodyfikować klasę DField lub DList, ustawiając w jej konstruktorze parametr encrypted=true. Wszystkie pola z tą flagą są automatycznie szyfrowane przed wysłaniem do sieci za pomocą kluczy zapisanych w liście read_authorized_keys.

Jakie są największe różnice w stosunku do centraljen bazy danych?

Przede wszystkim Dinemic został stworzony aby zapewnić możliwie wysoką konsystencję danych i stanu klastra w przypadku awarii. Aplikacje w architekturach, które za pomocą logiki dokonują zmian w centralnej bazie danych nie są odporne na awarie sieci. Po dłuższym odcięciu od bazy realny stan klastra może się mocno różnić z zapisanymi w bazie danymi.

Dinemic postawił ten problem na pierwszym miejscu, przez co dowolne rozcięcie klastra, przez tzw. split brain nie powoduje rozjechania się stanu klastra i bazy danych. Po split brain’ie tworzą się de facto dwa oddzielne klastry Dinemic, które zaczynają żyć własnym życiem. Każdy z nich bazuje na ostatniej wersji bazy sprzed split-brain’a i modyfikuje tą bazę według własnego uznania. Po rejoin’ie, czyli po ponownym połączeniu dwóch części, wszystkie nody zaczynają się wymieniać brakującymi im aktualizacjami stanu.

W tym punkcje architektura Dinemic zaczyna się znacznie różnić od zwykłej, z centralją bazą danych lub od Blockchain’a. Po rejoin’ie może nie być możliwe doprowadzenie do konsystencji w takim klastrze za równo na warstwie bazy danych (co zostało przeniesione na barki programisty piszącego aplikacje korzystającą z tego frameworka) jak i na płaszczyźnie konfiguracji i stanu samego klastra. Zamiast tego otrzymujemy węzły klastra, które w miarę możliwości starają się doprowadzić do jednolitego stanu, jednak bez takiej gwarancji.

Dlaczego tak się dzieje? Popatrzmy na przykład na powyższą aplikację kalendarza. Co jeśli dwie osoby będące w danej chwili offline wprowadziły w swoich kalendarzach dwie sprzeczne zmiany dotyczące tego samego eventu? John przestawił godzinę na 11 rano, a my ustawiliśmy na 8 rano? Trudno podjąć decyzję, która wersja ma być prawidłowa i ostateczna. Co więcej, odrzucenie jednej, tak jak np. w blockchain’ie Bitcoin’a może doprowadzić do tego, że wydarzenie przesunięte przez Johna na 11 będzie kolidowało nam, ponieważ utworzyliśmy już o tej godzinie inne. Decyzja co w takim przypadku zrobić pozostaje już tylko nam (i John’owi). Z najbardziej oczywistych rozwiązań pozostaje nam odrzucenie obu zmian i zaproponowanie nowego czasu, np. przez wyświetlenie odpowiedniego komunikatu. Nie ma tu jednak sposobu na realne zsynchronizowanie planów dnia tych dwóch osób.

W przypadku tej samej sytuacji w aplikacji z centralną bazą danych, prawdopodobnie jedna z aktualizacji nie doszłaby do skutku, na przykład przez brak łączności lub zostałaby nadpisana przez drugą zmianę.

Z tego powodu framework Dinemic jedynie dąży do zsynchronizowania stanu obiektów w bazach poszczególnych węzłów klastra, jednak nie wymusza tego sztucznie i nie gwarantuje konsystencji. W zamian za to dostarcza pełen wgląd w historię zmian jakie odbywały się od początku istnienia takich obiektów i daje możliwość podejmowania dziań w zależności od kolejności zdarzeń.

Gdzie szukać dalej?

Dokładna instrukcja instalacji oraz dokumentacja frameworka jest dostępna pod adresem: https://dinemic.io

Thank you AWS Free Tier!

maciej — Sun, 04 Nov 2018 12:21:16 +0000

W tym poście kilka gorzkich żali na temat (prawie) darmowego okresu na chmurze Amazona, po korzystaniu z niego przez trzy miesiące. Polecam dla tych, którzy zastanawiają się czy warto oszczędzić na zasobach i skorzystać z darmowego okresu.

Super oferta

Amazon, podobnie jak Google Cloud ma w swojej ofercie całą masę usług. Od podstawowej wirtualnej maszyny, przez dodatkowe dyski, transfery, sieci aż po kontenery i sztuczną inteligencję. Jest w czym wybierać, zwłaszcza gdy zaczynamy. W Google wygląda to równie imponująco. Do tego dochodzi nam jeszcze gratis $300 na start do wykorzystania przez rok… No jest w czym wybierać :)

Przeliczając na złotówki to ponad 1000zł lub ok. 100zł miesięcznie, w zależności od kursu PLN/USD. Co można za to kupić? Między innymi pojedynczą instancję AWS EC2 t1.micro, na której da się postawić prosty serwer www lub inną usługę. Nie ma ona zbyt wiele zasobów, ale zawsze to coś (1GB ram, 8GB dysku i 1vCPU współdzielone z innymi). Przez rok nie musimy się martwić o portfel, sporo kasy zostaje w kieszeni, ale…

Co po roku? Korzystając z tej samej oferty będziesz musiał prawdopodobnie wyłożyć ten tysiąć zł aby utrzymać te same zasoby co wcześniej. Patrząc na inne oferty usługodawców, można odnieść wrażenie, że AWS w cale taki tani się nie okazuje. Nieco większa wirtualna maszyna (VPS) w OVH kosztuje całe… 10zł netto miesięcznie. Za zaoszczędzone 1000zł trzeba liczyć się z koniecznością przemigrowania do tańszego usługodawcy po roku lub zwrócić z nawiązką to, co dostało się na początku.

Porównując koszty kolejnego roku zostania w chmurze lub przejścia do innego hostingu – 1000zł vs 120zł. Na jednym i na drugim mamy szanse wpaść na serwer upychany z takich tanich wirtualnych maszyn, gdzie nie ma też gwarancji osiągnięcia pełnej wydajności.

A jeśli o wydajności mowa

Free tier w rejonie, z którego korzystałem oferował bardzo marną wydajność sieci. Docelowo używałem go tylko i wyłącznie jako reverse proxy do usługi, która stoi za VPN, ale samo przejście przez wirtualną maszynę w AWS spowalniało znacznie ruch. Natomiast same transfery z i do VM wahały się na poziomach ok. 2MB/s, ale czegóż chcieć od darmowej usługi. Przykładowo dzisiejsze niedzielne przedpołudnie, czyli okres, w którym raczej nie spodziewałbym się dużego ruchu w sieci, zwłaszcza gdy USA jeszcze śpi dawało transfer na poziomie 1,2MB/s:

Jeśli natomiast chciałbym przenieść swoje zasoby gdzieś indziej, w lepszy rejon, to prawdopodobnie wiązało by się to ze zwiększeniem kosztów, również przez postawienie lepszej instancji, o lepszych parametrach.

Nie takie darmowe

Ten, kto myśli, że koszt samej wirtualki to wszystko, ten się myli. W AWS bardzo łatwo wyklikać swoje zasoby, dokładając spore gigabajty, lepsze sieci itd. Free tier momentami ogranicza je i mówi, że nie można postawić np. lepszej instancji w ramach darmowego $300. Gdy jednak przekroczymy pewne granice, darmowy AWS staje się płatnym AWSem.

To właśnie skłoniło mnie do przeniesienia się na płatne (ale dużo mniej) OVH i porzucenia publicznych chmur na długi czas. Przez ostatni miesiąc transfer z serwisu, który hostuje duże pliki przekroczyło kilkaset GB. Nigdy nie było z tym problemu podczas korzystania z OVH, jednak w AWS kwalifikuje się to do obciążenia użytkownika dodatkowymi kosztami. Kosztami, które nie będą niestety pokryte z darmowego $300, a z jego karty. Tak oto za ponad 40zł Amazon dokupił mi dodatkowe 10TB transferu na ostatnie kilka dni października. Jedyny plus jaki mogę się tu doszukać, to że poinformowali mnie o tym (czego Google nie robiło dopinając dysk, który zjadł większość darmowego bonu).

Cóż, nie dość, że transfer w AWS jest marny, to jeszcze jest go mało i dość drogi. Z jednej strony warto przeczytać cenniki i niedopatrzenie jest tylko i wyłącznie moją winą, natomiast z drugiej – jeśli ktoś planuje hostować w Free Tier nieco więcej danych, to warto pomyśleć czy mu się to opłaci. Za jeden “darmowy” miesiąc można zapłacić tu więcej niż za kilka miesięcy płatnych u innych usługodawców.

Jak to wygląda gdzie indziej?

O Google Cloud już wspominałem – podobnie jak w AWS płaci się za wszystko, jednak darmowa kasa pokrywa wszystko na bieżąco, a nie jest rozłożona w 12 ratek i pokrywa tylko części usług.

Po drugiej stronie stoi OVH, z którego korzystam od dawna bez większych problemów. Można u nich kupić serwery dedykowane z oferty Kimsufi lub VPS w chmurze. Jak na razie jedno i drugie wychodzi dużo taniej i wydajniej niż to, co za poprzednie miesiące zaoferował AWS w “darmowym” pakiecie.

To, o czym warto pamiętać to porządne zautomatyzowanie swoich usług, aby przejście z jednego usługodawcy do drugiego nie okazało się niewykonalnym krokiem.

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ść.

Wirtualka w 7 sekund – jak skonfigurować macierz z SheepDog

maciej — Fri, 03 Nov 2017 08:15:17 +0000

Podczas sprawdzania działania CoreCluster z Debianem Stretch przetestowałem też macierz software’ową, opartą o Sheepdog, zamiast tradycyjnego udziału opartego o NFS + lokalne dyski. Wynik – niecałe 7 sekund od kliknięcia w interfejsie do otrzymania wirtualnej maszyny w stanie stopped.

Jak to działało do tej pory?

Domyślnie CoreCluster konfiguruje się w najprostszej konfiguracji do używania zasobu NFS. W panelu administratora podajemy IP i katalog z macierzy (lub jakiegokolwiek serwera) i wszystko się montuje automatycznie. Dyski bazowe dla wirtualek są kopiowane podczas tworzenia ich na lokalne dyski nodów (do lokalnego libvirt pool images). Wydajność poszczególnych wirtualek zależy wtedy głównie od wydajności lokalnego dysku i jego obciążenia przez inne wirtualki.

Czas dostarczenia zatrzymanej wirtualnej maszyny jest więc zależny głównie od tego, co startujemy. Kilku gigabajtowy dysk kopiuje się do kilku minut, w zależności od naszego sprzętu i sieci.

Jak to działa z Sheepdog?

Zanim niektórzy zaczną krzyczeć dlaczego nie Ceph albo Gluster – sheepdog odpala się prawie bezboleśnie dla administratora (o czym później) i nie ma absolutnie żadnego centralnego punktu klastra, co czasem może być plusem.

Jak więc to działa? Sheepdog po doinstalowaniu korzysta z Corosync zintegrowanego z CoreCluster do znalezienia innych węzłów w sieci. Od strony użytkownika pozwala on tworzyć dyski (odpowiednik block storage), które możemy wykorzystać m.in. w wirtualnych maszynach. Dzięki jego architekturze, każdy węzeł obsługujący Sheepdog’a ma taki sam dostęp do obiektów zapisanych na macierzy, niezależnie od położenia w sieci.

Podczas tworzenia klastra możemy podać w ilu miejscach na raz będą trzymane dane. Tak – w RAID możesz to zrobić wybierając odpowiednią konfigurację (RAID1, 5 itd.). W sheepdog podajesz po prostu ile kopii każdego dysku ma mieć Twój klaster:

dog cluster format --copies 3

Niezależnie od Twoich dysków o sprzętu, jeśli tylko ilość węzłów sheepdog’a pozwoli, będziesz on starał się tak rozłożyć dane, aby każdy fragment każdego dysku był zapisany w trzech różnych lokalizacjach. Oczywiście ma to wpływ na pojemność klastra.

CoreCluster, po dodaniu macierzy z transportem sheepdog wykorzystuje ją jako pojemnik na wszystkie swoje dyski. Obrazy użytkowników chmury są zapisywane oczywiście przez sheepdog, natomiast w odróżniniu od NFS, lokalne pule obrazów na nodach (te, w których są trzymane wirtualne maszyny, w /images) nie są wykorzystane. Zamiast tego CoreCluster zapisuje te obrazy również jako obrazy w sheepdog, pod trochę inną nazwą.

Plusem takiego rozwiązania jest to, że każdy dysk wirtualnej maszyny jest klonem swojego bazowego obrazu. Dzięki temu tworzenie wirtualnej maszyny trwa sekundy zamiast minut. Nie jest konieczne kopiowanie obrazów pomiędzy libvirt’owymi pulami podczas bootu. Dodatkowo Sheepdog nieco przyspiesza sam dostęp do danych – jeśli obraz ma więcej niż jedną kopię w sheepdog, to sam odczyt jest wtedy nieco szybszy w porównaniu do NFS i lokalnych obrazów.

Instalacja i konfiguracja macierzy

Management CoreCluster potrzebuje jednego dodatkowego pakietu – corecluster-storage-sheepdog. Zainstaluj go poleceniem:

apt-get install corecluster-storage-sheepdog

Doinstaluje on wszystkie zależności. Następnie na każdym Compute Node doinstaluj sam pakiet sheepdog:

apt-get install sheepdog

Następnie sprawdź, czy w plikach /etc/default/corosync oraz /etc/default/sheepdog oba demony są uruchamiane (parametr START=yes). Możesz też sprawdzić, czy są w uruchomionych procesach:

ps uax | grep corosync
...
ps uax | grep sheep

Sprawdź też, czy corosync jest poprawnie zainstalowany i skonfigurowany. Powinieneś widzieć wszystkie Compute Nody oraz Management:

corosync-cmapctl | grep member

runtime.totem.pg.mrp.srp.members.167772417.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772417.ip (str) = r(0) ip(10.0.1.1)
runtime.totem.pg.mrp.srp.members.167772417.join_count (u32) = 2
runtime.totem.pg.mrp.srp.members.167772417.status (str) = joined
runtime.totem.pg.mrp.srp.members.167772418.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772418.ip (str) = r(0) ip(10.0.1.2)
runtime.totem.pg.mrp.srp.members.167772418.join_count (u32) = 2
runtime.totem.pg.mrp.srp.members.167772418.status (str) = joined
runtime.totem.pg.mrp.srp.members.167772419.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772419.ip (str) = r(0) ip(10.0.1.3)
runtime.totem.pg.mrp.srp.members.167772419.join_count (u32) = 2
runtime.totem.pg.mrp.srp.members.167772419.status (str) = joined
runtime.totem.pg.mrp.srp.members.167772670.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772670.ip (str) = r(0) ip(10.0.1.254)
runtime.totem.pg.mrp.srp.members.167772670.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.167772670.status (str) = joined

Jeśli wszystko działa, to Twój klaster sheepdog powinien być gotowy do użycia. Sformatuj go poleceniem:

dog cluster format --copies 2

Możesz oczywiście zmienić ilość kopii jeśli potrzebujesz. Następnie dodaj taką macierz do CoreCluster, w panelu administratora z następującymi parametrami:

directory /var/lib/sheepdog (jest pomijane) przez sterownik
address 127.0.0.1 (każdy node będzie miał swój własny punkt dostępu)
transport sheepdog (najważniejszy parametr)

Oraz capacity według Twojego uznania.

To, czy sheepdog działa możesz sprawdzić kilkoma poleceniami:

dog node list

 Id Host:Port V-Nodes Zone
 0 10.0.1.1:7000 	129 16842762
 1 10.0.1.2:7000 	129 33619978
 2 10.0.1.3:7000 	129 50397194
 3 10.0.1.254:7000 	126 4261478410

Powinien wyświetlić listę wszystkich nodów oraz management

dog vdi create test 10M
dog vdi list

 Name Id Size Used Shared Creation time VDI id Copies Tag
 test 0 10 MB 0.0 MB 0.0 MB 2017-11-03 09:17 7c2b26 2

Powinno utworzyć nowy dysk o rozmiarze 10M. Dysk ten powinien być widoczny z wszystkich nodów w klastrze oraz managementu.

Pozostało jeszcze ustawić sterownik w konfiguracji CoreCluster management i zrestartować wszystko. Znajdź listę APPS w pliku /etc/corecluster/config.py i zamień wpis:

 'corecluster-storage-libvirt.app',

na:

 'corecluster-storage-sheepdog.app',

Finalnie lista APPS powinna wyglądać mniej więcej tak:

APPS = [
 'corecluster.app',
 'corecluster-auth-db.app',
 'corecluster-algorithm-storage-default.app',
 'corecluster-algorithm-node-fillup.app',
 'corecluster-algorithm-id-uuid.app',
 'corecluster-storage-sheepdog.app',
 'corenetwork.app',
 'coretalk.app',
]

Na koniec restartujemy procesy agentów corecluster:

service corecluster restart

Przy pomyślnym układzie gwiazd i sprzyjającej koniunkcji Jowisza z Neptunem po restarcie macierz zamontuje się i będziesz mógł cieszyć się jej wydajnością.

Problemy?

Większość problemów jest związana z konfiguracją sieci na nodach lub management (plik pakietu CoreNetwork – /etc/corenetwork/config.py), która ma wpływ na konfigurację Corosync. Jeśli to działa poprawnie i corosync-cmapctl poprawnie listuje wszystkie węzły, to powinieneś bez problemu uruchomić całość.

ps. co się składa na wspomniane 7 sekund?

Task – ładowanie dysku
Task – zdefiniowanie wirtualnej maszyny
Task – podłączenie karty sieciowej
Odświeżanie listy wirtualnych maszyn co sekundę – max. 1s

Plus mały, pomijalny lag przeglądarki i komunikacji z nodami.