LXC vs VM для докера и не только

KRom · 06.Июль.2025 23:31:48

Навеено статьей в официальной документации

Что такое LXC контейнеры (CT в терминологии PVE)

Это контейнеризация в Linux, которая работает аналогично docker, но при этом, если внутри docker контейнера по-умолчанию крутится 1 процесс, то LXC держит полноценный init (да?) c SSH и прочими ништяками, но при этом ядро ОС одно как для контейнера, так и для хоста

Что такое KVM (VM в терминологии PVE)

Это паравиртуализированная виртуальная машина, которая с точки зрения гостя является полностью независимой от хоста, может быть как linux, так и любой другой ОС и даже иметь другую архитектуру (если мы говори про qemu, естественно, в этом случае уже ни о какой паравиртуализации речи не идет)

Плюсы CT по сравнению с VM

Меньше оверхед, alpine linux прям очень легкий, сотни контейнеров тянуть проще, нежели сотни виртуалок, при этом ядро одно и переключений контекста меньше
Быстрее и проще установка, по сути, надо распаковать архив и настроить параметры (в VM частично реализуется через cloud init)
Консоль из коробки
Лучше распределение ресурсов, в чистом LXC и LXD вообще может не быть ограничений на оперативку и процессор для контейнера и он может использовать все доступные ресурсы, резервирования нет, с одной стороны это хорошо, т.к. можно больше уместить в одном сервере, с другой стороны можно словить OOM когда не ожидаешь

Плюсы VM

Выбор гостевых систем практически неограничен
Практически идеальные изоляция и функционал, т.к. нет общего ядра, оперативки, файлов.
Совместимость выше, NFS шара работает, какие-то приколюхи работают, например, у меня пока не получилось запустить podman в alpine linux внутри LXC контейнера в PVE, SSSD работает, в LXC freeIpa пользователи у меня не работали т.к ID пользователей слишком большие т.к. они транслируются в ID хоста
Безопасность выше, особенно с учетом 3 пункта, когда не все работает в непривилегированном контейнера, а перевод его в привилегированный режим рушит изоляцию и безопасность
Работают живые миграции между нодами когда без перезагрузки виртуалка переtзжает на другую ноду, у меня максимум 1 пинг терялся, в LXC миграция только с перезапуском
Работает ZFS over ISCSI - это прям крутая штука, когда NAS или SAN выдает блочное устройство, я проверил дома и отзывчивость по сравнению с ZFS over NFS на порядок выше (вот проект)

Что по хостингам

Сейчас цены выросли, а лет 10 назад многие любили продавать opvenVZ, это аналог LXC, при этом они были дешевле KVM за счет того, что можно было за счет массового обслуживания с оверсейлить ресурсы и заработать больше, например, через на 10 ГБ оперативки делится на 20 “VDSок” по 1-2-4 ГБ оперативки, но без гарантии выделеиня этих ресурсов. Но при этом, OpenVPN не поставить, какие-то сервисы, ктрубующие модули ядра не поставить и т.д. ну и постоянные ООМ
Сейчас в том числе по причинам безопасности предлагают KVM, но все равно оверсейлят, еще я подозреваю, что для KVM проще подкинуть диск

Как снизить оверхед как в LXC так и в KVM режиме

Я нашел для себя Alpine linux, (есть и другие варианты, можете накидать в комментах) раньше использовал в качестве базового образа для docker, а теперь перевел почти все LXC контейнера на него и попробовал в VM. Но там есть момент с libc, это может быть критичным.
Ну понятно, что выкидывать ненужный функционал, с влучае с Alpine выкидывать нечего, надо добавлять только нужный, в случае Ubuntu/debian я находил скрипт, который удаляет лишне и оставляет только docker
Смотреть в сторону легковесных альтернатив, например busybox заменяет кучу всего, dropbear вместо openssh и т.д. даже crond можно заменить на реализацию в busybox
Для VM можно влкючать Balloning device, это когда часть оперативки гостевой ОС раздается другим системам, можно выделить, например, от 2 до 4 ГБ оперативки и при старте будет выделяться 4, а потом при помощи этого самого воздушного шара 2 ГБ резервироваться и этот резерв переиспользоваться, при этом, если гостю надо будет больше 2ГБ и эти ресурсы будут свободные на хосте, то это резервирование уменьшается и ПО внутри гостя может использовать эту оперативку
Для VM использовать virtio и guest-agent, virtio для windows гостей дает прям большой буст производительности

Что я выбирают для себя

