Zabezpieczanie Docker'a obejmuje wiele warstw — minimalne i zaufane obrazy, uruchamianie jako non-root, skanowanie podatności, zarządzanie sekretami, ograniczenia zasobów i możliwości oraz wzmocnienie hosta/demona. Bezpieczeństwo kontenera jest ważne, ponieważ podatności mogą wpłynąć zarówno na kontener, jak i na host.
✓ Use MINIMAL base images (alpine, distroless) → fewer packages = smaller attack surface
✓ Use TRUSTED/official images; pin specific versions/DIGESTS (not "latest")
✓ SCAN images for vulnerabilities (Trivy, docker scout, Snyk) — in CI and regularly
✓ Keep base images UPDATED (patch known CVEs)
✓ Don't include secrets or unnecessary tools in images
✓ Run as NON-ROOT (USER instruction) — a root container that's compromised is far more
dangerous (especially with host access). This is one of the most important practices.
✓ Drop capabilities (--cap-drop ALL, add only needed ones) — limit what the container can do
✓ Read-only filesystem (--read-only) where possible
✓ no-new-privileges (prevent privilege escalation)
✓ Set RESOURCE LIMITS (prevent DoS from resource exhaustion)
✓ NEVER run --privileged unless absolutely necessary (it gives near-host access)
✓ Don't bake secrets into images; use secrets management at runtime
✓ Protect the DOCKER DAEMON — the daemon runs as root; access to it = root on the host
(don't expose the Docker socket; mounting /var/run/docker.sock into a container is risky)
✓ Keep the host and Docker engine PATCHED; use minimal/hardened host OS
✓ Isolate networks; limit container-to-container and container-to-host access
✓ Consider rootless Docker / user namespaces for stronger isolation
Zabezpieczanie kontenerów Docker'a jest ważną wiedzą na poziomie senior, ponieważ podatności kontenerów mogą wpłynąć zarówno na kontener, jak i na host, czyniąc bezpieczeństwo wielowarstwowym problemem z rzeczywistymi konsekwencjami. Praktyki bezpieczeństwa obrazu (minimalne/zaufane obrazy bazowe w celu zmniejszenia powierzchni ataku, przypinanie wersji, skanowanie podatności w celu wykrycia znanych CVE, aktualizowanie obrazów) zapobiegają dostarczaniu podatnych obrazów — częsty źródło podatności. Bezpieczeństwo runtime jest szczególnie krytyczne: uruchamianie jako non-root to jedna z najważniejszych praktyk, ponieważ skompromitowany kontener root jest znacznie bardziej niebezpieczny (potencjalnie prowadzący do kompromitacji hosta), a usuwanie możliwości, używanie systemów plików tylko do odczytu, zapobieganie eskalacji uprawnień i nigdy nie używanie --privileged chyba że absolutnie konieczne (przyznaje dostęp bliski hostowi) wszystko ogranicza, co atakujący może zrobić, jeśli kontener zostanie naruszony — obrona w głąb. Zarządzanie sekretami (nigdy nie umieszczanie sekretów w obrazach, używanie sekretów runtime) zapobiega wyciekom poświadczeń. Bezpieczeństwo hosta i demona jest kluczowe i często pomijane: demon Docker'a uruchamia się jako root, więc dostęp do niego (lub do gniazda Docker'a) efectywnie oznacza root na hoście — czyniąc ochronę demona, nieupublicznianie gniazda Docker'a i utrzymywanie hosta w aktualizacji zasadniczymi, z rootless Docker'em i przestrzeniami nazw użytkownika oferującymi silniejszą izolację.
Ponieważ kontenery dzielą jądro hosta (więc ucieczka z kontenera lub kompromitacja hosta ma poważne konsekwencje) i aplikacje konteneryzowane są wszechobecne w produkcji, a właściwe bezpieczeństwo (minimalne/skanowane obrazy, non-root runtime z ograniczonymi możliwościami, zarządzanie sekretami i wzmocnienie demona/hosta) to to, co zapobiega rzeczywistym kompromisom kontenerów i hostów, zrozumienie sposobu zabezpieczania kontenerów Docker'a jest ważną wiedzą na poziomie senior — krytyczną odpowiedzialnością dla wdrożeń kontenerów w produkcji, gdzie wielowarstwowe praktyki (szczególnie uruchamianie jako non-root i ochrona demona z uprawnieniami root) radzą sobie z rzeczywistymi, poważnymi zagrożeniami bezpieczeństwa inherentnymi dla konteneryzacji.