Jak złośliwe obrazy Dockera trafiają do zaufanych Pipelines Niezauważony
Rejestr Dockera to serce każdego konteneryzowanego przepływu pracy. Przechowuje, dystrybuuje i wersjonuje obrazy. Jednak jeśli pozostanie on niewidoczny lub słabo kontrolowany, atakujący mogą wstrzyknąć złośliwe obrazy Dockera bezpośrednio do… pipelines.
Jak to się dzieje:
- Zasady otwierania: pipeline ciągnie myorg/base: najnowsze bez sprawdzania źródła lub integralności
- Przejęte konta:Atakujący uzyskują dostęp do rejestru kontenerów i zastępują zaufane obrazy
- Typosquatting:Deweloperzy błędnie wyciągają baza myorg zamiast myorg/base
Przykład zadania CI w GitLab:
Tutaj, węzeł:najnowszy może zmienić się z dnia na dzień. Jeśli atakującemu uda się opublikować zatrute firmy obraz, zostanie automatycznie wyciągnięta. Wersja bezpieczna:
Zablokowanie obrazów do konkretnej wersji zapobiega ich „cichemu dryfowaniu”. Złośliwy obraz Dockera może wejść do sieci tylko wtedy, gdy bezgranicznie ufasz „najnowszej” wersji.
Dlaczego nie wszystkie rejestry Dockera są domyślnie bezpieczne
Nie każdy rejestr Dockera wymusza silne ustawienia domyślne. Programiści często ufają publicznym źródłom bez weryfikowania ich pochodzenia. Ryzyka obejmują:
- Niezatwierdzone pobrania z publicznych rejestrów kontenerów
- Niepodpisane obrazy bez dowodu na to, kto je zbudował
- Rejestry stron trzecich ze słabą polityką, co prowadzi do sfałszowanych obrazów bazowych
Przykład niebezpiecznego zachowania:
Niebezpieczeństwo: Nie wiesz, kto to zbudował, kiedy ani co jest w środku. Bezpieczniejsze podejście:
Zawsze weryfikuj wydawcę, sprawdzaj integralność kryptograficzną i wybieraj zaufane, oficjalne rejestry. Założenie, że każdy rejestr Dockera jest domyślnie bezpieczny, tworzy martwe punkty w łańcuchu dostaw.
Wymuszanie pochodzenia obrazu za pomocą podpisów i kontroli dostępu
Aby zapobiec złośliwym obrazom Dockera, zespoły DevSecOps muszą egzekwować pochodzenie obrazów. Oznacza to weryfikację autentyczności przed wprowadzeniem jakiegokolwiek obrazu do środowiska deweloperskiego, testowego lub produkcyjnego. Najlepsze praktyki obejmują:
- Podpisywanie obrazem:Użyj Docker Content Trust lub Sigstore do podpisywania obrazów
- Zasady RBAC:Ogranicz, kto może wypychać lub pobierać dane z rejestru kontenerów
Atesty:Wymagaj metadanych udowadniających, w jaki sposób i gdzie obraz został utworzony. Przykład z Docker Content Trust:
Po włączeniu zaufania niepodpisane obrazy są odrzucane. W połączeniu z kontrolą dostępu na podstawie ról (RBAC) zapobiega to wstawianiu przez nieuczciwych użytkowników zatrutych kompilacji do rejestru Dockera.
Automatyzacja kontroli bezpieczeństwa obrazu w CI/CD Pipelines
Ręczna weryfikacja nie jest skalowalna. Kontrole bezpieczeństwa muszą być zautomatyzowane, aby blokować złośliwe obrazy Dockera, zanim się rozprzestrzenią.
Techniki:
- Silniki polityk:Narzędzia takie jak OPA Gatekeeper wymuszają stosowanie dozwolonych rejestrów i tagów
- Skanery podatności:Automatyczna analiza obrazów pod kątem znanych luk CVE
- Pipeline gwardia:Blokada jest wdrażana, jeśli obraz nie spełnia wymagań podpisu lub skanowania.
CI/CD Przykład
Mini lista kontrolna dla programistów (CI/CD Bezpieczeństwo rejestru)
- Nigdy nie używaj firmy tagi w produkcji pipelines
- Pobieraj tylko z zaufanych rejestrów Docker
- Wymuś podpisywanie kryptograficzne dla każdego obrazu
- Skanuj obrazy podczas kompilacji i wdrażania
- Automatycznie blokuj niepodpisane lub nieskanowane obrazy
Zautomatyzowane sprawdzanie gwarantuje, że atakujący nie będą mogli przemycić złośliwego obrazu Dockera, gdy programiści będą skupieni na kodowaniu.
Budowanie bezpiecznej strategii rejestru Docker z zasadami DevSecOps
Wzmocniony rejestr Docker to coś więcej niż system przechowywania danych; to część Twojej granicy bezpieczeństwa. Podstawowe praktyki:
- Ogranicz operacje push/pull wyłącznie do zaufanych kont
- Segmentuj rejestry według środowiska (dev, staging, prod)
- Włącz rejestrowanie audytu dla każdej akcji rejestru
- Regularnie czyść nieużywane obrazy, aby zmniejszyć powierzchnię ataku
Rejestr kontenerów zgodny z Zasady DevSecOps zapewnia, że każdy obraz poruszający się przez pipeline jest kontrolowany, możliwy do śledzenia i zabezpieczony.
Rozwiązania takie jak Xygeni poprawić to poprzez ciągłe monitorowanie rejestrów i pipelines dla nieautoryzowanych lub sfałszowanych obrazów. Egzekwują guardrails więc tylko zweryfikowane obrazy dotrą do wdrożenia.
Blokowanie rejestru Docker
Rejestr Dockera jest częścią Twojej powierzchni ataku. Jeśli atakujący wkradną się do Twoich obrazów Dockera, CI/CD pipeline może stać się systemem dostarczania ładunków. Wnioski dla programistów są jasne:
- Nie ufaj ustawieniom domyślnym: sprawdź poprawność każdego źródła obrazu
- Przypnij wersje i unikaj firmy
- Automatyzacja skanowania i egzekwowanie zasad podpisywania
- Traktuj swój rejestr kontenerów jako infrastrukturę krytyczną
Zintegrowanie zabezpieczeń rejestru z procesem DevSecOps zmniejsza ryzyko cichego rozprzestrzeniania się zatrutych kompilacji w środowiskach. Narzędzia takie jak Xygeni ułatwiają to, zapewniając wgląd w ukryte zagrożenia rejestru, egzekwując zasady i wykrywając zmodyfikowane obrazy przed ich uruchomieniem. Zablokowanie rejestru Dockera nie dotyczy tylko przechowywania danych, ale także kontroli całego łańcucha dostaw kontenerów. Deweloperzy, którzy traktują rejestry jako granicę bezpieczeństwa, powstrzymują atakujących, zanim jeszcze dotrą do środowiska uruchomieniowego.