У мня дома более 50 CT и VM на мини ПК, я использую подход Application Containers, но Proxmox это не рекомендуют, они за System Containers и VM
Если есть неограниченные ресурсы и время на разворачивание, то однозначно VM, но даже если не заморачиваться с автоустановкой и провижинингом, то LXC развернуть пару минут надо, а VM чуть подольше
Если не создавать под каждое приложение LXC контейнер, а по виртуалке на ноде и там развернуть K8S или его аналоги, то тоже лучше VM
Очень не люблю расширять хост PVE, видел статьи где docker ставится на PVE и потом все крутиться там, но это дичь полная, удивляюсь, что PVE это позволяет, вот Truenas отключили apt и рады

Выводы

Пользуйте в качестве выводов предыдущий параграф, а если не согласны или хочется дополнить, то прошу высказать свои мысли в комментариях.

KRom · 23.Сентябрь.2025 21:47:36

Еще раз попробую объяснить

Если у вас дикий энтерпрайз, а именно

Выделяются деньги на железо и софт
Выделяются деньги на штат специалистов
Имеются повышенные требования к безопасности
Стоимость минуты простоя очень высокая
Требуется максимальная совместимость

То однозначно следует выбирать VM т.к. она позволяет

Максимально качественно разделить хост и гостевое окружение на уровне ядра, процессов, памяти (в том числе)
Обеспечить паравиртуализацию ресурсов на уровне гипервизора
Иметь возможность мигрировать виртуалки с машины на машину без даунтайма за счет копирования содержимого оперативной памяти
Устанавливать необходимые модули ядра, монтировать SMB и NFS шары, менять ядро, тюнить его, например, менять планировщик
Резервировать ресурсы (CPU и RAM) под виртуалку (на самом деле, переиспользование незанятой оперативки это целый механизм драйверов гостевой системы)
Устанавливать различные версии ядра и вообще операционки, например, совмещать windows и linux
Настраивать сетевые интерфейсы внутри виртуальной машины
Передавать специфичные устройства типа TPU чипов, UEFI,

Если у вас самохостинг и

Какой-нить мини ПК, списанный сервак или мащинист на Z99
На приказ ФСТЭК №21, оценка безопасности КИИ и ГОСТ Р ИСО/МЭК 27001-2021 у вас только одна реакция
Вы играючи монтируется папки с хоста PVE в ваши контейнеры
Быстроподнятое упавшим не считается, а если не быстроподнятое, то можно словить"опять у тебя ничего не работает!" из соседней комнаты
Вы даже не знаете какой дистрибутив развернут в LXC контейнере с immich т.к. он создавался автоматически хелпер скриптом
У вас нет 6 млн рублей на покупку видеокарты с аппаратной виртуализацией и возможностью независимого проброса в виртуалки

То LXC будет однозначно предпочтительней т.к.

Выдает минимальный оверхед
Быстрее создается
Быстрее запускается

За счет того, что LXC в отиличе от KVM

