Image Hardening – jak zabezpieczać obrazy Docker przed atakami
Bezpieczeństwo kontenerów bardzo często zaczyna się jeszcze zanim kontener zostanie uruchomiony.
Wiele organizacji skupia się na:
- konfiguracji Dockera,
- zabezpieczeniu hosta,
- monitoringu runtime,
ale zapomina o najważniejszym elemencie:
obrazie kontenera (Docker Image).
Jeżeli obraz zawiera niepotrzebne pakiety, stare biblioteki lub wrażliwe dane, problem pojawi się w każdym środowisku, gdzie zostanie wdrożony.
Dlatego jednym z fundamentów DevSecOps jest:
Image Hardening – proces tworzenia minimalnych, bezpiecznych i kontrolowanych obrazów kontenerów.
Czym jest Image Hardening?
Image Hardening to zestaw praktyk mających na celu zmniejszenie ryzyka związanego z obrazami Docker.
Cel:
id="1a3x9m"
Niebezpieczny obraz
↓
Hardening
↓
Minimalny i bezpieczny obraz
Obejmuje między innymi:
- minimalizację obrazu,
- usunięcie zbędnych komponentów,
- eliminację sekretów,
- aktualizację bibliotek,
- skanowanie podatności,
- podpisywanie obrazów,
- kontrolę pochodzenia.
Dlaczego obraz Docker jest powierzchnią ataku?
Obraz zawiera:
- system bazowy,
- biblioteki,
- aplikację,
- konfigurację,
- zależności.
Przykład:
id="x9d2fz"
Docker Image
├── Ubuntu
├── Python
├── OpenSSL
├── Framework
├── Biblioteki
└── Aplikacja
Każdy element może posiadać:
- podatność CVE,
- błędną konfigurację,
- niepotrzebne uprawnienia.
Zasada minimalnego obrazu
Jedna z najważniejszych zasad:
Instaluj tylko to, czego aplikacja faktycznie potrzebuje.
Przykład złego podejścia:
FROM ubuntu:latest
RUN apt update
RUN apt install -y \
vim \
curl \
wget \
gcc \
python3
Problem:
Obraz zawiera:
- kompilator,
- narzędzia administracyjne,
- dodatkowe biblioteki.
W produkcji są niepotrzebne.
Lepsze podejście:
FROM python:3.12-slim
COPY app.py /
CMD ["python","/app.py"]
Mniejszy obraz:
- mniej pakietów,
- mniej CVE,
- łatwiejszy audyt.
Minimal Base Images
Popularne strategie:
1. Slim images
Przykład:
FROM python:3.12-slim
Usunięte:
- dokumentacja,
- narzędzia developerskie,
- niepotrzebne pakiety.
2. Alpine Linux
Przykład:
FROM alpine:3.20
Zalety:
- bardzo mały rozmiar,
- minimalna powierzchnia ataku.
3. Distroless Images
Jeszcze bardziej restrykcyjne.
Przykład:
FROM gcr.io/distroless/base
Brak:
- shell,
- package manager,
- narzędzi diagnostycznych.
Schemat:
Normalny obraz:
Linux
+
Shell
+
Tools
+
Application
Distroless:
Minimal runtime
+
Application
Multi-stage Build jako element hardeningu
Jedna z najważniejszych technik.
Zamiast:
Builder
+
Compiler
+
Source code
+
Application
=
Production Image
Stosujemy:
Builder Stage
↓
Compiled Artifact
↓
Runtime Image
Przykład:
FROM golang:1.23 AS builder
WORKDIR /app
COPY .
RUN go build -o server
FROM alpine
COPY --from=builder /app/server /
CMD ["/server"]
Efekt:
W produkcji nie ma:
- Go compiler,
- kodu źródłowego,
- narzędzi build.
Nie przechowuj sekretów w obrazie
Jeden z najczęstszych błędów.
Bardzo źle:
ENV API_KEY=123456
lub:
COPY .env /
Problem:
Sekret pozostaje w warstwach obrazu.
Nawet po usunięciu:
docker history image
może ujawnić dane.
Poprawne rozwiązania:
- Docker Secrets,
- HashiCorp Vault,
- Kubernetes Secrets,
- CI/CD Secret Store.
Uruchamianie aplikacji jako non-root
Domyślnie:
Container
UID 0
(root)
Jeżeli aplikacja zostanie przejęta:
atakujący otrzymuje uprawnienia root wewnątrz kontenera.
Lepszy Dockerfile:
FROM nginx:alpine
RUN adduser \
-D appuser
USER appuser
Efekt:
Container User
↓
UID 1000
Usuwanie niepotrzebnych pakietów
Przykład:
Źle:
RUN apt install curl vim git
Jeżeli aplikacja nie potrzebuje tych narzędzi:
usuń je.
Sprawdzenie:
docker run image sh
i analiza:
which curl
which wget
which gcc
Aktualizacja zależności
Obraz powinien być regularnie aktualizowany.
Problem:
FROM ubuntu:20.04
po kilku latach:
- stare biblioteki,
- niezałatane CVE.
Lepsze:
FROM ubuntu:24.04
oraz regularne rebuildy.
Pinowanie wersji obrazów
Błąd:
FROM nginx:latest
Dlaczego?
Dzisiaj:
nginx 1.27
jutro:
nginx 1.28
Zmiana może nastąpić bez kontroli.
Lepsze:
FROM nginx:1.27.0
Jeszcze lepiej:
digest:
FROM nginx@sha256:xxxx
Skanowanie obrazów
Image Hardening wymaga automatycznego skanowania.
Popularne narzędzia:
- Trivy,
- Grype,
- Docker Scout,
- Clair.
Przykład:
trivy image myapp:v1
Wynik:
HIGH CVE-2026-xxxx
Package:
openssl
Fix:
upgrade version
Dockerfile Security Best Practices
Dobry Dockerfile:
FROM alpine:3.20
RUN addgroup app \
&& adduser -D app -G app
COPY app /app
USER app
CMD ["/app"]
Zasady:
✅ mały obraz
✅ brak sekretów
✅ non-root
✅ konkretna wersja
✅ minimalne zależności
.dockerignore – często pomijany element
Bez niego do obrazu mogą trafić:
.git
.env
node_modules
logs
backup.sql
Przykład:
.git
.env
*.log
node_modules
Dockerfile*
Podpisywanie obrazów
Problem:
Skąd wiadomo, że obraz pochodzi od właściwego autora?
Rozwiązanie:
Image Signing
Przykład:
- Cosign,
- Notary,
- Sigstore.
Schemat:
Developer
↓
Build Image
↓
Sign Image
↓
Registry
↓
Verify Before Deploy
Image Hardening w CI/CD
Najlepszy model:
Developer
↓
Git Repository
↓
BuildKit
↓
Multi-stage Build
↓
Security Scan
↓
Image Signing
↓
Registry
↓
Production
Policy as Code
W dużych organizacjach stosuje się automatyczne reguły.
Przykład:
Nie pozwól wdrożyć obrazu:
IF
image runs as root
OR
HIGH CVE exists
OR
secret detected
THEN
BLOCK DEPLOYMENT
Narzędzia:
- Open Policy Agent (OPA),
- Kyverno,
- Gatekeeper.
Image Hardening a Supply Chain Security
Nowoczesne ataki często nie celują w działającą aplikację.
Cel:
łańcuch dostarczania.
Przykład:
Developer
↓
Malicious Dependency
↓
Docker Image
↓
Registry
↓
Production
↓
Compromise
Dlatego ważne są:
- SBOM,
- podpisy,
- skanowanie,
- kontrola zależności.
SBOM – Software Bill of Materials
SBOM to lista komponentów znajdujących się w obrazie.
Przykład:
Application Image
├── OpenSSL 3.x
├── Python 3.12
├── Flask
└── Requests
Dzięki temu wiadomo:
- jakie biblioteki są używane,
- czy pojawiła się podatność.
Praktyczna checklista Image Hardening
Obraz
✅ minimalny base image
✅ brak latest tag
✅ przypięte wersje
✅ regularne aktualizacje
Dockerfile
✅ multi-stage build
✅ USER non-root
✅ brak sekretów
✅ .dockerignore
✅ minimalne RUN
Bezpieczeństwo
✅ Trivy/Docker Scout
✅ SBOM
✅ podpis obrazu
✅ kontrola CI/CD
Runtime
✅ read-only filesystem
✅ seccomp
✅ AppArmor/SELinux
✅ ograniczone capabilities
Przykładowa bezpieczna architektura
Source Code
↓
BuildKit
↓
Multi-stage Build
↓
Hardened Image
↓
Scanner + SBOM + Signing
↓
Registry
↓
Docker Runtime
↓
Seccomp + SELinux + Monitoring
Podsumowanie
Image Hardening jest pierwszą linią obrony w świecie kontenerów.
Bezpieczny kontener zaczyna się nie od konfiguracji Dockera, ale od dobrze przygotowanego obrazu.
Najważniejsze zasady:
✅ twórz małe obrazy
✅ usuwaj wszystko, czego aplikacja nie potrzebuje
✅ nie uruchamiaj jako root
✅ nie przechowuj sekretów w obrazie
✅ skanuj każdą wersję
✅ kontroluj pochodzenie obrazu
Profesjonalne środowisko DevSecOps traktuje obraz Docker jako produkt wymagający audytu, a nie tylko plik potrzebny do uruchomienia aplikacji.
Jak działa izolacja aplikacji (sandboxing) w Windows, Linux i przeglądarkach Współczesne systemy operacyjne coraz częściej uruchamiają aplikacje w odizolowanych środowiskach. Czytaj dalej
Zabezpieczanie sieci w systemie Linux za pomocą zapory ogniowej (firewall) i VPN Bezpieczeństwo sieci jest jednym z najważniejszych aspektów, na Czytaj dalej
