LINUX.ORG.RU
ФорумAdmin

Обсуждается переработка механизма перенаправления портов в Docker-контейнеры

 , ,


0

3

Docker на сегодняшний день является одним из наиболее популярных движков для запуска контейнеров. Запущенные контейнеры получают частные IP-адреса, на которые Docker автоматически перенаправляет входящие соединения по настроенным портам.

Однако, есть один плохо документированный пробел в безопасности: проброшенные в контейнеры порты необходимо защищать брандмауэром не так, как порты, прослушиваемые приложениями, запущенными непосредственно на хостовой системе. Как следствие, оболочки над iptables, такие как ufw и firewalld, оказываются неэффективными и пропускают входящие соединения, которые они вроде бы настроены блокировать.

Этот пробел был заявлен как баг в Docker по меньшей мере 10 раз. Поскольку проблема возникает на стыке двух подсистем, однозначно классифицировать ее как баг в Docker было бы априори несправедливо, и есть пользователи, которые по этому поводу отправляли отчеты об ошибке не разработчикам Docker, а разработчикам firewalld и других аналогичных программ для организации сетевого экрана.

Корень проблемы в том, что пакеты, перенаправляемые средствами iptables в контейнер через DNAT, проходят через цепочку FORWARD, а не INPUT, как того ожидают наивные пользователи, ufw и firewalld.

Разработчики Docker признали проблему своей и сейчас обсуждают отказ от использования iptables-цели DNAT для проброса портов в контейнеры. В качестве альтернативы предлагается IPVS, поскольку обрабатываемые им пакеты проходят через цепочку INPUT так, как они проходили бы для запущенных непосредственно на хосте приложений. Тем самым, ufw и firewalld станут работоспособны на системах с контейнерами.

Параллельно обсуждается небезопасное поведение по умолчанию, когда порт, проброшенный через -p 1234:1234, оказывается доступным извне, тогда как в большинстве случаев пользователи имели в виду доступ только с локальной машины. Ситуацию усугубляет то, что в различных руководствах для портов, которые должны быть доступны только с локальной машины, используется небезопасный синтаксис -p 1234:1234 вместо безопасного -p 127.0.0.1:1234:1234.

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

Подробности

Перемещено hobbit из security

★★★★★

Последнее исправление: AEP (всего исправлений: 2)

Корень проблемы в том, что пакеты, перенаправляемые средствами iptables в контейнер через DNAT, проходят через цепочку FORWARD, а не INPUT, как того ожидают наивные пользователи, ufw и firewalld.

ИМХО не совсем точно написано, как будто проблема как-то связана с DNAT. Проблема же не в DNAT, а в том что у контейнера свой интерфейс, поэтому и FORWARD, а не INPUT.

Eshkin_kot ★★
()

И вот все так с этой контейнеризацией. Вы либо пургу в глаза про изоляцию снимите, либо SLIRP наденьте =P

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Вы либо пургу в глаза про изоляцию снимите

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

uwuwuu
()
Ответ на: комментарий от uwuwuu

повторюсь, как в каждом треде про Nix… контейнеры — цирк про якобы безопасность и удобство, на фоне полной импотенции пакетных менеджеров из прошлого века. а юзали бы ну хоть капельку пристойные, не надо было бы городить огород. а вот этот весь мямлинг про якобы удобство таскания за собой целых чрутов — это лишь отчаяние и стокгольмский синдром.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

якобы безопасность и удобство

а чем неудобно? при переезде на новый сервер скопировал конфиги и папочки в которых база лежит, сделал docker-compose up -d, и все работает. безопасность - это какая-то шиза от маркетолухов. оно и дураку должно быть понятно, что докер от такого или такого не защитит

uwuwuu
()
Ответ на: комментарий от uwuwuu

Если для запуска софтинки тебе нужен бонусный дистр, ты проиграл в распространение софта, точка. Надо просто чтобы любой софт запускался, не мешая любому другому софту, а все эти чруты и пробросы это припарки к месту самопрострела стопы.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Например, у тебя есть приложение на python, где в зависимостях пару библиотек, которые для компиляции требуют системные зависимости не ниже M и не старше N версии. Таких либ на самом деле много. Даже postgres возьмем, любую либу для работы с ним на Python, она будет требовать пакет типа postgresql-dev… Не только пистон умеет «прозрачно» использовать системные либы, но и Node.js, PHP, Go… Никто не реализует какое-нибудь AES шифрование нативно и тп. Можно взять в докер и запихнуть идеальную сборку, а можно… пытаться запихнуть невпихуемое, установить неустанавливаемое, компилить исходники, создавать линки на govno.so с именами govno6.0.so, так как пакет требует… нет - это путь в никуда и спор ни о чем, и винить разрабов которым проще docker-релиз выкатить чем твои тикеты читать о том что у тебя в слаке «караул не работает»… А уж как на работе раньше было, когда тебе дают какую-то дрисню на Perl с кучей каких-то переменных окружения, отсутствием документации, и говорят разверни и исправь какой-то баг, потому что перловик себе голову сломал и в реанимации, а там нужно пару строчек заменить и пох, что ты на нем никогда не писал. Вот у тебя бы наверное счастье было трахаться с установков пакетов на твой рабочий комп, которые в твоем дистре все абсолютно иначе называются, не говоря уже что то дерьмо писали 20 лет назад, и оно запускается на древнем дебиане

