Osiąganie prawdziwej izolacji wielodostępnej w Dockerze

Podsumowanie

Kontenery Docker współdzielą jądro hosta, co może być problemem bezpieczeństwa w środowiskach wielodostępnych, gdzie dzierżawcy mogą sobie nie ufać. Ten artykuł wyjaśnia luki w izolacji w domyślnych konfiguracjach Docker i przedstawia konkretne kroki wzmacniające izolację przy użyciu przestrzeni nazw Linuksa, cgroups, przestrzeni nazw użytkowników, seccomp, AppArmor i wirtualizacji sprzętowej. Dowiesz się, jak skonfigurować demony Docker dla poszczególnych dzierżawców, używać narzędzi sandboxingowych jak gVisor lub Firecracker dla silniejszej izolacji oraz orkiestrować z Kubernetes dla wielodostępności. Omówimy również wybór odpowiedniego dostawcy infrastruktury oferującego wirtualizację KVM dla dodatkowej warstwy separacji. Na koniec będziesz miał plan uruchamiania bezpiecznych obciążeń wielodostępnych z Docker.

Podczas hostowania wielu dzierżawców na jednym hoście Docker, domyślna izolacja kontenerów – oparta na przestrzeniach nazw Linuksa i cgroups – często nie wystarcza. Ucieczka z kontenera jednego dzierżawcy może zagrozić całemu hostowi i wszystkim innym kontenerom. Ten problem jest szczególnie dotkliwy w hostingach współdzielonych, platformach SaaS lub w każdym scenariuszu, gdzie niezaufany kod działa obok twojego. Dobra wiadomość: możesz nałożyć wiele technik izolacji, aby zbudować wzmocnione środowisko wielodostępne. Ten przewodnik przeprowadzi przez sześć praktycznych kroków, od łatwych do wdrożenia, jak przestrzenie nazw użytkowników, po zaawansowane, jak uruchomienia w sandboksie i wybory infrastruktury.

Zrozumienie domyślnej izolacji Docker

Docker używa przestrzeni nazw Linuksa do izolacji procesów, sieci, systemu plików i innych zasobów. Cgroups ograniczają CPU, pamięć i I/O. Ale te wszystkie współdzielą jedno jądro – podatność w jądrze może wpłynąć na wszystkie kontenery. Dla prawdziwej wielodostępności, zwłaszcza z niezaufanymi dzierżawcami, potrzebujesz obrony w głąb. Jak omówiono w Projektowaniu wielodostępnej architektury Docker: wybór odpowiedniego poziomu izolacji, poziomy izolacji wahają się od słabego (tylko przestrzenie nazw) do silnego (wirtualizacja sprzętowa). Zacznijmy od najsłabszego.

Krok 1: Włącz przestrzenie nazw użytkowników

Domyślnie root wewnątrz kontenera mapuje się na root na hoście. Ucieczka z kontenera daje pełny dostęp do hosta. Przestrzenie nazw użytkowników mapują root kontenera na nieuprzywilejowanego użytkownika na zewnątrz. Włącz globalnie za pomocą dockerd --userns-remap=default lub dla poszczególnych kontenerów przez --userns=host. Ten prosty krok eliminuje wiele ataków eskalacji uprawnień. Przetestuj swoje aplikacje: niektóre wymagające uprawnień hosta (np. montowanie systemów plików) mogą się zepsuć. Dla stron Drupal lub WordPress jest to zazwyczaj bezpieczne.

Krok 2: Zastosuj profile Seccomp i AppArmor

Seccomp ogranicza wywołania systemowe, które może wykonać kontener. Docker dostarcza domyślny profil seccomp blokujący niebezpieczne wywołania systemowe, takie jak mount i reboot. Dla wielodostępności zaostrz go – zablokuj rzadkie wywołania systemowe używane przez narzędzia do ucieczki. Podobnie AppArmor może ograniczać procesy kontenera. Stwórz własny profil AppArmor, który odmawia zapisu do interfejsów jądra i ogranicza ścieżki plików. Obie funkcje ustawia się za pomocą flag --security-opt. Połącz je dla warstwowej obrony.

Krok 3: Użyj demonów Docker dla poszczególnych dzierżawców

Uruchamianie pojedynczego demona Docker dla wszystkich dzierżawców jest ryzykowne – każda ucieczka z kontenera może uzyskać dostęp do gniazda demona. Izoluj demony dla każdego dzierżawcy za pomocą Docker-in-Docker (DinD) lub zdalnych punktów końcowych demona. Na przykład uruchom demona Docker wewnątrz kontenera z --privileged (ale to osłabia izolację). Lepsze podejście: uruchom oddzielne demony na oddzielnych maszynach wirtualnych lub użyj eksperymentalnej funkcji Docker --group z przestrzeniami nazw użytkowników. Dla orkiestracji izolacja oparta na przestrzeniach nazw Kubernetes jest bardziej praktyczna, jak omówiono w Obronie przed ucieczką z kontenera: praktyczny przewodnik po izolacji Docker dla hostingu wielodostępnego.

