Docker Bench Security – automatyczny audyt bezpieczeństwa środowiska Docker
Docker Bench Security – automatyczny audyt bezpieczeństwa środowiska Docker
Bezpieczeństwo kontenerów nie kończy się na samym uruchomieniu aplikacji. W środowisku produkcyjnym administrator musi regularnie sprawdzać:
- czy Docker działa zgodnie z najlepszymi praktykami,
- czy daemon ma poprawną konfigurację,
- czy kontenery nie mają nadmiernych uprawnień,
- czy host Linux jest odpowiednio zabezpieczony.
Jednym z najpopularniejszych narzędzi do takiego audytu jest Docker Bench Security.
To skrypt audytowy typu security compliance checker, który sprawdza konfigurację Dockera według zaleceń bezpieczeństwa.
Czym jest Docker Bench Security?
Docker Bench Security to narzędzie typu open source stworzone przez społeczność Dockera, oparte na wytycznych:
CIS Docker Benchmark
(Center for Internet Security).
Jego zadaniem jest automatyczne sprawdzenie, czy środowisko Docker spełnia określone wymagania bezpieczeństwa.
Schemat działania:
id="0p5n4a"
Docker Host
↓
Docker Bench Security
↓
CIS Docker Benchmark
↓
Raport bezpieczeństwa
↓
Fix / Hardening
Co sprawdza Docker Bench Security?
Audyt obejmuje kilka głównych obszarów:
- konfigurację hosta Linux,
- konfigurację Docker Engine,
- uprawnienia kontenerów,
- obrazy,
- sieć,
- logowanie,
- mechanizmy izolacji.
CIS Docker Benchmark – standard bezpieczeństwa
CIS Benchmark to zestaw zaleceń bezpieczeństwa dla popularnych technologii.
Dla Dockera obejmuje między innymi:
- Docker daemon configuration,
- Docker files,
- container runtime,
- images,
- networking,
- logging.
Nie jest to skaner podatności aplikacji.
Sprawdza raczej:
„Czy Docker został skonfigurowany zgodnie z dobrymi praktykami bezpieczeństwa?”
Instalacja Docker Bench Security
Najprostsza metoda:
git clone https://github.com/docker/docker-bench-security.git
Przejście do katalogu:
cd docker-bench-security
Uruchomienie:
sudo sh docker-bench-security.sh
Uruchomienie jako kontener
Docker Bench może działać również jako kontener:
docker run --rm \
--net host \
--pid host \
--userns host \
-v /var/lib:/var/lib \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc:/etc \
docker/docker-bench-security
Dlaczego potrzebuje wysokich uprawnień?
Docker Bench musi sprawdzić:
- konfigurację systemu,
- socket Dockera,
- procesy,
- ustawienia kernela.
Dlatego wymaga dostępu administracyjnego.
To normalne dla narzędzi audytowych.
Przykładowy wynik audytu
Raport wygląda mniej więcej tak:
[INFO] Docker version
PASS: Docker version is up to date
[WARN] Docker daemon configuration
WARN: User namespace remapping not enabled
[PASS] Container security
PASS: Containers do not run privileged
Statusy:
| Status | Znaczenie |
|---|---|
| PASS | poprawnie |
| WARN | wymaga sprawdzenia |
| INFO | informacja |
| FAIL | problem bezpieczeństwa |
Najważniejsze kontrole Docker Bench Security
1. Docker daemon configuration
Sprawdzane są między innymi:
- konfiguracja dockerd,
- TLS,
- uprawnienia socketu,
- logowanie.
Przykład problemu:
WARN:
Docker socket accessible by non-root users
Ryzyko:
docker.sock
↓
pełna kontrola Docker API
2. Ochrona Docker socket
Sprawdzane:
/var/run/docker.sock
Prawidłowo:
root:docker
660 permissions
Niebezpiecznie:
777
czyli:
każdy użytkownik
↓
Docker API
3. User Namespace Remapping
Jedna z ważnych kontroli.
Domyślnie:
Container root
UID 0
Można użyć:
{
"userns-remap": "default"
}
Efekt:
Container UID 0
↓
Host UID 100000+
Zmniejsza ryzyko eskalacji.
4. Kontenery uruchomione jako root
Docker Bench sprawdza:
czy kontenery mają:
USER root
Lepsze:
USER app
5. Privileged containers
Kontrola:
docker ps
Sprawdzane:
czy użyto:
--privileged
Dlaczego jest niebezpieczne?
Ponieważ daje szeroki dostęp:
Container
↓
Kernel
↓
Host
6. Capabilities
Docker Bench sprawdza nadane uprawnienia.
Przykład:
Niepotrzebne:
--cap-add ALL
Lepsze:
--cap-drop ALL
i dodanie tylko wymaganych.
7. Seccomp Profile
Sprawdzane:
czy kontenery używają ograniczeń syscalli.
Źle:
--security-opt seccomp=unconfined
Dobrze:
Default Docker seccomp profile
8. AppArmor / SELinux
Docker Bench sprawdza:
czy aktywna jest dodatkowa kontrola dostępu.
Przykład:
AppArmor enabled
RHEL:
SELinux enforcing
9. Container health monitoring
Sprawdzane:
czy kontenery mają:
HEALTHCHECK
Przykład:
HEALTHCHECK CMD curl localhost
Dzięki temu system wie:
- czy aplikacja działa,
- czy wymaga restartu.
10. Logowanie zdarzeń
Kontenery powinny mieć kontrolowane logi.
Sprawdzane:
- logging driver,
- rotacja,
- dostępność logów.
Przykład:
{
"log-driver": "journald"
}
Docker Bench Security a Docker Compose
Wiele problemów pojawia się w plikach:
docker-compose.yml
Przykład ryzykownej konfiguracji:
services:
app:
privileged: true
volumes:
- /:/host
Problem:
Kontener otrzymuje dostęp do hosta.
Lepsza konfiguracja:
services:
app:
read_only: true
security_opt:
- no-new-privileges:true
no-new-privileges
Bardzo przydatna opcja.
Blokuje zdobywanie nowych uprawnień.
Przykład:
docker run \
--security-opt=no-new-privileges:true \
app
Chroni przed:
- SUID escalation,
- zmianą uprawnień.
Docker Bench Security i CI/CD
Audyt nie powinien odbywać się dopiero na produkcji.
Lepszy proces:
Developer
↓
Build Image
↓
Security Scan
↓
Docker Bench
↓
Registry
↓
Production
Przykład pipeline:
GitHub Actions
↓
Trivy scan
↓
Docker Bench
↓
Deploy
Automatyczny audyt serwera
Dobrym rozwiązaniem jest uruchamianie audytu cyklicznie:
cron
Przykład:
0 3 * * 1 docker-bench-security.sh
Raz w tygodniu:
- sprawdzenie zmian,
- wykrycie nowych problemów.
Docker Bench Security vs skaner podatności
Częsty błąd:
Mylenie narzędzi.
Docker Bench:
sprawdza konfigurację.
Przykład:
Czy Docker działa bezpiecznie?
Trivy:
sprawdza obrazy.
Przykład:
Czy biblioteka nginx ma CVE?
Najlepiej używać razem:
Docker Bench
+
Trivy
+
Falco
+
SIEM
Przykładowy proces hardeningu Docker
Etap 1 – audyt
Uruchom:
docker-bench-security.sh
Etap 2 – poprawki
Przykłady:
- wyłącz privileged,
- dodaj seccomp,
- usuń capabilities,
- włącz AppArmor,
- ogranicz zasoby.
Etap 3 – ponowny test
Porównaj wynik:
Przed:
PASS 40
WARN 25
Po:
PASS 75
WARN 5
Praktyczna checklista Docker Security
Host
✅ aktualny kernel
✅ firewall nftables
✅ auditd
✅ journald
✅ SELinux/AppArmor
Docker Engine
✅ aktualna wersja
✅ ograniczony socket
✅ TLS gdzie wymagane
✅ user namespace
Kontenery
✅ non-root
✅ brak privileged
✅ ograniczone capabilities
✅ seccomp enabled
✅ limity CPU/RAM
Obrazy
✅ minimalne obrazy
✅ skanowanie CVE
✅ brak sekretów
✅ przypięte wersje
Podsumowanie
Docker Bench Security jest jednym z podstawowych narzędzi każdego administratora odpowiedzialnego za bezpieczeństwo kontenerów.
Nie zastępuje:
- skanerów podatności,
- monitoringu,
- systemów SIEM,
- ręcznego audytu,
ale daje bardzo dobrą bazę do sprawdzenia, czy środowisko Docker nie posiada oczywistych błędów konfiguracji.
W dojrzałej infrastrukturze powinien być elementem całego procesu:
Hardening
↓
Docker Bench Security
↓
CVE Scanning
↓
Monitoring
↓
Incident Response
Bezpieczny Docker to nie pojedyncza opcja w konfiguracji. To połączenie Linux Security, poprawnej konfiguracji kontenerów i ciągłego audytu.
Routing dynamiczny w Linuxie polega na automatycznym wymienianiu informacji o trasach między routerami w sieci, aby skonfigurować tablice routingu. Protokoły Czytaj dalej
Serwer SFTP z Ograniczonym Dostępem (chroot) – Zabezpieczenie Przed Nieautoryzowanym Dostępem SFTP (SSH File Transfer Protocol) to bezpieczny sposób transferu Czytaj dalej