Использует одно ядро ОС
Использует общий файловый буфер
Использует общие файлы и процессы, изоляция производится при помощи механизма cgroups, как и в docker, между прочим
Ограничение доступных ресурсов RAM и CPU является скорее дополнительным функционалом (в PVE обязателен, а вот в чистом LXC/LXD при создании контейнера не требует указания RAM и CPU и даже диска т.к. может использовать общую ФС (тут у меня был прикол, когда 10 lxc контейнеров с docker исчерпали лимиты по inode хостовой файловой системы)
Создает контейнер из шаблона без фактической установки операционной системы, поэтому и нет cloudinit для CT
За счет пункта 3 я, например, пробросил в CT USB принтеры просто на уровне USB шины

И отличие при работе с устройствами, например, вы пробрасываете видеокарту в гостевую систему, то

В qemu/KVM (VM) - устройство или полностью, если не умеет, или частично, если имеет соответствущие аппаратные возможности (например, для CPU это AMD-V и VTx, которые должны быть в процессоре и включены в BIOS) убираются из хоста и передаются в бинарном виде в гостевую систему, а гостевая система при помощи драйверов работает с этим устройством
В LXC (CT) - процессам в группе процессов, в простонародье называемыми LXC контейнером предоставляется доступ к логическому устройству (например видеокодер /dev/dri/renderD128), при этом само устройство обслуживаеся драйверами, находящимися в ядре хоста (а ядро то и там всего одно)

Например
Alpine linux в CT ходит за информацией не туда, куда следует и команда top показывает количество CPU и RAM хоста, а не те значения, которые вы указали в настройках контейнера

vk_hlab · 24.Сентябрь.2025 03:17:21

Возникает вопрос : а зачем тогда вообще proxmox такому пользователю, который не знает какая выбрана в LXC, когда с некоторых пор есть truenas с магазином приложений и их установке “по кнопке”? Думаю там вопрос шаринга видео также не заботит пользователя…

vk_hlab · 24.Сентябрь.2025 03:22:42

А можно подробнее…у интела то же есть такая технология..кажется iGPU-g до 11й версии проца…

Получается, что проще купить проц, чем костылить бытовые дискретные видюхи mvidia…

dr0n1k · 24.Сентябрь.2025 06:28:46

AMD-V и VTx - это инструкции процессоров для работы с виртуализацией, а вы говорите про iGPU - это интегрированный графический чип в процессор. Это абсолютно разные вещи. И да - для получения возможности транскодирования на том же самом jellyfin - покупать специально для это отдельно видео карточку не обязательно, встроенное видео ядро от интел достаточно не плохо справляется с этими задачами.

Конечно если у вас стоят задачи куда выше уровнем, чем просто просмотр видео, то тут уже не обойтись без дискретной карты.

KRom · 24.Сентябрь.2025 06:42:01

И и наблюдаю тенденцию к переходу на truenas apps

Тем более, что 25 версия очень сильно прокачалась в плане приложений, а в плане высокой дисковой нагрузки в этих приложениях такой метод установки является самым эффективным

vk_hlab · 24.Сентябрь.2025 07:20:08

Меня примерно год назад, попробовав truenas only смутило:

Куча каких то юзеров с какими то правами и еще надо создавать юзеров…не разобраться…в каком месте дырки в безопасности
Очень круто они поступали с сообществом… Был кубернетис…нахрен, были какие то приложерия от сообщества…при обновлении версии вообще могут больше ее работать…хотя может сейчас все стабилировалось…развернул себе truenas изначально в proxmox.. И думаю - а зачем мне трунас нужен? Кроме как “гляделка за zfs”? А теперь вот думаю, что не зря пробросил в него родные материнке sata…теперь видюху прокинуь …и уже тупо в трунасе навертеть сервисы, которые требуют видюхи…

KRom · 24.Сентябрь.2025 07:27:29

Вот тут не понял ничего

Да, их колбасит нехило так и это еще не конец, контейнеры у них с пометкой experimental.

Я пробовал их куберовские приложения когда они k3s крутили локально. Конфигурация приложений от слова оверинжинеринг, деплоятся приложения целую вечность, свои приложения не поставить, в итоге они приняли правильное решение, что перешли на docker-compose здорового человека, но не допилили их до конца.

Подобную ситуацию можно понять и простить если это был пет проект, но для вполне себе коммерческого продукта как минимум странно.

Ну мне нравится

Удобное управление пулами и датасетами
Управление сетевыми шарами
Настройки создания снепшотов, сетевых синхронизаций
Мониторинг именно дисков, сети и прочего в режиме реального времени и в разрезе NAS

vk_hlab · 24.Сентябрь.2025 07:29:28

Имел ввиду GVT-g:

.Intel GVT-g is a full GPU virtualization solution with mediated pass-through (VFIO mediated device framework based), starting from 5th generation Intel Core™ processors with Intel Graphics processors. GVT-g supports both Xen and KVM (a.k.a XenGT & a.k.a KVMGT). A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned…For client platforms, 5th, 6th, 7th, 8th or 7th SoC Generation IntelÂ® Core Processor Graphics is required.

For server platforms, E3_v4, E3_v5 or E3_v6 Xeon Processor Graphics is required.

KRom · 24.Сентябрь.2025 07:38:27

Это уже скорее в ветку по выбору GPU

Идея интересная, но меня смущает 2 момента

я не знал, что есть зеоны с gpu, подозреваю, что найти их очень сложно и стоят неоправданно дорого
Вот это

DISCONTINUATION OF PROJECT

This project will no longer be maintained by Intel.
This project has been identified as having known security escapes.
Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.
Intel no longer accepts patches to this project.

В общем, опять 25, как всегда и да сколько же можно. Очередная попрытка виртуализировать GPU провалилась

vk_hlab · 24.Сентябрь.2025 08:02:20

Зеоны бу есть и их много и они не дорогие. Но видео ядро там несколько усеченное…я не зеоны имел ввижу уже

А так да, бросили Интел эту технологию, только не копал почему, вы нашли…
С другой стороны покодения еще не старые, а в части цены, так бу даже дешевле но это уже буду уточнять в ветке прл cpu

KRom · 24.Сентябрь.2025 08:50:25

Предлагаю перевести обсуждение GPU в эту тему

Так как оно выходит за рамки данной темы

Rid-lin · 27.Сентябрь.2025 10:51:01

Кстати, для себя открыл давно DietPi на основе Debian, её можно на x86 запускать. Довольно маленькая ОС с небольшими и удобными TUI-скриптами, типа монтирования дисков, управления процессами, встроенным бекапом(через rsync), установкой/удалением ПО. Хранит почти все настройки установленного через её скрипты ПО в одной папке. Недавно переезжал с Hyper-V на Proxmox и миграция заключалась в “скопировать эту папку, после того как установил всё ПО которое было”.

KRom · 06.Октябрь.2025 08:16:51

Еще видео в тему

KRom · 17.Октябрь.2025 12:36:15

А теперь разоблачение года

Миф №0: Матрешка вида PVE → LXC → Docker дает потерю производительности и виртуализацию внутри виртуализации

Нет смысла делать контейнер в контейнере в контейнере… и запускать докер внутри LXC т.к. это увеличивает накладные расходы и дублирует функциональность.

Разоблачение: Что LXC, что Docker под linux используют механизм cgroups/cgroups2, который позволяет изолировать процессы на на уровне ядра операционной системы

Для примера возьмем PVE 9 с LXC контейнером на основе alpine и 3 Docker сервисами

Не знаю, зачем я включал там fuse, возможно для overlayfs, но есть nesting, который означает, что используется вложенность

Заходим в контейнер

vaultwarden:~# docker compose ls
NAME                STATUS              CONFIG FILES
komodo              running(1)          /srv/komodo/compose.yaml
vw                  running(2)          /srv/vw/compose.yaml

vaultwarden:~# docker ps
CONTAINER ID   IMAGE                                      COMMAND                  CREATED       STATUS                PORTS                                                                                  NAMES
5e733ff0019c   ghcr.io/moghtech/komodo-periphery:latest   "periphery"              2 weeks ago   Up 6 days             0.0.0.0:8120->8120/tcp, [::]:8120->8120/tcp                                            komodo-periphery-1
488bebf5e6bc   vaultwarden/server:latest-alpine           "/start.sh"              5 weeks ago   Up 6 days (healthy)   0.0.0.0:3012->3012/tcp, [::]:3012->3012/tcp, 0.0.0.0:8884->80/tcp, [::]:8884->80/tcp   vaultwarden
1a41d9d1b566   ghcr.io/openbao/openbao:latest             "docker-entrypoint.s…"   5 weeks ago   Up 6 days             8200/tcp                                                                               vw-vault-agent-1
vaultwarden:~#

и видим, что там запущено 2 стека и docker контейнера

Теперь переходим на хост Proxmox и вводим команду systemd-cgls -c /lxc/150

root@pve-01:~# systemd-cgls -c /lxc/150
CGroup /lxc/150:
└─ns (#7570)
  ├─   1825 /sbin/init
  ├─   3511 /sbin/getty 38400 console
  ├─   3513 /bin/login -- кщще
  ├─   3514 /sbin/getty 38400 tty2
  ├─3831564 -sh
  ├─openrc.syslog (#8396)
  │ └─3414 /sbin/syslogd -t -n
  ├─openrc.dropbear (#8414)
  │ └─3470 /usr/sbin/dropbear
  ├─docker (#8655)
  │ ├─5e733ff0019c24245e762694f4cdd446da476905e3eb98657b0639892b2693cd (#8691)
  │ │ └─4775 periphery
  │ ├─488bebf5e6bc9acd213be890ee2f0efe7c18ccd96cf658d0b12297f6e791fe82 (#8673)
  │ │ └─4771 /vaultwarden
  │ └─1a41d9d1b566ad4e8ce50a44fe740e944ae23e1ed6c0d479603339222ec4a854 (#8709)
  │   ├─4773 /usr/bin/dumb-init /bin/sh /usr/local/bin/docker-entrypoint.sh agent -config=/etc/vault/agent-config.hcl
  │   └─4980 bao agent -config=/etc/vault/agent-config.hcl
  ├─openrc.docker (#8378)
  │ ├─3351 supervise-daemon docker --start --retry TERM/60/KILL/10 --stdout-logger log_proxy -m /var/log/docker.log --stderr-logger log_proxy -m /var/log/docker.log --respawn-delay 2 --respawn-max 5 --respawn-period 180>
  │ ├─3352 /usr/bin/dockerd
  │ ├─3373 log_proxy -m /var/log/docker.log
  │ ├─3374 log_proxy -m /var/log/docker.log
  │ ├─3647 containerd --config /var/run/docker/containerd/containerd.toml
  │ ├─4659 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 1a41d9d1b566ad4e8ce50a44fe740e944ae23e1ed6c0d479603339222ec4a854 -address /var/run/docker/containerd/containerd.sock
  │ ├─4660 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 5e733ff0019c24245e762694f4cdd446da476905e3eb98657b0639892b2693cd -address /var/run/docker/containerd/containerd.sock
  │ ├─4662 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 488bebf5e6bc9acd213be890ee2f0efe7c18ccd96cf658d0b12297f6e791fe82 -address /var/run/docker/containerd/containerd.sock
  │ ├─4899 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8884 -container-ip 172.18.0.2 -container-port 80 -use-listen-fd
  │ ├─4916 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 8884 -container-ip 172.18.0.2 -container-port 80 -use-listen-fd
  │ ├─4922 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3012 -container-ip 172.18.0.2 -container-port 3012 -use-listen-fd
  │ ├─4927 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 3012 -container-ip 172.18.0.2 -container-port 3012 -use-listen-fd
  │ ├─4956 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8120 -container-ip 172.19.0.2 -container-port 8120 -use-listen-fd
  │ └─4963 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 8120 -container-ip 172.19.0.2 -container-port 8120 -use-listen-fd
  ├─openrc.crond (#8432)
  │ └─3504 /usr/sbin/crond -c /etc/crontabs -f
  └─openrc.networking (#7922)
    └─2372 /sbin/udhcpc -b -R -p /var/run/udhcpc.eth0.pid -i eth0 -x hostname:vaultwarden

Что мы тут видим?

PVE создал группу /lxc для контейнеров
В нее положил группу 150 с номером CT (и неймспейс 7570)
Там запущен init в качестве родителя всех процессов (в linux должен быть родительский процесс)
Там же запущен docker через openrc
Docker создал 3 группы для каждого контейнера и внутри запустил по init процессу docker (#8655), тоже имеет свой неймспейс но не обображается утилитой

Если кратко, то мы имеем следующую иерархию

Host Kernel
└── cgroup / namespaces (LXC)
    ├── init, getty, openrc...
    └── cgroup / namespaces (Docker)
        ├── vaultwarden
        ├── periphery
        └── bao agent

Ну и выполним еще одну команду на хосте

root@pve-01:~# ps -p 881,3470,4771 -o pid,ppid,user,cmd
    PID    PPID USER     CMD
    881       1 root     sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
   3470    1825 100000   /usr/sbin/dropbear
   4771    4662 100000   /vaultwarden

Мы видим тут следующее

ssh от рута на хосте (через который я сейчас и зпускаю данную команду)
ssh сервер dropbear внутри LXC контейнера. Он запущен от рута в контейнере, на хосте для безопасности к ID пользователя прибавляется 100000, таким образом, процесс, запущенный от root внутри контейнера на хосте является обычным пользователем и не обладает расширенными правами
vaultvarden внутри docker контейнера, который запущен тоже под рутом, поэтому и рекомендуется указывать user: UID:GID в докере, чтобы ограничить права процесса

Что мы из этого поняли?

LXC → Docker не порождает вложенную контейнеризацию и тем более, виртуализацию, не добавляет накладных расходов, Это только способ упорядочивания процессов и ресурсов, точно также как мы создаем каталоги в файловой системе или пользовуем docker-compose в место docker run

Единственное, что мы тут имеем из накладного это вложенность файловых систем и независимые слои docker образов. Это значит, что docker pull в отдельных контейнерах будет скачивать образы каждый раз, а docker compose pull будет использовать общий набор слоев для всех стеков и условная ubuntu, использованная в качестве базового образа будет скачана 1 раз для всех контейнеров, которые запускаются на внутри текущего LXC контейнера

На уровне ядра операционной системы эти процессы будут работать как обычные процессы, просто им будут доступны различные ресурсы и возможности

Ну и напоследок, чтобы совсем взорвать мозг зуммерам

Если в Docker в качестве entrypoint указать /sbin/init, предварительно сложив нужные файлы внутрь docker образа, то мы получим практическу полноценную “операционную систему” внутри докера, с ssh, и кучей сервисов, т.е. вместо кучи контейнеров можно в одном запустить и postgresql и redis и nginx и crond и свои сервисы, которые будут работать со всем этим.

Vovec · 18.Октябрь.2025 09:13:41

Большое спасибо, что поделились с нами своим опытом, исследованием и выводами. Тема интересная и полезная.

А можно какую-нибудь толковую ссылку или фразу для гугления, чтобы поподробнее почитать про этот момент? Это ваше сообщение по данному вопросу читал.

KRom · 18.Октябрь.2025 13:04:20

Не знаю прям такие, чтоб в одном месте, но вот попросил ChatGPT кратко расписать (с толковым промптом)

Развернуть

Зачем задают пользователя в Docker

По умолчанию процессы в контейнере запускаются от root. Это удобно, но небезопасно. Задание пользователя помогает:

Плюсы:

Безопасность: ограничиваем права процесса, чтобы при взломе контейнера злоумышленник не получил root-доступ на хосте.
Совместимость с томами: UID/GID пользователя в контейнере можно подстроить под хостовые права на volume.
Контроль файлов: процессы создают файлы с правильным владельцем.

Минусы:

Некоторые приложения требуют root (например, чтобы слушать порты <1024, монтировать устройства, устанавливать пакеты).
Нужно правильно настроить права на тома и папки внутри контейнера.

Если пользователь не задан

По умолчанию процесс запускается от root (UID=0).
Все права на файлы и порты по умолчанию root.

Как задать пользователя

В Dockerfile

# создаём пользователя
RUN useradd -m myuser
USER myuser

или с конкретным UID/GID:

RUN groupadd -g 1001 app && useradd -r -u 1001 -g app app
USER app

В `docker run`

docker run -u 1001:1001 myimage

или по имени:

docker run --user app myimage

В Docker Compose

services:
  app:
    image: myimage
    user: "1001:1001"

Особенности работы с volume

Если контейнер работает не от root, он может не иметь прав на чтение/запись в volume.
Можно заранее поменять права на папки на хосте:

chown -R 1001:1001 /path/to/volume

или монтировать volume с правильными правами.

Порты <1024 (например, 80, 443)

Только root может слушать порты ниже 1024.
Если пользователь не root, придётся:
- Использовать порты >1024 внутри контейнера и проброс -p 8080:80.
- Использовать CAP_NET_BIND_SERVICE через --cap-add=NET_BIND_SERVICE.
- Или запускать процесс через root, а затем drop privileges к обычному пользователю.

В итоге получаем, что задание пользователя в докере является одним из обязательным шагом харденинга, с другой стороны имеет ряд неудобств, с которыми надо будет мириться

Часто контейнер не может писать в волюм и надо руками создать его и прописать соответствуюие права
В vault-agent используется пользователь и у меня вечно проблемы с тем, что он не может сохранить файл с переменными окружения
В этом же vault-agent прокидываю /var/run/docker.sock, чтобы можно было пинать сервис при обновлении сертификато и пишет, что нет доступа, в итоге приходится запускать vault-agent с GID докера

Но зато, злоумышленник, который взломает ваш сервис не сможет

Установить доп пакеты и ПО
При наличии проброшенной корневой ФС -v /:/host не будет полного доступа от имени рута
Мутить всякие мутки с системой типа дебага хостовых процессов, и изменения ФС (тут мы уже погражаемся в дебри харденинга докера)

Vovec · 18.Октябрь.2025 19:26:30

Спасибо. Основной смысл ясен. Далее можно уже с конкретными интересующими контейнерами разбираться. Как всегда - нет предела совершенству

KRom · 09.Ноябрь.2025 19:08:12

Вылезла следующая проблема

По ней, ожидаемо, заведен баг

Как оказалось, обсуждение данной проблемы тянется еще с 22 года и если перевести с немецкого на английский а с английского на русский, то получим следующее:

Если вы хотите запускать контейнеры приложений, например, образы Docker, рекомендуется запускать их внутри виртуальной машины Proxmox QEMU. Это позволит вам воспользоваться всеми преимуществами контейнеризации приложений, а также преимуществами виртуальных машин, такими как строгая изоляция от хоста и возможность живой миграции, что в противном случае было бы невозможно при использовании контейнеров.

И далее идет ссылка на wiki, которую я привел в первой стройке данной темы (круг замкнулся), финита ля комедия.

KRom · 18.Ноябрь.2025 19:37:47

В новом PVE LXC контейнеры стали еще ближе к докеру

Теперь можно задавать через интерфейс запускаемый процесс и переменные окружения, что является прямым аналогом соответствующих команд в Docker