Krok 4: Rozważ uruchomienia w sandboksie

Gdy samo jądro Linuksa jest nieufne, użyj uruchomienia w sandboksie, które dodaje lekką warstwę maszyny wirtualnej. gVisor (runsc) przechwytuje wywołania systemowe i implementuje własne jądro, podczas gdy Firecracker używa mikro-Maszyn wirtualnych z wirtualizacją sprzętową. Oba integrują się z Docker przez uruchomienia containerd. Na przykład dodaj "runtimes": {"runsc": {}} do konfiguracji demona Docker i uruchamiaj kontenery z --runtime=runsc. Narzut wydajności wynosi 5–15%, ale izolacja jest znacznie silniejsza. Idealnie nadaje się do konfiguracji wielodostępnych o wysokim bezpieczeństwie.

Krok 5: Orkiestruj z Kubernetes i politykami bezpieczeństwa

Kubernetes zapewnia natywną wielodostępność przez przestrzenie nazw, standardy bezpieczeństwa podów (Pod Security Standards) i polityki sieciowe (NetworkPolicies). Zdefiniuj przestrzenie nazw dla każdego dzierżawcy z przydziałami zasobów i wymuszaj ograniczone konteksty bezpieczeństwa podów (usuń wszystkie możliwości, tylko do odczytu system plików root). Kontrolery przyjęcia (admission controllers) jak OPA/Gatekeeper mogą blokować błędne konfiguracje. Jeśli zarządzasz wieloma dzierżawcami, Kubernetes automatyzuje egzekwowanie izolacji. Dla orkiestracji na skalę produkcyjną, odsyłamy do Poza Docker Compose: orkiestracja gotowych do produkcji konteneryzowanych aplikacji.

Krok 6: Wybierz odpowiedniego dostawcę hostingu

Hiperwizor twojego dostawcy infrastruktury ma znaczenie. Docker na hostingu współdzielonym (OpenVZ) zapewnia słabą izolację – jeden dzierżawca może widzieć procesy innych. Preferuj dostawców używających KVM lub VMware, które oferują separację na poziomie sprzętu. Dostawcy tacy jak DigitalOcean, Kamatera lub AWS oferują VPS oparte na KVM z dedykowanymi zasobami. Dla bare-metal upewnij się, że wirtualizacja na poziomie BIOS jest włączona dla zagnieżdżonych kontenerów. Dostawca izolujący dzierżawców na warstwie hiperwizora uzupełnia izolację kontenerów. Jak szczegółowo opisano w Opanowaniu izolacji Docker dla bezpiecznego i wydajnego hostingu internetowego, system operacyjny hosta również powinien być wzmocniony o minimalną powierzchnię ataku.

Zastrzeżenia i kompromisy

Każda dodatkowa warstwa dodaje złożoności i kosztów wydajności. Przestrzenie nazw użytkowników mogą zepsuć woluminy montowane na hoście. Profile seccomp wymagają dostrojenia dla każdej aplikacji. Uruchomienia w sandboksie jak gVisor nie obsługują wszystkich wywołań systemowych – twoja aplikacja może nie działać. Demony Docker dla każdego dzierżawcy zwiększają narzut pamięci. Wybierz poziom izolacji odpowiadający twojemu modelowi zagrożeń: dla zaufanych dzierżawców domyślne przestrzenie nazw mogą wystarczyć; dla publicznego SaaS zainwestuj w uruchomienia w sandboksie i polityki Kubernetes. Przetestuj dokładnie przed wdrożeniem produkcyjnym.

Podsumowanie

Prawdziwa izolacja wielodostępna w Docker jest osiągalna poprzez nakładanie wielu funkcji jądra, uruchomień w sandboksie i kontroli orkiestracji. Zacznij od przestrzeni nazw użytkowników i seccomp, a następnie przejdź do demonów dla poszczególnych dzierżawców lub uruchomień w sandboksie. Dla dużych skal Kubernetes zapewnia izolację sterowaną politykami. Zawsze łącz z oddzielonym na poziomie hiperwizora hostem od renomowanego dostawcy. Żadna pojedyncza technika nie jest nieprzenikniona, ale ich połączenie tworzy solidną obronę. Twoi dzierżawcy będą ci wdzięczni – i tak samo twój audyt bezpieczeństwa.