Rootless Docker – kontenery bez uprawnień root i nowoczesne podejście do bezpieczeństwa
Przez wiele lat Docker kojarzył się z jednym problemem bezpieczeństwa:
Daemon Dockera działa jako root, więc przejęcie kontroli nad nim może oznaczać przejęcie całego hosta.
Nie oznacza to, że Docker jest z założenia niebezpieczny. Problem wynikał z modelu działania:
Użytkownik
↓
docker CLI
↓
Docker daemon (root)
↓
Kernel Linux
↓
Host
Jeżeli użytkownik miał dostęp do grupy:
docker
otrzymywał praktycznie możliwości administratora.
Rozwiązaniem tego problemu jest Rootless Docker – tryb pracy, w którym zarówno daemon Dockera, jak i kontenery działają bez uprawnień root.
Czym jest Rootless Docker?
Rootless Docker pozwala uruchamiać kontenery jako zwykły użytkownik Linux.
Czyli zamiast:
root
↓
dockerd
↓
containers
otrzymujemy:
user
↓
rootless dockerd
↓
containers
Kontenery nadal mogą posiadać użytkownika root wewnątrz własnego namespace, ale nie jest to prawdziwy root na hoście.
Klasyczny Docker vs Rootless Docker
Standardowy Docker
Host Linux
root
|
Docker daemon
|
Container root
|
Kernel Linux
Rootless Docker
Host Linux
User account
|
Rootless Docker daemon
|
User namespace container
|
Kernel Linux
Dlaczego rootless jest ważny?
Największy problem klasycznego Dockera:
Dostęp do:
/var/run/docker.sock
oznacza komunikację z daemonem.
Przykład:
docker run -v /:/host alpine
Może dać kontenerowi dostęp do całego systemu plików hosta.
Dlatego grupa:
docker
jest traktowana praktycznie jak grupa administratorów.
Rootless Docker ogranicza ten problem.
Atakujący, który przejmie kontener, nadal musi pokonać dodatkowe bariery:
- user namespaces,
- brak realnych uprawnień root,
- ograniczenia kernela.
User Namespaces – fundament rootless
Najważniejszym mechanizmem jest:
Linux User Namespace
Pozwala mapować użytkowników wewnątrz kontenera na innych użytkowników hosta.
Przykład:
W kontenerze:
root UID 0
Na hoście:
UID 1000
Czyli:
Container root
↓
Host normal user
Sprawdzenie:
cat /proc/self/uid_map
Przykład:
0 1000 1
oznacza:
kontenerowy root = użytkownik 1000 na hoście.
Jak działa Rootless Docker od strony technicznej?
Rootless wykorzystuje kilka mechanizmów Linux:
User namespaces
Izolacja UID/GID.

RootlessKit
Warstwa umożliwiająca działanie procesów bez root.
slirp4netns
Obsługa sieci bez uprawnień administratora.
cgroups v2
Kontrola zasobów użytkownika.
Schemat:
Docker CLI
↓
rootless dockerd
↓
RootlessKit
↓
User Namespace
↓
Kernel Linux
Instalacja Rootless Docker
Najpierw zwykły użytkownik.
Sprawdzenie wymagań:
docker info
Instalacja:
dockerd-rootless-setuptool.sh install
Sprawdzenie:
docker info
Powinniśmy zobaczyć:
rootless
Rootless Docker i systemd
Rootless Docker działa jako usługa użytkownika.
Sprawdzenie:
systemctl --user status docker
Automatyczny start:
systemctl --user enable docker
Ograniczenia Rootless Docker
Rootless nie jest magicznym rozwiązaniem.
Ma kilka ograniczeń.
1. Porty poniżej 1024
Normalnie:
nginx → port 80
wymaga root.
Rootless:
80
↓
blokada
Rozwiązania:
Użycie wyższego portu:
8080
lub konfiguracja:
sysctl net.ipv4.ip_unprivileged_port_start=80
2. Wydajność sieci
Rootless często wykorzystuje:
slirp4netns
które działa w przestrzeni użytkownika.
Może być wolniejsze niż klasyczny networking Dockera.
3. Storage
Niektóre sterowniki mają ograniczenia.
Najczęściej:
overlay2
działa poprawnie przy:
- nowym kernelu,
- odpowiedniej konfiguracji.
Rootless Docker i bezpieczeństwo
Największa zaleta:
redukcja skutków przejęcia kontenera.
Przykład:
Atakujący przejmuje aplikację:
Web application
↓
Container
Klasyczny Docker:
Container root
↓
Docker daemon root
↓
Host compromise
Rootless:
Container root
↓
User namespace
↓
Normal user
↓
Host ograniczony
Rootless Docker a Docker socket
Klasyczny Docker:
/var/run/docker.sock
root:
-rw-rw---- root docker
Rootless:
socket użytkownika:
/run/user/1000/docker.sock
Dostęp ma tylko właściciel.
Rootless Docker vs Podman
Bardzo często porównuje się:
- Rootless Docker
- Podman
| Cecha | Rootless Docker | Podman |
|---|---|---|
| Daemon | Tak | Nie |
| Rootless | Tak | Tak |
| Docker CLI kompatybilność | Bardzo dobra | Dobra |
| Kubernetes | Tak | Tak |
| Bezpieczeństwo domyślne | Lepsze niż Docker root | Bardzo dobre |
Podman od początku był projektowany z myślą o modelu:
daemonless containers
Rootless Docker i Kubernetes
W Kubernetes tradycyjnie:
container runtime
↓
root privileges
ale rozwój idzie w stronę:
- rootless containers,
- user namespaces,
- sandboxing.
Mechanizmy współpracujące:
Rootless
+
Namespaces
+
cgroups v2
+
Seccomp
+
SELinux/AppArmor
Diagnostyka Rootless Docker
Sprawdzenie trybu:
docker info | grep rootless
Procesy:
ps aux | grep dockerd
Socket:
echo $DOCKER_HOST
Przykład:
unix:///run/user/1000/docker.sock
User namespaces:
lsns
Najczęstsze błędy administratorów
1. Myślenie, że rootless = pełna izolacja
Nie.
Rootless zmniejsza ryzyko, ale nadal potrzebujesz:
- aktualizacji,
- ograniczeń seccomp,
- AppArmor/SELinux,
- monitoringu.
2. Uruchamianie wszystkiego jako root w kontenerze
Nawet rootless warto stosować:
USER appuser
3. Brak limitów zasobów
Rootless nie zastępuje:
cgroups
Należy kontrolować:
- CPU,
- RAM,
- procesy.
Rootless Docker w praktyce
Dobry scenariusz:
Serwer aplikacyjny:
Ubuntu Server
↓
zwykły użytkownik
↓
Rootless Docker
↓
aplikacje webowe
↓
reverse proxy
Zyski:
- mniejszy zakres uprawnień,
- łatwiejsza separacja aplikacji,
- mniejsze ryzyko eskalacji.
Podsumowanie
Rootless Docker jest ważnym krokiem w kierunku bezpieczniejszej konteneryzacji.
Nie usuwa wszystkich zagrożeń, ale eliminuje jeden z największych problemów klasycznego modelu Dockera:
centralny daemon działający jako root.
W połączeniu z:
- Namespaces – izolacja procesów,
- cgroups v2 – kontrola zasobów,
- OverlayFS – warstwowy system plików,
- Seccomp – ograniczenie syscalli,
- AppArmor/SELinux – kontrola dostępu,
- nftables – ochrona sieci,
tworzy znacznie bardziej dojrzałą architekturę bezpieczeństwa dla współczesnych środowisk Linux i DevOps.