uwuwuu
()
Ответ на: комментарий от t184256

В Nix разные версии библиотек лежат в разных каталогах, в Docker разные версии библиотек лежат в разных контейнерах которые по сути те же каталоги в ФС и в чём принципиальная разница?

Зато с Docker не надо городить свою систему конфигурирования и сборки.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

А если купить пять разных компов, то можно библиотеки по пяти разным компам разложить, будет еще тупее и неудобнее.

t184256 ★★★★★
()

Корень проблемы в том

что

наивные пользователи

и это конечно баг Docker

anc ★★★★★
()

Невероятно…. И десяти лет не прошло…

Tsukasa
()

вот когда они перестанут всё ломать - можно будет начать присматриваться

Shushundr ★★★
()

Хорошо, если исправят. До сих пор никто не умеет настраивать эти фаерволы с докером. Хорошо, если в облаке есть внешний фаервол. А если нет - так и торчат базы. Посканируйте интернет на предмет :5432, ужаснитесь.

vbr ★★★★
()
Ответ на: комментарий от emorozov

Блажен кто верует. Большие дяди может и не разворачивают, а так - много кто разворачивает.

vbr ★★★★
()
Ответ на: комментарий от vbr

До сих пор никто не умеет настраивать эти фаерволы с докером.

И от того, что исправят «все сразу научатся» ? Вот внесут они изменения, и у тех у кого все было давно настроено и работало внезапно поломается, получат ещё 100500 сообщений вида «у меня все работало, а после обновления поломалось».

anc ★★★★★
()
Ответ на: комментарий от anc

Та оно и так регулярно ломается, как и всё остальное. Не так давно, при переходе на последнюю версию Docker, контейнеры с MySQL начинали отжирать всю свободную память, пока их не прибивал OOM killer. Если при этом не стояло restart: no, то процесс запускался заново, и надо было как-то успеть на фактически полуживой системе прибить контейнер из консоли.

Ошибка была то ли в докере, то ли в последней версии go. Гипотез в баге было много, мне не хватило времени и знаний докопаться, главное, что через 20 итераций я нашёл работающий костыль для обхода этого бага.

emorozov
()

Корень проблемы в том, что пакеты, перенаправляемые средствами iptables в контейнер через DNAT, проходят через цепочку FORWARD, а не INPUT, как того ожидают наивные пользователи, ufw и firewalld.

ну тоесть проблема не в docker и iptables, а в пользователях uwf и firewalld которые packet flow не знают

Kolins ★★★★
()
Ответ на: комментарий от anc

И от того, что исправят «все сразу научатся» ?

А что тут учиться? Стандартным образом порты закрывать все умеют. А для докера до сих пор нет ни одного туториала, я так подозреваю. По крайней мере в последний раз я потратил несколько дней, чтобы разобраться и готовых рецептов не нашёл. Причём даже мой способ получился не слишком универсальным.

Вот внесут они изменения, и у тех у кого все было давно настроено и работало внезапно поломается, получат ещё 100500 сообщений вида «у меня все работало, а после обновления поломалось».

Ну и ладно. Если сделали криво с первого раза, надо исправлять, а не тянуть кривое решение до конца времён.

vbr ★★★★
()
Ответ на: комментарий от emorozov

Ну одно дело это баг, другое дело целенаправленная поломка из-за «наивных пользователей», завтра эти «наивные» ещё чего-то не осилят, так и будут ломать ради наивных?

anc ★★★★★
()
Ответ на: комментарий от emorozov

Базы еще туда-сюда (хотя стартаперам здравый смысл не указ), а вот редисов в интернет торчит хренова гора. Из-за этих слабоумных авторы редиса даже запилили дебильный protected mode по дефолту, в котором оно не принимает команды при коннекте не с локалхоста.

leave ★★★★★
()
Ответ на: комментарий от vbr

А для докера до сих пор нет ни одного туториала, я так подозреваю.

Есть, называется iptables tutorial.

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

По вашему мнению предлагаемые в топике изменения резко родят готовые рецепты?

Если сделали криво с первого раза, надо исправлять, а не тянуть кривое решение до конца времён.

Нормально они сделали, а вот поменять собираются на «криво».

anc ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.