Що таке rootless Docker і userns-remap і коли вони потрібні?

У звичайній конфігурації демон Docker працює від root, і root усередині контейнера - це root ядра (UID 0). Вихід з контейнера через вразливість чи помилку конфігурації дає права root на хості. Два механізми зменшують цей ризик.

1. User namespace remapping (userns-remap) - демон лишається від root, але користувачі контейнера відображаються на непривілейований діапазон UID хоста:

// /etc/docker/daemon.json
{ "userns-remap": "default" }

Root (UID 0) у контейнері насправді є, наприклад, UID 100000 на хості. Якщо процес вирветься з контейнера, на хості він - звичайний користувач без прав.

2. Rootless mode - і демон, і контейнери працюють від звичайного користувача:

• демон не має прав root узагалі - вразливість у самому демоні не дає root на хості;
• доступ до сокета Docker дає лише права цього користувача (а не «фактично root», як у звичайному режимі);
• кожен користувач може мати власний Docker.

Обмеження й компроміси:

• порти нижче 1024 без додаткового налаштування недоступні (net.ipv4.ip_unprivileged_port_start);
• мережа реалізована в просторі користувача - продуктивність нижча, а справжня адреса клієнта може бути недоступна без додаткового налаштування;
• обмеження ресурсів через cgroups потребують cgroup v2 і делегування;
• деякі драйвери сховища й можливості недоступні;
• права на bind mount: файли, створені в контейнері, на хості належать відображеним UID - треба розуміти відображення, щоб не отримати «чужі» файли;
• з userns-remap деякі опції (--privileged, спільні простори імен з хостом) не працюють чи потребують вимкнення відображення для конкретного контейнера.

Альтернатива - Podman: працює без демона і за замовчуванням без root; CLI сумісний з Docker.

Коли варто:

• багатокористувацькі сервери й CI, де контейнери запускають люди чи процеси з різним рівнем довіри;
• посилена безпека продакшен-хостів, де можна прийняти обмеження;
• для локальної розробки rootless зазвичай зайвий, а Docker Desktop і так ізолює контейнери у віртуальній машині.

Незалежно від режиму USER в образі (непривілейований користувач усередині контейнера) - базова практика.

Докладніше в документації: Режим rootless