Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania
Utwardzaj obrazy Docker, usuwając zbędne pakiety i uruchamiając je jako użytkownik inny niż root, a także korzystaj z narzędzi bezpieczeństwa środowiska uruchomieniowego (Falco, Sysdig) do wykrywania anomalnego zachowania kontenerów.
Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania to bezpłatna lekcja Security+ Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Security+ Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Podstawy bezpieczeństwa kontenerów
Kontenery pakują kod aplikacji i jego zależności w izolowane jednostki współdzielące jądro systemu operacyjnego hosta, w przeciwieństwie do maszyn wirtualnych, które zawierają pełny system operacyjny gościa. Takie współdzielenie sprawia, że kontenery są lekkie i szybkie, ale wprowadza odmienny model bezpieczeństwa: luka umożliwiająca ucieczkę z kontenera może pozwolić osobie atakującej wydostać się z kontenera i uzyskać bezpośredni dostęp do jądra hosta, wpływając na wszystkie pozostałe kontenery. Bezpieczeństwo kontenerów koncentruje się na trzech warstwach: obrazie (co zawiera), środowisku uruchomieniowym (co kontener może robić podczas działania) oraz platformie orkiestracji (jak zarządza się kontenerami).
Minimalne obrazy bazowe: ograniczanie powierzchni ataku
Każdy pakiet zainstalowany w obrazie kontenera stanowi potencjalną powierzchnię ataku. Zasada minimalnych obrazów bazowych oznacza rozpoczęcie od możliwie najmniejszej podstawy: Alpine Linux (5 MB, minimalny zestaw pakietów), obrazy distroless (obrazy firmy Google zawierające wyłącznie środowisko uruchomieniowe i aplikację, bez powłoki ani menedżera pakietów) lub scratch (całkowicie pusty obraz, przeznaczony dla statycznie kompilowanych plików binarnych). Kontener bez powłoki oznacza, że osoba atakująca, która uzyska możliwość wykonywania kodu, nie może łatwo uruchomić wget, curl ani innych narzędzi w celu rozszerzenia ataku — jest to zasada nazywana obroną przez minimalną ekspozycję.
# Bad: starts from a full OS image
FROM ubuntu:22.04
# Better: minimal Alpine base
FROM alpine:3.18
# Best: distroless for Java apps
FROM gcr.io/distroless/java17-debian11Uruchamianie jako użytkownik inny niż root: pierwsza zasada
Domyślnie kontenery Docker działają jako root (UID 0). Jeśli osoba atakująca wykorzysta lukę w aplikacji działającej w kontenerze, uzyska uprawnienia roota wewnątrz kontenera. Jeśli kontener współdzieli wolumin lub ma zamontowane zasoby hosta, root wewnątrz kontenera może oznaczać roota na hoście. Rozwiązanie jest proste: utworzyć dedykowanego użytkownika w pliku Dockerfile i przełączyć się na niego za pomocą dyrektywy USER przed końcowym CMD/ENTRYPOINT. Wiele narzędzi do skanowania bezpieczeństwa kontenerów zgłasza jako problem każdy obraz, w którym nie zdefiniowano użytkownika innego niż root.
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup app /app/app
USER appuser
CMD ["/app/app"]Niezmienne kontenery i systemy plików tylko do odczytu
Niezmienne kontenery to kontenery, których systemu plików nie można modyfikować w czasie działania. Włączenie opcji --read-only w Dockerze (lub readOnlyRootFilesystem: true w Kubernetes) uniemożliwia osobom atakującym zapisywanie złośliwego oprogramowania na dysku, modyfikowanie plików konfiguracyjnych oraz instalowanie narzędzi w działającym kontenerze. Aplikacje, które rzeczywiście muszą zapisywać dane (logi, pliki tymczasowe), mogą montować określone woluminy tmpfs do zapisu danych efemerycznych. Niezmienne kontenery wymuszają zasadę, zgodnie z którą stan środowiska uruchomieniowego powinien pochodzić wyłącznie z obrazu i konfiguracji, a nie z modyfikacji wewnątrz kontenera omijających proces bezpieczeństwa CI/CD.
# Run container with read-only root filesystem
docker run --read-only \
--tmpfs /tmp \
--tmpfs /var/run \
myapp:latestSkanowanie obrazów: wykrywanie CVE przed wdrożeniem
Narzędzia do skanowania obrazów kontenerów analizują pakiety zainstalowane w obrazie Docker pod kątem podatności na podstawie baz podatności (NVD, CVE) i zgłaszają znane CVE. Do najpopularniejszych skanerów należą Trivy (Aqua Security, szybki i bezpłatny), Grype (Anchore), Snyk Container oraz AWS ECR image scanning. Skanowanie powinno być zintegrowane z potokiem CI/CD, aby każdy obraz zawierający krytyczne lub wysokie CVE powodował przerwanie potoku przed przesłaniem obrazu do rejestru. Skanery powinny również sprawdzać, czy w warstwach obrazu nie osadzono przypadkowo sekretów (kluczy API, haseł).
# Scan a Docker image with Trivy
trivy image --severity HIGH,CRITICAL myapp:latest
# Fail CI pipeline if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latestZarządzanie sekretami: nigdy w warstwach obrazu
Częstym i niebezpiecznym błędem jest osadzanie sekretów (kluczy API, haseł do baz danych, certyfikatów TLS) w obrazach Docker — zarówno w zmiennych środowiskowych zapisanych w obrazie, jak i w plikach dodanych za pomocą COPY. Sekrety te są widoczne dla każdej osoby mającej dostęp do obrazu — za pomocą docker history lub po rozpakowaniu warstw obrazu. Nawet jeśli kolejna warstwa usunie plik, pozostaje on w historii obrazu. Sekrety należy wstrzykiwać w czasie uruchamiania za pośrednictwem zmiennych środowiskowych pobieranych z menedżera sekretów, Docker secrets lub Kubernetes Secrets zamontowanych jako woluminy.
# Never bake secrets into images
# Bad: ENV DATABASE_PASSWORD='supersecret'
# Good: inject at runtime via environment
docker run -e DATABASE_PASSWORD=$(vault read -field=password secret/db) myapp:latest
# Or use Docker secrets in Swarm/K8sOchrona środowiska uruchomieniowego: Falco i monitorowanie wywołań systemowych
Narzędzia bezpieczeństwa środowiska uruchomieniowego monitorują zachowanie kontenera podczas jego działania oraz zgłaszają anomalie lub blokują podejrzaną aktywność. Falco (projekt CNCF) integruje się z jądrem Linux za pomocą eBPF lub modułów jądra, aby przechwytywać wywołania systemowe i porównywać je z regułami. Reguła może na przykład zgłosić alert, gdy kontener uruchomi powłokę (execve('/bin/sh')), otworzy połączenie sieciowe na nieoczekiwanym porcie lub odczyta plik /etc/shadow. Takie wskaźniki behawioralne często sygnalizują aktywny atak, nawet jeśli nie wykorzystano żadnego znanego CVE. Platformy Sysdig Secure i Aqua Security zapewniają komercyjne rozwiązania do ochrony środowiska uruchomieniowego.
# Example Falco rule: alert on shell execution in container
# - rule: Shell Spawned in Container
# desc: A shell was spawned in a container
# condition: container and proc.name in (bash, sh, zsh)
# output: Shell spawned (user=%user.name container=%container.name)
# priority: WARNINGMożliwości systemu Linux i profile Seccomp
Kontenery Docker domyślnie usuwają wiele możliwości systemu Linux, ale nadal zachowują więcej uprawnień, niż potrzebuje większość aplikacji. Capabilities dzielą uprawnienia roota na odrębne jednostki (np. CAP_NET_ADMIN, CAP_SYS_ADMIN). Najlepszą praktyką jest usunięcie wszystkich capabilities i dodanie tylko tych wymaganych za pomocą --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Profile Seccomp (Secure Computing Mode) określają listę dozwolonych wywołań systemowych kontenera — Docker zawiera domyślny profil seccomp, który blokuje około 44 niebezpiecznych wywołań systemowych. Niestandardowe profile seccomp dopasowane do konkretnych aplikacji mogą dodatkowo ograniczyć ten zakres, blokując wszystkie wywołania systemowe, z których aplikacja nigdy legalnie nie korzysta.
# Drop all capabilities, add only what's needed
docker run \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--security-opt seccomp=/etc/docker/seccomp-custom.json \
myapp:latestRejestry kontenerów i podpisywanie obrazów
Rejestry kontenerów (Docker Hub, AWS ECR, Google Artifact Registry) przechowują i dystrybuują obrazy. Zabezpieczanie rejestru obejmuje: włączenie skanowania podatności przy przesyłaniu obrazu, ograniczenie uprawnień do przesyłania wyłącznie do kont usługowych CI/CD, włączenie podpisywania obrazów za pomocą Sigstore/Cosign lub Docker Content Trust (Notary), aby środowiska uruchomieniowe pobierały wyłącznie kryptograficznie podpisane obrazy z zaufanych źródeł, oraz skonfigurowanie niezmienności obrazów, aby nie można było nadpisywać tagów (eliminuje to ataki polegające na modyfikacji tagów, w których atakujący zastępuje zaufany tag :latest złośliwym obrazem).
# Sign a container image with Cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3
# Verify signature before deployment
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3Techniki ucieczki z kontenera i zabezpieczenia
Atakujący, którzy uzyskali możliwość wykonywania kodu wewnątrz kontenera, mogą próbować przeprowadzić ucieczkę z kontenera, aby uzyskać dostęp do hosta. Typowe techniki obejmują: wykorzystanie podatnych kontenerów uprzywilejowanych (--privileged zapewnia niemal nieograniczony dostęp do hosta), nadużycie udostępnionych gniazd Dockera (zamontowanie /var/run/docker.sock w kontenerze zapewnia pełny dostęp do API Dockera, w tym możliwość tworzenia kontenerów uprzywilejowanych) oraz wykorzystanie podatności jądra za pośrednictwem niezabezpieczonych capabilities. Zabezpieczenia obejmują: nieużywanie trybu uprzywilejowanego, chyba że jest to absolutnie konieczne, niemontowanie gniazda Dockera w kontenerach aplikacji, regularne aktualizowanie jądra hosta oraz używanie gVisor lub Kata Containers w przypadku obciążeń wymagających silnej izolacji.
# DANGEROUS: never do this in production
# docker run --privileged -v /:/host myapp:latest
# Check if a container is running privileged
docker inspect mycontainer | grep -i privilegedZgodność ze standardem CIS Docker Benchmark
Center for Internet Security (CIS) Docker Benchmark zawiera szczegółowe wytyczne dotyczące bezpiecznej konfiguracji hostów i kontenerów Docker. Obejmują one konfigurację demona, higienę obrazów, ustawienia środowiska uruchomieniowego kontenerów oraz mechanizmy kontroli sieci. Narzędzia takie jak Docker Bench for Security automatyzują sprawdzanie zgodności ze standardem CIS, generując punktowany raport elementów zakończonych wynikiem pozytywnym lub negatywnym. Okresowe uruchamianie tego testu oraz integracja z CI/CD zapewniają szybkie wykrywanie rozbieżności w konfiguracji zabezpieczeń. Osoby przygotowujące się do egzaminu Security+ powinny wiedzieć, że CIS Benchmarks są jednym z najważniejszych źródeł informacji dotyczących wzmacniania zabezpieczeń systemów operacyjnych i platform w kontekście egzaminu.
# Run Docker Bench for Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
-v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
-v /etc:/etc docker/docker-bench-securitySzybki test
Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji nauczyli się Państwo, że minimalne obrazy bazowe i użytkownicy inni niż root zmniejszają powierzchnię ataku oraz poziom uprawnień obciążeń uruchamianych w kontenerach, narzędzia ochrony środowiska uruchomieniowego, takie jak Falco, wykrywają anomalne wzorce wywołań systemowych wskazujące na aktywne ataki wewnątrz kontenerów, a także że nie należy używać kontenerów uprzywilejowanych ani montować gniazda Dockera w kontenerach aplikacji, ponieważ takie konfiguracje umożliwiają ucieczkę z kontenera. W następnej części omówimy bezpieczeństwo Kubernetes, w tym RBAC, zasady sieciowe i standardy bezpieczeństwa podów.
Często zadawane pytania
Czy lekcja „Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania” jest bezpłatna?
Tak — pełny tekst „Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Security+ Academy, przejdź na CoddyKit PRO. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Co nauczysz się w „Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania”?
Utwardzaj obrazy Docker, usuwając zbędne pakiety i uruchamiając je jako użytkownik inny niż root, a także korzystaj z narzędzi bezpieczeństwa środowiska uruchomieniowego (Falco, Sysdig) do wykrywania… Ćwiczysz Security+ Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Security+ Academy?
Nie wymagamy żadnego doświadczenia. Security+ Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.
Ile czasu zajmuje lekcja „Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Security+ Academy?
Tak. Każda lekcja Security+ Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Bezpieczeństwo kontenerów: utwardzanie obrazów i ochrona w czasie działania
- Bezpieczeństwo Kubernetes: RBAC, zasady sieciowe i bezpieczeństwo podów
- Bezpieczeństwo środowisk serverless i funkcji
- Skanowanie bezpieczeństwa infrastruktury jako kodu