Możesz uruchamiać Docker w środowisku produkcyjnym przez miesiące bez widocznych problemów. Kontenery się uruchamiają, aplikacje odpowiadają, nic się nie psuje. Ale jeden otwarty port lub jedna błędnie skonfigurowana uprawnienie mogą stworzyć dziurę, którą atakujący nie musiał sobie zarabiać. Większość błędów bezpieczeństwa Docker nie wygląda na błędy dopóki coś się nie zepsuje.
Ten artykuł obejmuje specyficzne konfiguracje, które narażają środowiska kontenerowe na ryzyko, co każda z nich umożliwia atakującemu, i kończy się listą kontrolną, którą możesz uruchomić na swoim systemie dzisiaj.
Dlaczego bezpieczeństwo Docker jest trudniejsze niż się wydaje
Kontenery wydają się izolowane. Uruchamiasz jeden, uruchamia swoje własne miejsce procesów, a z jego wnętrza następny kontener nie istnieje. Uzyskujesz izolację, ale tylko częściową. Kontenery dzielą jądro hosta, co oznacza, że proces wewnątrz kontenera może, pod pewnymi warunkami, całkowicie dotrzeć do systemu hosta.
Docker jest domyślnie konfigurowany dla wygody developerów, a nie do hartowania produkcji. Dostęp root włączony. Wszystkie porty można powiązać ze wszystkimi interfejsami. Brak monitorowania w środowisku uruchomieniowym. Większość developerów akceptuje te ustawienia, wdrażają kontener i przechodzą dalej. To rozsądny sposób na początek, ale to nie jest gotowa postawa bezpieczeństwa.
Zgodnie z Raport Red Hat z 2024 roku o stanie bezpieczeństwa Kubernetes, 67% organizacji opóźniło lub spowolniło wdrażanie aplikacji z powodu obaw dotyczących bezpieczeństwa kontenerów lub Kubernetes. Tego tarcia zwykle nie powodują ataki. Pochodzi ono z zespołów odkrywających, że ich konfiguracje kontenerów wymagały hartowania, które nie zostały wbudowane.
Często widzimy kontenery uruchomione w produkcji z taką samą konfiguracją, jaką miały na lokalnym komputerze developa. Tu błędy bezpieczeństwa Docker zwykle się kumulują cicho, bez widocznych objawów dopóki coś nie zostanie sprawdzone lub nie zawiedzie.
Błędy, które powodują te luki, są specificzne, przewidywalne i na większość z nich można uniknąć, zaczynając od poziomu konfiguracji.
Typowe błędy konfiguracji Docker
Większość naruszeń w kontenerach nie zaczyna się od exploita zero-day. Zaczyna się od konfiguracji ustawionej w pierwszy dzień, bez większego myślenia o ekspozycji sieciowej lub zakresie uprawnień.
Domyślne ustawienia Docker są zbudowane do pracy. Różnica między funkcjonalnym a bezpiecznym jest tam, gdzie ryzyka bezpieczeństwa kontenerów Docker się kumulują, zwłaszcza w samo hostowanych wdrażaniach, które są wdrażane i nigdy już nie są zmieniane.
Często widujemy ten schemat: kontenery na serwerach z publicznym IP z powiązaniami portów, ustawieniami użytkownika i konfiguracjami sieciowymi dokładnie takimi, jakie były przy początkowym wdrażaniu.
Uruchamianie kontenerów jako root
Gdy uruchamiasz kontener Docker bez określenia użytkownika, działa jako root. To oznacza, że każdy proces wewnątrz kontenera, w tym twoja aplikacja, ma uprawnienia roota w przestrzeni nazw kontenera.
Root wewnątrz kontenera to nie to samo co root na hoście, ale separacja nie jest absolutna. Exploity eskalacji uprawnień skierowane na runtime, takie jak dobrze udokumentowany runc CVE-2019-5736 i podobne luki w runtimeach, często wymagają roota w procesie kontenera, aby się powieść.
Kontenery z użytkownikiem innym niż root eliminują wymóg roota, na którym zależą te exploity, znacznie zmniejszając powierzchnię ataku dla tej klasy podatności, choć nie eliminują całkowicie ryzyka ucieczki z kontenera.
Dodanie dyrektywy USER do twojego Dockerfile rozwiązuje ten problem. Niektóre oficjalne obrazy zawierają nieprivililegiwanego użytkownika, który możesz aktywować dyrektywą USER, ale wiele nadal domyślnie używa roota bez gotowego użytkownika aplikacji. W takich przypadkach tworzysz użytkownika w Dockerfile przed przełączeniem się na niego. Dla większości samodzielnie hostowanych konfiguracji ta jedyna zmiana eliminuje całą kategorię ryzyka eskalacji.
Udostępnianie zbyt wielu portów publicznie w internecie
Gdy publikujesz port za pomocą Docker, Docker zapisuje własne reguły iptables bezpośrednio. Te reguły działają przed regułami zapory na poziomie hosta. To dobrze znane zachowanie zgłaszane przez społeczność i udokumentowane w przewodniku filtrowania pakietów Docker, a nie błąd konfiguracji, i oznacza to, że UFW i podobne narzędzia nie blokują tego, co Docker już otworzył.
Docker pisze bezpośrednio do iptables, omijając domyślne UFW i firewalld na wielu hostach Linux. To oznacza, że port powiązany z 0.0.0.0 może być publicznie osiągalny nawet gdy zapora wydaje się skonfigurowana. Grupy bezpieczeństwa chmury i reguły łańcucha DOCKER-USER mogą nadal blokować ten ruch, więc rzeczywiste narażenie zależy od twojej konkretnej konfiguracji sieci.
Powiąż usługi z 127.0.0.1 gdzie to możliwe, przekierowuj publiczny ruch przez reverse proxy i publikuj tylko to, co naprawdę wymaga dostępu zewnętrznego. Reverse proxy to najbardziej niezawodny sposób na kontrolę tego, co jest eksponowane spoza hosta.
Ignorowanie izolacji sieci między kontenerami
Każdy kontener w tej sieci może osiągnąć każdy inny kontener bez ograniczeń. Domyślna mostek nie stosuje filtrowania ruchu między kontenerami, które ją dzielą, a większość konfiguracji nigdy tego nie zmienia.
Jeśli jeden kontener zostanie skompromitowany, ta otwarta komunikacja staje się ścieżką ruchu lateralnego. Kontener frontend może osiągnąć bazę danych, wewnętrzny API lub cokolwiek innego w tej samej sieci domyślnego mostu, nawet gdy ten dostęp nigdy nie był zamierzony.
Sieci zdefiniowane przez użytkownika dają ci jawną kontrolę nad tym, które kontenery mogą się komunikować, ale pojedyncza niestandardowa sieć współdzielona przez wszystkie twoje usługi nadal pozwala na swobodną komunikację między kontenerami. Rzeczywista izolacja wymaga umieszczenia usług, które nie powinny się ze sobą rozmawiać, w oddzielnych sieciach. Wyłączenie domyślnego mostu to punkt wyjścia, a nie meta.
Pomijanie gniazda Docker
Gniazdo Docker w /var/run/docker.sock to interfejs sterowania całym silnikiem Docker. Zamontowanie go w kontenerze daje temu kontenerowi bezpośredni dostęp API do daemona działającego na hoście.
Mając ten dostęp, kontener może uruchamiać nowe kontenery, montować katalogi hosta, sprawdzać i modyfikować działające kontenery i faktycznie kontrolować maszynę hosta. Powierzchnia ataku jest równoważna rootowi na hoście, dlatego każde narzędzie wymagające dostępu do gniazda zasługuje na ostrożną ocenę.
Dla większości przypadków użycia istnieją bezpieczniejsze alternatywy: ograniczone APIy lub narzędzia zarządzania Docker które nie wymagają dostępu do gniazda. Docker-w-Docker niesie ze sobą własne kompromisy bezpieczeństwa i operacyjne i nie jest bezpośrednim substytutem.
Błędy konfiguracji otwierają pierwszą lukę w bezpieczeństwie. Wybór obrazu i zależności określa, jak ta luka się rozprzestrzenia w czasie.
Błędy obrazu i sekretów, które przeżywają kontener
Gdy zatrzymasz kontener, błędy konfiguracji wewnątrz niego również się zatrzymują. Gdy przebudujesz obraz zawierający podatność lub hasło zapisane na stałe, problem powraca razem z kontenerem. Błędy na poziomie obrazu nie zerują się między wdrożeniami.
Rozprzestrzeniają się wraz z obrazem do każdego środowiska, które go pobiera, każdego rejestru, który go przechowuje, i każdego członka zespołu, który go uruchamia. Ta persistencja czyni zarządzanie obrazami i sekretami odrębną kategorią ryzyka, którą warto audytować oddzielnie od konfiguracji.
Widzimy ten wzorzec często: obraz wybrany starannie na początek projektu i nigdy od tego czasu nie przebudowany, powoli odchodzący od linii bezpieczeństwa, którą reprezentował na początku.
Używanie niezaufanych lub nieaktualnych obrazów
Publiczne rejestry są otwarte dla każdego. Złośliwe obrazy trafiały do Docker Hub z kopnikami kryptowaluty i backdoorami wbudowanymi w historię warstw, które utrzymują się przez restarty kontenerów. Weryfikacja przed pobraniem ma znaczenie, szczególnie dla obrazów nieoficjalnych lub od nieznanych wydawców.
Odrębny problem to nieaktualność. Oficjalny obraz pobrany sześć miesięcy temu i od tego czasu nigdy nie przebudowany gromadzi nieopatchowane podatności z każdym ujawnionym CVE wobec swoich pakietów. Obraz nie jest uszkodzony. Po prostu nie jest już aktualny.
Raport Sonatype's 2024 State of the Software Supply Chain wykazał, że w 95% przypadków, gdy podatny komponent jest używany, ustalona wersja jest już dostępna, i 80% zależności aplikacji pozostaje bez aktualizacji przez ponad rok. Ten wzorzec dotyczy także obrazów bazowych, ponieważ opierają się na tych samych pakietach open-source.
Używaj obrazów oficjalnych od zweryfikowanych wydawców i przypinaj konkretne tagi wersji zamiast polegać na "latest". Ustanów regularny harmonogram przebudowy, aby utrzymać obrazy aktualne.
Hardkodowanie sekretów w plikach Dockerfile i plikach Compose
Poświadczenia wpisane w instrukcję ENV lub ARG pliku Dockerfile, zakodowane na stałe w bloku środowiska Compose, przekazane jako argumenty budowania lub przechowywane w pliku .env zatwierdzonym w kontroli wersji nie znikają, gdy zatrzymasz kontener. Pozostają w historii warstw obrazu lub kontroli wersji, dostępne dla każdego, kto może do nich dotrzeć.
To jeden z najczęściej pomijanych błędów bezpieczeństwa Docker, ponieważ nie powoduje widocznych problemów podczas rozwoju. Klucz w instrukcji ENV działa prawidłowo. Jest też w twoim repozytorium, wbudowany w twój obraz i rozpowszechniany wszędzie, gdzie ten obraz się rozprzestrzenia.
Nowoczesny Docker Compose obsługuje natywny mechanizm sekretów, który montuje poświadczenia w czasie wykonania bez wbudowywania ich w obraz. Secrets w Docker i zewnętrzne menedżery sekretów stosują tę samą zasadę. To są opcje, które utrzymują poświadczenia całkowicie poza artefaktami budowania i zatwierdzonymi plikami.
Zmienne środowiskowe w czasie wykonania to ulepszenie w stosunku do zahardkodowanych poświadczeń, ale nadal są widoczne w wyniku docker inspect, logach i zrzutach awaryjnych. To krok naprzód od sekretów wbudowanych, ale nie rozwiązanie końcowe.
Nieregularna aktualizacja obrazów kontenerów
Uruchamianie tego samego obrazu przez miesiące to zwyczaj. Każdy dzień, który mija po ujawnieniu nowej podatności, ale przed przebudową, twoje kontenery noszą okno ekspozycji, które rośnie bez żadnej widocznej zmiany.
Ustanów spójny harmonogram przebudowy. Zautomatyzuj ten proces tam, gdzie to możliwe, i okresowo uruchamiaj skaner podatności wobec swoich aktualnych obrazów. Celem nie jest doskonałość. Chodzi o zmniejszenie czasu między wydaniem poprawki a jej wdrożeniem.
Kontrola dostępu i monitorowanie mogą być depriorytetyzowane w szybkich wdrożeniach. To także kategorie, w których incydenty pozostają niezauważone najdłużej.
Luki w kontroli dostępu i widoczności
Po uruchomieniu kontenera ze solidną konfiguracją i aktualnymi obrazami pozostają dwie kategorie awarii. Obie są niewidoczne z natury: nie zauważysz słabego problemu z kontrolą dostępu, dopóki ktoś go nie użyje, i nie zauważysz luki w monitorowaniu, dopóki nie będziesz musiał zbadać aktywność, która nigdy nie została zarejestrowana.
To samo Badania z 2024 roku 42% zespołów nie posiadało wystarczających możliwości, aby radzić sobie z bezpieczeństwem kontenerów i powiązanymi zagrożeniami.
Okazuje się, że luki w monitorowaniu ujawniają się zwykle podczas analizy incydentów, a nie wcześniej. Zanim widoczność staje się priorytetem, najczęściej reagujemy na coś, co już się stało, zamiast to zapobiegać.
Słabe uwierzytelnianie i odsłonięte pulpity zarządzania
Pulpit zarządzania kontenerem na publicznym IP bez uwierzytelniania nie wymaga wyrafinowanego atakującego. Wymaga tylko, aby znał adres. To niższy próg niż wielu zespołów się spodziewało.
Narzędzia do monitorowania i zarządzania hostowane samodzielnie zwykle udostępniają interfejs sieciowy na wszystkich kartach sieciowych. Zostawienie ich na publicznym IP bez uwierzytelniania to kontenerowiec bez odblokowanego panelu admina.
Uwierzytelnianie, odwrotny serwer proxy i umieszczenie w sieci prywatnej to podstawa. Kontrola dostępu to krok konfiguracyjny, który dodajesz do dowolnego interfejsu zarządzania, a nie coś, co jest domyślnie włączone.
Ta sama zasada dotyczy Docker CLI i zarządzania GUI; dostęp na poziomie administratora do demona niesie to samo ryzyko niezależnie od interfejsu.
Niemonitorowanie tego, co robią twoje kontenery
Jeśli kontener zostanie przeniknięty, działalność atakującego pozostawia ślad: zmiany zachowania procesów, niezwykłe połączenia sieciowe i nieoczekiwane modyfikacje plików. Bez zbierania dzienników ten ślad nie istnieje w formie, na którą możesz działać.
Scentralizowane zbieranie dzienników, rejestrowanie audytu kontenerów i narzędzia do monitorowania w czasie rzeczywistym dają ci dane do wykrycia nienormalnej aktywności, zanim się narośnie. Celem nie jest analizowanie każdej linii. To posiadanie danych, gdy będziesz potrzebować śledztwa.
Ustawienia kontenerów działające cicho w produkcji bez pipeline'u dzienników i bez alertów to nie niskie koszty utrzymania. To brak nadzoru. To dwa różne stany operacyjne.
Dlaczego środowisko infrastruktury również ma znaczenie
Bezpieczeństwo kontenerów zaczyna się od konfiguracji, ale konfiguracja działa na infrastrukturze. Host ze złą konfiguracją sieci, wspólnymi zasobami lub bez filtrowania na poziomie sieci tworzy warunki wpływające na każdy kontener powyżej. Właściwe ustawienie kontenerów i właściwa konfiguracja serwera to dwa osobne zadania.
Wiele luk w bezpieczeństwie Docker jest wzmacniana przez warunki, które kontenery same dziedziczą:
- Serwer z dzieloną dzierżawą bez izolacji sprzętu między dzierżawcami
- Jądro hosta działające bez poprawek
- Host bez wbudowanego filtrowania na poziomie sieci
To nie eliminuje potrzeby wykonania powyższych kroków konfiguracyjnych, ponieważ prawidłowe wzmacnianie kontenerów ma znaczenie niezależnie od warstwy infrastruktury. Rozpoczęcie od izolowanej infrastruktury usuwa jedną warstwę obaw z równania.
W Cloudzy oferujemy dwie opcje w zależności od tego, co wymaga twoja konfiguracja:
- Linux VPS: czysty środowisk do wdrożenia Docker samodzielnie i zastosowania kroków wzmacniania z tego artykułu
- Portainer VPS: opcja jednym kliknięciem z preinstalowanym Portainer; serwer uruchamia się i już jesteś w pulpicie
Obie opcje działają na tej samej infrastrukturze: wirtualizacja KVM, AMD AMD Ryzen 9 CPUs do 5,7 GHz zegara boost, pamięć DDR5, magazyn NVMe SSD, do 40 Gbps sieci, bezpłatna ochrona DDoS poprzez filtrowanie BuyVM, w 12 globalnymi lokalizacjach z gwarancją uptime 99,95% SLA.
Szczegółowe informacje dotyczące uruchamiania Portainer na VPS znajdziesz w osobnym artykule.
Praktyczna lista kontrolna bezpieczeństwa wdrożeń Docker
Większość błędów bezpieczeństwa Docker wynika z decyzji dotyczących konfiguracji podjętych raz i nigdy więcej nieprzejrzanych. Uruchomienie tej listy kontrolnej względem istniejącego systemu ujawnia te luki. Działa jako audyt, a nie przewodnik wdrażania.
Te praktyki bezpieczeństwa Docker obejmują sposób zabezpieczenia kontenerów Docker przed najczęstszymi błędami konfiguracji opisanymi powyżej.
Krótki przegląd: wszystkie 9 błędów
| Błąd | Kategoria | Jednolinijkowa poprawka |
| Uruchamianie jako root | Konfiguracja | Dodaj USER dyrektywę do pliku Docker |
| Porty powiązane z 0.0.0.0 | Konfiguracja | Powiąż z 127.0.0.1 i kieruj ruch przez serwer pośredniczący |
| Brak izolacji sieci | Konfiguracja | Rozdziel usługi między osobne sieci zdefiniowane przez użytkownika na podstawie wymagań dostępu. |
| Gniazdo Docker zamontowane | Konfiguracja | Usuń montowanie; użyj ograniczonych APIs lub alternatyw |
| Niezaufane lub nieaktualne obrazy | Obraz | Używaj oficjalnych obrazów ze stałymi znacznikami wersji |
| Zapisane na stałe sekrety | Obraz | Przenieś poświadczenia do zmiennych środowiskowych w czasie wykonania lub menedżera wpisów tajnych |
| Brak harmonogramu przebudowy obrazu | Obraz | Ustaw przebudowę raz w miesiącu; zautomatyzuj tam gdzie to możliwe |
| Pulpity bez uwierzytelnienia | Dostęp | Dodaj uwierzytelnianie i przenieś interfejsy zarządzania do sieci prywatnych |
| Brak zbierania dzienników kontenerów | Dostęp | Skonfiguruj scentralizowane rejestrowanie i monitorowanie w czasie wykonania |
Zalecamy uruchomienie tego najpierw względem istniejących systemów, ponieważ tam są luki najcześciej już obecne.
Kontenery uruchomione bez uprawnień administratora: Sprawdź pliki Docker pod kątem dyrektywy USER. Jeśli jej nie ma, kontener uruchamia się z uprawnieniami root.
Powiązania portów ograniczone do localhost lub przekazane przez serwer pośredniczący: Uruchom docker ps i sprawdź powiązania portów. Wpis 0.0.0.0:PORT może być publicznie dostępny na hostach, gdzie żadna grupa bezpieczeństwa upstream, zewnętrzna zapora sieciowa ani reguła łańcucha DOCKER-USER go nie blokuje.
Niestandardowe sieci mostkowe w użyciu: Kontenery na domyślnym moście Docker mogą się swobodnie komunikować. Kontenery w tej samej sieci zdefiniowanej przez użytkownika również mogą się komunikować, dlatego podziel usługi na osobne sieci według granic zaufania, aby uzyskać rzeczywistą izolację.
Gniazdo Docker nie zamontowane w kontenerach: Sprawdź pliki Compose i argumenty uruchamiania. Jeśli /var/run/docker.sock pojawia się jako wolumin, potwierdź, że jest wymagany i zamierzony.
Obrazy bazowe od zweryfikowanych wydawców z przypiętymi wersjami: FROM ubuntu:latest pobiera nieokreśloną, potencjalnie nieaktualną wersję. Przypiń do konkretnego wydania.
Brak tajnych danych w plikach Docker, plikach Compose ani argumentach budowania: Historia warstw obrazu utrzymuje poświadczenia nawet po usunięciu kontenera. Użyj tajnych danych Compose, tajnych danych Swarm, zainstalowanych tajnych danych podczas budowania lub zewnętrznego menedżera tajnych danych. Zmienne środowiskowe w czasie uruchamiania są lepsze niż wartości zakodowane na stałe, ale nadal pojawiają się w wyniku inspect i logach.
Zdefiniowany harmonogram przebudowy obrazu: Stare obrazy gromadzą luki w zabezpieczeniach. Miesięczny cykl przebudowy utrzymuje okno ekspozycji na rozsądnym poziomie dla większości instalacji.
Interfejsy zarządzania chronione uwierzytelnianiem: Każdy pulpit na publicznym adresie IP bez uwierzytelniania to otwarty punkt wejścia. Jeśli to możliwe, lepsza jest lokalizacja w sieci prywatnej.
Zbierane są logi kontenerów: Bez potoku logów detekcja incydentów zależy od widocznego wpływu na system. To zbyt późny sygnał do działania.
Wnioski
Domyślna konfiguracja Docker jest zbudowana dla wygody, nie bezpieczeństwa. Większość błędów omówionych w tym artykule pochodzi z ustawień, które nigdy nie zostały zmienione po początkowym wdrożeniu, a nie z zaawansowanych ataków.
Naprawa to głównie jednorazowe decyzje konfiguracyjne: dyrektywa USER, zmiana wiązania portów, sieć niestandardowa, harmonogram przebudowy. Żadna z nich nie wymaga nowych narzędzi dla większości instalacji.
Prawidłowa konfiguracja kontenera to pierwsze zadanie. Infrastruktura, na której się uruchamia, to drugie. Oba są ważne i żaden nie zastępuje drugiego.
