Kontener rootless
Kontener działający bez uprawnień roota — ani środowisko uruchomieniowe, ani proces w środku nie musi być rootem na hoście. Zamyka poważną lukę: atakujący, który wydostanie się z kontenera rootless, ląduje jako zwykły użytkownik, a nie root.
Problem: tradycyjnie Docker działał jako demon roota, więc kontener, który „wyrwał się” (container escape), mógł zdobyć roota na hoście — katastrofa. Rootless rozwiązuje to przez user namespaces: root kontenera (UID 0 w środku) jest mapowany na zwykły, nieuprzywilejowany UID na hoście, więc nawet pełny root w środku jest nieszkodliwy na zewnątrz. Pionierem był Podman (bez demona i domyślnie rootless); Docker i containerd mają także tryby rootless. Pokrewna, ale odrębna sprawa: uruchamianie procesu w kontenerze jako nie-root (linia USER w Dockerfile), czego wymaga standard „Restricted” w Pod Security Standards. Zysk: radykalnie mniejsze skutki ucieczki z kontenera i możliwość uruchamiania kontenerów przez programistów bez sudo. Koszt: niektóre funkcje (porty uprzywilejowane, pewne montowania) wymagają dodatkowej konfiguracji. Podstawowa zasada utwardzania. Spokrewnione z pod security standards i przestrzeniami nazw (Linux).