Granice bezpieczeństwa Dockera i LXC w przypadku uprzywilejowanych usług domowych

Docker jest bezpieczniejszym wyborem domyślnym, gdy uprzywilejowana usługa domowa może pozostać jedną zadeklarowaną aplikacją z wąsko określonymi montowaniami. LXC jest prostsze, gdy usługa naprawdę potrzebuje niewielkiego systemu Linux, ale żadne z tych rozwiązań nie tworzy oddzielnej granicy jądra.

Decydujące nie jest to, która nazwa brzmi bardziej izolująco. Oba rozwiązania opierają się na izolacji w jądrze hosta. Porównaj faktycznie przyznane uprawnienia, udostępnione urządzenia i pliki, jednostkę, którą aktualizujesz i przywracasz, oraz konsekwencje ucieczki z izolacji. Jeśli ryzyko związane ze współdzielonym jądrem jest nieakceptowalne, przestań porównywać Docker i LXC, a zamiast tego użyj maszyny wirtualnej lub osobnego hosta.

Zaakceptuj granice współdzielonego jądra, zanim porównasz funkcje

Docker zwykle pakuje aplikację i jej zależności; LXC udostępnia pełniejsze środowisko użytkownika Linux z systemem init, kontami, pakietami i usługami systemowymi. Ta różnica w działaniu nie zapewnia LXC niezależnego jądra gościa.

Badania nad mechanizmami izolacji kontenerów w systemie Linux opisują mechanizmy przestrzeni nazw i polityk jako zestaw łatek, których działanie może być trudne do skontrolowania. To ograniczenie izolacji przy współdzielonym jądrze dotyczy obu rozwiązań i wyklucza wybór któregokolwiek z nich, gdy oddzielenie jąder jest niezbędne.

Rozważaj oba rozwiązania tylko w przypadku zaufanych lub ograniczonych obciążeń. Przenieś kod dostępny z internetu, nieznane obrazy lub automatyzację o poważnych konsekwencjach do maszyny wirtualnej, jeśli naruszenie nie może bezpośrednio zagrozić jądru hosta.

Dostosuj domyślny wybór do wymaganych uprawnień

Docker nadal jest atrakcyjny, gdy usługa potrzebuje kilku jawnie określonych uprawnień, konfiguracji tylko do odczytu i jednej lub dwóch trwałych ścieżek. Definicja Compose może sprawić, że te wyjątki będą widoczne podczas przeglądu.

LXC sprawdza się w przypadku usług, które oczekują konwencjonalnego systemu Linux, kilku demonów, menedżera pakietów lub stabilnej łączności sieciowej na poziomie systemu. LXC bez uprawnień administratora zachowuje użyteczne mapowanie UID, ale tryb uprzywilejowany, zagnieżdżanie i szerokie montowania bind osłabiają tę przewagę.

Zlicz wyjątki zamiast zaznaczać pole „uprzywilejowany”. Jeśli którykolwiek wariant wymaga sieci hosta, gniazda do zarządzania kontenerami, zapisywalnych montowań systemowych, dostępu do wszystkich urządzeń lub profilu bez ograniczeń, przeprojektuj ścieżkę dostępu albo zrezygnuj z warstwy współdzielącej jądro.

Dostęp do urządzeń i pamięci masowej określa zasięg skutków naruszenia

Koordynator USB, węzeł renderujący GPU, interfejs UPS lub katalog z multimediami należy udostępniać w możliwie najwęższym zakresie, na jaki pozwala usługa. Stabilne ścieżki urządzeń, montowania tylko do odczytu oraz jawnie określona własność UID/GID to zarówno mechanizmy ograniczające skutki awarii, jak i wygodne ustawienia.

Niedawna relacja z wdrożenia Proxmox pokazuje, że nieuprzywilejowane LXC może izolować usługi oparte na Docker w osobnych jednostkach przywracania, a jednocześnie współdzielić jądro hosta i stos pamięci masowej. Ten wzorzec LXC o małym zasięgu skutków awarii jest przydatny tylko wtedy, gdy zagnieżdżanie i wyjątki dotyczące sterowników pamięci masowej są udokumentowane.

Wybierz Docker, gdy jedna aplikacja potrzebuje jednej niewielkiej granicy danych. Wybierz LXC, gdy kilka usług systemowych ma działać razem. Odrzuć każdy z tych układów, jeśli jedno przejęcie zapewnia zapis do kopii zapasowych, kontrolę nad hipernadzorcą lub dostęp do niezwiązanych z usługą danych rodzinnych.

Featured

ZimaBoard 2 - Miniaturowy serwer domowy dla wielkich pomysłów

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Porównaj jednostkę, którą aktualizujesz i przywracasz

Cofnięcie zmian w Docker zwykle oznacza przywrócenie poprzedniej wersji Compose i obrazu wraz ze spójnymi z danymi aplikacji danymi. Cofnięcie zmian w LXC może przywrócić całe środowisko użytkownika, co jest wygodne, ale może też przywrócić nieaktualne pakiety, dane logowania i ukryte ręczne zmiany.

Odtwórz każde rozwiązanie na tymczasowym hoście. W przypadku Docker przywróć definicje, sekrety i woluminy; w przypadku LXC odtwórz lub przywróć kontener i sprawdź stan pakietów, sieci, urządzeń i punktów montowania. Udany test przywracania jest mocniejszym dowodem niż niższe zużycie pamięci w spoczynku.

Szersza decyzja dotycząca ZimaSpace w kwestii granic usług VM, LXC i Docker to kolejny krok, gdy niezależne jądro nadal jest przedmiotem sporu.

Werdykt warunkowy: wybierz najwęższą granicę, która nadal ogranicza skutki awarii

Wybierz Docker dla jednej dobrze opakowanej, zaufanej aplikacji, której urządzenia, uprawnienia, sekrety i trwałe ścieżki można określić w sposób jawny i minimalny.

Wybierz LXC dla zaufanego środowiska usług Linuksa, które rzeczywiście korzysta na obecności init, pakietów, wielu demonów lub sieci na poziomie systemu, zachowując wszędzie, gdzie to możliwe, tryb nieuprzywilejowany.

Nie wybieraj żadnego z tych rozwiązań, gdy obciążenie wymaga szerokiej kontroli nad hostem, obsługuje niezaufane dane wejściowe o poważnych konsekwencjach lub musi przetrwać przejęcie jądra hosta. Wtedy maszyna wirtualna albo osobna maszyna nie są przerostem formy nad treścią - to brakująca granica bezpieczeństwa.