В чём преимущество Докера? если ещё больше нагружает слабенькую VPS за 2-3 доллара.
Легче устанавливается (парой команд), легко обновляется до новых версий, и в отличие от всяких мутных инсталляционных скриптов не устраивает срач в системе, и панель будет изолирована от остальной системы (лучше для безопасности).
Оверхед по производительности у докера минимальный и практически незаметный даже на слабых VPS, можно пренебречь.
В топике по ссылке выше очень неплохо расписаны преимущества.
Без докеров устанавливается одной командой install x-ui
rsync --inplace
От контейнеров мусора и неразберихи больше, чем от самого приложения.
При условии, что само приложение контейнеризации не содержит уязвимостей, а лишняя сущность эту вероятность повышает.
Можно не использовать контейнеры (я несколько раз пытался разобратся в этих диковинных технологиях, но не сдюжил и забил).
$ install x-ui
install: missing destination file operand after 'x-ui'
Try 'install --help' for more information.
$ install x-ui /opt/xui
install: cannot stat 'x-ui': No such file or directory
очень смешная шутка, спасибо.
понижает. модель швейцарского сыра, основной принцип инфобезопасности. при использовании панели сразу в системе достаточно чтобы была дыра или бэкдор в самой панели, при использовании панели в контейнере злоумышленник дальше контейнера не выберется, нужно чтобы была еще одна дыра в системе контейнеризации (читай дыра в подсистеме cgroups ядра Linux).
все понятно, сочувствую, выздоравливайте.
и теперь стало понятно, почему вы пишете такие глупости, вообще не разобравшись в теме.
Перед инсталяцией нужно скомпилировать из исходников.
А если её небыло изначально, а контейнеризатор её привнёс?
Благодарю, но от старости нет исцеления.
Не понятно о каких глупостях идёт речь, и не понятно, зачем мне разбиратся в теме, когда это создаёт лишнюю когнитивную нагрузку и можно не напрягаться не используя контейнеры.
Занавес, апплодисменты.
То атакующий не сможет ей воспользоваться. Контейнеризатор-то сам в интернет не смотрит и сетевым сервисом не является.
Как не сможет, если там вдруг RCE уязвимость, атакующий сможет использовать права приложения контейнера для манипуляций или повышения привелегий. Ещё мне не понятно, как контейнер спасёт от установки ботнета в контейнер через RCE уязвимость контейнеризуемого приложения.
где? в контейнеризаторе? так он не принимает сам по себе никаких внешних подключений по сети. вам нужна для этого еще одна дыра в самом приложении внутри контейнера, иначе ничего не выйдет. может быть уязвимость в docker-proxy, но в случае с панелями ей воспользоваться тоже не выйдет, потому что почти все панели создают контейнеры как network_mode: host и docker-proxy там в работе никак не участвует. Ну и заключение, вероятность появления уязвимости в докере на несколько порядков меньше, чем в левых панелей которые пилят три с половиной анонимных васяна.
ботнет окажется только в контейнере, а не во внешней системе, и от него будет гораздо легче избавиться.
а если это не ботнет, а что-то похуже, то он будет иметь только доступ к данным и процессам внутри контейнера, но не во всей остальной системе.
Произвольный код запустит прослушивание.
Предположим, что это истина: возьмём вероятность появления уязвимости в панели за x, получается вероятность уязвимости докера x/1000, итоговая вероятность уязвимости системы x + x/1000, а это больше чем x.
Допустим, читатель этой темы увидит словосочетание контейнер лучше для безопасности, будет использовать его, а затем через RCE злоумышленник от имени читателя оставит дискредитирующий пост или поищет материалы — лёжа на шконаре мысль о том, что избавиться от ботнета легче не будет утешать.
Как этот произвольный код окажется в процессе контейнеризатора? RCE не может произойти само по себе, этот код для исполнения должен каким-то образом быть доставлен в процесс. Например при неправильной обработке входных данных - но система контейнеризации никаких данных “снаружи” не обрабатывает.
вы упорно игнорируете тот простой факт, что для успеха подобной операции нужно чтобы уязвимость была одновременно и в приложении внутри контейнера, и в самой системе контейнеризации. при последовательных событиях вероятности не складываются, а перемножаются.
вы везде упоминаете RCE но так и не смогли написать реалистичный механизм как именно оно может произойти без уязвимости в приложении внутри контейнера.
Например, приложение контейнера обрабатывает пользовательский ввод (байты с интернетов) для передачи их во внутрь контейнера и происходит переполнение буфера/стека на странице памяти с разрешением на исполнение.
или
Написал в первом предложении. Безопасность приложения контейнера нельзя доказать.
Я вышел написал, что тут оно невозможно. Контейнеризатор просто настраивает cgroups в ядре Linux (это родной ядерный механизм), это не система виртуализации. И в случае с network_mode: host (который используется почти у всех панелей) никакие байты с интернетов он не обрабатывает, пакеты пересылаются ядром системы сразу контейнеризированному процессу без посредников.
Именно. То есть считаем приложение внутри контейнера может иметь дыру. Без контейнеризации оно автоматически имеет полный доступ к системе с правами пользователя, от которого оно запущено, а внутри контейнера оно ограничено контейнером и сможет как-то вылезти наружу только если вместе с дырой в приложении будет одновременно еще и дыра в системе контейнеризации, которая, как я уже сказал выше, является ничем иным как подсистемой cgroups в ядре Linux, которая используется еще для кучи всего другого. Ваши рассуждения есть ни что иное как “можно использовать iptables или там ufw для повышения безопасности - но ведь с самих iptables и ufw тоже могут быть баги! значит не надо их использовать”.
Я имел ввиду безопасность приложения-контейнеризатора. Ну да ладно, информации в теме достаточно, чтобы читатель выбирал между “мутным” скриптом или “прозрачным-безопасным” контейнером.
Надо, я тогда перефразирую с “никакого” на “имеет смысл использовать, если нужно решить задачи из перечисленных, а если не надо решать эти задачи, то не имеет смысла”.
@Uporoty, @Xunlei, господа, прочел вашу дискуссию. Оба ваших взгляда имеют под собой основания, но, кажется, вы говорите о немного разных вещах.
О чем еще не упомянули, так это управление ресурсами. Многие дешевые VPS продаются с fair use политикой, и постоянная загрузка CPU на 100% может привести к блокировке. Контейнеры решают эту проблему очень легко. Через cgroups можно жестко ограничить контейнер, например, в 50% одного ядра и 512 МБ ОЗУ. Docker делает это удобной оберткой, но, по сути, это нативный механизм ядра. Если не нравится Docker, никто не мешает управлять cgroups напрямую через systemd, создавая для сервиса свой slice.
Аргумент @Uporoty про удобство развертывания и отсутствия срача в системе. @Xunlei, в вашем скепсисе есть смысл, особенно когда речь идет об одном единственном сервисе. Для одного сервиса, если вам так хочется, то можно и скомпилировать, и аккуратно разложить по /opt. Но как только вам понадобится поднять рядом еще что-то, то тут и начинается прелесть декларативного подхода. У вас есть docker-compose.yml самодокументируемый файл, описывающий весь ваш стек, его сети, тома и зависимости. Это можно версионировать в Git, передавать другому человеку, и он одной командой поднимет точную копию вашего окружения. Попробуйте проделать то же самое со скриптами компиляции и развертывания, получится гораздо тяжелее.
Необязательно зацикливаться на Docker. Если главная претензия к постоянно висящему в памяти демону, работающему от root, то есть Podman. Он работает в daemon-less режиме и, что самое важное, прекрасно умеет в rootless-контейнеры. Если даже произойдет побег из контейнера, злоумышленник получит права не root на хосте, а лишь права того пользователя, от которого был запущен контейнер. При этом Podman отлично работает с синтаксисом Docker, отлично стекуется с docker-compose v2. Но и Podman не предел, кто любит другой подход, есть systemd-nspawn.
Теперь к безопасности. @Uporoty совершенно прав, говоря о модели швейцарского сыра и снижении поверхности атаки. Грамотно (бывает часто неграмотно) настроенный контейнер это дополнительный слой, который нужно преодолеть. Но и тут понятен скепсис @Xunlei, контейнер – это не магия, от всех атак и уязвимостей он не спасёт, а его неверная настройка создает лишь иллюзию защиты.
Безопасность достигается комплексно. Контейнеризация лишь один из возможных элементов. Для защиты нужны:
- Правильные права. Как в рамках классического разделения прав, так и в рамках мандатной защиты (это муторно)
- Файрвол и его тщательная настройка
- Виртуализация, как самый надежный вариант
Но если говорить о копеешной VPS, то тут слой дополнительной виртуализации не добавить.
1 Like
Кстати, 3x-ui не поддерживает rootless docker, к сожалению. По крайней мере, у меня не получилось это сделать.
так приложение-контейнеризатор всего лишь настраивает стандартные механизмы ядра Linux (cgroups и namespaces) для изоляции процессов в “контейнерах” и их ресурсов, и больше ничего в принципе и не делает. Поэтому ваши слова звучат как “безопасность ядра Linux”, а это уже совершенно отдельная тема выходящая далеко за рамки текущей дискуссии.
Из ваших слов кажется, что вы воспринимаете контейнеры типа как виртуальные машины, постоянно требующие трансляции вызовов или еще что-то подобное, а это совсем не так. Почитайте про cgroups и namespaces в ядре Linux, многое станет понятнее.
золотые слова.
Понятно, не знаю ничего о cgroups. Пока не было необходимости для изучения, если нужно будет снизить нагрузку на CPU буду читать.
если нужно будет снизить нагрузку на CPU буду читать
cgroups v2 не только про это, там сильно больше полезных вещей. Более того, раз это штатный механизм ядра, то его можно использовать без контейнеров вовсе. В systemd с ним полностью интегрирована удобная работа.
А AppArmor как работает? Я его использовал с самообучением.
А можно в дескрипторе службы настроить права куда приложение может лазить приложение? Пока мне это не удавалось настроить. (AmbientCapabilities, DeviceAllow работали, а файлы что-то нет, я и забил пока).