Docker apsaugojimas apima kelis sluoksnius — minimalias ir patikimas atvaizdes, paleistą ne kaip root, pažeidžiamumų nuskenavimą, slaptųjų duomenų valdymą, išteklių ir galimybių ribojimus ir šeimininko/demono sustiprinimą. Konteinerio saugumas yra svarbus, nes pažeidžiamumai gali paveikti tiek konteinerį, tiek šeimininką.
✓ 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
Docker konteinerių apsaugojimas yra svarbus aukšto lygio žinios, nes konteinerio pažeidžiamumai gali paveikti tiek konteinerį, tiek šeimininką, todėl saugumas yra daugiasluoksnis klausimas su realiais padariniais. Atvaizdo saugumas (minimalios/patikimos bazo atvaizdo naudojimas atakos paviršiui sumažinti, versijų fiksuojimas, nuskenavimas dėl pažeidžiamumų, kad būtų aptikti žinomi CVE, atvaizdo atnaujinimas) neleidžia išleisti išnaudojamų atvaizdų — tai dažnas pažeidžiamumų šaltinis. Vykdymo laikmečio saugumas yra ypač kritiškas: paleistinas ne kaip root yra viena iš svarbiausių praktikų, nes komprometetas root konteineris yra daug pavojingesnis (potencialiai gali sukelti šeimininko komprometavimą), o galimybių atmetimas, naudojimas tik skaitymui skirtų failų sistemų, privilegijų šuolio prevencija ir niekuomet nenaudojimas --privileged jei tai absoliučiai reikalinga (ji suteikia beveik šeimininko priėjimą) — viskas apriboja, ką atakuotojas gali padaryti, jei konteineris yra palankytas — gynyba iš visų pusių. Slaptųjų duomenų valdymas (niekuomet nededimas slaptųjų duomenų į atvaizdo, naudojimas vykdymo laiko slaptųjų duomenų) prevencija kredencialų nutekėjimą. Šeimininko ir demono saugumas yra labai svarbus ir dažnai nepastebimas: Docker demonas veikia kaip root, todėl priėjimas prie jo (arba Docker socket) efektyviai reiškia root prieigą prie šeimininko — todėl demono apsaugojimas, Docker socket neišdengimas ir šeimininko tobulinimas yra būtini, o šakninis Docker ir naudotojų vardai suteikia stipresnį izoliavimą.
Kadangi konteineriai dalinasi šeimininko branduoliu (todėl konteinerio pabėgimas arba šeimininko komprometavimas turi rimtas pasekmes) ir konteineriuotos programos yra plačiai naudojamos gamyboje, ir kadangi tinkamas saugumas (minimalios/nuskanuotos atvaizdo, ne-root vykdymas su ribotomis galimybėmis, slaptųjų duomenų valdymas ir demonam/šeimininko sustiprinimas) yra tai, kas prevencija realų konteinerio ir šeimininko komprometavimą, Docker konteinerių apsaugojimo supratimas yra svarbi aukšto lygio žinios — kritinė atsakomybė gamybos konteinerio įtaigai, kur sluoksniai praktikos (ypač ne-root vykdymas ir šaknies prieigos demonam apsaugojimas) sprendžia tikrus, rimtus saugumo rizikus, esančius konteinerizacijoje.